From dime-bounces@ietf.org Sun Dec 02 12:58:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyt50-0004Em-CL; Sun, 02 Dec 2007 12:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iyt4y-0004ET-NN for dime@ietf.org; Sun, 02 Dec 2007 12:58:08 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iyt4w-00088p-HX for dime@ietf.org; Sun, 02 Dec 2007 12:58:08 -0500 Received: (qmail invoked by alias); 02 Dec 2007 17:51:24 -0000 Received: from unknown (EHLO [204.244.76.141]) [204.244.76.141] by mail.gmx.net (mp005) with SMTP; 02 Dec 2007 18:51:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+GWYEEK9aGeZ9N0UeQ6U/qGeNJF4y3fQWz6pOZez 8aTO9aAMwfW4gH Message-ID: <4752F09C.1020600@gmx.net> Date: Sun, 02 Dec 2007 18:51:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org, keyprov@ietf.org, ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [Dime] Slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We wouldn't be angry if speakers could send us their slides already before the meeting starts. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 03 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4tN-0004DY-OH; Mon, 03 Dec 2007 01:34:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz4tM-0004DL-DS for DiME@ietf.org; Mon, 03 Dec 2007 01:34:56 -0500 Received: from chn-hclin-gws02.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz4tI-0007an-Sg for DiME@ietf.org; Mon, 03 Dec 2007 01:34:56 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 6F8373670F1 for ; Mon, 3 Dec 2007 12:04:49 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id 642C5364074for ; Mon, 3 Dec 2007 12:04:49 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 12:04:48 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Dec 2007 12:04:09 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC603013F64@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding "Change in rating contition" Thread-Index: Acg1doKLMLfMmPJqS7+l+a62Twsn5A== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 03 Dec 2007 06:34:48.0945 (UTC) FILETIME=[9A322610:01C83576] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-11.9452 TC:1F TRN:39 TV:5.0.1023(15582.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.4 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Subject: [Dime] Clarification regarding "Change in rating contition" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1363183069==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1363183069== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83576.82D2B900" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83576.82D2B900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I need one clarification on Credit control client fsm in RFC4006=2E The Fsm has one event named "Change in rating condition"=2E What is the difference between Tariff-Change and "Change in rating condition"? Can any one give some mapping between the above events and prepaid credit control=2E Thanks, Bala DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C83576.82D2B900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarification regarding "Change in rating= contition"

Hi All,

    I need one clarification on Credit control= client fsm in RFC4006=2E The Fsm has one event named “Change in rating= condition”= =2E What is the difference between Tariff-Change= and “Change= in rating condition”?

   Can any one give some= mapping= between the= above events and prepaid credit control=2E

Thanks,

Bala

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C83576.82D2B900-- --===============1363183069== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1363183069==-- From dime-bounces@ietf.org Mon Dec 03 06:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz93Q-0000uJ-QA; Mon, 03 Dec 2007 06:01:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz93P-0000uE-Sd for DiME@ietf.org; Mon, 03 Dec 2007 06:01:35 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz93J-0006AZ-Kp for DiME@ietf.org; Mon, 03 Dec 2007 06:01:35 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lB3ApQ9j004538 for ; Mon, 3 Dec 2007 16:21:27 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lB3ApQxa004523; Mon, 3 Dec 2007 16:21:26 +0530 In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC603013F64@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> To: "Balamurugan T, TLS-Chennai" Subject: Re: [Dime] Clarification regarding "Change in rating contition" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Mon, 3 Dec 2007 16:31:03 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 03/12/2007 04:36:14 PM, Serialize complete at 03/12/2007 04:36:14 PM X-Spam-Score: 0.4 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282524333==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1282524333== Content-Type: multipart/alternative; boundary="=_alternative 003C8BE9652573A6_=" This is a multipart message in MIME format. --=_alternative 003C8BE9652573A6_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20!=0D=0A=0D=0A'Change=20in=20rating=20condition'=20is=20an=20event=20= identified=20in=20the=20client=20state=20=0D=0Amachine=20while=20Tariff-C= hange-Usage=20is=20an=20=20is=20an=20AVP.=20State=20machine=20=0D=0Aindic= ates=20that=20if=20there=20is=20any=20change=20in=20the=20tariff=20before= =20the=20response=20is=20=0D=0Areceived=20from=20server=20for=20the=20fir= st=20interrogation=20request,=20same=20should=20be=20=0D=0Aqueued=20and= =20when=20response=20for=20the=20request=20is=20received=20from=20server= =20for=20first=20=0D=0Ainterrogation=20request,=20client=20should=20send= =20update=20request=20immediately=20for=20=0D=0Athe=20queued=20request=20= .=0D=0A=0D=0AHope=20this=20clarifies=0D=0A=0D=0Aregards=0D=0APreeti.=0D= =0A=0D=0A=0D=0A=0D=0A"Balamurugan=20T,=20TLS-Chennai"=20=20=0D=0A12/03/2007=2012:04=20PM=0D=0A=0D=0A=0D=0ATo=0D=0A=0D=0Acc=0D=0A=0D=0ASubject=0D=0A[Dime]=20Clarification=20regarding= =20"Change=20in=20rating=20contition"=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0AHi=20All,=0D=0A=20=20=20=20I=20need=20one=20clarification=20on=20Cr= edit=20control=20client=20fsm=20in=20RFC4006.=20The=20=0D=0AFsm=20has=20o= ne=20event=20named=20?Change=20in=20rating=20condition?.=20What=20is=20th= e=20=0D=0Adifference=20between=20Tariff-Change=20and=20?Change=20in=20rat= ing=20condition??=0D=0A=20=20=20Can=20any=20one=20give=20some=20mapping= =20between=20the=20above=20events=20and=20prepaid=20=0D=0Acredit=20contro= l.=0D=0AThanks,=0D=0ABala=0D=0A=0D=0ADISCLAIMER:=0D=0A-------------------= -------------------------------------------------------------------------= ---------------------------=0D=0A=0D=0AThe=20contents=20of=20this=20e-mai= l=20and=20any=20attachment(s)=20are=20confidential=20and=20=0D=0Aintended= =20for=20the=20named=20recipient(s)=20only.=0D=0AIt=20shall=20not=20attac= h=20any=20liability=20on=20the=20originator=20or=20HCL=20or=20its=20=0D= =0Aaffiliates.=20Any=20views=20or=20opinions=20presented=20in=20=0D=0Athi= s=20email=20are=20solely=20those=20of=20the=20author=20and=20may=20not=20= necessarily=20reflect=20=0D=0Athe=20opinions=20of=20HCL=20or=20its=20affi= liates.=0D=0AAny=20form=20of=20reproduction,=20dissemination,=20copying,= =20disclosure,=20=0D=0Amodification,=20distribution=20and=20/=20or=20publ= ication=20of=20=0D=0Athis=20message=20without=20the=20prior=20written=20c= onsent=20of=20the=20author=20of=20this=20=0D=0Ae-mail=20is=20strictly=20p= rohibited.=20If=20you=20have=20=0D=0Areceived=20this=20email=20in=20error= =20please=20delete=20it=20and=20notify=20the=20sender=20=0D=0Aimmediately= .=20Before=20opening=20any=20mail=20and=20=0D=0Aattachments=20please=20ch= eck=20them=20for=20viruses=20and=20defect.=0D=0A=0D=0A-------------------= -------------------------------------------------------------------------= ---------------------------=0D=0A________________________________________= _______=0D=0ADiME=20mailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/dime=0D=0A=0D=0A=0D=0A=0D=0A********************= ***=20=20Aricent-Restricted=20=20=20***********************=0D=0A"DISCLAI= MER:=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20i= ntended=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom= =20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confiden= tial=20information=20and=20should=20not=20be=20=0Acirculated=20or=20used= =20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.= =20If=20you=20have=20received=20this=20message=20in=20error,=20=0Aplease= =20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20the= =20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20stri= ctly=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosin= g=20the=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20resp= onsibility=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20o= f=20the=20information=20transmitted=20by=20this=20email=20including=20dam= age=20from=20virus."=0A --=_alternative 003C8BE9652573A6_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20!=0D=0A
= =0D=0A
'Change=20in=20rating=20= condition'=20is=20an=20event=0D=0Aidentified=20in=20the=20client=20state= =20machine=20while=20Tariff-Change-Usage=20is=20an=0D=0A is=20an=20A= VP.=20State=20machine=20indicates=20that=20if=20there=20is=20any=20change= =20in=0D=0Athe=20tariff=20before=20the=20response=20is=20received=20from= =20server=20for=20the=20first=20interrogation=0D=0Arequest,=20same=20shou= ld=20be=20queued=20and=20when=20response=20for=20the=20request=20is=20rec= eived=0D=0Afrom=20server=20for=20first=20interrogation=20request,=20clien= t=20should=20send=20update=0D=0Arequest=20immediately=20for=20the=20queue= d=20request=20.=0D=0A
=0D=0A
Hope=20this=20clarifies=0D=0A
=0D=0A
regards=0D=0A
Preeti.=0D=0A
=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A"Balamurugan=20T,=20TLS-Chennai&qu= ot;=0D=0A<tbalamurugan@hcl.in>=20=0D=0A

12/03/2007=2012:04=20PM=0D=0A
=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A<= div=20align=3Dright>To=0D=0A<DiME= @ietf.org>=0D=0A=0D=0A=0D=0Acc=0D=0A=0D=0A=0D=0A=0D=0ASubject=0D=0A[Dime]=20Clarification=20regarding=0D=0A"= Change=20in=20rating=20contition"=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
Hi=20All= ,=0D=0A

 =20 =20I=20= need=20one=20clarification=20on=0D=0ACredit=20control=20client=20fsm=20in= =20RFC4006.=20The=20Fsm=20has=20one=20event=20named=0D=0A“Change=20in=20rat= ing=20condition”.=0D=0AWhat=20is=20the=20difference=20between=20Tariff-Cha= nge=0D=0Aand=20“Change=20in=20rating=0D=0Acondition”?=0D=0A

=  =20 Can=20any=20one=20give= =20some=20mapping=0D=0Abetween=20the=20above=20events=20and=20prepaid=20credit=0D=0Acontr= ol.=0D=0A

Thanks,=0D=0A=

Bala=0D=0A

=0D=0A=0D=0A=0D=0ADISCLAIMER:
=0D=0A-------------------------------------------= -------------------------------------------------------------------------= ---
=0D=0A
=0D=0AThe=20contents=20of=20this=20e-mail=20and=20any=20= attachment(s)=20are=20confidential=20and=0D=0Aintended=20for=20the=20name= d=20recipient(s)=20only.
=0D=0AIt=20shall=20not=20attach=20any=20liabi= lity=20on=20the=20originator=20or=20HCL=20or=20its=20affiliates.=0D=0AAny= =20views=20or=20opinions=20presented=20in=20
=0D=0Athis=20email=20are= =20solely=20those=20of=20the=20author=20and=20may=20not=20necessarily=20r= eflect=0D=0Athe=20opinions=20of=20HCL=20or=20its=20affiliates.
=0D=0AA= ny=20form=20of=20reproduction,=20dissemination,=20copying,=20disclosure,= =20modification,=0D=0Adistribution=20and=20/=20or=20publication=20of=20=0D=0Athis=20message=20without=20the=20prior=20written=20consent=20of= =20the=20author=20of=20this=20e-mail=0D=0Ais=20strictly=20prohibited.=20I= f=20you=20have=20
=0D=0Areceived=20this=20email=20in=20error=20please= =20delete=20it=20and=20notify=20the=20sender=20immediately.=0D=0ABefore= =20opening=20any=20mail=20and=20
=0D=0Aattachments=20please=20check=20= them=20for=20viruses=20and=20defect.
=0D=0A
=0D=0A-----------------= -------------------------------------------------------------------------= -----------------------------=0D=0A
_______________________________________________
=0D=0ADiME=20mailing= =20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.ietf.org/mailman/lis= tinfo/dime
=0D=0A=0D=0A

=0D=0A
=0D=0A***********************=20 Aricent-Restr= icted=20 =20***********************=0D=0A
"DISCLAIMER:=20This=20message=
=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20fo=
r=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addresse=
d.=20It=20may=20contain=20privileged=20or=20confidential=20information=20=
and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=
=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=20have=20re=
ceived=20this=20message=20in=20error,=20=0Aplease=20notify=20the=20origin=
ator=20immediately.=20If=20you=20are=20not=20the=20intended=20recipient,=
=20you=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20from=
=20using,=20copying,=20altering,=20or=20disclosing=20the=20contents=20of=
=20this=20message.=20Aricent=20accepts=20no=20responsibility=20for=20=0Al=
oss=20or=20damage=20arising=20from=20the=20use=20of=20the=20information=
=20transmitted=20by=20this=20email=20including=20damage=20from=20virus."=
=0A
--=_alternative 003C8BE9652573A6_=-- --===============1282524333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1282524333==-- From dime-bounces@ietf.org Mon Dec 03 06:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9cX-0002Ye-H4; Mon, 03 Dec 2007 06:37:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9cW-0002V2-K1 for DiME@ietf.org; Mon, 03 Dec 2007 06:37:52 -0500 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz9cU-00089a-SU for DiME@ietf.org; Mon, 03 Dec 2007 06:37:52 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id 1813F37C2DF; Mon, 3 Dec 2007 17:07:47 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTPid CF09A37C2CC; Mon, 3 Dec 2007 17:07:46 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 17:07:45 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Clarification regarding "Change in rating contition" Date: Mon, 3 Dec 2007 17:07:44 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC603050A69@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Clarification regarding "Change in rating contition" Thread-Index: Acg1m9//ilLtnkO7RiivQGB4j5WbvwAA05bQ References: From: "Balamurugan T, TLS-Chennai" To: "Preeti Shandilya" X-OriginalArrivalTime: 03 Dec 2007 11:37:45.0814 (UTC) FILETIME=[EC743F60:01C835A0] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-21.9650 TC:1F TRN:94 TV:5.0.1023(15582.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1669953518==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1669953518== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C835A0.EC29BFDC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C835A0.EC29BFDC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Preeti, =20 Thanks for your reply. Please see my doubt inline. =20 Regards, Bala =20 ________________________________ From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 Sent: Monday, December 03, 2007 4:31 PM To: Balamurugan T, TLS-Chennai Cc: DiME@ietf.org Subject: Re: [Dime] Clarification regarding "Change in rating contition" =20 Hi !=20 'Change in rating condition' is an event identified in the client state machine while Tariff-Change-Usage is an is an AVP.=20 {If there is a Tariff change, the CCS will send the tariff-time-change avp in first interrogation answer. So, the client will include the tariff-change-usage AVP in next update request. } But in client FSM," rating condition change" comes in PendingI state. Is this possible? State machine indicates that if there is any change in the tariff before the response is received from server for the first interrogation request, same should be queued and when response for the request is received from server for first interrogation request, client should send update request immediately for the queued request .=20 Hope this clarifies=20 regards=20 Preeti.=20 "Balamurugan T, TLS-Chennai" =20 12/03/2007 12:04 PM=20 To =20 cc =20 Subject [Dime] Clarification regarding "Change in rating contition" =20 =20 =20 Hi All,=20 I need one clarification on Credit control client fsm in RFC4006. The Fsm has one event named "Change in rating condition". What is the difference between Tariff-Change and "Change in rating condition"?=20 Can any one give some mapping between the above events and prepaid credit control.=20 Thanks,=20 Bala=20 DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime *********************** Aricent-Restricted ***********************=20 "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of=20 the individual to whom it is addressed. It may contain privileged or confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. If you have received this message in error,=20 please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by this email including damage from virus." =20 ------_=_NextPart_001_01C835A0.EC29BFDC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Preeti,

 

Thanks for your = reply.

Please see my doubt = inline.

 

Regards,

Bala

 

From: = Preeti Shandilya [mailto:preeti.shandilya@aricent.com]
Sent: Monday, December = 03, 2007 4:31 PM
To: Balamurugan T, TLS-Chennai
Cc: DiME@ietf.org
Subject: Re: [Dime] = Clarification regarding "Change in rating = contition"

 


Hi !

'Change in rating condition' is an event identified in the client state machine = while Tariff-Change-Usage is an  is an AVP.

{If there is a Tariff change, the CCS will send the tariff-time-change avp = in first interrogation answer. So, the client will include the = tariff-change-usage AVP in next update request. }

But in client FSM,” rating condition change” comes in PendingI state. Is this = possible?

State machine = indicates that if there is any change in the tariff before the response is received from = server for the first interrogation request, same should be queued and when = response for the request is received from server for first interrogation request, = client should send update request immediately for the queued request = .

Hope this clarifies

regards
Preeti.

"Balamurugan T, TLS-Chennai" = <tbalamurugan@hcl.in> =

12/03/2007 12:04 PM

To

<DiME@ietf.org>

cc

 

Subject

[Dime] Clarification regarding = "Change in rating contition"

 

 

 




Hi All,

    I need one clarification on Credit control client fsm in RFC4006. = The Fsm has one event named “Change in rating condition”. What is the difference between Tariff-Change = and “Change in rating condition”?

   Can any one give some mapping between the above events = and prepaid credit control.

Thanks,

Bala

DISCLAIMER:
= -------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its = affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily = reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, = modification, distribution and / or publication of
this message without the prior written consent of the author of this = e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

= -------------------------------------------------------------------------= ----------------------------------------------


______________________________________________= _
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



***********************  Aricent-Restricted   = *********************** 

"DISCLAIMER: This message is proprietary to =
Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain =
privileged or confidential information and should not be =

circulated or used for any purpose other than for what it =
is intended. If you have received this message in error, =

please notify the originator immediately. If you are not =
the intended recipient, you are notified that you are =
strictly
prohibited from using, copying, altering, or disclosing =
the contents of this message. Aricent accepts no responsibility for =

loss or damage arising from the use of the information =
transmitted by this email including damage from =
virus."

 

------_=_NextPart_001_01C835A0.EC29BFDC-- --===============1669953518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1669953518==-- From dime-bounces@ietf.org Mon Dec 03 06:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9v2-0005Ty-3N; Mon, 03 Dec 2007 06:57:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz9v0-0005Tt-Hi for DiME@ietf.org; Mon, 03 Dec 2007 06:56:58 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz9us-0007wF-32 for DiME@ietf.org; Mon, 03 Dec 2007 06:56:58 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lB3BklMC017279 for ; Mon, 3 Dec 2007 17:16:47 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lB3Bkk9B017265; Mon, 3 Dec 2007 17:16:46 +0530 In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC603050A69@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> To: "Balamurugan T, TLS-Chennai" Subject: RE: [Dime] Clarification regarding "Change in rating contition" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Mon, 3 Dec 2007 17:26:24 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 03/12/2007 05:31:34 PM, Serialize complete at 03/12/2007 05:31:34 PM X-Spam-Score: 0.4 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2049913611==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============2049913611== Content-Type: multipart/alternative; boundary="=_alternative 00419D40652573A6_=" This is a multipart message in MIME format. --=_alternative 00419D40652573A6_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20!=0D=0A=0D=0AClient=20=20provides=20the=20rating=20inputs=20to=20ser= ver=20using=20service=20parameter=20info=20=0D=0AAVP=20or=20someother=20a= pplication=20specific=20AVP.=20These=20rating=20AVPs=20map=20to=20the=20= =0D=0Aservices=20requested=20by=20the=20client.=20It=20is=20possible=20th= at=20before=20the=20server=20=0D=0Aprovides=20authorization=20based=20upo= n=20the=20rating=20inputs=20in=20CCR=20message,=20few=20=0D=0Arating=20co= nditions=20have=20got=20changed=20(may=20be=20due=20to=20user=20cancelled= =20the=20one=20=0D=0Aof=20the=20requested=20service).=20In=20that=20case= =20,=20this=20shall=20attribute=20to=20change=20=0D=0Ain=20rating=20condi= tion.=0D=0A=0D=0ASo=20'change=20in=20rating=20condition'=20does=20not=20i= ndicate=20'change=20in=20rating'=0D=0A=0D=0AHope=20this=20answers=20your= =20doubt.=0D=0A=0D=0Aregards=0D=0APreeti=0D=0A=0D=0A=0D=0A=0D=0A"Balamuru= gan=20T,=20TLS-Chennai"=20=20=0D=0A12/03/2007=2005:0= 7=20PM=0D=0A=0D=0A=0D=0ATo=0D=0APreeti=20Shandilya/HSS@HSS=0D=0Acc=0D=0AD= iME@ietf.org=0D=0ASubject=0D=0ARE:=20[Dime]=20Clarification=20regarding= =20"Change=20in=20rating=20contition"=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0AHi=20Preeti,=0D=0A=20=0D=0AThanks=20for=20your=20reply.=0D=0APlease= =20see=20my=20doubt=20inline.=0D=0A=20=0D=0ARegards,=0D=0ABala=0D=0A=20= =0D=0A=0D=0AFrom:=20Preeti=20Shandilya=20[mailto:preeti.shandilya@aricent= .com]=20=0D=0ASent:=20Monday,=20December=2003,=202007=204:31=20PM=0D=0ATo= :=20Balamurugan=20T,=20TLS-Chennai=0D=0ACc:=20DiME@ietf.org=0D=0ASubject:= =20Re:=20[Dime]=20Clarification=20regarding=20"Change=20in=20rating=20con= tition"=0D=0A=20=0D=0A=0D=0AHi=20!=20=0D=0A=0D=0A'Change=20in=20rating=20= condition'=20is=20an=20event=20identified=20in=20the=20client=20state=20= =0D=0Amachine=20while=20Tariff-Change-Usage=20is=20an=20=20is=20an=20AVP.= =20=0D=0A{If=20there=20is=20a=20Tariff=20change,=20the=20CCS=20will=20sen= d=20the=20tariff-time-change=20avp=20=0D=0Ain=20first=20interrogation=20a= nswer.=20So,=20the=20client=20will=20include=20the=20=0D=0Atariff-change-= usage=20AVP=20in=20next=20update=20request.=20}=0D=0ABut=20in=20client=20= FSM,?=20rating=20condition=20change?=20comes=20in=20PendingI=20state.=20I= s=20=0D=0Athis=20possible?=0D=0AState=20machine=20indicates=20that=20if= =20there=20is=20any=20change=20in=20the=20tariff=20before=20=0D=0Athe=20r= esponse=20is=20received=20from=20server=20for=20the=20first=20interrogati= on=20request,=20=0D=0Asame=20should=20be=20queued=20and=20when=20response= =20for=20the=20request=20is=20received=20from=20=0D=0Aserver=20for=20firs= t=20interrogation=20request,=20client=20should=20send=20update=20request= =20=0D=0Aimmediately=20for=20the=20queued=20request=20.=20=0D=0A=0D=0AHop= e=20this=20clarifies=20=0D=0A=0D=0Aregards=20=0D=0APreeti.=20=0D=0A=0D=0A= =0D=0A"Balamurugan=20T,=20TLS-Chennai"=20=20=0D=0A12= /03/2007=2012:04=20PM=20=0D=0A=0D=0A=0D=0ATo=0D=0A=20=0D= =0Acc=0D=0A=20=0D=0ASubject=0D=0A[Dime]=20Clarification=20regarding=20"Ch= ange=20in=20rating=20contition"=0D=0A=20=0D=0A=0D=0A=0D=0A=20=0D=0A=20=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0AHi=20All,=20=0D=0A=20=20=20=20I=20need=20one= =20clarification=20on=20Credit=20control=20client=20fsm=20in=20RFC4006.= =20The=20=0D=0AFsm=20has=20one=20event=20named=20?Change=20in=20rating=20= condition?.=20What=20is=20the=20=0D=0Adifference=20between=20Tariff-Chang= e=20and=20?Change=20in=20rating=20condition??=20=0D=0A=20=20=20Can=20any= =20one=20give=20some=20mapping=20between=20the=20above=20events=20and=20p= repaid=20=0D=0Acredit=20control.=20=0D=0AThanks,=20=0D=0ABala=20=0D=0A=0D= =0ADISCLAIMER:=0D=0A-----------------------------------------------------= ------------------------------------------------------------------=0D=0A= =0D=0AThe=20contents=20of=20this=20e-mail=20and=20any=20attachment(s)=20a= re=20confidential=20and=20=0D=0Aintended=20for=20the=20named=20recipient(= s)=20only.=0D=0AIt=20shall=20not=20attach=20any=20liability=20on=20the=20= originator=20or=20HCL=20or=20its=20=0D=0Aaffiliates.=20Any=20views=20or= =20opinions=20presented=20in=20=0D=0Athis=20email=20are=20solely=20those= =20of=20the=20author=20and=20may=20not=20necessarily=20reflect=20=0D=0Ath= e=20opinions=20of=20HCL=20or=20its=20affiliates.=0D=0AAny=20form=20of=20r= eproduction,=20dissemination,=20copying,=20disclosure,=20=0D=0Amodificati= on,=20distribution=20and=20/=20or=20publication=20of=20=0D=0Athis=20messa= ge=20without=20the=20prior=20written=20consent=20of=20the=20author=20of= =20this=20=0D=0Ae-mail=20is=20strictly=20prohibited.=20If=20you=20have=20= =0D=0Areceived=20this=20email=20in=20error=20please=20delete=20it=20and= =20notify=20the=20sender=20=0D=0Aimmediately.=20Before=20opening=20any=20= mail=20and=20=0D=0Aattachments=20please=20check=20them=20for=20viruses=20= and=20defect.=0D=0A=0D=0A------------------------------------------------= -----------------------------------------------------------------------= =0D=0A=0D=0A_______________________________________________=0D=0ADiME=20m= ailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listi= nfo/dime=0D=0A=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Rest= ricted=20=20=20***********************=20=0D=0A=0D=0A"DISCLAIMER:=20This= =20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20= =0D=0Asolely=20for=20the=20use=20of=20=0D=0Athe=20individual=20to=20whom= =20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20=0D=0Aco= nfidential=20information=20and=20should=20not=20be=20=0D=0Acirculated=20o= r=20used=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20in= tended.=20If=20=0D=0Ayou=20have=20received=20this=20message=20in=20error,= =20=0D=0Aplease=20notify=20the=20originator=20immediately.=20If=20you=20a= re=20not=20the=20intended=20=0D=0Arecipient,=20you=20are=20notified=20tha= t=20you=20are=20strictly=0D=0Aprohibited=20from=20using,=20copying,=20alt= ering,=20or=20disclosing=20the=20contents=20of=20=0D=0Athis=20message.=20= Aricent=20accepts=20no=20responsibility=20for=20=0D=0Aloss=20or=20damage= =20arising=20from=20the=20use=20of=20the=20information=20transmitted=20by= =20this=20=0D=0Aemail=20including=20damage=20from=20virus."=0D=0A=20_____= __________________________________________=0D=0ADiME=20mailing=20list=0D= =0ADiME@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/dime=0D=0A= =0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Restricted=20=20= =20***********************=0D=0A"DISCLAIMER:=20This=20message=20is=20prop= rietary=20to=20Aricent=20=20and=20is=20intended=20solely=20for=20the=20us= e=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20ma= y=20contain=20privileged=20or=20confidential=20information=20and=20should= =20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20t= han=20for=20what=20it=20is=20intended.=20If=20you=20have=20received=20thi= s=20message=20in=20error,=20=0Aplease=20notify=20the=20originator=20immed= iately.=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are= =20notified=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20= copying,=20altering,=20or=20disclosing=20the=20contents=20of=20this=20mes= sage.=20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20da= mage=20arising=20from=20the=20use=20of=20the=20information=20transmitted= =20by=20this=20email=20including=20damage=20from=20virus."=0A --=_alternative 00419D40652573A6_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20!=0D=0A
= =0D=0A
Client=20 provides= =20the=20rating=20inputs=0D=0Ato=20server=20using=20service=20parameter= =20info=20AVP=20or=20someother=20application=20specific=0D=0AAVP.=20These= =20rating=20AVPs=20map=20to=20the=20services=20requested=20by=20the=20cli= ent.=20It=0D=0Ais=20possible=20that=20before=20the=20server=20provides=20= authorization=20based=20upon=20the=0D=0Arating=20inputs=20in=20CCR=20mess= age,=20few=20rating=20conditions=20have=20got=20changed=20(may=0D=0Abe=20= due=20to=20user=20cancelled=20the=20one=20of=20the=20requested=20service)= .=20In=20that=20case=0D=0A,=20this=20shall=20attribute=20to=20change=20in= =20rating=20condition.=0D=0A
=0D=0A
So=20'change=20in=20rating=20condition'=20does=0D=0Anot= =20indicate=20'change=20in=20rating'=0D=0A
=0D=0A
Hope=20this=20answers=20your=20doubt.= =0D=0A
=0D=0A
regards= =0D=0A
Preeti=0D=0A
= =0D=0A
=0D=0A
=0D=0A=0D=0A= =0D=0A"B= alamurugan=20T,=20TLS-Chennai"=0D=0A<tbalamurugan@hcl.in>= =20=0D=0A

12/03/2007=2005= :07=20PM=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ATo=0D=0APreeti=20Shandilya/HSS@HSS=0D=0A=0D=0A<= td>=0D=0Acc=0D=0ADiME@ietf.org=0D=0A=0D=0A=0D=0ASubject=0D=0ARE:=20[Dime]=20Clarificatio= n=0D=0Aregarding=20"Change=20in=20rating=20contition"=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A=
=0D=0A
=0D=0A
=0D=0A
=0D=0A
Hi=20Preeti,=0D=0A
 =0D=0A
Thanks=20for=20your=20repl= y.=0D=0A
Pl= ease=20see=20my=20doubt=20inline.=0D=0A
 =0D=0A
Regards,=0D=0A
Bala=0D=0A
 =0D=0A=0D=0A
=0D=0A

=0D=0A
From:=20Preeti=20Shandilya=20[mailto:preeti.shandilya@aricent.co= m]=0D=0A
=0D=0ASent:=20Monday,=20December=2003,=202007=204:31= =20PM
=0D=0ATo:=20Balamurugan=20T,=20TLS-Chennai
=0D=0ACc= :=20DiME@ietf.org
=0D=0ASubject:=20Re:=20[Dime]=20Clarifica= tion=20regarding=20"Change=20in=20rating=0D=0Acontition"= =0D=0A
 = =0D=0A

=0D=0AHi=20!<= font=20size=3D3=20face=3D"Times=20New=20Roman">=20
=0D=0A
=0D=0A'Change=20in=20rating=20condi= tion'=20is=20an=20event=20identified=20in=20the=20client=20state=0D=0Amac= hine=20while=20Tariff-Change-Usage=20is=20an=20 is=20an=20AVP.=20=0D=0A
{If=20t= here=20is=20a=20Tariff=20change,=0D=0Athe=20CCS=20will=20send=20the=20tar= iff-time-change=20avp=20in=20first=20interrogation=20answer.=0D=0ASo,=20t= he=20client=20will=20include=20the=20tariff-change-usage=20AVP=20in=20nex= t=20update=0D=0Arequest.=20}=0D=0A
But=20in=20client=20FSM,”=20rating=0D=0Acon= dition=20change”=20comes=20in=20PendingI=20state.=20Is=20thi= s=20possible?=0D=0A
Stat= e=20machine=20indicates=20that=20if=20there=0D=0Ais=20any=20change=20in= =20the=20tariff=20before=20the=20response=20is=20received=20from=20server= =0D=0Afor=20the=20first=20interrogation=20request,=20same=20should=20be= =20queued=20and=20when=20response=0D=0Afor=20the=20request=20is=20receive= d=20from=20server=20for=20first=20interrogation=20request,=0D=0Aclient=20= should=20send=20update=20request=20immediately=20for=20the=20queued=20req= uest=20.=0D=0A
= =0D=0A
=0D=0AHope=20this= =20clarifies=20=0D=0A
=0D=0Aregards=20
=0D=0APreeti.=20
=0D=0A=0D=0A

=0D=0A=0D=0A=0D=0A"Balamurugan=20T,=20TLS-Chennai"= =0D=0A<tbalamurugan@hcl.in>=20=0D=0A

12/03/2007=2012:04=20PM=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ATo= =0D=0A<DiME@ietf.org>=0D=0A=0D=0A=0D=0A=0D=0Acc=0D=0A =0D=0A=0D=0A=0D=0ASubject=0D=0A[Dime]=20Clarification=20regarding=0D=0A"Change=20in= =20rating=20contition"=0D=0A
 =0D=0A

=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A = =0D=0A
=0D=0A

=0D=0A
=0D=0A
=0D= =0AHi=20All,=20=0D=0A

 =20 =20I=20need= =20one=20clarification=20on=0D=0ACredit=20control=20client=20fsm=20in=20R= FC4006.=20The=20Fsm=20has=20one=20event=20named=0D=0A“Change=20in=20rating=20condition”.=0D=0AWhat=20is=20the=20difference=20between=20Tariff-Change=0D=0Aand=20“Change=0D=0Ain=20rating=20condition”?<= /font>=20=0D=0A

=  =20 Can=20any=20one=20give= =20some=20mapping= =0D=0Abetween=20the=20above=20ev= ents=20and=20prepaid=20credit=0D=0Acontrol.= =0D=0A=0D=0A

Thanks,=0D=0A=0D=0A

Bala=0D=0A=0D=0A

=0D=0A=0D=0A=0D=0ADISCLA= IMER:
=0D=0A----------------------------------------------------------= -------------------------------------------------------------
=0D=0A=0D=0AThe=20contents=20of=20this=20e-mail=20and=20any=20attachment(s)= =20are=20confidential=20and=0D=0Aintended=20for=20the=20named=20recipient= (s)=20only.
=0D=0AIt=20shall=20not=20attach=20any=20liability=20on=20t= he=20originator=20or=20HCL=20or=20its=20affiliates.=0D=0AAny=20views=20or= =20opinions=20presented=20in=20
=0D=0Athis=20email=20are=20solely=20th= ose=20of=20the=20author=20and=20may=20not=20necessarily=20reflect=0D=0Ath= e=20opinions=20of=20HCL=20or=20its=20affiliates.
=0D=0AAny=20form=20of= =20reproduction,=20dissemination,=20copying,=20disclosure,=20modification= ,=0D=0Adistribution=20and=20/=20or=20publication=20of=20
=0D=0Athis=20= message=20without=20the=20prior=20written=20consent=20of=20the=20author= =20of=20this=20e-mail=0D=0Ais=20strictly=20prohibited.=20If=20you=20have= =20
=0D=0Areceived=20this=20email=20in=20error=20please=20delete=20it= =20and=20notify=20the=20sender=20immediately.=0D=0ABefore=20opening=20any= =20mail=20and=20
=0D=0Aattachments=20please=20check=20them=20for=20vir= uses=20and=20defect.
=0D=0A
=0D=0A---------------------------------= -------------------------------------------------------------------------= -------------=0D=0A


=0D=0A_______________________________________________
=0D= =0ADiME=20mailing=20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.iet= f.org/mailman/listinfo/dime
=0D=0A
=0D= =0A
=0D=0A
=0D=0A***********************=20 Aricent-Restricted= =20 =20***********************=0D=0A=0D=0A

=0D=0A=0D=0A= =0D=0A"DISCLAIMER:=0D=0AThis=20message=20is=20proprietary= =20to=20Aricent=20 and=20is=20intended=20solely=20for=0D=0Athe=20use= =20of=20=0D=0A
the=20= individual=20to=20whom=20it=20is=20addressed.=0D=0AIt=20may=20contain=20p= rivileged=20or=20confidential=20information=20and=20should=20not=20be=0D= =0A=0D=0A
circulated= =20or=20used=20for=20any=20purpose=0D=0Aother=20than=20for=20what=20it=20= is=20intended.=20If=20you=20have=20received=20this=20message=20in=0D=0Aer= ror,=20=0D=0A
please= =20notify=20the=20originator=20immediately.=0D=0AIf=20you=20are=20not=20t= he=20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20st= rictly=0D=0A
prohibit= ed=20from=20using,=20copying,=20altering,=0D=0Aor=20disclosing=20the=20co= ntents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibility= =0D=0Afor=20=0D=0A
lo= ss=20or=20damage=20arising=20from=20the=20use=0D=0Aof=20the=20information= =20transmitted=20by=20this=20email=20including=20damage=20from=20virus.&q= uot;=0D=0A
 ___________________________________= ____________
=0D=0ADiME=20mailing=20list
=0D=0ADiME@ietf.org
=0D= =0Ahttps://www1.ietf.org/mailman/listinfo/dime
=0D=0A=0D= =0A

=0D=0A
=0D=0A*******= ****************=20 Aricent-Restricted=20 =20******************= *****=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20Aricent=
=20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=20indi=
vidual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20privileg=
ed=20or=20confidential=20information=20and=20should=20not=20be=20=0Acircu=
lated=20or=20used=20for=20any=20purpose=20other=20than=20for=20what=20it=
=20is=20intended.=20If=20you=20have=20received=20this=20message=20in=20er=
ror,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=20you=20=
are=20not=20the=20intended=20recipient,=20you=20are=20notified=20that=20y=
ou=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20altering,=
=20or=20disclosing=20the=20contents=20of=20this=20message.=20Aricent=20ac=
cepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20arising=20fro=
m=20the=20use=20of=20the=20information=20transmitted=20by=20this=20email=
=20including=20damage=20from=20virus."=0A
--=_alternative 00419D40652573A6_=-- --===============2049913611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2049913611==-- From dime-bounces@ietf.org Mon Dec 03 13:20:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFu4-0003Tq-Qv; Mon, 03 Dec 2007 13:20:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFu3-0003Tb-9W for dime@ietf.org; Mon, 03 Dec 2007 13:20:23 -0500 Received: from mout.perfora.net ([74.208.4.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFu1-0007FX-Nx for dime@ietf.org; Mon, 03 Dec 2007 13:20:23 -0500 Received: from IBM52A5038A94F (dhcp-11f3.ietf70.org [130.129.17.243]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1IzFtv0wLG-0007UR; Mon, 03 Dec 2007 13:20:21 -0500 From: "Alper Yegin" To: "'Avi Lior'" , "'Romascanu, Dan \(Dan\)'" , "'Ahmad Muhanna'" , "'Hannes Tschofenig'" , Subject: RE: (8) [Dime] Tough IETF#70 Meeting Date: Mon, 3 Dec 2007 20:20:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acgx1YRzyBBsoppAQe6tLMsDd+eOEQEAiJgQ Message-Id: <0MKp8S-1IzFtv0wLG-0007UR@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/MdZGeJTe1Hfy52SHg/Eul6FbFQYfnUe8QT7X FsY8hr1ipjKq9bWWiqCvi4Cwxmdscq7+hSKqUMoNYfFzXUnNdE qCAot1dXbrwFQ3JG7tu9A== X-Spam-Score: -0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Release 1.0 of WiMAX Forum Network Working Group (NWG) architecture is using RADIUS for EAP, MIP4, accounting, etc. Now NWG is working on Release 1.5, and one of the tasks is to include Diameter support for the same. We are targeting June 2008 as the completion of this task. NWG has agreed to the concept of defining a new MIP4 application for Diameter, instead of using RFC 4004. As for "approved" vs "published", "approved by IESG" is good enough, especially if we get the RFC out in two months like it has been discussed these days. Alper > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Wednesday, November 28, 2007 5:44 PM > To: Romascanu, Dan (Dan); Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > Cc: Alper Yegin > Subject: RE: (8) [Dime] Tough IETF#70 Meeting > > In 3GPP2 the concept is approved. Which means that it is going to be > standerdized. Thus need mean required. > PP2 will develp the text and will publish something. We hope that this > would be the same as IETF text. > > In WiMAX, it may be the same but perhaps a little softer. But it has > been discussed and indication is that we need to move in that direction. > We havent gotten to approval yet. I may be wrong hence CCing Alper. > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: November 28, 2007 10:30 AM > > To: Avi Lior; Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > > Subject: RE: (8) [Dime] Tough IETF#70 Meeting > > > > 'need' like in approved, or published, or something else? > > > > Thanks, > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Tuesday, November 27, 2007 10:35 PM > > > To: Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > > > Subject: RE: (8) [Dime] Tough IETF#70 Meeting > > > > > > > > > > > > > > > * Is there a deadline for the work to be completed? > > > > > > > > I would leave this for Avi to answer. I believe 3GPP2 is > > > looking for > > > > the timeframe of Aug. Sept 2008. > > > > > > Both WiMAX and 3GPP2 will need this by Q2, 2008. > > > > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 03 16:04:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzISM-0002jC-Nd; Mon, 03 Dec 2007 16:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzISK-0002iv-Rj for dime@ietf.org; Mon, 03 Dec 2007 16:03:56 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzISI-0004jU-5P for dime@ietf.org; Mon, 03 Dec 2007 16:03:56 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2684714rvb for ; Mon, 03 Dec 2007 13:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=UXYvZXMlX1IrMHGjmW0lzKxRv5+iOG3cSjlMXydzhQE=; b=sVucZmNLuWX77nLW76Qd5bGsDRwm875cbUxRVs9QzH+6+QqJsDjI+/TliPObkfB9BCBiodJXEPtDzFEvtJ4p4Q/Wp0NF8YbsfbFCDIkMorqwfobK1/KiOdwA5mLH0fYyJmsBUXsa6p/bM1enJI2/hprn2dm357iZFBKw+LLbFY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=PACzXEAWc1TumKruUgIG7YNW6bqh1XFrXD7MJqUYT3uiVgC/B6qtvRPR6f/Uw3PFVco7L+tyl4NWbZNhZ/nGyitkeSeUKovUGUoy5I8Fsfsgt3pOlCa3C9oDbxSGYF0T8+nR7wBXgM0KkdAWRUFA8bVJV0PLTRFaFr3FLU+Ztrg= Received: by 10.140.82.40 with SMTP id f40mr1404412rvb.1196715829085; Mon, 03 Dec 2007 13:03:49 -0800 (PST) Received: by 10.141.50.5 with HTTP; Mon, 3 Dec 2007 13:03:49 -0800 (PST) Message-ID: <9cf5ced20712031303j29c05daao39b04373f1740c75@mail.gmail.com> Date: Mon, 3 Dec 2007 16:03:49 -0500 From: "David Frascone" To: "Hannes Tschofenig" Subject: Re: [Dime] Slides In-Reply-To: <4752F09C.1020600@gmx.net> MIME-Version: 1.0 References: <4752F09C.1020600@gmx.net> X-Google-Sender-Auth: 0cfcaa552cf79f5f X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0710244085==" Errors-To: dime-bounces@ietf.org --===============0710244085== Content-Type: multipart/alternative; boundary="----=_Part_6715_18443165.1196715829092" ------=_Part_6715_18443165.1196715829092 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So far, I only have two presentations. Please send me your presentations, so I can add them to the ietf page. -dave On Dec 2, 2007 12:51 PM, Hannes Tschofenig wrote: > We wouldn't be angry if speakers could send us their slides already > before the meeting starts. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > ------=_Part_6715_18443165.1196715829092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So far, I only have two presentations.  Please send me your presentations, so I can add them to the ietf page.

-dave

On Dec 2, 2007 12:51 PM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote:
We wouldn't be angry if speakers could send us their slides already
before the meeting starts.


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

------=_Part_6715_18443165.1196715829092-- --===============0710244085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0710244085==-- From dime-bounces@ietf.org Mon Dec 03 19:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzM7V-0000ES-Mj; Mon, 03 Dec 2007 19:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzM7U-0000Bd-4n for dime@ietf.org; Mon, 03 Dec 2007 19:58:40 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzM7S-0007zd-Mj for dime@ietf.org; Mon, 03 Dec 2007 19:58:40 -0500 Received: (qmail invoked by alias); 04 Dec 2007 00:58:37 -0000 Received: from dhcp-16ce.ietf70.org (EHLO [130.129.22.206]) [130.129.22.206] by mail.gmx.net (mp051) with SMTP; 04 Dec 2007 01:58:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+7u/gdAH2760cguSyfkNI3flS06CW7y4kZ9cenIw xGMITxO6CenU/5 Message-ID: <475427AA.8020106@gmx.net> Date: Mon, 03 Dec 2007 16:58:34 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.9 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] Shorten Presentation Slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have received a couple of presentation slides. Thanks! When you look at the agenda then you will realize that we have 1 hour for 17 presentations. Hence, I would appreciate if everyone has only a single slide with content (+1 title slide). Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 04 12:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc2F-0007aK-IN; Tue, 04 Dec 2007 12:58:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izc2E-0007Ye-OR for dime@ietf.org; Tue, 04 Dec 2007 12:58:18 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izc2D-00046Y-C6 for dime@ietf.org; Tue, 04 Dec 2007 12:58:18 -0500 Received: by rv-out-0910.google.com with SMTP id l15so3059830rvb for ; Tue, 04 Dec 2007 09:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=U00PBJ7qiwxACAe8dZgZ2Wyc8JymH4EYrhVET/J0gMw=; b=ey4Shy1WmpU0C/QplCnaawLLDUNBuVS5sV+Y3V5IaaaYDwGdGgYFOyL8Iz1eUsioGARgbG2iwtCO/MBQjUFDnZ7aqjOMhf9NEI38kjTSzsUGJ4PfMLIlL9sr6hMeEDvrNHSed7CnelU/5WSV6qobGixT6OZQb0xXbrmtQaRm2T4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=RahQfL67a1uFYA6AWB10r43GHumF5rVFe1JZdJI4A894P22XsLrM5cZNmkmEer7hmk+/pzvCZXyAHIw2ATowSx3D/BBzG5W46kuREHj4kAExRFSVIOdZukUspIsNLIyVTTGx5BZMswPaJlDViN8CAxtWTRRCBPh2QPbHzVl3N1E= Received: by 10.140.128.3 with SMTP id a3mr506713rvd.1196791091542; Tue, 04 Dec 2007 09:58:11 -0800 (PST) Received: by 10.141.50.5 with HTTP; Tue, 4 Dec 2007 09:58:11 -0800 (PST) Message-ID: <9cf5ced20712040958x21de4a33sc78bc78c22a8f975@mail.gmail.com> Date: Tue, 4 Dec 2007 12:58:11 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: eb6f971cb3431216 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] All received slides have been posted X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0136278628==" Errors-To: dime-bounces@ietf.org --===============0136278628== Content-Type: multipart/alternative; boundary="----=_Part_9370_25611645.1196791091549" ------=_Part_9370_25611645.1196791091549 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please let me know if you see any mistakes or omissions. The slides before we talk about rechartering are in order of presentation. After we start on rechartering, the slides are in no particular order, and will be grouped according to subject. (The Applications Design Guideline is the last pre-re-charter slideset) https://datatracker.ietf.org/meeting/70/materials.html -Dave ------=_Part_9370_25611645.1196791091549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please let me know if you see any mistakes or omissions.  The slides before we talk about rechartering are in order of presentation.

After we start on rechartering, the slides are in no particular order, and will be grouped according to subject.  (The Applications Design Guideline is the last pre-re-charter slideset)

https://datatracker.ietf.org/meeting/70/materials.html

-Dave
------=_Part_9370_25611645.1196791091549-- --===============0136278628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0136278628==-- From dime-bounces@ietf.org Tue Dec 04 21:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkPw-0002Gs-Is; Tue, 04 Dec 2007 21:55:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkPv-00027H-25 for dime@ietf.org; Tue, 04 Dec 2007 21:55:19 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzkPs-0001u6-Vm for dime@ietf.org; Tue, 04 Dec 2007 21:55:19 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSK00H922RZ5F@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 05 Dec 2007 02:55:11 +0000 (GMT) Received: from jys3105121962 (dhcp-14f9.ietf70.org [130.129.20.249]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSK00C1E2RUJ8@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 05 Dec 2007 02:55:11 +0000 (GMT) Date: Tue, 04 Dec 2007 18:54:58 -0800 From: Tina TSOU To: dime@ietf.org Message-id: <016d01c836ea$3bdd86c0$f9148182@jys3105121962> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <9cf5ced20712040958x21de4a33sc78bc78c22a8f975@mail.gmail.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [Dime] Diameter Explicit Routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1875830806==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1875830806== Content-type: multipart/alternative; boundary="Boundary_(ID_3vJnFvMq76j3XBEANfXKyQ)" This is a multi-part message in MIME format. --Boundary_(ID_3vJnFvMq76j3XBEANfXKyQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear all, Here is the presentation we did not have time to present, it is no.8 presentation in the website. If it is presented, we will ask who is interested at it, and what's the next step for it. Overview .Refresher -Ability for intermediaries to stay in the Diameter signaling path during a session (e.g. an outgoing gateway for a domain enforcing policy) .Updates since IETF 68/69 -Proposes new "workarounds" to provide explicit routing without using new routing AVPs .Introduce intermediate proxy nodes that are session stateful (back-to-back server/relay) .Session stateful nodes can select the next hop node to send session messages to -Retain old scheme .Use new routing AVPs that keep track of nodes to visit .Why do we need this solution ? .TISPAN-NASS - clustering of UAAF .3G-IWLAN - clustering of 3GPP AAA Proxy, currently using decorated NAI to do strict routing .Diameter MIPv6 Application - clustering of AAA MSP B. R. Tina --Boundary_(ID_3vJnFvMq76j3XBEANfXKyQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear all,
Here is the presentation we did not = have time to=20 present, it is no.8 presentation in the website. If it is presented, we = will ask=20 who is interested at it, and what's the next step for it.
 
Overview=20
=95Refresher=20
=96Ability=20 for intermediaries to stay in the Diameter signaling path during a = session=20 (e.g.=20 an outgoing gateway for a domain enforcing policy)
=95Updates=20 since IETF 68/69
=96Proposes=20 new =93workarounds=94 to provide explicit routing without using new = routing=20 AVPs
=95Introduce=20 intermediate proxy nodes that are session stateful (back-to-back = server/relay) =
=95Session=20 stateful nodes can select the next hop node to send session messages to=20
=96Retain=20 old scheme
=95Use=20 new routing AVPs that keep track of nodes to visit
=95Why=20 do we need this solution ?
=95TISPAN-NASS=20 =96 clustering of UAAF
=953G-IWLAN=20 =96 clustering of 3GPP AAA Proxy, currently using decorated NAI to do = strict=20 routing
=95Diameter=20 MIPv6 Application =96 clustering of AAA MSP
 
B. R.
Tina
--Boundary_(ID_3vJnFvMq76j3XBEANfXKyQ)-- --===============1875830806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1875830806==-- From dime-bounces@ietf.org Tue Dec 04 22:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izkbb-0007mH-BE; Tue, 04 Dec 2007 22:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izkba-0007ly-0H for dime@ietf.org; Tue, 04 Dec 2007 22:07:22 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IzkbY-0002TM-9l for dime@ietf.org; Tue, 04 Dec 2007 22:07:21 -0500 Received: (qmail invoked by alias); 05 Dec 2007 03:07:19 -0000 Received: from dhcp-16c7.ietf70.org (EHLO [130.129.22.199]) [130.129.22.199] by mail.gmx.net (mp032) with SMTP; 05 Dec 2007 04:07:19 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/CGNYfMkjCgFsg7OzPoerVu0x2KuXHhB+AKizerZ uU3CFS6Cs+O8oB Message-ID: <475615E4.5010004@gmx.net> Date: Wed, 05 Dec 2007 04:07:16 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] We couldn't get all our presentations done today X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org We unfortunately weren't able to present all slides today. It would be great if the authors of the following documents could post a description about their work to this list: -- Diameter MIBs Glen Zorn http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-cc-appl-mib-02.txt http://tools.ietf.org/wg/dime/draft-zorn-dime-diameter-base-protocol-mib-02.txt -- Explicit routing Tina Tsou http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt -- Diameter extensions to base protocol facilitating development of redundant applications, handling overload situations and improving existing reliability procedures Tolga Asveren http://tools.ietf.org/html/draft-asveren-dime-dupcons-00 http://tools.ietf.org/html/draft-asveren-dime-cong-02 http://tools.ietf.org/html/draft-asveren-dime-ansack _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 04 22:13:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izkh8-0007tW-Te; Tue, 04 Dec 2007 22:13:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izkh7-0007qC-Qb for dime@ietf.org; Tue, 04 Dec 2007 22:13:05 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izkh5-0002hC-N2 for dime@ietf.org; Tue, 04 Dec 2007 22:13:05 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 04:13:01 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter Explicit Routing Date: Wed, 5 Dec 2007 04:12:39 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026051A2A01@ftrdmel2> In-Reply-To: <016d01c836ea$3bdd86c0$f9148182@jys3105121962> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Explicit Routing Thread-Index: Acg26k4KwE+/6SwrQ3CofuImnvlv6wAAM09A References: <9cf5ced20712040958x21de4a33sc78bc78c22a8f975@mail.gmail.com> <016d01c836ea$3bdd86c0$f9148182@jys3105121962> From: "MORAND Lionel RD-CORE-ISS" To: "Tina TSOU" , X-OriginalArrivalTime: 05 Dec 2007 03:13:01.0746 (UTC) FILETIME=[BE91B120:01C836EC] X-Spam-Score: 0.6 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1840790259==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1840790259== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C836EC.BDA4CF26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C836EC.BDA4CF26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At least, I do agree that the problem exists in some AAA architecture = deployments (e.g. referring to 3GPP example) and this problem needs a = standardized solution. Therefore, if the question is "should we consider this work in Dime", my = response is "yes". We should therefore discuss/challenge/improve the proposed solutions = described in the draft in order to reach a wg consensus on the final = solution(s). =20 Lionel =20 ________________________________ De : Tina TSOU [mailto:tena@huawei.com]=20 Envoy=E9 : mercredi 5 d=E9cembre 2007 03:55 =C0 : dime@ietf.org Objet : [Dime] Diameter Explicit Routing =09 =09 Dear all, Here is the presentation we did not have time to present, it is no.8 = presentation in the website. If it is presented, we will ask who is = interested at it, and what's the next step for it. =20 Overview=20 =09 *Refresher=20 -Ability for intermediaries to stay in the Diameter signaling path = during a session (e.g. an outgoing gateway for a domain enforcing = policy)=20 *Updates since IETF 68/69=20 -Proposes new "workarounds" to provide explicit routing without using = new routing AVPs=20 *Introduce intermediate proxy nodes that are session stateful = (back-to-back server/relay)=20 *Session stateful nodes can select the next hop node to send session = messages to=20 -Retain old scheme=20 *Use new routing AVPs that keep track of nodes to visit=20 *Why do we need this solution ?=20 *TISPAN-NASS - clustering of UAAF=20 *3G-IWLAN - clustering of 3GPP AAA Proxy, currently using decorated NAI = to do strict routing=20 *Diameter MIPv6 Application - clustering of AAA MSP=20 =20 B. R. Tina ------_=_NextPart_001_01C836EC.BDA4CF26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At least, I do agree that the problem = exists in some=20 AAA architecture deployments (e.g. referring to 3GPP example) and = this=20 problem needs a standardized solution.
Therefore, if the question is "should we = consider this work=20 in Dime", my response is "yes".
We should therefore discuss/challenge/improve = the proposed=20 solutions described in the draft in order to reach a wg consensus = on the=20 final solution(s).
 
Lionel
 

De : Tina TSOU = [mailto:tena@huawei.com]=20
Envoy=E9 : mercredi 5 d=E9cembre 2007 = 03:55
=C0 :=20 dime@ietf.org
Objet : [Dime] Diameter Explicit=20 Routing

Dear all,
Here is the presentation we did not = have time to=20 present, it is no.8 presentation in the website. If it is presented, = we will=20 ask who is interested at it, and what's the next step for = it.
 =20
Overview=20
=95Refresher=20
=96Ability=20 for intermediaries to stay in the Diameter signaling path during a = session=20 (e.g.=20 an outgoing gateway for a domain enforcing policy)
=95Updates=20 since IETF 68/69
=96Proposes=20 new =93workarounds=94 to provide explicit routing without using new = routing=20 AVPs
=95Introduce=20 intermediate proxy nodes that are session stateful (back-to-back = server/relay) =
=95Session=20 stateful nodes can select the next hop node to send session messages = to=20
=96Retain=20 old scheme
=95Use=20 new routing AVPs that keep track of nodes to visit
=95Why=20 do we need this solution ?
=95TISPAN-NASS=20 =96 clustering of UAAF
=953G-IWLAN=20 =96 clustering of 3GPP AAA Proxy, currently using decorated NAI to do=20 strict=20 routing
=95Diameter=20 MIPv6 Application =96 clustering of AAA MSP
 
B. R.
Tina
------_=_NextPart_001_01C836EC.BDA4CF26-- --===============1840790259== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1840790259==-- From dime-bounces@ietf.org Tue Dec 04 22:14:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkiO-0001b5-MF; Tue, 04 Dec 2007 22:14:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkiN-0001ay-Kp for dime@ietf.org; Tue, 04 Dec 2007 22:14:23 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IzkiN-0006MU-BE for dime@ietf.org; Tue, 04 Dec 2007 22:14:23 -0500 Received: (qmail invoked by alias); 05 Dec 2007 03:14:21 -0000 Received: from dhcp-16c7.ietf70.org (EHLO [130.129.22.199]) [130.129.22.199] by mail.gmx.net (mp057) with SMTP; 05 Dec 2007 04:14:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18HQDZukFoHUDA2UHraSw7hD6u+t6argFQLb61Guf 50SduIQCptD29a Message-ID: <4756178A.30201@gmx.net> Date: Wed, 05 Dec 2007 04:14:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Dime] Requirements for new work in DIME X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Dan, our AD, made an important comment today at the end of the DIME meeting We are looking for new work where there is deployment interest. We are not just doing work that appears to be interesting. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 04 22:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkrB-0001Eb-EZ; Tue, 04 Dec 2007 22:23:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkrA-0001EK-40 for dime@ietf.org; Tue, 04 Dec 2007 22:23:28 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Izkr9-0006ki-Dl for dime@ietf.org; Tue, 04 Dec 2007 22:23:27 -0500 Received: (qmail invoked by alias); 05 Dec 2007 03:23:26 -0000 Received: from dhcp-16c7.ietf70.org (EHLO [130.129.22.199]) [130.129.22.199] by mail.gmx.net (mp031) with SMTP; 05 Dec 2007 04:23:26 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+27wZh5Re226SaQ4T5aBqPT+JMCMgQ9ZBdf6oz45 QAfm3zh3BuDmdE Message-ID: <475619AA.5020107@gmx.net> Date: Wed, 05 Dec 2007 04:23:22 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Dime] Diameter QoS discussions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org In case someone wants to join: We are going to have a Diameter QoS discussion among the draft authors Wednesday, 16:10-17:00. We are going to meet at the IETF registration desk. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 05 03:22:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzpWo-00073n-6G; Wed, 05 Dec 2007 03:22:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzpWn-00073M-Fq for DiME@ietf.org; Wed, 05 Dec 2007 03:22:45 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzpWm-0007og-OC for DiME@ietf.org; Wed, 05 Dec 2007 03:22:45 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id E775F3670D9 for ; Wed, 5 Dec 2007 13:52:39 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTP id 5A509367129for ; Wed, 5 Dec 2007 13:52:39 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 13:52:38 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Dec 2007 13:51:59 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60307C4CE@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding the usage of FSM for CCA Thread-Index: Acg3F+egZC7TpQTGSfCqRSf6y81GDA== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 05 Dec 2007 08:22:38.0918 (UTC) FILETIME=[FF6D2E60:01C83717] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-12.6283 TC:1F TRN:35 TV:5.0.1023(15586.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: [Dime] Regarding the usage of FSM for CCA X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857271812==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0857271812== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83717.E8153FDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83717.E8153FDE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I need some clarification regarding the usage of FSMs for credit control application=2E=20 1=2E First Interrogation with CCR - First interrogation after authorization/authentication process=2E Here, the CC client FSM in RFC4006 is cranked first and the CCR comes to base=20 diameter stack In this case, the CCR message can be sent directly to CCR server using the Peer FSM=2E 2=2E First Interrogation with AA Request - First interrogation during authorization/authentication process [NASREQ] In this case, The AAR may include Auth-Session-State AVP=2E Here, the AAR has to transferred via the First interrogation FSM in RFC4006 and then via Auth Client FSM in Base diameter stack as per RFC 3588=2E Is it necessary to maintain the two state FSMs for a single Auth Sessions=2E?? Please clarify, if I my interpretation is wrong=2E Thanks & Regards, Bala =09 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C83717.E8153FDE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the usage of FSM for CCA

Hi All,

     I need some= clarification regarding the usage of FSMs for credit control application= =2E

1= =2E      First= Interrogation with CCR – First interrogation after= authorization/authentication process=2E

          &nbs= p; Here, the CC client FSM in RFC4006 is cranked first and the CCR comes to= base

diameter stack In this case, the CCR= message can be sent directly to CCR server using the Peer FSM= =2E

2= =2E      First= Interrogation with AA Request - First interrogation during= authorization/authentication

     process= [NASREQ]

    In this case, The AAR may include= Auth-Session-State AVP=2E Here, the AAR has to= transferred via the First interrogation FSM in RFC4006 and then via Auth= Client FSM in Base diameter stack as per RFC 3588=2E

     Is it necessary to maintain the two= state FSMs for a single Auth Sessions=2E??

    Please clarify, if I my interpretation is= wrong=2E

Thanks & Regards,

Bala

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C83717.E8153FDE-- --===============0857271812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0857271812==-- From dime-bounces@ietf.org Wed Dec 05 16:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01bt-0004lA-6W; Wed, 05 Dec 2007 16:16:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01br-0004ks-SM for dime@ietf.org; Wed, 05 Dec 2007 16:16:47 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J01bp-0003uM-Uy for dime@ietf.org; Wed, 05 Dec 2007 16:16:47 -0500 Received: (qmail invoked by alias); 05 Dec 2007 21:16:44 -0000 Received: from dhcp-16ce.ietf70.org (EHLO [130.129.22.206]) [130.129.22.206] by mail.gmx.net (mp042) with SMTP; 05 Dec 2007 22:16:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196RUUPSzt6aaIEYVvXHeNuJv02Zp+Lx4qNehej0u SacRlDNIb1NJLj Message-ID: <4757153B.2060802@gmx.net> Date: Wed, 05 Dec 2007 22:16:43 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt References: <4749471C.8090507@gmx.net> <012401c8300c$b2ba3e30$544c460a@china.huawei.com> In-Reply-To: <012401c8300c$b2ba3e30$544c460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tina, I just noticed that you replied to my mail. Please find further comments below: Tina TSOU wrote: > Dear Hannes, > Thank you for your review:) > Please see my comments in line demarked as [Tina: ...]. > > B. R. > Tina > -------------------------------------------------------- > Mondays aren't so bad; and pigs have wings... > ----- Original Message ----- > From: Hannes Tschofenig > To: dime@ietf.org > Sent: Sunday, November 25, 2007 5:57 PM > Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > > > I read through > http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt > > At this point in time I only have high-level comments. > > I am not sure about the usefulness of the proposed mechanism. In some > sense you dynamically establish an explicit route based on the initial > routing of the message. Then, this information is used for subsequent > messages. When something changes along the path then a new route is > being "established" and cached by the originator. > > Diameter routes do not regularly change. If they change then there is a > good reason (e.g., failure of a node). > This mechanism only seems to be useful for the cases where Diameter > routes change because of some irrelevant reason but routing through the > explicit path would still be possible. > [Tina: There is Relay Agent in Diameter routing path, at the same time, in the case it has relative many next hop nodes, routing probably changes. > Do we have these types of Diameter deployments already that have so many hops? > It is because that the Diameter Relay Agent is likely to select the next hop node by random. > Hmmm. Probably this is then the problem. We then shouldn't develop protocol extensions but rather write a document that indicates what good design for Relay Agents is. > In Diameter Base Protocol, usually when session starts, the Destination-Host is not appointed. Only the Destination-Realm is appointed. However, > The subsequent requests in the session need to appoint Destination-Host to assure it is routed to the same server, as the routing may changes. > And the mechanism define by this protocol, is to assure that it is routed to the intermediate stateful Proxy Agent.] > I agree that the issue sounds like a logical thing todo. I do, however, wonder whether this is going to be an issue in real issue. > Is there some evidence that the proposed mechanism would actually be > helpful? > [Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" in draft-tsou-dime-base-routing-ext-03.txt. > After a Diameter Relay Agent, there are two stateful Proxy Agents. > > VISITED NETWORK | HOME NETWORK > | > +--------+ +--------+ | +--------+ > | Client |<--->| Relay1 |<----->| Proxy1 | > +--------+ +--------+ | +--------+\ > \ | \+-------------+ > \ | | Home Server | > \| /+-------------+ > \ +--------+/ > |---| Proxy2 | > | +--------+ > > ] > > Your proposal only helps if the Relay does random routing. I do, however, doubt that this is true. > Do we have some real-world data indicating that this is indeed a problem > rather than an academic exercise? > [Tina: Here are some application with stateful Proxy Agent in 3GPP and ETSI TISPAN. I think that if there is stateful Proxy Agent, such mechanism is needed. > [TS23.234] > 3GPP, "3GPP system to Wireles Local Area Network (WLAN) > interworking; System description", 3GPP TS 23.234 Version > 7.4.0 2006. > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > RES/TISPAN-02045-NGN-R2 V0.0.5 > ETSI Standard > Telecommunications and Internet converged Services and > Protocols for Advanced Networking (TISPAN); > NGN Functional Architecture; > Network Attachment Sub-System (NASS) > > Here, in Visited NGN Network, the UAAF, CLF are also in this case. > ] > I was told that there was a discussion in the 3GPP once about this aspect. The WLAN 3G interworking was done a long time ago and we have never heard back from them. I would like to hear from an operator that they have a large Diameter network and that issue turned out to be a problem. I would also be happy to hear from vendors what they do. I will certainly investigate this issue with vendors and operators. Ciao Hannes > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 05 16:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01ue-0003O8-TG; Wed, 05 Dec 2007 16:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01ud-0003Nd-JD for dime@ietf.org; Wed, 05 Dec 2007 16:36:11 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J01uc-0005rm-Sh for dime@ietf.org; Wed, 05 Dec 2007 16:36:11 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lB5La4Yu026217; Wed, 5 Dec 2007 16:36:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Wed, 5 Dec 2007 16:36:04 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509610@sonusmail04.sonusnet.com> In-Reply-To: <4757153B.2060802@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg3hC2bLWFU3hgJSnSgkOwGeBz/2QAAR4Uw References: <4749471C.8090507@gmx.net><012401c8300c$b2ba3e30$544c460a@china.huawei.com> <4757153B.2060802@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , "Tina TSOU" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, > Your proposal only helps if the Relay does random routing. I do, > however, doubt that this is true. I think we have two issues related with this: 1) That relays should route messages for the same session always to the same next hop is not mandated. It definitely is preferable to loadshare traffic somehow, and a basic round-robin loadsharing could lead messages of a single session to be sent to different entities. 2) It is preferable for the relays to be stateless from efficiency perspective (and we also do not want to synchronize state between relays). One way of doing "consistent routing" is running some type of hash function on Session-Id to determine the next hop, but this also has its challenges if the set of next hops change. In Section 1.2 of the draft, there is some discussion about possible workarounds with existing mechanisms. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, December 05, 2007 4:17 PM > To: Tina TSOU > Cc: dime@ietf.org > Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > Hi Tina, >=20 > I just noticed that you replied to my mail. > Please find further comments below: >=20 > Tina TSOU wrote: > > Dear Hannes, > > Thank you for your review:) > > Please see my comments in line demarked as [Tina: ...]. > > > > B. R. > > Tina > > -------------------------------------------------------- > > Mondays aren't so bad; and pigs have wings... > > ----- Original Message ----- > > From: Hannes Tschofenig > > To: dime@ietf.org > > Sent: Sunday, November 25, 2007 5:57 PM > > Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > > > > > > I read through > > http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt > > > > At this point in time I only have high-level comments. > > > > I am not sure about the usefulness of the proposed mechanism. In some > > sense you dynamically establish an explicit route based on the initial > > routing of the message. Then, this information is used for subsequent > > messages. When something changes along the path then a new route is > > being "established" and cached by the originator. > > > > Diameter routes do not regularly change. If they change then there is > a > > good reason (e.g., failure of a node). > > This mechanism only seems to be useful for the cases where Diameter > > routes change because of some irrelevant reason but routing through > the > > explicit path would still be possible. > > [Tina: There is Relay Agent in Diameter routing path, at the same > time, in the case it has relative many next hop nodes, routing probably > changes. > > > Do we have these types of Diameter deployments already that have so many > hops? >=20 > > It is because that the Diameter Relay Agent is likely to select the > next hop node by random. > > > Hmmm. Probably this is then the problem. We then shouldn't develop > protocol extensions but rather write a document that indicates what good > design for Relay Agents is. >=20 > > In Diameter Base Protocol, usually when session starts, the > Destination-Host is not appointed. Only the Destination-Realm is > appointed. However, > > The subsequent requests in the session need to appoint Destination- > Host to assure it is routed to the same server, as the routing may > changes. > > And the mechanism define by this protocol, is to assure that it is > routed to the intermediate stateful Proxy Agent.] > > > I agree that the issue sounds like a logical thing todo. > I do, however, wonder whether this is going to be an issue in real issue. >=20 > > Is there some evidence that the proposed mechanism would actually be > > helpful? > > [Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" > in draft-tsou-dime-base-routing-ext-03.txt. > > After a Diameter Relay Agent, there are two stateful Proxy Agents. > > > > VISITED NETWORK | HOME NETWORK > > | > > +--------+ +--------+ | +--------+ > > | Client |<--->| Relay1 |<----->| Proxy1 | > > +--------+ +--------+ | +--------+\ > > \ | \+-------------+ > > \ | | Home Server | > > \| /+-------------+ > > \ +--------+/ > > |---| Proxy2 | > > | +--------+ > > > > ] > > > > > Your proposal only helps if the Relay does random routing. I do, > however, doubt that this is true. >=20 > > Do we have some real-world data indicating that this is indeed a > problem > > rather than an academic exercise? > > [Tina: Here are some application with stateful Proxy Agent in 3GPP and > ETSI TISPAN. I think that if there is stateful Proxy Agent, such mechanism > is needed. > > [TS23.234] > > 3GPP, "3GPP system to Wireles Local Area Network (WLAN) > > interworking; System description", 3GPP TS 23.234 > Version > > 7.4.0 2006. > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > RES/TISPAN-02045-NGN-R2 V0.0.5 > > ETSI Standard > > Telecommunications and Internet converged Services and > > Protocols for Advanced Networking (TISPAN); > > NGN Functional Architecture; > > Network Attachment Sub-System (NASS) > > > > Here, in Visited NGN Network, the UAAF, CLF are also in this case. > > ] > > > I was told that there was a discussion in the 3GPP once about this > aspect. The WLAN 3G interworking was done a long time ago and we have > never heard back from them. >=20 > I would like to hear from an operator that they have a large Diameter > network and that issue turned out to be a problem. I would also be happy > to hear from vendors what they do. I will certainly investigate this > issue with vendors and operators. >=20 >=20 > Ciao > Hannes >=20 > > Ciao > > Hannes > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 05 17:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Jx-000827-SR; Wed, 05 Dec 2007 17:02:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Jw-00081s-Kp for dime@ietf.org; Wed, 05 Dec 2007 17:02:20 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J02Jv-0004qH-Ih for dime@ietf.org; Wed, 05 Dec 2007 17:02:20 -0500 Received: (qmail invoked by alias); 05 Dec 2007 22:02:16 -0000 Received: from dhcp-16ce.ietf70.org (EHLO [130.129.22.206]) [130.129.22.206] by mail.gmx.net (mp006) with SMTP; 05 Dec 2007 23:02:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19UZxIU5xZUp1Ij+fBcsxnEN7rAuE5DE40RmqC+dt RgolQ9a3zg4/ma Message-ID: <47571FE6.6010602@gmx.net> Date: Wed, 05 Dec 2007 23:02:14 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt References: <4749471C.8090507@gmx.net><012401c8300c$b2ba3e30$544c460a@china.huawei.com> <4757153B.2060802@gmx.net> <033458F56EC2A64E8D2D7B759FA3E7E7509610@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7509610@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Asveren, Tolga wrote: > Hi Hannes, > > >> Your proposal only helps if the Relay does random routing. I do, >> however, doubt that this is true. >> > I think we have two issues related with this: > > 1) That relays should route messages for the same session always to the > same next hop is not mandated. It definitely is preferable to loadshare > traffic somehow, and a basic round-robin loadsharing could lead messages > of a single session to be sent to different entities. > The question is how relays route messages. If your deployment wants to route Diameter messages differently per-session AND you are concerned about the consequences then why do you put a stateless agent in there in the first place. > 2) It is preferable for the relays to be stateless from efficiency > perspective (and we also do not want to synchronize state between > relays). One way of doing "consistent routing" is running some type of > hash function on Session-Id to determine the next hop, but this also has > its challenges if the set of next hops change. > > I agree that you would want to have stateless routing. However, on the other hand here you seem to also want to * route messages as you want (almost randomly) * and at the same time ensure that the Diameter messages of a specific session is routed along the same path. I appreciate the text in Section 1.2. For example, Section 1.2.1 indicates that you have to have stateful proxies along the entire path. That's not necessary. You only need to have them at places where it really matters. Ciao Hannes > In Section 1.2 of the draft, there is some discussion about possible > workarounds with existing mechanisms. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, December 05, 2007 4:17 PM >> To: Tina TSOU >> Cc: dime@ietf.org >> Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >> >> Hi Tina, >> >> I just noticed that you replied to my mail. >> Please find further comments below: >> >> Tina TSOU wrote: >> >>> Dear Hannes, >>> Thank you for your review:) >>> Please see my comments in line demarked as [Tina: ...]. >>> >>> B. R. >>> Tina >>> -------------------------------------------------------- >>> Mondays aren't so bad; and pigs have wings... >>> ----- Original Message ----- >>> From: Hannes Tschofenig >>> To: dime@ietf.org >>> Sent: Sunday, November 25, 2007 5:57 PM >>> Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >>> >>> >>> I read through >>> >>> > http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt > >>> At this point in time I only have high-level comments. >>> >>> I am not sure about the usefulness of the proposed mechanism. In >>> > some > >>> sense you dynamically establish an explicit route based on the >>> > initial > >>> routing of the message. Then, this information is used for >>> > subsequent > >>> messages. When something changes along the path then a new route >>> > is > >>> being "established" and cached by the originator. >>> >>> Diameter routes do not regularly change. If they change then there >>> > is > >> a >> >>> good reason (e.g., failure of a node). >>> This mechanism only seems to be useful for the cases where >>> > Diameter > >>> routes change because of some irrelevant reason but routing >>> > through > >> the >> >>> explicit path would still be possible. >>> [Tina: There is Relay Agent in Diameter routing path, at the same >>> >> time, in the case it has relative many next hop nodes, routing >> > probably > >> changes. >> >> Do we have these types of Diameter deployments already that have so >> > many > >> hops? >> >> >>> It is because that the Diameter Relay Agent is likely to select >>> > the > >> next hop node by random. >> >> Hmmm. Probably this is then the problem. We then shouldn't develop >> protocol extensions but rather write a document that indicates what >> > good > >> design for Relay Agents is. >> >> >>> In Diameter Base Protocol, usually when session starts, the >>> >> Destination-Host is not appointed. Only the Destination-Realm is >> appointed. However, >> >>> The subsequent requests in the session need to appoint >>> > Destination- > >> Host to assure it is routed to the same server, as the routing may >> changes. >> >>> And the mechanism define by this protocol, is to assure that it is >>> >> routed to the intermediate stateful Proxy Agent.] >> >> I agree that the issue sounds like a logical thing todo. >> I do, however, wonder whether this is going to be an issue in real >> > issue. > >>> Is there some evidence that the proposed mechanism would actually >>> > be > >>> helpful? >>> [Tina: Please look at the "Figure 1: Generic Stateful Proxy >>> > Problem" > >> in draft-tsou-dime-base-routing-ext-03.txt. >> >>> After a Diameter Relay Agent, there are two stateful Proxy Agents. >>> >>> VISITED NETWORK | HOME NETWORK >>> | >>> +--------+ +--------+ | +--------+ >>> | Client |<--->| Relay1 |<----->| Proxy1 | >>> +--------+ +--------+ | +--------+\ >>> \ | \+-------------+ >>> \ | | Home Server | >>> \| /+-------------+ >>> \ +--------+/ >>> |---| Proxy2 | >>> | +--------+ >>> >>> ] >>> >>> >>> >> Your proposal only helps if the Relay does random routing. I do, >> however, doubt that this is true. >> >> >>> Do we have some real-world data indicating that this is indeed a >>> >> problem >> >>> rather than an academic exercise? >>> [Tina: Here are some application with stateful Proxy Agent in 3GPP >>> > and > >> ETSI TISPAN. I think that if there is stateful Proxy Agent, such >> > mechanism > >> is needed. >> >>> [TS23.234] >>> 3GPP, "3GPP system to Wireles Local Area Network >>> > (WLAN) > >>> interworking; System description", 3GPP TS 23.234 >>> >> Version >> >>> 7.4.0 2006. >>> Here, 3GPP AAA Proxy is a stateful Proxy Agent. >>> >>> >>> RES/TISPAN-02045-NGN-R2 V0.0.5 >>> ETSI Standard >>> Telecommunications and Internet converged Services and >>> Protocols for Advanced Networking (TISPAN); >>> NGN Functional Architecture; >>> Network Attachment Sub-System (NASS) >>> >>> Here, in Visited NGN Network, the UAAF, CLF are also in this case. >>> ] >>> >>> >> I was told that there was a discussion in the 3GPP once about this >> aspect. The WLAN 3G interworking was done a long time ago and we have >> never heard back from them. >> >> I would like to hear from an operator that they have a large Diameter >> network and that issue turned out to be a problem. I would also be >> > happy > >> to hear from vendors what they do. I will certainly investigate this >> issue with vendors and operators. >> >> >> Ciao >> Hannes >> >> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 06 06:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0El1-0002Mg-UT; Thu, 06 Dec 2007 06:19:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0El0-0002MX-GL for dime@ietf.org; Thu, 06 Dec 2007 06:19:06 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Ekr-0000aM-M6 for dime@ietf.org; Thu, 06 Dec 2007 06:19:06 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM0009TKQ576@szxga04-in.huawei.com> for dime@ietf.org; Thu, 06 Dec 2007 19:18:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSM00B6IKQ2OP@szxga04-in.huawei.com> for dime@ietf.org; Thu, 06 Dec 2007 19:18:05 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSM006YEKQ2UV@szxml03-in.huawei.com> for dime@ietf.org; Thu, 06 Dec 2007 19:18:02 +0800 (CST) Date: Thu, 06 Dec 2007 19:18:02 +0800 From: Tony Zhang Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt In-reply-to: <47571FE6.6010602@gmx.net> To: 'Hannes Tschofenig' , "'Asveren, Tolga'" Message-id: <013e01c837f9$aa663af0$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acg3io2OIC7pWayZTu2iZ7Ma4ewV3wAbPP3g X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi: My comments: >The question is how relays route messages. If your deployment wants to >route Diameter messages differently per-session AND you are concerned >about the consequences then why do you put a stateless agent in there in >the first place. If just Use Diameter base protocol routing procedure ,the client also should face the problem when the next hop have many statefule agent. below deployment. VISITED NETWORK | HOME NETWORK | +--------+ | +--------+ | Client |<------------\-- ----->| Proxy1 | +--------+ \ | +--------+\ \ | \+-------------+ \ | | Home Server | \| /+-------------+ \ +--------+/ |---| Proxy2 | | +--------+ The another problem,any network node should not care about the network how to deployment.it should use same routing procedure for meet any network case. Tony. -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, December 06, 2007 6:02 AM To: Asveren, Tolga Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Hi Tolga, Asveren, Tolga wrote: > Hi Hannes, > > >> Your proposal only helps if the Relay does random routing. I do, >> however, doubt that this is true. >> > I think we have two issues related with this: > > 1) That relays should route messages for the same session always to the > same next hop is not mandated. It definitely is preferable to loadshare > traffic somehow, and a basic round-robin loadsharing could lead messages > of a single session to be sent to different entities. > The question is how relays route messages. If your deployment wants to route Diameter messages differently per-session AND you are concerned about the consequences then why do you put a stateless agent in there in the first place. > 2) It is preferable for the relays to be stateless from efficiency > perspective (and we also do not want to synchronize state between > relays). One way of doing "consistent routing" is running some type of > hash function on Session-Id to determine the next hop, but this also has > its challenges if the set of next hops change. > > I agree that you would want to have stateless routing. However, on the other hand here you seem to also want to * route messages as you want (almost randomly) * and at the same time ensure that the Diameter messages of a specific session is routed along the same path. I appreciate the text in Section 1.2. For example, Section 1.2.1 indicates that you have to have stateful proxies along the entire path. That's not necessary. You only need to have them at places where it really matters. Ciao Hannes > In Section 1.2 of the draft, there is some discussion about possible > workarounds with existing mechanisms. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, December 05, 2007 4:17 PM >> To: Tina TSOU >> Cc: dime@ietf.org >> Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >> >> Hi Tina, >> >> I just noticed that you replied to my mail. >> Please find further comments below: >> >> Tina TSOU wrote: >> >>> Dear Hannes, >>> Thank you for your review:) >>> Please see my comments in line demarked as [Tina: ...]. >>> >>> B. R. >>> Tina >>> -------------------------------------------------------- >>> Mondays aren't so bad; and pigs have wings... >>> ----- Original Message ----- >>> From: Hannes Tschofenig >>> To: dime@ietf.org >>> Sent: Sunday, November 25, 2007 5:57 PM >>> Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >>> >>> >>> I read through >>> >>> > http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt > >>> At this point in time I only have high-level comments. >>> >>> I am not sure about the usefulness of the proposed mechanism. In >>> > some > >>> sense you dynamically establish an explicit route based on the >>> > initial > >>> routing of the message. Then, this information is used for >>> > subsequent > >>> messages. When something changes along the path then a new route >>> > is > >>> being "established" and cached by the originator. >>> >>> Diameter routes do not regularly change. If they change then there >>> > is > >> a >> >>> good reason (e.g., failure of a node). >>> This mechanism only seems to be useful for the cases where >>> > Diameter > >>> routes change because of some irrelevant reason but routing >>> > through > >> the >> >>> explicit path would still be possible. >>> [Tina: There is Relay Agent in Diameter routing path, at the same >>> >> time, in the case it has relative many next hop nodes, routing >> > probably > >> changes. >> >> Do we have these types of Diameter deployments already that have so >> > many > >> hops? >> >> >>> It is because that the Diameter Relay Agent is likely to select >>> > the > >> next hop node by random. >> >> Hmmm. Probably this is then the problem. We then shouldn't develop >> protocol extensions but rather write a document that indicates what >> > good > >> design for Relay Agents is. >> >> >>> In Diameter Base Protocol, usually when session starts, the >>> >> Destination-Host is not appointed. Only the Destination-Realm is >> appointed. However, >> >>> The subsequent requests in the session need to appoint >>> > Destination- > >> Host to assure it is routed to the same server, as the routing may >> changes. >> >>> And the mechanism define by this protocol, is to assure that it is >>> >> routed to the intermediate stateful Proxy Agent.] >> >> I agree that the issue sounds like a logical thing todo. >> I do, however, wonder whether this is going to be an issue in real >> > issue. > >>> Is there some evidence that the proposed mechanism would actually >>> > be > >>> helpful? >>> [Tina: Please look at the "Figure 1: Generic Stateful Proxy >>> > Problem" > >> in draft-tsou-dime-base-routing-ext-03.txt. >> >>> After a Diameter Relay Agent, there are two stateful Proxy Agents. >>> >>> VISITED NETWORK | HOME NETWORK >>> | >>> +--------+ +--------+ | +--------+ >>> | Client |<--->| Relay1 |<----->| Proxy1 | >>> +--------+ +--------+ | +--------+\ >>> \ | \+-------------+ >>> \ | | Home Server | >>> \| /+-------------+ >>> \ +--------+/ >>> |---| Proxy2 | >>> | +--------+ >>> >>> ] >>> >>> >>> >> Your proposal only helps if the Relay does random routing. I do, >> however, doubt that this is true. >> >> >>> Do we have some real-world data indicating that this is indeed a >>> >> problem >> >>> rather than an academic exercise? >>> [Tina: Here are some application with stateful Proxy Agent in 3GPP >>> > and > >> ETSI TISPAN. I think that if there is stateful Proxy Agent, such >> > mechanism > >> is needed. >> >>> [TS23.234] >>> 3GPP, "3GPP system to Wireles Local Area Network >>> > (WLAN) > >>> interworking; System description", 3GPP TS 23.234 >>> >> Version >> >>> 7.4.0 2006. >>> Here, 3GPP AAA Proxy is a stateful Proxy Agent. >>> >>> >>> RES/TISPAN-02045-NGN-R2 V0.0.5 >>> ETSI Standard >>> Telecommunications and Internet converged Services and >>> Protocols for Advanced Networking (TISPAN); >>> NGN Functional Architecture; >>> Network Attachment Sub-System (NASS) >>> >>> Here, in Visited NGN Network, the UAAF, CLF are also in this case. >>> ] >>> >>> >> I was told that there was a discussion in the 3GPP once about this >> aspect. The WLAN 3G interworking was done a long time ago and we have >> never heard back from them. >> >> I would like to hear from an operator that they have a large Diameter >> network and that issue turned out to be a problem. I would also be >> > happy > >> to hear from vendors what they do. I will certainly investigate this >> issue with vendors and operators. >> >> >> Ciao >> Hannes >> >> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 06 13:14:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LEb-00008o-P3; Thu, 06 Dec 2007 13:14:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LEa-0008OP-7I for dime@ietf.org; Thu, 06 Dec 2007 13:14:04 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LEZ-0002Wx-6X for dime@ietf.org; Thu, 06 Dec 2007 13:14:04 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lB6IE1JE072886 for ; Thu, 6 Dec 2007 13:14:02 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47583BE9.9030600@tari.toshiba.com> Date: Thu, 06 Dec 2007 13:14:01 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Subject: [Dime] DIME Meeting minutes (IETF70) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Agenda Bashing -------------- * Very full agenda * Two parts, WG documents that are to be completed and new work RFC3588Bis Work --------------- * All open issues are now closed * Version 09 is in LC * Version 10 will contain latest comments from reviewers * No open issues. WGLC under way. Need more reviews. A few recent issues resolved. Hannes : Asked for reviewers - Jouni, Mark, Lionel MIPv6: NAS-HAAA support ----------------------- * Changes from 0x -> 05: Big rewrite to support RFC4285bis * Changes from 05 -> 06: Fixes surrounding 4825bis again * RO support * Open issues - split the ID into two - Replay protection * WGLC Hannes : We not going to split, we pass one LC and people are happy with the doc Gerardo : Disagree, 4285 solution is all informational in the bis Hannes : This is not a problem. In proto writeup its a downward reference. Gerardo : Don't see a reason why standard track document refers to informational docs. Hannes : Some sections are informational or downward reference. Dan : Could have non-normative reference. MIPv6: HA-AAA support --------------------- * Changes from 05 -> 06: Fine tuning * Changes from 06 -> 07: - Home-link-prefix AVP - Correcting flags again to make it application independent - Provide clear examples how to use MPv6 feature * Submit to IESG ? Hannes : WG LC already on this document. Need to issue a short LC for one week before IESG Qos Attributes -------------- * Changes from 01->02: - Add Qos profiles - Add flow states and direction - Add Qos object types * Chnages 02 -> 03: Renaming of AVPs etc * ID extends diameter base * New AVPs convey Qos as part of the NAS * Qos maybe pre-provisioned or NAS * Next steps: - Error codes - Reviews for WGLC required Hannes : Still has WGLC. Document has been sent to other SDOs and had good feedback Qos Parameters -------------- * Issued WGLC early. Turned out to be good since we found conflicts with NSIS and TSVWG. * Resolution was that tsvwg-emergency-rsp will create IANA register then QSPEC and DIME documents will point to the registry Francious : Resoultion announcement did not make it to the list. Will resend. Diameter App Guidelines ----------------------- * Updates from reviewers - Added M-bit clarification - Added min count on optional AVP - Added Vendor specific command codes - Fixed accounting model that uses different app-ids in header and body Reviewers : Jouni, Lionel, Mark Proxy MIPv6 ----------- * NETLM WG is finalizing the PMIPv6 * ID aims to support: MAG (NAS) to AAA and LMA(HA) to AAA * Proposed solutions: extends MPv6 boostrapping which is not specific to PMIPv6 * Issues: - RADIUS internetworking - Accounting on MAG & LMA - Session mngt - etc * Adopt as a WG work item ? Hannes : New work classified into categories. One would be work related to other work being done from other WGs Gerardo : Normal procedure is that the related mobility WG give us requirement for the work before starting something. Is this a procedural issue ? Do we need some requirement ? Hannes : We have several documents to look at for new work. But we do not need formal requirements from other WG to start work. Gerardo : NETLMM has a lot of issue for bootstrapping MAG and LMA. Those things belong to the NETLMM WG. Should this work be there as well ? Bechet : Similar issues arise for draft with RADIUS for NETLMM. We need to support this work. Regarding NETLMM requirements, theres no official view on this Glen : Is it a good thing to throw over to NETLMM since they know what they want to do ? Hannes : Worth while idea Dimaeter Qos ------------ * Changes: Split the document into framework and protocol. Still not sure if this is good idea or not. It may slow us down. * Changes: - Editorials - New terms - Handle discovery and selection (for push mode) - etc Francious : This does not cover control of signaling proxy behavior, do we all agree that this will taken care of in the next rev ? Hannes : More details are needed in the doc. Are there any IPR related issue ? Francious : Not sure. Not aware of one. Hannes : Most documetns are making good progress in the group except maybe this document. ** Rechartering Discussion Hannes : What are the priority for MIPv4 dime application ? Can we hum for interest in this work ? ** Hum: not strong but seems no objection Gerardo : What is the scope of this work ? Which are we talking about ? MAG profiles or bootstrapping of security ? Hannes : Who has read MIPv6 application ? We can take the discussion to the list Auditing -------- * History: 2 drafts on the subject, requirements and state-recovery (expired). The second considers possible design approachs * Why include this work ? - Evidence of functionlity and the need for both soft and hard state storage * Drafts go into requirements in details * Next steps ? - Add to the charter and merge both drafts - Decide use of resource management Hannes : We have ask the group in the past if work in this area is need ? There was good response plus liason from TISPAN for this work Glen : There are bunch of requirments in that document but not sure what the problem they're trying to solve or why theres a need for box communication Speaker : In the use cases section, there's are explanations for reasons and what the document is trying to solve Glen : There where use cases but did not lay out the problem they are trying to solve Speaker : The second doc talks at lenght on why a protocol method is needed. Hannes : This can be an action item to sort this out in the list. Diameter MIPv4 application -------------------------- * This is an alternative approach to DIME MIPv4 - we highligthed performance issue with respect to radius * RFC4004 provies AAA and MSA allocation but does not rely on access auth for MIPv4 MSA allocation * MIPv4 RRQ/RRP are coupled with RFC4004 * 3GPP2 and WIMAX use EAP for access auth * HA in 3GPP2 and WiMAX need to fetch MN-HA secret key * Recommendations - New model for diameter MIPv4 must support new messages between HA and HAAA for MIPv4 authorization and MH-HA, FA-HA, MSA * Can approve a need for diameter MIPv4 Glen : 3GPP2 and WiMAX has taken standard IETF protocol and misuse it and now want us to change the standard to support them ? Ahmad : Old MIPv4 does not use access authentication. They still need diameter at the HA. Hannes : There are many details so lets take it to the list, Pete's going to talk about MIPv4 that has a different deployment model RFC4004bis ---------- * Changes: No major overhaul, just fixes a few bugs * Left out the AAA-SPI needed for 3957, MN-FA SPI is created by the FA but not being transfered in the AMR * MN-HA SPI is not needed in the MN-HA MSA AVP * Changed text in section 9.5 Hannes : Its not a competing type with the alternative dime MIPv4 apps. The document change is a small effort. Some of these issue came up with dime MIPv6 work as well. Alper : Is this going to be done in DIME. In WiMAX, we only discuss concept. We would like to separate signaling from diameter. We would like to bring this to idea to IETF. Hannes : We generally do not care where the idea came from. We will still review it. Diameter Classifier ------------------- * Document defines a grouped AVP which can be used to express and IP or L2 packet classifier * Benefits: more extensible than ASCII and decouples condition from action and in the filter rule * Propose this as a dime WG work item. Its straight-forward work and well-defined Hannes : Presented in last IETF. Came in the context of the RADEXT Hannes : Who has read the document ... only a few Prefix Delegation ----------------- * The LMA prefix managment in proxy MIPv6 * NEMO requires prefix manamagement * Diameter-PD vs DHCP-PD, both solutions are complementary with each other * operators can choose a solution * It is a natural extension to IP address manaanment * Proposals: put it into DIME re-charting Hannes : We can discuss this issue in the mobility working group, mext group Support for ERP --------------- * Support for ERP (EAP re-authentication) * Message needs to be carried over RADIUS/Diameter * Carry new EAP codes in diameter messages. Nas needs to copy the content of rikname-nai tlv, rmsk is sent via eap-master-sesison-key * dsrk request and delivery Hannes : Work in some other WG, some interaction with backend. Use next weeks to discuss different proposals. Who wants them and for whatever reasons. Claim the need for that work is justified. Speaker : Some discussion in the HOAKEY WG Dan : Criteria - Need to prove operational need for the doc. pool of reviewers for this doc. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 06 13:45:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lj3-0001Rl-Nq; Thu, 06 Dec 2007 13:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Lj2-0001Qf-It for dime@ietf.org; Thu, 06 Dec 2007 13:45:32 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Lj1-00075h-Jj for dime@ietf.org; Thu, 06 Dec 2007 13:45:32 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lB6IjLjM010233; Thu, 6 Dec 2007 13:45:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Thu, 6 Dec 2007 13:45:21 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E750961C@sonusmail04.sonusnet.com> In-Reply-To: <47571FE6.6010602@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg3ioLS/8xH3HJrSdGYaTAoMPsS7AArHsaA References: <4749471C.8090507@gmx.net><012401c8300c$b2ba3e30$544c460a@china.huawei.com> <4757153B.2060802@gmx.net> <033458F56EC2A64E8D2D7B759FA3E7E7509610@sonusmail04.sonusnet.com> <47571FE6.6010602@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, December 05, 2007 5:02 PM > To: Asveren, Tolga > Cc: Tina TSOU; dime@ietf.org > Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > Hi Tolga, >=20 > Asveren, Tolga wrote: > > Hi Hannes, > > > > > >> Your proposal only helps if the Relay does random routing. I do, > >> however, doubt that this is true. > >> > > I think we have two issues related with this: > > > > 1) That relays should route messages for the same session always to the > > same next hop is not mandated. It definitely is preferable to loadshare > > traffic somehow, and a basic round-robin loadsharing could lead messages > > of a single session to be sent to different entities. > > > The question is how relays route messages. If your deployment wants to > route Diameter messages differently per-session AND you are concerned > about the consequences then why do you put a stateless agent in there in > the first place. [TOLGA]There are different use cases for intermediaries. For example, an intermediary which is performing some level of policing may need to be stateful. OTOH, a node whose purpose is to loadbalance does not really need to be stateful. It is possible to have these two types of intermediaries in the same network and this is what creates the problem case. >=20 > > 2) It is preferable for the relays to be stateless from efficiency > > perspective (and we also do not want to synchronize state between > > relays). One way of doing "consistent routing" is running some type of > > hash function on Session-Id to determine the next hop, but this also has > > its challenges if the set of next hops change. > > > > > I agree that you would want to have stateless routing. > However, on the other hand here you seem to also want to > * route messages as you want (almost randomly) > * and at the same time ensure that the Diameter messages of a specific > session is routed along the same path. >=20 > I appreciate the text in Section 1.2. > For example, Section 1.2.1 indicates that you have to have stateful > proxies along the entire path. > That's not necessary. You only need to have them at places where it > really matters. [TOLGA]If one has a mix of staful and steles entities, there is no guarantee that the right stateful entity will get all of the messages for a particular session, because stateless entities may select the next hop quite randomly. Based on existing specification, the solution seems to be to make all entities stateful (hashing is promising but seems to fall short providing a full stateful solution). >=20 > Ciao > Hannes >=20 > > In Section 1.2 of the draft, there is some discussion about possible > > workarounds with existing mechanisms. > > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Wednesday, December 05, 2007 4:17 PM > >> To: Tina TSOU > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > >> > >> Hi Tina, > >> > >> I just noticed that you replied to my mail. > >> Please find further comments below: > >> > >> Tina TSOU wrote: > >> > >>> Dear Hannes, > >>> Thank you for your review:) > >>> Please see my comments in line demarked as [Tina: ...]. > >>> > >>> B. R. > >>> Tina > >>> -------------------------------------------------------- > >>> Mondays aren't so bad; and pigs have wings... > >>> ----- Original Message ----- > >>> From: Hannes Tschofenig > >>> To: dime@ietf.org > >>> Sent: Sunday, November 25, 2007 5:57 PM > >>> Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > >>> > >>> > >>> I read through > >>> > >>> > > http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt > > > >>> At this point in time I only have high-level comments. > >>> > >>> I am not sure about the usefulness of the proposed mechanism. In > >>> > > some > > > >>> sense you dynamically establish an explicit route based on the > >>> > > initial > > > >>> routing of the message. Then, this information is used for > >>> > > subsequent > > > >>> messages. When something changes along the path then a new route > >>> > > is > > > >>> being "established" and cached by the originator. > >>> > >>> Diameter routes do not regularly change. If they change then there > >>> > > is > > > >> a > >> > >>> good reason (e.g., failure of a node). > >>> This mechanism only seems to be useful for the cases where > >>> > > Diameter > > > >>> routes change because of some irrelevant reason but routing > >>> > > through > > > >> the > >> > >>> explicit path would still be possible. > >>> [Tina: There is Relay Agent in Diameter routing path, at the same > >>> > >> time, in the case it has relative many next hop nodes, routing > >> > > probably > > > >> changes. > >> > >> Do we have these types of Diameter deployments already that have so > >> > > many > > > >> hops? > >> > >> > >>> It is because that the Diameter Relay Agent is likely to select > >>> > > the > > > >> next hop node by random. > >> > >> Hmmm. Probably this is then the problem. We then shouldn't develop > >> protocol extensions but rather write a document that indicates what > >> > > good > > > >> design for Relay Agents is. > >> > >> > >>> In Diameter Base Protocol, usually when session starts, the > >>> > >> Destination-Host is not appointed. Only the Destination-Realm is > >> appointed. However, > >> > >>> The subsequent requests in the session need to appoint > >>> > > Destination- > > > >> Host to assure it is routed to the same server, as the routing may > >> changes. > >> > >>> And the mechanism define by this protocol, is to assure that it is > >>> > >> routed to the intermediate stateful Proxy Agent.] > >> > >> I agree that the issue sounds like a logical thing todo. > >> I do, however, wonder whether this is going to be an issue in real > >> > > issue. > > > >>> Is there some evidence that the proposed mechanism would actually > >>> > > be > > > >>> helpful? > >>> [Tina: Please look at the "Figure 1: Generic Stateful Proxy > >>> > > Problem" > > > >> in draft-tsou-dime-base-routing-ext-03.txt. > >> > >>> After a Diameter Relay Agent, there are two stateful Proxy Agents. > >>> > >>> VISITED NETWORK | HOME NETWORK > >>> | > >>> +--------+ +--------+ | +--------+ > >>> | Client |<--->| Relay1 |<----->| Proxy1 | > >>> +--------+ +--------+ | +--------+\ > >>> \ | \+-------------+ > >>> \ | | Home Server | > >>> \| /+-------------+ > >>> \ +--------+/ > >>> |---| Proxy2 | > >>> | +--------+ > >>> > >>> ] > >>> > >>> > >>> > >> Your proposal only helps if the Relay does random routing. I do, > >> however, doubt that this is true. > >> > >> > >>> Do we have some real-world data indicating that this is indeed a > >>> > >> problem > >> > >>> rather than an academic exercise? > >>> [Tina: Here are some application with stateful Proxy Agent in 3GPP > >>> > > and > > > >> ETSI TISPAN. I think that if there is stateful Proxy Agent, such > >> > > mechanism > > > >> is needed. > >> > >>> [TS23.234] > >>> 3GPP, "3GPP system to Wireles Local Area Network > >>> > > (WLAN) > > > >>> interworking; System description", 3GPP TS 23.234 > >>> > >> Version > >> > >>> 7.4.0 2006. > >>> Here, 3GPP AAA Proxy is a stateful Proxy Agent. > >>> > >>> > >>> RES/TISPAN-02045-NGN-R2 V0.0.5 > >>> ETSI Standard > >>> Telecommunications and Internet converged Services and > >>> Protocols for Advanced Networking (TISPAN); > >>> NGN Functional Architecture; > >>> Network Attachment Sub-System (NASS) > >>> > >>> Here, in Visited NGN Network, the UAAF, CLF are also in this case. > >>> ] > >>> > >>> > >> I was told that there was a discussion in the 3GPP once about this > >> aspect. The WLAN 3G interworking was done a long time ago and we have > >> never heard back from them. > >> > >> I would like to hear from an operator that they have a large Diameter > >> network and that issue turned out to be a problem. I would also be > >> > > happy > > > >> to hear from vendors what they do. I will certainly investigate this > >> issue with vendors and operators. > >> > >> > >> Ciao > >> Hannes > >> > >> > >>> Ciao > >>> Hannes > >>> > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 06 14:21:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MHO-0001Gr-GE; Thu, 06 Dec 2007 14:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MHM-0001GV-Kt for dime@ietf.org; Thu, 06 Dec 2007 14:21:00 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0MHK-0001NJ-3h for dime@ietf.org; Thu, 06 Dec 2007 14:21:00 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 20:20:56 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Thu, 6 Dec 2007 20:20:43 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> In-Reply-To: <4757153B.2060802@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg3hC2XRkOjYh6LSkuAjJpIOpAKkgAtQN7Q From: To: , X-OriginalArrivalTime: 06 Dec 2007 19:20:56.0779 (UTC) FILETIME=[206639B0:01C8383D] X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, Few comments inline.=20 [snip] > > [Tina: There is Relay Agent in Diameter routing path, at=20 > the same time, in the case it has relative many next hop=20 > nodes, routing probably changes. > > =20 > Do we have these types of Diameter deployments already that=20 > have so many hops? Do we have large deployments in general that have inter-operator interfaces? At this stage requiring deployment experience is kinda weird. I mean, there are identified issues slash grey areas, so why not study and document those before we hit them in real deployments? > > It is because that the Diameter Relay Agent is likely to=20 > select the next hop node by random. > > =20 > Hmmm. Probably this is then the problem. We then shouldn't=20 > develop protocol extensions but rather write a document that=20 > indicates what good design for Relay Agents is. IMHO that still does not make the issue go away. [snap] > > Do we have some real-world data indicating that this is=20 > indeed a problem=20 > > rather than an academic exercise? > > [Tina: Here are some application with stateful Proxy=20 > Agent in 3GPP and ETSI TISPAN. I think that if there is=20 > stateful Proxy Agent, such mechanism is needed. > > [TS23.234] > > 3GPP, "3GPP system to Wireles Local Area=20 > Network (WLAN) > > interworking; System description", 3GPP TS=20 > 23.234 Version > > 7.4.0 2006. > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. [chop] =20 > I was told that there was a discussion in the 3GPP once about=20 > this aspect. The WLAN 3G interworking was done a long time=20 > ago and we have never heard back from them. Heard back what? In 3GPP routing etc is again under discussion in rel-8 timeframe. Coming back to above reference, the same family of scary specs also use NAI decoration based source routing as part of NASREQ & EAP application for selecting the next hop. I cannot find this (might be a result of sloppy reading) feature being described anywhere in Diameter specification thus I suspect it will actually work. Or can we just assume that everything defined in RFC4282 gets reflected back to existing applications? > I would like to hear from an operator that they have a large=20 > Diameter network and that issue turned out to be a problem. I=20 > would also be happy to hear from vendors what they do. I will=20 > certainly investigate this issue with vendors and operators. Rather ask.. "an operator that have a large Diameter network with inter-operator interfaces in multi-vendor environment" ;) Cheers, Jouni >=20 >=20 > Ciao > Hannes >=20 > > Ciao > > Hannes >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 06 14:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MLM-00027r-6O; Thu, 06 Dec 2007 14:25:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0MLL-00027m-34 for dime@ietf.org; Thu, 06 Dec 2007 14:25:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0MLJ-000051-Tm for dime@ietf.org; Thu, 06 Dec 2007 14:25:07 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Dec 2007 11:25:05 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB6JP5tC010358 for ; Thu, 6 Dec 2007 11:25:05 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB6JP025003027 for ; Thu, 6 Dec 2007 19:25:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 11:25:04 -0800 Received: from [130.129.17.241] ([10.21.148.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 11:25:03 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) To: dime@ietf.org Message-Id: <01CD6E29-1847-472E-96E8-C8000CCAF092@cisco.com> References: From: Francois Le Faucheur IMAP Date: Thu, 6 Dec 2007 11:25:01 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 06 Dec 2007 19:25:03.0660 (UTC) FILETIME=[B38D46C0:01C8383D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14062; t=1196969105; x=1197833105; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Resolution=20of=20issue=20on=20QoS=20Parameters=20encoding=20 in=20, =20=20&=20 |Sender:=20; bh=KLaNDAWi/uFDo59sNxgIbyjTNMa+QqVB1/mlZRPlPk8=; b=VrrwLWMdeshiPE+hyW+EawYut+KhnRgSYx4BXD30yCYG6gx91tUYEe9tl+TnZwZhG26v3Flr AoxFkxkGS3LsfGGs5FuzZcONCecPHBorG6Z5nWdUfYS9YNlz8MqZzS6gRlz63vyfF1UAAPxKpF uUz/K0KO0eEdm7NUsnJDY9i54=; Authentication-Results: sj-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Subject: [Dime] Resolution of issue on QoS Parameters encoding in , & X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329896197==" Errors-To: dime-bounces@ietf.org --===============0329896197== Content-Type: multipart/alternative; boundary=Apple-Mail-7--381430596 --Apple-Mail-7--381430596 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI. Francois Begin forwarded message: > From: Francois Le Faucheur > Date: 4 December 2007 18:37:08 GMT-08:00 > To: tsvwg tsvwg > Cc: Francois Le Faucheur > Subject: Resolution of issue on QoS Parameters encoding in qos-parameters>, & > > Hello, > > There was one pending issue with draft-ietf-tsvwg-emergency-rsvp. > This related to consistent QoS Parameters encoding across qos-parameters>, and . Please > find below the proposed resolution that was developed by co-authors > of the three I-Ds as well as WG chairs of the corresponding WGs. > Please let us know if you have issue/concern with this. > > Thanks > > Francois > > > The Issue: > ======= > Three different documents (dime-qos-parameters, nsis-qos-nslp, > tsvwg-emergency-rsvp) need to convey an overlapping set of QoS > parameters (specifically RPH-Priority and Admission Priority) and > currently do that in an inconsistent manner. This has been brought > up and partially discussed on the WG mailing lists. > > The Proposed Resolution > =================== > Co-authors of the three I-Ds as well as WG chairs of the > corresponding WGs converged on the following proposed resolution. > Please let us know if you have an issue/concern with this. > > o Regarding RPH-Priority: > * tsvwg-emergency-rsvp will go ahead with its requests to IANA to > provide numerical registry for RPH priority (via extending existing > RPH registry). See IANA Considerations section of tsvwg-emergency- > rsvp. > * nsis-qspec (in section 6.2.10) will point to this registry > instead of defining its own values > * dime-qos-parameters (in section 4.11) will point to this > registry instead of defining its own values > * tsvwg-emergency-rsvp (in section 3.2) will keep pointing to this > registry. > > o Regarding Admission Priority: > * every protocol spec will only indicate that "higher value means > higher priority". > * there is no attempt to define what specific values should be > used for what. this is left outside the scope of the protocol specs. > * each protocol spec will add a statement clarifying that a given > Admission Priority is to be encoded with the same value in each of > the three protocol spec. For example, in tsvwg-emergency-rsvp, > under section 3.1. we will add: > " A given Admission Priority is encoded in this information > element > using the same value as when encoded in the Admission Priority > parameter defined in section 6.2.9 of [nsis-qspec], or in the > Admission > Priority parameter defined in section 4.10 of [dime-qos-parameters]. > In other words, a given value in any of the [emergency-rsvp] > Admission > Priority information element, the [nsis-qspec] Admission Priority > parameter > or the [dime-qos-parameters] Admission Priority parameter, refers to > the same Admission Priority. > " > * the mirror statement will be added in nsis-qspec (section 6.2.9) > and dime-qos-parameters (section 4.10) > > Francois > --Apple-Mail-7--381430596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI.
Francois

Begin forwarded message:

From: = Francois Le Faucheur <flefauch@cisco.com>
=
Date: = 4 December 2007 18:37:08 GMT-08:00
To: tsvwg = tsvwg <tsvwg@ietf.org>
Cc: Francois = Le Faucheur <flefauch@cisco.com>
=
Subject: = Resolution of issue on QoS Parameters encoding in = <dime-qos-parameters>, <nsis-qspec> & = <tsvwg-emergency-rsvp>


There was one pending issue with = draft-ietf-tsvwg-emergency-rsvp. This related to consistent QoS = Parameters encoding across=A0 = <dime-qos-parameters>, <nsis-qspec> and = <tsvwg-emergency-rsvp>. Please find below the proposed resolution = that was developed by co-authors of the three I-Ds as well as WG chairs = of the corresponding WGs. Please let us know if you have issue/concern = with this.

Thanks

Francois


The = Issue:
=3D=3D=3D=3D=3D=3D=3D
Three different documents (dime-qos-parameters, = nsis-qos-nslp, tsvwg-emergency-rsvp) need to convey an overlapping set = of QoS parameters (specifically RPH-Priority and Admission Priority) and = currently do that in an inconsistent manner. This has been brought up = and partially discussed on the WG mailing lists.

The = Proposed Resolution
Co-authors of the three I-Ds as well as WG chairs of = the corresponding WGs converged on the following proposed resolution. = Please let us know if you have an issue/concern with this.

o = Regarding RPH-Priority:
* = tsvwg-emergency-rsvp will go ahead with its requests to IANA to provide = numerical registry for RPH priority (via extending existing RPH = registry). See IANA Considerations section of = tsvwg-emergency-rsvp.
* = nsis-qspec (in section 6.2.10) will point to this registry instead of = defining its own values
* = dime-qos-parameters (in section 4.11) will point to this registry = instead of defining its own values
* = tsvwg-emergency-rsvp (in section 3.2) will keep pointing to this = registry.

o Regarding Admission Priority:
* every protocol spec will only = indicate that "higher value means higher priority".
* there is no attempt to define = what specific values should be used for what. this is left outside the = scope of the protocol specs.
* each = protocol spec will add a statement clarifying that a given Admission = Priority is to be encoded with the same value in each of the three = protocol spec. For example, in tsvwg-emergency-rsvp, under section = 3.1.=A0 we will = add:
"=A0 =A0 =A0 A given Admission = Priority is encoded in this information element
using the same value as when = encoded in the Admission Priority
parameter = defined in section 6.2.9 of [nsis-qspec], or in the Admission
Priority parameter defined in = section 4.10 of [dime-qos-parameters].
In other = words, a given value in any of the [emergency-rsvp] Admission
Priority information element, the = [nsis-qspec] Admission Priority parameter
or the = [dime-qos-parameters] Admission Priority parameter, refers to
the same Admission = Priority.
"
* the = mirror statement will be added in nsis-qspec (section 6.2.9) and = dime-qos-parameters (section 4.10)

Francois

=

= --Apple-Mail-7--381430596-- --===============0329896197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0329896197==-- From dime-bounces@ietf.org Mon Dec 10 13:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n0n-0005Nc-Qq; Mon, 10 Dec 2007 13:05:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1n0m-0005NW-Nh for dime@ietf.org; Mon, 10 Dec 2007 13:05:48 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1n0m-0002ac-21 for dime@ietf.org; Mon, 10 Dec 2007 13:05:48 -0500 Received: by nz-out-0506.google.com with SMTP id n1so606375nzf for ; Mon, 10 Dec 2007 10:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=4fo+hnthTq9QLI5/QSXebYuBK6RV0KJEv5toyjpQZgk=; b=eCtXhJTKzbNDWL1TK2vUJQpdWjzm5qgvvory/diwRktvLr46FIk9wIyMpl6s6yUVezCEnSn4by/NuG/bULQKiMuGK1qBKXc1L6mE8ep5Gi/YDJJbj0LYwMIYY9DwzxE2gy35v4laT8tHPTE+GROZDAYgB1g66YQSgunTP1S2nnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HYYQGsTOAYDKmBsELYjvTWh1jiEDCvxpX2SgfATseqAvhBedSqU3/W29qVY+BpIqpoJg4aKIWMuRaNtmQx50UFRLv7O4IrSONwBNlKTbqepuBgnzgS+OojPx3OOYM34awRYiXWXRulI4kC7mecRvfD6pttZlrAA8PS+lRVZ9lp4= Received: by 10.142.165.9 with SMTP id n9mr629621wfe.1197309942480; Mon, 10 Dec 2007 10:05:42 -0800 (PST) Received: by 10.142.194.16 with HTTP; Mon, 10 Dec 2007 10:05:42 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 20:05:42 +0200 From: "Gil Shafran" To: dime@ietf.org Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4757153B.2060802@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> X-Google-Sender-Auth: e7c4d11f5abdd776 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, IMHO, visited network clients should not force an explicit routing in network domains of other operators. I believe operators would prefer to fully control their load balancing and routing issues. They can also assure routing through their own stateful Diameter proxies. Using the existing Diameter routing definitions (RFC 3588), an operator has only rough knowledge and control (destination realm) over other networks, which is a good modular model. Regards, Gil On Dec 6, 2007 9:20 PM, wrote: > Hannes, > > Few comments inline. > > [snip] > > > > [Tina: There is Relay Agent in Diameter routing path, at > > the same time, in the case it has relative many next hop > > nodes, routing probably changes. > > > > > Do we have these types of Diameter deployments already that > > have so many hops? > > Do we have large deployments in general that have inter-operator > interfaces? At this stage requiring deployment experience is > kinda weird. I mean, there are identified issues slash grey > areas, so why not study and document those before we hit them > in real deployments? > > > > It is because that the Diameter Relay Agent is likely to > > select the next hop node by random. > > > > > Hmmm. Probably this is then the problem. We then shouldn't > > develop protocol extensions but rather write a document that > > indicates what good design for Relay Agents is. > > IMHO that still does not make the issue go away. > > [snap] > > > > Do we have some real-world data indicating that this is > > indeed a problem > > > rather than an academic exercise? > > > [Tina: Here are some application with stateful Proxy > > Agent in 3GPP and ETSI TISPAN. I think that if there is > > stateful Proxy Agent, such mechanism is needed. > > > [TS23.234] > > > 3GPP, "3GPP system to Wireles Local Area > > Network (WLAN) > > > interworking; System description", 3GPP TS > > 23.234 Version > > > 7.4.0 2006. > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > [chop] > > > I was told that there was a discussion in the 3GPP once about > > this aspect. The WLAN 3G interworking was done a long time > > ago and we have never heard back from them. > > Heard back what? In 3GPP routing etc is again under discussion > in rel-8 timeframe. Coming back to above reference, the same > family of scary specs also use NAI decoration based source > routing as part of NASREQ & EAP application for selecting the > next hop. I cannot find this (might be a result of sloppy reading) > feature being described anywhere in Diameter specification thus I > suspect it will actually work. Or can we just assume that everything > defined in RFC4282 gets reflected back to existing applications? > > > I would like to hear from an operator that they have a large > > Diameter network and that issue turned out to be a problem. I > > would also be happy to hear from vendors what they do. I will > > certainly investigate this issue with vendors and operators. > > Rather ask.. "an operator that have a large Diameter network > with inter-operator interfaces in multi-vendor environment" ;) > > > Cheers, > Jouni > > > > > > > > Ciao > > Hannes > > > > > Ciao > > > Hannes > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 10 14:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oGr-0003eH-6J; Mon, 10 Dec 2007 14:26:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oGp-0003eB-Ut for dime@ietf.org; Mon, 10 Dec 2007 14:26:28 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1oGp-0005NN-BM for dime@ietf.org; Mon, 10 Dec 2007 14:26:27 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lBAJQQdX027364; Mon, 10 Dec 2007 14:26:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Mon, 10 Dec 2007 14:26:25 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1bBzx35dE/uTVyXf2WFmqEsWwACTyjQ References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> From: "Asveren, Tolga" To: "Gil Shafran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gil, I think explicit routing issue is more related with visited network (actually any network) trying to make sure that messages for a session traverse some of the intermediaries, which were used during routing of the initial request for that particular session. I don't see this mechanism as the originator of the session enforcing a path (potentially/partly in another network) before the session is established. BTW, intermediaries which do not want to stay on the path don't need to participate. A network with all elements stateful won't have an issue but here the key point is that *all* elements should have the intelligence to select the same next-hope for all requests of a particular session. Thanks, Tolga > -----Original Message----- > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > Sent: Monday, December 10, 2007 1:06 PM > To: dime@ietf.org > Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > Hi all, >=20 > IMHO, visited network clients should not force an explicit routing in > network domains of other operators. I believe operators would prefer > to fully control their load balancing and routing issues. They can > also assure routing through their own stateful Diameter proxies. Using > the existing Diameter routing definitions (RFC 3588), an operator has > only rough knowledge and control (destination realm) over other > networks, which is a good modular model. >=20 > Regards, > Gil >=20 >=20 > On Dec 6, 2007 9:20 PM, wrote: > > Hannes, > > > > Few comments inline. > > > > [snip] > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > the same time, in the case it has relative many next hop > > > nodes, routing probably changes. > > > > > > > Do we have these types of Diameter deployments already that > > > have so many hops? > > > > Do we have large deployments in general that have inter-operator > > interfaces? At this stage requiring deployment experience is > > kinda weird. I mean, there are identified issues slash grey > > areas, so why not study and document those before we hit them > > in real deployments? > > > > > > It is because that the Diameter Relay Agent is likely to > > > select the next hop node by random. > > > > > > > Hmmm. Probably this is then the problem. We then shouldn't > > > develop protocol extensions but rather write a document that > > > indicates what good design for Relay Agents is. > > > > IMHO that still does not make the issue go away. > > > > [snap] > > > > > > Do we have some real-world data indicating that this is > > > indeed a problem > > > > rather than an academic exercise? > > > > [Tina: Here are some application with stateful Proxy > > > Agent in 3GPP and ETSI TISPAN. I think that if there is > > > stateful Proxy Agent, such mechanism is needed. > > > > [TS23.234] > > > > 3GPP, "3GPP system to Wireles Local Area > > > Network (WLAN) > > > > interworking; System description", 3GPP TS > > > 23.234 Version > > > > 7.4.0 2006. > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > [chop] > > > > > I was told that there was a discussion in the 3GPP once about > > > this aspect. The WLAN 3G interworking was done a long time > > > ago and we have never heard back from them. > > > > Heard back what? In 3GPP routing etc is again under discussion > > in rel-8 timeframe. Coming back to above reference, the same > > family of scary specs also use NAI decoration based source > > routing as part of NASREQ & EAP application for selecting the > > next hop. I cannot find this (might be a result of sloppy reading) > > feature being described anywhere in Diameter specification thus I > > suspect it will actually work. Or can we just assume that everything > > defined in RFC4282 gets reflected back to existing applications? > > > > > I would like to hear from an operator that they have a large > > > Diameter network and that issue turned out to be a problem. I > > > would also be happy to hear from vendors what they do. I will > > > certainly investigate this issue with vendors and operators. > > > > Rather ask.. "an operator that have a large Diameter network > > with inter-operator interfaces in multi-vendor environment" ;) > > > > > > Cheers, > > Jouni > > > > > > > > > > > > > Ciao > > > Hannes > > > > > > > Ciao > > > > Hannes > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 10 16:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pqc-0001Gc-0m; Mon, 10 Dec 2007 16:07:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pqa-0001C0-Uv for dime@ietf.org; Mon, 10 Dec 2007 16:07:29 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1pqZ-00084M-US for dime@ietf.org; Mon, 10 Dec 2007 16:07:28 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 22:07:24 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Mon, 10 Dec 2007 22:07:23 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1X6yiO+AoLiTfm8vnb3hd0GnQACsyyg References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> From: To: , X-OriginalArrivalTime: 10 Dec 2007 21:07:24.0176 (UTC) FILETIME=[A93CA900:01C83B70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Gil, The functionality referenced earlier was actually requested by operators to enable some of their potential roaming and deployment scenarios. "Forcing" next hop is, for example,=20 for deployments where a shared NAP advertises a number direct roaming connections for realms (say A.com, B.com and C.com) but none of them match to roaming user's home realm (say D.com). However, the roaming user knows that B.com has an agreement with D.com, thus it asks from NAP for an "authentication route" to D.com through B.com. After this all subsequent messages should take the same path (either on realm or actual agent granularity depending on the deployment). Cheers, Jouni > -----Original Message----- > From: Gil Shafran [mailto:gshafran@traffixsystems.com]=20 > Sent: 10. joulukuuta 2007 20:06 > To: dime@ietf.org > Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 >=20 > Hi all, >=20 > IMHO, visited network clients should not force an explicit=20 > routing in network domains of other operators. I believe=20 > operators would prefer to fully control their load balancing=20 > and routing issues. They can also assure routing through=20 > their own stateful Diameter proxies. Using the existing=20 > Diameter routing definitions (RFC 3588), an operator has only=20 > rough knowledge and control (destination realm) over other=20 > networks, which is a good modular model. >=20 > Regards, > Gil >=20 >=20 > On Dec 6, 2007 9:20 PM, wrote: > > Hannes, > > > > Few comments inline. > > > > [snip] > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > the same time, in the case it has relative many next hop nodes,=20 > > > routing probably changes. > > > > > > > Do we have these types of Diameter deployments already=20 > that have so=20 > > > many hops? > > > > Do we have large deployments in general that have inter-operator=20 > > interfaces? At this stage requiring deployment experience is kinda=20 > > weird. I mean, there are identified issues slash grey areas, so why=20 > > not study and document those before we hit them in real deployments? > > > > > > It is because that the Diameter Relay Agent is likely to > > > select the next hop node by random. > > > > > > > Hmmm. Probably this is then the problem. We then=20 > shouldn't develop=20 > > > protocol extensions but rather write a document that=20 > indicates what=20 > > > good design for Relay Agents is. > > > > IMHO that still does not make the issue go away. > > > > [snap] > > > > > > Do we have some real-world data indicating that this is > > > indeed a problem > > > > rather than an academic exercise? > > > > [Tina: Here are some application with stateful Proxy > > > Agent in 3GPP and ETSI TISPAN. I think that if there is stateful=20 > > > Proxy Agent, such mechanism is needed. > > > > [TS23.234] > > > > 3GPP, "3GPP system to Wireles Local Area > > > Network (WLAN) > > > > interworking; System description", 3GPP TS > > > 23.234 Version > > > > 7.4.0 2006. > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > [chop] > > > > > I was told that there was a discussion in the 3GPP once=20 > about this=20 > > > aspect. The WLAN 3G interworking was done a long time ago and we=20 > > > have never heard back from them. > > > > Heard back what? In 3GPP routing etc is again under discussion in=20 > > rel-8 timeframe. Coming back to above reference, the same family of=20 > > scary specs also use NAI decoration based source routing as part of=20 > > NASREQ & EAP application for selecting the next hop. I cannot find=20 > > this (might be a result of sloppy reading) feature being described=20 > > anywhere in Diameter specification thus I suspect it will actually=20 > > work. Or can we just assume that everything defined in RFC4282 gets=20 > > reflected back to existing applications? > > > > > I would like to hear from an operator that they have a large=20 > > > Diameter network and that issue turned out to be a=20 > problem. I would=20 > > > also be happy to hear from vendors what they do. I will certainly=20 > > > investigate this issue with vendors and operators. > > > > Rather ask.. "an operator that have a large Diameter network with=20 > > inter-operator interfaces in multi-vendor environment" ;) > > > > > > Cheers, > > Jouni > > > > > > > > > > > > > Ciao > > > Hannes > > > > > > > Ciao > > > > Hannes > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 10 16:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pxy-00087v-IH; Mon, 10 Dec 2007 16:15:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pxy-00083q-3d for dime@ietf.org; Mon, 10 Dec 2007 16:15:06 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1pxx-0008Ho-Bo for dime@ietf.org; Mon, 10 Dec 2007 16:15:06 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lBALF4Jv007913; Mon, 10 Dec 2007 16:15:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Mon, 10 Dec 2007 16:15:04 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509626@sonusmail04.sonusnet.com> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1X6yiO+AoLiTfm8vnb3hd0GnQACsyygAAPMaYA= References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> From: "Asveren, Tolga" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, A bit off topic but one question below. Thanks, Tolga > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Monday, December 10, 2007 4:07 PM > To: gshafran@traffixsystems.com; dime@ietf.org > Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > Hi Gil, >=20 > The functionality referenced earlier was actually requested > by operators to enable some of their potential roaming and > deployment scenarios. "Forcing" next hop is, for example, > for deployments where a shared NAP advertises a number direct > roaming connections for realms (say A.com, B.com and C.com) but [TOLGA]How does this advertisement work? Capability exchange mechanism does not have that type of capability(i.e. advertising application support per realm). > none of them match to roaming user's home realm (say D.com). > However, the roaming user knows that B.com has an agreement > with D.com, thus it asks from NAP for an "authentication route" > to D.com through B.com. After this all subsequent messages > should take the same path (either on realm or actual agent > granularity depending on the deployment). >=20 > Cheers, > Jouni >=20 >=20 >=20 > > -----Original Message----- > > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > > Sent: 10. joulukuuta 2007 20:06 > > To: dime@ietf.org > > Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > > > > > > Hi all, > > > > IMHO, visited network clients should not force an explicit > > routing in network domains of other operators. I believe > > operators would prefer to fully control their load balancing > > and routing issues. They can also assure routing through > > their own stateful Diameter proxies. Using the existing > > Diameter routing definitions (RFC 3588), an operator has only > > rough knowledge and control (destination realm) over other > > networks, which is a good modular model. > > > > Regards, > > Gil > > > > > > On Dec 6, 2007 9:20 PM, wrote: > > > Hannes, > > > > > > Few comments inline. > > > > > > [snip] > > > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > > the same time, in the case it has relative many next hop nodes, > > > > routing probably changes. > > > > > > > > > Do we have these types of Diameter deployments already > > that have so > > > > many hops? > > > > > > Do we have large deployments in general that have inter-operator > > > interfaces? At this stage requiring deployment experience is kinda > > > weird. I mean, there are identified issues slash grey areas, so why > > > not study and document those before we hit them in real deployments? > > > > > > > > It is because that the Diameter Relay Agent is likely to > > > > select the next hop node by random. > > > > > > > > > Hmmm. Probably this is then the problem. We then > > shouldn't develop > > > > protocol extensions but rather write a document that > > indicates what > > > > good design for Relay Agents is. > > > > > > IMHO that still does not make the issue go away. > > > > > > [snap] > > > > > > > > Do we have some real-world data indicating that this is > > > > indeed a problem > > > > > rather than an academic exercise? > > > > > [Tina: Here are some application with stateful Proxy > > > > Agent in 3GPP and ETSI TISPAN. I think that if there is stateful > > > > Proxy Agent, such mechanism is needed. > > > > > [TS23.234] > > > > > 3GPP, "3GPP system to Wireles Local Area > > > > Network (WLAN) > > > > > interworking; System description", 3GPP TS > > > > 23.234 Version > > > > > 7.4.0 2006. > > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > [chop] > > > > > > > I was told that there was a discussion in the 3GPP once > > about this > > > > aspect. The WLAN 3G interworking was done a long time ago and we > > > > have never heard back from them. > > > > > > Heard back what? In 3GPP routing etc is again under discussion in > > > rel-8 timeframe. Coming back to above reference, the same family of > > > scary specs also use NAI decoration based source routing as part of > > > NASREQ & EAP application for selecting the next hop. I cannot find > > > this (might be a result of sloppy reading) feature being described > > > anywhere in Diameter specification thus I suspect it will actually > > > work. Or can we just assume that everything defined in RFC4282 gets > > > reflected back to existing applications? > > > > > > > I would like to hear from an operator that they have a large > > > > Diameter network and that issue turned out to be a > > problem. I would > > > > also be happy to hear from vendors what they do. I will certainly > > > > investigate this issue with vendors and operators. > > > > > > Rather ask.. "an operator that have a large Diameter network with > > > inter-operator interfaces in multi-vendor environment" ;) > > > > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > > > > > Ciao > > > > Hannes > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 10 16:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qUl-0001aq-0l; Mon, 10 Dec 2007 16:48:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1qUj-0001aj-JT for dime@ietf.org; Mon, 10 Dec 2007 16:48:57 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1qUi-0000fx-MS for dime@ietf.org; Mon, 10 Dec 2007 16:48:57 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 22:48:55 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Mon, 10 Dec 2007 22:48:54 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB0@SEHAN021MB.tcad.telia.se> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7509626@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1X6yiO+AoLiTfm8vnb3hd0GnQACsyygAAPMaYAAALAHUA== References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> <033458F56EC2A64E8D2D7B759FA3E7E7509626@sonusmail04.sonusnet.com> From: To: , X-OriginalArrivalTime: 10 Dec 2007 21:48:55.0491 (UTC) FILETIME=[762D2930:01C83B76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, > Hi Jouni, >=20 > A bit off topic but one question below. >=20 > Thanks, > Tolga >=20 > >=20 > > Hi Gil, > >=20 > > The functionality referenced earlier was actually requested by=20 > > operators to enable some of their potential roaming and deployment=20 > > scenarios. "Forcing" next hop is, for example, for=20 > deployments where a=20 > > shared NAP advertises a number direct roaming connections=20 > for realms=20 > > (say A.com, B.com and C.com) but > [TOLGA]How does this advertisement work? Capability exchange=20 > mechanism does not have that type of capability(i.e.=20 > advertising application support per realm). That's typically done before gaining the access to the network. The access network may for example use RFC4284 to advertise realms or then some access technology specific way (like .11u, .16g etc). I am not actually sure what you are after with your question=20 related to capability exchange. Cheers, Jouni > > none of them match to roaming user's home realm (say D.com). > > However, the roaming user knows that B.com has an agreement with=20 > > D.com, thus it asks from NAP for an "authentication route" > > to D.com through B.com. After this all subsequent messages=20 > should take=20 > > the same path (either on realm or actual agent granularity=20 > depending=20 > > on the deployment). > >=20 > > Cheers, > > Jouni > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > > > Sent: 10. joulukuuta 2007 20:06 > > > To: dime@ietf.org > > > Subject: Re: [Dime] Review of > draft-tsou-dime-base-routing-ext-03.txt > > > > > > > > > Hi all, > > > > > > IMHO, visited network clients should not force an=20 > explicit routing=20 > > > in network domains of other operators. I believe operators would=20 > > > prefer to fully control their load balancing and routing issues.=20 > > > They can also assure routing through their own stateful Diameter=20 > > > proxies. Using the existing Diameter routing definitions=20 > (RFC 3588),=20 > > > an operator has only rough knowledge and control=20 > (destination realm)=20 > > > over other networks, which is a good modular model. > > > > > > Regards, > > > Gil > > > > > > > > > On Dec 6, 2007 9:20 PM, wrote: > > > > Hannes, > > > > > > > > Few comments inline. > > > > > > > > [snip] > > > > > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > > > the same time, in the case it has relative many next=20 > hop nodes,=20 > > > > > routing probably changes. > > > > > > > > > > > Do we have these types of Diameter deployments already > > > that have so > > > > > many hops? > > > > > > > > Do we have large deployments in general that have=20 > inter-operator=20 > > > > interfaces? At this stage requiring deployment=20 > experience is kinda=20 > > > > weird. I mean, there are identified issues slash grey areas, so > why > > > > not study and document those before we hit them in real > deployments? > > > > > > > > > > It is because that the Diameter Relay Agent is likely to > > > > > select the next hop node by random. > > > > > > > > > > > Hmmm. Probably this is then the problem. We then > > > shouldn't develop > > > > > protocol extensions but rather write a document that > > > indicates what > > > > > good design for Relay Agents is. > > > > > > > > IMHO that still does not make the issue go away. > > > > > > > > [snap] > > > > > > > > > > Do we have some real-world data indicating that this is > > > > > indeed a problem > > > > > > rather than an academic exercise? > > > > > > [Tina: Here are some application with stateful Proxy > > > > > Agent in 3GPP and ETSI TISPAN. I think that if there=20 > is stateful=20 > > > > > Proxy Agent, such mechanism is needed. > > > > > > [TS23.234] > > > > > > 3GPP, "3GPP system to Wireles Local Area > > > > > Network (WLAN) > > > > > > interworking; System description", 3GPP TS > > > > > 23.234 Version > > > > > > 7.4.0 2006. > > > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > > > [chop] > > > > > > > > > I was told that there was a discussion in the 3GPP once > > > about this > > > > > aspect. The WLAN 3G interworking was done a long time=20 > ago and we=20 > > > > > have never heard back from them. > > > > > > > > Heard back what? In 3GPP routing etc is again under=20 > discussion in > > > > rel-8 timeframe. Coming back to above reference, the same family > of > > > > scary specs also use NAI decoration based source routing as part > of > > > > NASREQ & EAP application for selecting the next hop. I=20 > cannot find=20 > > > > this (might be a result of sloppy reading) feature=20 > being described=20 > > > > anywhere in Diameter specification thus I suspect it=20 > will actually=20 > > > > work. Or can we just assume that everything defined in RFC4282 > gets > > > > reflected back to existing applications? > > > > > > > > > I would like to hear from an operator that they have a large=20 > > > > > Diameter network and that issue turned out to be a > > > problem. I would > > > > > also be happy to hear from vendors what they do. I will > certainly > > > > > investigate this issue with vendors and operators. > > > > > > > > Rather ask.. "an operator that have a large Diameter=20 > network with=20 > > > > inter-operator interfaces in multi-vendor environment" ;) > > > > > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 10 23:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1wat-0002sd-SJ; Mon, 10 Dec 2007 23:19:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1was-0002sX-EH for dime@ietf.org; Mon, 10 Dec 2007 23:19:42 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1wap-0001Hu-DX for dime@ietf.org; Mon, 10 Dec 2007 23:19:42 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBB49Kjp009770 for ; Tue, 11 Dec 2007 09:39:20 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBB49FoB009738; Tue, 11 Dec 2007 09:39:16 +0530 In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> To: "Asveren, Tolga" Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Tue, 11 Dec 2007 09:48:54 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 11/12/2007 09:54:26 AM, Serialize complete at 11/12/2007 09:54:26 AM X-Spam-Score: 2.8 (++) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: dime@ietf.org, Gil Shafran X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745161037==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1745161037== Content-Type: multipart/alternative; boundary="=_alternative 0017C062652573AE_=" This is a multipart message in MIME format. --=_alternative 0017C062652573AE_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGFtIG5vdCBzdXJlIHdoeSB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBzdWJz ZXF1ZW50IHNlc3Npb24gb3JpZW50ZWQgDQptZXNzYWdlIHRvIHRyYXZlcnNlIHRoZSBzYW1lIGlu dGVybWVkaWFyeSBob3BzIHdoaWNoIHRoZSBpbml0aWFsIG1lc3NhZ2UgDQpoYXMgdHJhdmVyc2Vk Lg0KVWx0aW1hdGUgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgc2Vzc2lvbiBvcmllbnRlZCBtZXNz YWdlIHNob3VsZCBsYW5kdXAgYXQgDQp0aGUgc2FtZSBkZXN0aW5hdGlvbiBob3N0IHRvIHdoaWNo IHRoZSBmaXJzdCBtZXNzYWdlLCAgd2l0aCByZXNwZWN0IHRvIA0KdGhhdCBzZXNzaW9uICwgaGFz IHJlYWNoZWQuIEFzIHBlciBSRkMgdGhlIHN1YnNlcXVlbnQgbWVzc2FnZSBzaGFsbCBoYXZlIA0K dGhlIGRlc3RpbmF0aW9uIGhvc3QgZW1iZWRkZWQgaW4gdGhlIG1lc3NhZ2UuIFNvIGlycmVzcGVj dGl2ZSBvZiB0aGUgcGF0aCANCndoaWNoIGludGVybWVkaWFyeSBtZXNzYWdlIGZvbGxvdywgaWYg aXQgcmVhY2hlcyB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbiANCm5vZGUsIGV2ZXJ5dGhpbmcgc2hh bGwgd29yayBmaW5lLg0KDQpPbmx5IHJlcXVpcmVtZW50IHdoaWNoIGlzIG1hbmRhdG9yeSBoZXJl IGlzIHRoYXQgcmVzcG9uc2UgbWVzc2FnZSBzaG91bGQgDQpmb2xsb3cgdGhlIHNhbWUgcm91dGUg d2hpY2ggcmVxdWVzdCBtZXNzYWdlIGhhcyB0cmF2ZXJzZWQsICB0byBoYXZlIHRoZSANCmNvcnJl Y3QgZW50cnkgb2YgdGhlIGhvcC1ieS1ob3AgSWQuIEFsc28gdGhlcmUgbmVlZCB0byBiZSBhIG1l Y2hhbmlzbSBzbyANCnRoYXQgbWFwcGluZyBjcmVhdGVkIGF0IHRoZSBpbnRlcm1lZGlhcnkgaG9w cyBzaG91bGQgYmUgcGVyaW9kaWNhbGx5IA0KZGVsZXRlZCB0byB0YWtlIGNhcmUgb2YgdGhlIHNj ZW5hcmlvIG9mIG5vdCByZWNlaXZpbmcgcmVzcG9uc2UgZnJvbSB0aGUgDQpzZXJ2ZXIgZXZlci4g aS5lIElmIHNlcnZlciByZXNwb25kcyB0byB0aGUgcmVzZW50IHJlcXVlc3QgZnJvbSBjbGllbnQg DQood2hpY2ggZm9sbG93cyB0aGUgZGlmZmVyZW50IHBhdGgpICBhbmQgb3JpZ2luYWwgcmVxdWVz dCB3YXMgbmV2ZXIgDQphbnN3ZXJlZC4NCg0KUGFyZG9uLCBpZiBJIGFtIG1pc3Npbmcgc29tZXRo aW5nDQoNClJlZ2FyZHMsDQotUHJlZXRpDQoNCg0KDQoiQXN2ZXJlbiwgVG9sZ2EiIDx0YXN2ZXJl bkBzb251c25ldC5jb20+IA0KMTIvMTEvMjAwNyAxMjo1NiBBTQ0KDQoNClRvDQoiR2lsIFNoYWZy YW4iIDxnc2hhZnJhbkB0cmFmZml4c3lzdGVtcy5jb20+LCA8ZGltZUBpZXRmLm9yZz4NCmNjDQoN ClN1YmplY3QNClJFOiBbRGltZV0gUmV2aWV3IG9mIGRyYWZ0LXRzb3UtZGltZS1iYXNlLXJvdXRp bmctZXh0LTAzLnR4dA0KDQoNCg0KDQoNCg0KSGkgR2lsLA0KDQpJIHRoaW5rIGV4cGxpY2l0IHJv dXRpbmcgaXNzdWUgaXMgbW9yZSByZWxhdGVkIHdpdGggdmlzaXRlZCBuZXR3b3JrDQooYWN0dWFs bHkgYW55IG5ldHdvcmspIHRyeWluZyB0byBtYWtlIHN1cmUgdGhhdCBtZXNzYWdlcyBmb3IgYSBz ZXNzaW9uDQp0cmF2ZXJzZSBzb21lIG9mIHRoZSBpbnRlcm1lZGlhcmllcywgd2hpY2ggd2VyZSB1 c2VkIGR1cmluZyByb3V0aW5nIG9mDQp0aGUgaW5pdGlhbCByZXF1ZXN0IGZvciB0aGF0IHBhcnRp Y3VsYXIgc2Vzc2lvbi4gSSBkb24ndCBzZWUgdGhpcw0KbWVjaGFuaXNtIGFzIHRoZSBvcmlnaW5h dG9yIG9mIHRoZSBzZXNzaW9uIGVuZm9yY2luZyBhIHBhdGgNCihwb3RlbnRpYWxseS9wYXJ0bHkg aW4gYW5vdGhlciBuZXR3b3JrKSBiZWZvcmUgdGhlIHNlc3Npb24gaXMNCmVzdGFibGlzaGVkLiBC VFcsIGludGVybWVkaWFyaWVzIHdoaWNoIGRvIG5vdCB3YW50IHRvIHN0YXkgb24gdGhlIHBhdGgN CmRvbid0IG5lZWQgdG8gcGFydGljaXBhdGUuDQoNCkEgbmV0d29yayB3aXRoIGFsbCBlbGVtZW50 cyBzdGF0ZWZ1bCB3b24ndCBoYXZlIGFuIGlzc3VlIGJ1dCBoZXJlIHRoZQ0Ka2V5IHBvaW50IGlz IHRoYXQgKmFsbCogZWxlbWVudHMgc2hvdWxkIGhhdmUgdGhlIGludGVsbGlnZW5jZSB0byBzZWxl Y3QNCnRoZSBzYW1lIG5leHQtaG9wZSBmb3IgYWxsIHJlcXVlc3RzIG9mIGEgcGFydGljdWxhciBz ZXNzaW9uLg0KDQogVGhhbmtzLA0KIFRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogR2lsIFNoYWZyYW4gW21haWx0bzpnc2hhZnJhbkB0cmFmZml4c3lzdGVtcy5j b21dDQo+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTAsIDIwMDcgMTowNiBQTQ0KPiBUbzogZGlt ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RpbWVdIFJldmlldyBvZiBkcmFmdC10c291LWRp bWUtYmFzZS1yb3V0aW5nLWV4dC0wMy50eHQNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IElNSE8sIHZp c2l0ZWQgbmV0d29yayBjbGllbnRzIHNob3VsZCBub3QgZm9yY2UgYW4gZXhwbGljaXQgcm91dGlu ZyBpbg0KPiBuZXR3b3JrIGRvbWFpbnMgb2Ygb3RoZXIgb3BlcmF0b3JzLiBJIGJlbGlldmUgb3Bl cmF0b3JzIHdvdWxkIHByZWZlcg0KPiB0byBmdWxseSBjb250cm9sIHRoZWlyIGxvYWQgYmFsYW5j aW5nIGFuZCByb3V0aW5nIGlzc3Vlcy4gVGhleSBjYW4NCj4gYWxzbyBhc3N1cmUgcm91dGluZyB0 aHJvdWdoIHRoZWlyIG93biBzdGF0ZWZ1bCBEaWFtZXRlciBwcm94aWVzLiBVc2luZw0KPiB0aGUg ZXhpc3RpbmcgRGlhbWV0ZXIgcm91dGluZyBkZWZpbml0aW9ucyAoUkZDIDM1ODgpLCBhbiBvcGVy YXRvciBoYXMNCj4gb25seSByb3VnaCBrbm93bGVkZ2UgYW5kIGNvbnRyb2wgKGRlc3RpbmF0aW9u IHJlYWxtKSBvdmVyIG90aGVyDQo+IG5ldHdvcmtzLCB3aGljaCBpcyBhIGdvb2QgbW9kdWxhciBt b2RlbC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEdpbA0KPiANCj4gDQo+IE9uIERlYyA2LCAyMDA3IDk6 MjAgUE0sICA8am91bmkua29yaG9uZW5AdGVsaWFzb25lcmEuY29tPiB3cm90ZToNCj4gPiBIYW5u ZXMsDQo+ID4NCj4gPiBGZXcgY29tbWVudHMgaW5saW5lLg0KPiA+DQo+ID4gW3NuaXBdDQo+ID4N Cj4gPiA+ID4gICBbVGluYTogVGhlcmUgaXMgUmVsYXkgQWdlbnQgaW4gRGlhbWV0ZXIgcm91dGlu ZyBwYXRoLCBhdA0KPiA+ID4gdGhlIHNhbWUgdGltZSwgaW4gdGhlIGNhc2UgaXQgaGFzIHJlbGF0 aXZlIG1hbnkgbmV4dCBob3ANCj4gPiA+IG5vZGVzLCByb3V0aW5nIHByb2JhYmx5IGNoYW5nZXMu DQo+ID4gPiA+DQo+ID4gPiBEbyB3ZSBoYXZlIHRoZXNlIHR5cGVzIG9mIERpYW1ldGVyIGRlcGxv eW1lbnRzIGFscmVhZHkgdGhhdA0KPiA+ID4gaGF2ZSBzbyBtYW55IGhvcHM/DQo+ID4NCj4gPiBE byB3ZSBoYXZlIGxhcmdlIGRlcGxveW1lbnRzIGluIGdlbmVyYWwgdGhhdCBoYXZlIGludGVyLW9w ZXJhdG9yDQo+ID4gaW50ZXJmYWNlcz8gQXQgdGhpcyBzdGFnZSByZXF1aXJpbmcgZGVwbG95bWVu dCBleHBlcmllbmNlIGlzDQo+ID4ga2luZGEgd2VpcmQuIEkgbWVhbiwgdGhlcmUgYXJlIGlkZW50 aWZpZWQgaXNzdWVzIHNsYXNoIGdyZXkNCj4gPiBhcmVhcywgc28gd2h5IG5vdCBzdHVkeSBhbmQg ZG9jdW1lbnQgdGhvc2UgYmVmb3JlIHdlIGhpdCB0aGVtDQo+ID4gaW4gcmVhbCBkZXBsb3ltZW50 cz8NCj4gPg0KPiA+ID4gPiAgIEl0IGlzIGJlY2F1c2UgdGhhdCB0aGUgRGlhbWV0ZXIgUmVsYXkg QWdlbnQgaXMgbGlrZWx5IHRvDQo+ID4gPiBzZWxlY3QgdGhlIG5leHQgaG9wIG5vZGUgYnkgcmFu ZG9tLg0KPiA+ID4gPg0KPiA+ID4gSG1tbS4gUHJvYmFibHkgdGhpcyBpcyB0aGVuIHRoZSBwcm9i bGVtLiBXZSB0aGVuIHNob3VsZG4ndA0KPiA+ID4gZGV2ZWxvcCBwcm90b2NvbCBleHRlbnNpb25z IGJ1dCByYXRoZXIgd3JpdGUgYSBkb2N1bWVudCB0aGF0DQo+ID4gPiBpbmRpY2F0ZXMgd2hhdCBn b29kIGRlc2lnbiBmb3IgUmVsYXkgQWdlbnRzIGlzLg0KPiA+DQo+ID4gSU1ITyB0aGF0IHN0aWxs IGRvZXMgbm90IG1ha2UgdGhlIGlzc3VlIGdvIGF3YXkuDQo+ID4NCj4gPiBbc25hcF0NCj4gPg0K PiA+ID4gPiAgIERvIHdlIGhhdmUgc29tZSByZWFsLXdvcmxkIGRhdGEgaW5kaWNhdGluZyB0aGF0 IHRoaXMgaXMNCj4gPiA+IGluZGVlZCBhIHByb2JsZW0NCj4gPiA+ID4gICByYXRoZXIgdGhhbiBh biBhY2FkZW1pYyBleGVyY2lzZT8NCj4gPiA+ID4gICBbVGluYTogSGVyZSBhcmUgc29tZSBhcHBs aWNhdGlvbiB3aXRoIHN0YXRlZnVsIFByb3h5DQo+ID4gPiBBZ2VudCBpbiAzR1BQIGFuZCBFVFNJ IFRJU1BBTi4gSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzDQo+ID4gPiBzdGF0ZWZ1bCBQcm94eSBB Z2VudCwgc3VjaCBtZWNoYW5pc20gaXMgbmVlZGVkLg0KPiA+ID4gPiAgIFtUUzIzLjIzNF0NCj4g PiA+ID4gICAgICAgICAgICAgICAgIDNHUFAsICIzR1BQIHN5c3RlbSB0byBXaXJlbGVzIExvY2Fs IEFyZWENCj4gPiA+IE5ldHdvcmsgKFdMQU4pDQo+ID4gPiA+ICAgICAgICAgICAgICAgICBpbnRl cndvcmtpbmc7IFN5c3RlbSBkZXNjcmlwdGlvbiIsIDNHUFAgVFMNCj4gPiA+IDIzLjIzNCBWZXJz aW9uDQo+ID4gPiA+ICAgICAgICAgICAgICAgICA3LjQuMCAyMDA2Lg0KPiA+ID4gPiAgIEhlcmUs IDNHUFAgQUFBIFByb3h5IGlzIGEgc3RhdGVmdWwgUHJveHkgQWdlbnQuDQo+ID4NCj4gPiBbY2hv cF0NCj4gPg0KPiA+ID4gSSB3YXMgdG9sZCB0aGF0IHRoZXJlIHdhcyBhIGRpc2N1c3Npb24gaW4g dGhlIDNHUFAgb25jZSBhYm91dA0KPiA+ID4gdGhpcyBhc3BlY3QuIFRoZSBXTEFOIDNHIGludGVy d29ya2luZyB3YXMgZG9uZSBhIGxvbmcgdGltZQ0KPiA+ID4gYWdvIGFuZCB3ZSBoYXZlIG5ldmVy IGhlYXJkIGJhY2sgZnJvbSB0aGVtLg0KPiA+DQo+ID4gSGVhcmQgYmFjayB3aGF0PyBJbiAzR1BQ IHJvdXRpbmcgZXRjIGlzIGFnYWluIHVuZGVyIGRpc2N1c3Npb24NCj4gPiBpbiByZWwtOCB0aW1l ZnJhbWUuIENvbWluZyBiYWNrIHRvIGFib3ZlIHJlZmVyZW5jZSwgdGhlIHNhbWUNCj4gPiBmYW1p bHkgb2Ygc2Nhcnkgc3BlY3MgYWxzbyB1c2UgTkFJIGRlY29yYXRpb24gYmFzZWQgc291cmNlDQo+ ID4gcm91dGluZyBhcyBwYXJ0IG9mIE5BU1JFUSAmIEVBUCBhcHBsaWNhdGlvbiBmb3Igc2VsZWN0 aW5nIHRoZQ0KPiA+IG5leHQgaG9wLiBJIGNhbm5vdCBmaW5kIHRoaXMgKG1pZ2h0IGJlIGEgcmVz dWx0IG9mIHNsb3BweSByZWFkaW5nKQ0KPiA+IGZlYXR1cmUgYmVpbmcgZGVzY3JpYmVkIGFueXdo ZXJlIGluIERpYW1ldGVyIHNwZWNpZmljYXRpb24gdGh1cyBJDQo+ID4gc3VzcGVjdCBpdCB3aWxs IGFjdHVhbGx5IHdvcmsuIE9yIGNhbiB3ZSBqdXN0IGFzc3VtZSB0aGF0IGV2ZXJ5dGhpbmcNCj4g PiBkZWZpbmVkIGluIFJGQzQyODIgZ2V0cyByZWZsZWN0ZWQgYmFjayB0byBleGlzdGluZyBhcHBs aWNhdGlvbnM/DQo+ID4NCj4gPiA+IEkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gYW4gb3BlcmF0 b3IgdGhhdCB0aGV5IGhhdmUgYSBsYXJnZQ0KPiA+ID4gRGlhbWV0ZXIgbmV0d29yayBhbmQgdGhh dCBpc3N1ZSB0dXJuZWQgb3V0IHRvIGJlIGEgcHJvYmxlbS4gSQ0KPiA+ID4gd291bGQgYWxzbyBi ZSBoYXBweSB0byBoZWFyIGZyb20gdmVuZG9ycyB3aGF0IHRoZXkgZG8uIEkgd2lsbA0KPiA+ID4g Y2VydGFpbmx5IGludmVzdGlnYXRlIHRoaXMgaXNzdWUgd2l0aCB2ZW5kb3JzIGFuZCBvcGVyYXRv cnMuDQo+ID4NCj4gPiBSYXRoZXIgYXNrLi4gImFuIG9wZXJhdG9yIHRoYXQgaGF2ZSBhIGxhcmdl IERpYW1ldGVyIG5ldHdvcmsNCj4gPiB3aXRoIGludGVyLW9wZXJhdG9yIGludGVyZmFjZXMgaW4g bXVsdGktdmVuZG9yIGVudmlyb25tZW50IiA7KQ0KPiA+DQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4g ICAgICAgIEpvdW5pDQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBDaWFvDQo+ID4gPiBI YW5uZXMNCj4gPiA+DQo+ID4gPiA+ICAgQ2lhbw0KPiA+ID4gPiAgIEhhbm5lcw0KPiA+ID4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0K PiBEaU1FQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqICBB cmljZW50LVJlc3RyaWN0ZWQgICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NMQUlNRVI6 IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJl c3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ug b3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1l ZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBu b3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5 aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdl LiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBh cmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhp cyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo= --=_alternative 0017C062652573AE_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gbm90IHN1cmUgd2h5IHRoZXJl IGlzIGEgcmVxdWlyZW1lbnQNCmZvciBzdWJzZXF1ZW50IHNlc3Npb24gb3JpZW50ZWQgbWVzc2Fn ZSB0byB0cmF2ZXJzZSB0aGUgc2FtZSBpbnRlcm1lZGlhcnkNCmhvcHMgd2hpY2ggdGhlIGluaXRp YWwgbWVzc2FnZSBoYXMgdHJhdmVyc2VkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+VWx0aW1hdGUgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgc2Vzc2lvbg0Kb3Jp ZW50ZWQgbWVzc2FnZSBzaG91bGQgbGFuZHVwIGF0IHRoZSBzYW1lIGRlc3RpbmF0aW9uIGhvc3Qg dG8gd2hpY2ggdGhlDQpmaXJzdCBtZXNzYWdlLCAmbmJzcDt3aXRoIHJlc3BlY3QgdG8gdGhhdCBz ZXNzaW9uICwgaGFzIHJlYWNoZWQuIEFzIHBlcg0KUkZDIHRoZSBzdWJzZXF1ZW50IG1lc3NhZ2Ug c2hhbGwgaGF2ZSB0aGUgZGVzdGluYXRpb24gaG9zdCBlbWJlZGRlZCBpbg0KdGhlIG1lc3NhZ2Uu IFNvIGlycmVzcGVjdGl2ZSBvZiB0aGUgcGF0aCB3aGljaCBpbnRlcm1lZGlhcnkgbWVzc2FnZSBm b2xsb3csDQppZiBpdCByZWFjaGVzIHRvIHRoZSBzYW1lIGRlc3RpbmF0aW9uIG5vZGUsIGV2ZXJ5 dGhpbmcgc2hhbGwgd29yayBmaW5lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+T25seSByZXF1aXJlbWVudCB3aGljaCBpcyBtYW5kYXRvcnkNCmhlcmUg aXMgdGhhdCByZXNwb25zZSBtZXNzYWdlIHNob3VsZCBmb2xsb3cgdGhlIHNhbWUgcm91dGUgd2hp Y2ggcmVxdWVzdA0KbWVzc2FnZSBoYXMgdHJhdmVyc2VkLCAmbmJzcDt0byBoYXZlIHRoZSBjb3Jy ZWN0IGVudHJ5IG9mIHRoZSBob3AtYnktaG9wDQpJZC4gQWxzbyB0aGVyZSBuZWVkIHRvIGJlIGEg bWVjaGFuaXNtIHNvIHRoYXQgbWFwcGluZyBjcmVhdGVkIGF0IHRoZSBpbnRlcm1lZGlhcnkNCmhv cHMgc2hvdWxkIGJlIHBlcmlvZGljYWxseSBkZWxldGVkIHRvIHRha2UgY2FyZSBvZiB0aGUgc2Nl bmFyaW8gb2Ygbm90DQpyZWNlaXZpbmcgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyIGV2ZXIuIGku ZSBJZiBzZXJ2ZXIgcmVzcG9uZHMgdG8gdGhlDQpyZXNlbnQgcmVxdWVzdCBmcm9tIGNsaWVudCAo d2hpY2ggZm9sbG93cyB0aGUgZGlmZmVyZW50IHBhdGgpICZuYnNwO2FuZA0Kb3JpZ2luYWwgcmVx dWVzdCB3YXMgbmV2ZXIgYW5zd2VyZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5QYXJkb24sIGlmIEkgYW0gbWlzc2luZyBzb21ldGhpbmc8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tUHJlZXRpPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O0FzdmVyZW4s IFRvbGdhJnF1b3Q7DQombHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0OzwvYj4gPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEyLzExLzIwMDcgMTI6NTYgQU08L2Zv bnQ+DQo8YnI+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9u dD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtHaWwgU2hhZnJhbiZxdW90OyAmbHQ7Z3NoYWZyYW5AdHJhZmZpeHN5c3RlbXMuY29tJmd0 OywNCiZsdDtkaW1lQGlldGYub3JnJmd0OzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRk IHZhbGlnbj10b3A+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbRGltZV0gUmV2aWV3IG9mIGRyYWZ0LXRz b3UtZGltZS1iYXNlLXJvdXRpbmctZXh0LTAzLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRh YmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0K PGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+SGkgR2lsLDxicj4NCjxicj4NCkkgdGhp bmsgZXhwbGljaXQgcm91dGluZyBpc3N1ZSBpcyBtb3JlIHJlbGF0ZWQgd2l0aCB2aXNpdGVkIG5l dHdvcms8YnI+DQooYWN0dWFsbHkgYW55IG5ldHdvcmspIHRyeWluZyB0byBtYWtlIHN1cmUgdGhh dCBtZXNzYWdlcyBmb3IgYSBzZXNzaW9uPGJyPg0KdHJhdmVyc2Ugc29tZSBvZiB0aGUgaW50ZXJt ZWRpYXJpZXMsIHdoaWNoIHdlcmUgdXNlZCBkdXJpbmcgcm91dGluZyBvZjxicj4NCnRoZSBpbml0 aWFsIHJlcXVlc3QgZm9yIHRoYXQgcGFydGljdWxhciBzZXNzaW9uLiBJIGRvbid0IHNlZSB0aGlz PGJyPg0KbWVjaGFuaXNtIGFzIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBzZXNzaW9uIGVuZm9yY2lu ZyBhIHBhdGg8YnI+DQoocG90ZW50aWFsbHkvcGFydGx5IGluIGFub3RoZXIgbmV0d29yaykgYmVm b3JlIHRoZSBzZXNzaW9uIGlzPGJyPg0KZXN0YWJsaXNoZWQuIEJUVywgaW50ZXJtZWRpYXJpZXMg d2hpY2ggZG8gbm90IHdhbnQgdG8gc3RheSBvbiB0aGUgcGF0aDxicj4NCmRvbid0IG5lZWQgdG8g cGFydGljaXBhdGUuPGJyPg0KPGJyPg0KQSBuZXR3b3JrIHdpdGggYWxsIGVsZW1lbnRzIHN0YXRl ZnVsIHdvbid0IGhhdmUgYW4gaXNzdWUgYnV0IGhlcmUgdGhlPGJyPg0Ka2V5IHBvaW50IGlzIHRo YXQgKmFsbCogZWxlbWVudHMgc2hvdWxkIGhhdmUgdGhlIGludGVsbGlnZW5jZSB0byBzZWxlY3Q8 YnI+DQp0aGUgc2FtZSBuZXh0LWhvcGUgZm9yIGFsbCByZXF1ZXN0cyBvZiBhIHBhcnRpY3VsYXIg c2Vzc2lvbi48YnI+DQo8YnI+DQogVGhhbmtzLDxicj4NCiBUb2xnYTxicj4NCjxicj4NCiZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEdpbCBTaGFmcmFuIFtt YWlsdG86Z3NoYWZyYW5AdHJhZmZpeHN5c3RlbXMuY29tXTxicj4NCiZndDsgU2VudDogTW9uZGF5 LCBEZWNlbWJlciAxMCwgMjAwNyAxOjA2IFBNPGJyPg0KJmd0OyBUbzogZGltZUBpZXRmLm9yZzxi cj4NCiZndDsgU3ViamVjdDogUmU6IFtEaW1lXSBSZXZpZXcgb2YgZHJhZnQtdHNvdS1kaW1lLWJh c2Utcm91dGluZy1leHQtMDMudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQom Z3Q7IDxicj4NCiZndDsgSU1ITywgdmlzaXRlZCBuZXR3b3JrIGNsaWVudHMgc2hvdWxkIG5vdCBm b3JjZSBhbiBleHBsaWNpdCByb3V0aW5nDQppbjxicj4NCiZndDsgbmV0d29yayBkb21haW5zIG9m IG90aGVyIG9wZXJhdG9ycy4gSSBiZWxpZXZlIG9wZXJhdG9ycyB3b3VsZCBwcmVmZXI8YnI+DQom Z3Q7IHRvIGZ1bGx5IGNvbnRyb2wgdGhlaXIgbG9hZCBiYWxhbmNpbmcgYW5kIHJvdXRpbmcgaXNz dWVzLiBUaGV5IGNhbjxicj4NCiZndDsgYWxzbyBhc3N1cmUgcm91dGluZyB0aHJvdWdoIHRoZWly IG93biBzdGF0ZWZ1bCBEaWFtZXRlciBwcm94aWVzLiBVc2luZzxicj4NCiZndDsgdGhlIGV4aXN0 aW5nIERpYW1ldGVyIHJvdXRpbmcgZGVmaW5pdGlvbnMgKFJGQyAzNTg4KSwgYW4gb3BlcmF0b3IN Cmhhczxicj4NCiZndDsgb25seSByb3VnaCBrbm93bGVkZ2UgYW5kIGNvbnRyb2wgKGRlc3RpbmF0 aW9uIHJlYWxtKSBvdmVyIG90aGVyPGJyPg0KJmd0OyBuZXR3b3Jrcywgd2hpY2ggaXMgYSBnb29k IG1vZHVsYXIgbW9kZWwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBH aWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBEZWMgNiwgMjAwNyA5OjIwIFBN LCAmbmJzcDsmbHQ7am91bmkua29yaG9uZW5AdGVsaWFzb25lcmEuY29tJmd0Ow0Kd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7IEhhbm5lcyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRmV3IGNv bW1lbnRzIGlubGluZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgW3NuaXBdPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgW1RpbmE6IFRoZXJlIGlz IFJlbGF5IEFnZW50IGluIERpYW1ldGVyIHJvdXRpbmcNCnBhdGgsIGF0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgdGhlIHNhbWUgdGltZSwgaW4gdGhlIGNhc2UgaXQgaGFzIHJlbGF0aXZlIG1hbnkgbmV4 dCBob3A8YnI+DQomZ3Q7ICZndDsgJmd0OyBub2Rlcywgcm91dGluZyBwcm9iYWJseSBjaGFuZ2Vz Ljxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBEbyB3ZSBoYXZl IHRoZXNlIHR5cGVzIG9mIERpYW1ldGVyIGRlcGxveW1lbnRzIGFscmVhZHkgdGhhdDxicj4NCiZn dDsgJmd0OyAmZ3Q7IGhhdmUgc28gbWFueSBob3BzPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBEbyB3ZSBoYXZlIGxhcmdlIGRlcGxveW1lbnRzIGluIGdlbmVyYWwgdGhhdCBoYXZlIGlu dGVyLW9wZXJhdG9yPGJyPg0KJmd0OyAmZ3Q7IGludGVyZmFjZXM/IEF0IHRoaXMgc3RhZ2UgcmVx dWlyaW5nIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBpczxicj4NCiZndDsgJmd0OyBraW5kYSB3ZWly ZC4gSSBtZWFuLCB0aGVyZSBhcmUgaWRlbnRpZmllZCBpc3N1ZXMgc2xhc2ggZ3JleTxicj4NCiZn dDsgJmd0OyBhcmVhcywgc28gd2h5IG5vdCBzdHVkeSBhbmQgZG9jdW1lbnQgdGhvc2UgYmVmb3Jl IHdlIGhpdCB0aGVtPGJyPg0KJmd0OyAmZ3Q7IGluIHJlYWwgZGVwbG95bWVudHM/PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgSXQgaXMgYmVjYXVzZSB0aGF0 IHRoZSBEaWFtZXRlciBSZWxheSBBZ2VudA0KaXMgbGlrZWx5IHRvPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgc2VsZWN0IHRoZSBuZXh0IGhvcCBub2RlIGJ5IHJhbmRvbS48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSG1tbS4gUHJvYmFibHkgdGhpcyBpcyB0aGVuIHRo ZSBwcm9ibGVtLiBXZSB0aGVuIHNob3VsZG4ndDxicj4NCiZndDsgJmd0OyAmZ3Q7IGRldmVsb3Ag cHJvdG9jb2wgZXh0ZW5zaW9ucyBidXQgcmF0aGVyIHdyaXRlIGEgZG9jdW1lbnQNCnRoYXQ8YnI+ DQomZ3Q7ICZndDsgJmd0OyBpbmRpY2F0ZXMgd2hhdCBnb29kIGRlc2lnbiBmb3IgUmVsYXkgQWdl bnRzIGlzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJTUhPIHRoYXQgc3RpbGwgZG9l cyBub3QgbWFrZSB0aGUgaXNzdWUgZ28gYXdheS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgW3NuYXBdPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg RG8gd2UgaGF2ZSBzb21lIHJlYWwtd29ybGQgZGF0YSBpbmRpY2F0aW5nIHRoYXQNCnRoaXMgaXM8 YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmRlZWQgYSBwcm9ibGVtPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgcmF0aGVyIHRoYW4gYW4gYWNhZGVtaWMgZXhlcmNpc2U/PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAmbmJzcDsgW1RpbmE6IEhlcmUgYXJlIHNvbWUgYXBwbGljYXRpb24gd2l0 aCBzdGF0ZWZ1bA0KUHJveHk8YnI+DQomZ3Q7ICZndDsgJmd0OyBBZ2VudCBpbiAzR1BQIGFuZCBF VFNJIFRJU1BBTi4gSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsg c3RhdGVmdWwgUHJveHkgQWdlbnQsIHN1Y2ggbWVjaGFuaXNtIGlzIG5lZWRlZC48YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBbVFMyMy4yMzRdPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQozR1BQLCAmcXVvdDszR1BQIHN5c3RlbSB0byBXaXJlbGVzIExvY2FsIEFyZWE8YnI+DQomZ3Q7 ICZndDsgJmd0OyBOZXR3b3JrIChXTEFOKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KaW50ZXJ3 b3JraW5nOyBTeXN0ZW0gZGVzY3JpcHRpb24mcXVvdDssIDNHUFAgVFM8YnI+DQomZ3Q7ICZndDsg Jmd0OyAyMy4yMzQgVmVyc2lvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KNy40LjAgMjAwNi48 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyBIZXJlLCAzR1BQIEFBQSBQcm94eSBpcyBh IHN0YXRlZnVsIFByb3h5IEFnZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBbY2hv cF08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdhcyB0b2xkIHRoYXQgdGhl cmUgd2FzIGEgZGlzY3Vzc2lvbiBpbiB0aGUgM0dQUCBvbmNlDQphYm91dDxicj4NCiZndDsgJmd0 OyAmZ3Q7IHRoaXMgYXNwZWN0LiBUaGUgV0xBTiAzRyBpbnRlcndvcmtpbmcgd2FzIGRvbmUgYSBs b25nIHRpbWU8YnI+DQomZ3Q7ICZndDsgJmd0OyBhZ28gYW5kIHdlIGhhdmUgbmV2ZXIgaGVhcmQg YmFjayBmcm9tIHRoZW0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhlYXJkIGJhY2sg d2hhdD8gSW4gM0dQUCByb3V0aW5nIGV0YyBpcyBhZ2FpbiB1bmRlciBkaXNjdXNzaW9uPGJyPg0K Jmd0OyAmZ3Q7IGluIHJlbC04IHRpbWVmcmFtZS4gQ29taW5nIGJhY2sgdG8gYWJvdmUgcmVmZXJl bmNlLCB0aGUgc2FtZTxicj4NCiZndDsgJmd0OyBmYW1pbHkgb2Ygc2Nhcnkgc3BlY3MgYWxzbyB1 c2UgTkFJIGRlY29yYXRpb24gYmFzZWQgc291cmNlPGJyPg0KJmd0OyAmZ3Q7IHJvdXRpbmcgYXMg cGFydCBvZiBOQVNSRVEgJmFtcDsgRUFQIGFwcGxpY2F0aW9uIGZvciBzZWxlY3RpbmcNCnRoZTxi cj4NCiZndDsgJmd0OyBuZXh0IGhvcC4gSSBjYW5ub3QgZmluZCB0aGlzIChtaWdodCBiZSBhIHJl c3VsdCBvZiBzbG9wcHkgcmVhZGluZyk8YnI+DQomZ3Q7ICZndDsgZmVhdHVyZSBiZWluZyBkZXNj cmliZWQgYW55d2hlcmUgaW4gRGlhbWV0ZXIgc3BlY2lmaWNhdGlvbiB0aHVzDQpJPGJyPg0KJmd0 OyAmZ3Q7IHN1c3BlY3QgaXQgd2lsbCBhY3R1YWxseSB3b3JrLiBPciBjYW4gd2UganVzdCBhc3N1 bWUgdGhhdCBldmVyeXRoaW5nPGJyPg0KJmd0OyAmZ3Q7IGRlZmluZWQgaW4gUkZDNDI4MiBnZXRz IHJlZmxlY3RlZCBiYWNrIHRvIGV4aXN0aW5nIGFwcGxpY2F0aW9ucz88YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIGFuIG9wZXJhdG9y IHRoYXQgdGhleSBoYXZlIGEgbGFyZ2U8YnI+DQomZ3Q7ICZndDsgJmd0OyBEaWFtZXRlciBuZXR3 b3JrIGFuZCB0aGF0IGlzc3VlIHR1cm5lZCBvdXQgdG8gYmUgYSBwcm9ibGVtLg0KSTxicj4NCiZn dDsgJmd0OyAmZ3Q7IHdvdWxkIGFsc28gYmUgaGFwcHkgdG8gaGVhciBmcm9tIHZlbmRvcnMgd2hh dCB0aGV5IGRvLiBJDQp3aWxsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY2VydGFpbmx5IGludmVzdGln YXRlIHRoaXMgaXNzdWUgd2l0aCB2ZW5kb3JzIGFuZCBvcGVyYXRvcnMuPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IFJhdGhlciBhc2suLiAmcXVvdDthbiBvcGVyYXRvciB0aGF0IGhhdmUg YSBsYXJnZSBEaWFtZXRlciBuZXR3b3JrPGJyPg0KJmd0OyAmZ3Q7IHdpdGggaW50ZXItb3BlcmF0 b3IgaW50ZXJmYWNlcyBpbiBtdWx0aS12ZW5kb3IgZW52aXJvbm1lbnQmcXVvdDsNCjspPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Sm91bmk8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgQ2lhbzxicj4NCiZndDsgJmd0OyAmZ3Q7IEhhbm5lczxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgQ2lhbzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7IEhhbm5lczxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IERpTUUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg RGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRpTUUgbWFpbGlu ZyBsaXN0PGJyPg0KRGlNRUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RpbWU8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKiog Jm5ic3A7QXJpY2VudC1SZXN0cmljdGVkICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwv Zm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAw PjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50 ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0 byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNl ZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRl ZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVu dHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9y IApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g dHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8 L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 0017C062652573AE_=-- --===============1745161037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1745161037==-- From dime-bounces@ietf.org Tue Dec 11 01:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1yqL-0001wD-NK; Tue, 11 Dec 2007 01:43:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1yqK-0001vl-Cg for dime@ietf.org; Tue, 11 Dec 2007 01:43:48 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J1yqI-0004T4-NI for dime@ietf.org; Tue, 11 Dec 2007 01:43:47 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 07:43:44 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 07:43:43 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7rRqyLoXOrcABSj+r85aZOywqsQAE3qnw References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> From: To: , X-OriginalArrivalTime: 11 Dec 2007 06:43:44.0692 (UTC) FILETIME=[2CD4A740:01C83BC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Preeti, > -----Original Message----- > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 > Sent: 11. joulukuuta 2007 6:19 >=20 > Hi !=20 >=20 > I am not sure why there is a requirement for subsequent=20 > session oriented message to traverse the same intermediary=20 > hops which the initial message has traversed.=20 What if some of the intermediates are stateful and e.g. collect charging data by tracking the user session? Cheers, Jouni > Ultimate requirement is that the session oriented message=20 > should landup at the same destination host to which the first=20 > message, with respect to that session , has reached. As per=20 > RFC the subsequent message shall have the destination host=20 > embedded in the message. So irrespective of the path which=20 > intermediary message follow, if it reaches to the same=20 > destination node, everything shall work fine.=20 >=20 > Only requirement which is mandatory here is that response=20 > message should follow the same route which request message=20 > has traversed, to have the correct entry of the hop-by-hop=20 > Id. Also there need to be a mechanism so that mapping created=20 > at the intermediary hops should be periodically deleted to=20 > take care of the scenario of not receiving response from the=20 > server ever. i.e If server responds to the resent request=20 > from client (which follows the different path) and original=20 > request was never answered.=20 >=20 > Pardon, if I am missing something=20 >=20 > Regards, > -Preeti=20 >=20 >=20 >=20 > "Asveren, Tolga" =20 >=20 > 12/11/2007 12:56 AM=20 > To > "Gil Shafran" , =20 > cc > Subject > RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > =09 >=20 >=20 >=20 >=20 > Hi Gil, >=20 > I think explicit routing issue is more related with visited network > (actually any network) trying to make sure that messages for a session > traverse some of the intermediaries, which were used during routing of > the initial request for that particular session. I don't see this > mechanism as the originator of the session enforcing a path > (potentially/partly in another network) before the session is > established. BTW, intermediaries which do not want to stay on the path > don't need to participate. >=20 > A network with all elements stateful won't have an issue but here the > key point is that *all* elements should have the intelligence=20 > to select > the same next-hope for all requests of a particular session. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > > Sent: Monday, December 10, 2007 1:06 PM > > To: dime@ietf.org > > Subject: Re: [Dime] Review of=20 > draft-tsou-dime-base-routing-ext-03.txt > >=20 > > Hi all, > >=20 > > IMHO, visited network clients should not force an explicit=20 > routing in > > network domains of other operators. I believe operators would prefer > > to fully control their load balancing and routing issues. They can > > also assure routing through their own stateful Diameter=20 > proxies. Using > > the existing Diameter routing definitions (RFC 3588), an=20 > operator has > > only rough knowledge and control (destination realm) over other > > networks, which is a good modular model. > >=20 > > Regards, > > Gil > >=20 > >=20 > > On Dec 6, 2007 9:20 PM, wrote: > > > Hannes, > > > > > > Few comments inline. > > > > > > [snip] > > > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > > the same time, in the case it has relative many next hop > > > > nodes, routing probably changes. > > > > > > > > > Do we have these types of Diameter deployments already that > > > > have so many hops? > > > > > > Do we have large deployments in general that have inter-operator > > > interfaces? At this stage requiring deployment experience is > > > kinda weird. I mean, there are identified issues slash grey > > > areas, so why not study and document those before we hit them > > > in real deployments? > > > > > > > > It is because that the Diameter Relay Agent is likely to > > > > select the next hop node by random. > > > > > > > > > Hmmm. Probably this is then the problem. We then shouldn't > > > > develop protocol extensions but rather write a document that > > > > indicates what good design for Relay Agents is. > > > > > > IMHO that still does not make the issue go away. > > > > > > [snap] > > > > > > > > Do we have some real-world data indicating that this is > > > > indeed a problem > > > > > rather than an academic exercise? > > > > > [Tina: Here are some application with stateful Proxy > > > > Agent in 3GPP and ETSI TISPAN. I think that if there is > > > > stateful Proxy Agent, such mechanism is needed. > > > > > [TS23.234] > > > > > 3GPP, "3GPP system to Wireles Local Area > > > > Network (WLAN) > > > > > interworking; System description", 3GPP TS > > > > 23.234 Version > > > > > 7.4.0 2006. > > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > [chop] > > > > > > > I was told that there was a discussion in the 3GPP once about > > > > this aspect. The WLAN 3G interworking was done a long time > > > > ago and we have never heard back from them. > > > > > > Heard back what? In 3GPP routing etc is again under discussion > > > in rel-8 timeframe. Coming back to above reference, the same > > > family of scary specs also use NAI decoration based source > > > routing as part of NASREQ & EAP application for selecting the > > > next hop. I cannot find this (might be a result of sloppy reading) > > > feature being described anywhere in Diameter specification thus I > > > suspect it will actually work. Or can we just assume that=20 > everything > > > defined in RFC4282 gets reflected back to existing applications? > > > > > > > I would like to hear from an operator that they have a large > > > > Diameter network and that issue turned out to be a problem. I > > > > would also be happy to hear from vendors what they do. I will > > > > certainly investigate this issue with vendors and operators. > > > > > > Rather ask.. "an operator that have a large Diameter network > > > with inter-operator interfaces in multi-vendor environment" ;) > > > > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > > > > > > Ciao > > > > Hannes > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 >=20 > *********************** Aricent-Restricted ***********************=20 > "DISCLAIMER: This message is proprietary to Aricent and is=20 > intended solely for the use of=20 > the individual to whom it is addressed. It may contain=20 > privileged or confidential information and should not be=20 > circulated or used for any purpose other than for what it is=20 > intended. If you have received this message in error,=20 > please notify the originator immediately. If you are not the=20 > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the=20 > contents of this message. Aricent accepts no responsibility for=20 > loss or damage arising from the use of the information=20 > transmitted by this email including damage from virus." >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 03:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J202k-0006Hs-0U; Tue, 11 Dec 2007 03:00:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J202i-0006BH-Rv for dime@ietf.org; Tue, 11 Dec 2007 03:00:40 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J202i-0006Kr-Ev for dime@ietf.org; Tue, 11 Dec 2007 03:00:40 -0500 Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id PKok1Y0010S2fkC0A00r00; Tue, 11 Dec 2007 08:00:45 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id PL0i1Y00C53lGY30800000; Tue, 11 Dec 2007 08:00:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=OiuAnNsvuevEUCZblc4A:9 a=7uHIHe71qzlv5xY-H4pcawZg7XsA:4 a=_3nJN2eeWHAA:10 From: "Glen Zorn" To: , , References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Mon, 10 Dec 2007 23:58:02 -0800 Message-ID: <00a701c83bcb$8f25acf0$ad7106d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7rRqyLoXOrcABSj+r85aZOywqsQAE3qnwAAKfSfA= Content-language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org ... > I am not sure why there is a requirement for subsequent > session oriented message to traverse the same intermediary > hops which the initial message has traversed. What if some of the intermediates are stateful and e.g. collect charging data by tracking the user session? [gwz] I must admit that I cannot think of a single (real-life) scenario where this kind of thing would be desirable (let alone required). Would you mind describing one in detail? [/gwz] ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 03:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J20ml-0003m8-EJ; Tue, 11 Dec 2007 03:48:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J20mk-0003m3-Pz for dime@ietf.org; Tue, 11 Dec 2007 03:48:14 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J20mh-0007Uw-Fd for dime@ietf.org; Tue, 11 Dec 2007 03:48:14 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBB8bqYr030495 for ; Tue, 11 Dec 2007 14:07:52 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBB8biNt030453; Tue, 11 Dec 2007 14:07:50 +0530 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> To: Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Tue, 11 Dec 2007 14:17:23 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 11/12/2007 02:23:00 PM, Serialize complete at 11/12/2007 02:23:00 PM X-Spam-Score: 2.8 (++) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1783300658==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1783300658== Content-Type: multipart/alternative; boundary="=_alternative 003054FB652573AE_=" This is a multipart message in MIME format. --=_alternative 003054FB652573AE_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgSm91bmkgIQ0KDQpBcyBwZXIgUkZDLCByZWxheSBub2RlIHNob3VsZCBub3QgZXZlbiBsb29r IGludG8gdGhlIG1lc3NhZ2UoZXhjZXB0IHRoZSANCnJvdXRpbmcgQVZQcykuIFNvIGludGVybWVk aWFyeSBub2RlcyBzaG91bGQgbm90IHRyeSAgdG8gY29sbGVjdCBjaGFyZ2luZyANCmRhdGEgYnkg dHJhY2tpbmcgdGhlIHVzZXIgc2Vzc2lvbi4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhpcyB3b3Vs ZCBiZSANCmFnYWluc3QgdGhlIHNwZWMNCg0KQXMgcGVyIGRlZmluaXRpb24gb2YgcmVsYXkgYWdl bnQgZnJvbSBSRkMgMzU4OA0KDQogICAgICAiUmVsYXlzIGZvcndhcmQgcmVxdWVzdHMgYW5kIHJl c3BvbnNlcyBiYXNlZCBvbiByb3V0aW5nLXJlbGF0ZWQNCiAgICAgIEFWUHMgYW5kIHJlYWxtIHJv dXRpbmcgdGFibGUgZW50cmllcy4gIFNpbmNlIHJlbGF5cyBkbyBub3QgbWFrZQ0KICAgICAgcG9s aWN5IGRlY2lzaW9ucywgdGhleSBkbyBub3QgZXhhbWluZSBvciBhbHRlciBub24tcm91dGluZyBB VlBzLg0KICAgICAgQXMgYSByZXN1bHQsIHJlbGF5cyBuZXZlciBvcmlnaW5hdGUgbWVzc2FnZXMs IGRvIG5vdCBuZWVkIHRvDQogICAgICB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpY3Mgb2YgbWVzc2Fn ZXMgb3Igbm9uLXJvdXRpbmcgQVZQcywgYW5kIGFyZQ0KICAgICAgY2FwYWJsZSBvZiBoYW5kbGlu ZyBhbnkgRGlhbWV0ZXIgYXBwbGljYXRpb24gb3IgbWVzc2FnZSB0eXBlLiINCg0KcmVnYXJkcw0K UHJlZXRpDQoNCg0KDQo8am91bmkua29yaG9uZW5AdGVsaWFzb25lcmEuY29tPiANCjEyLzExLzIw MDcgMTI6MTMgUE0NCg0KDQpUbw0KUHJlZXRpIFNoYW5kaWx5YS9IU1NASFNTLCA8dGFzdmVyZW5A c29udXNuZXQuY29tPg0KY2MNCjxkaW1lQGlldGYub3JnPiwgPGdzaGFmcmFuQHRyYWZmaXhzeXN0 ZW1zLmNvbT4NClN1YmplY3QNClJFOiBbRGltZV0gUmV2aWV3IG9mIGRyYWZ0LXRzb3UtZGltZS1i YXNlLXJvdXRpbmctZXh0LTAzLnR4dA0KDQoNCg0KDQoNCg0KSGkgUHJlZXRpLA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFByZWV0aSBTaGFuZGlseWEgW21haWx0bzpw cmVldGkuc2hhbmRpbHlhQGFyaWNlbnQuY29tXSANCj4gU2VudDogMTEuIGpvdWx1a3V1dGEgMjAw NyA2OjE5DQo+IA0KPiBIaSAhIA0KPiANCj4gSSBhbSBub3Qgc3VyZSB3aHkgdGhlcmUgaXMgYSBy ZXF1aXJlbWVudCBmb3Igc3Vic2VxdWVudCANCj4gc2Vzc2lvbiBvcmllbnRlZCBtZXNzYWdlIHRv IHRyYXZlcnNlIHRoZSBzYW1lIGludGVybWVkaWFyeSANCj4gaG9wcyB3aGljaCB0aGUgaW5pdGlh bCBtZXNzYWdlIGhhcyB0cmF2ZXJzZWQuIA0KDQpXaGF0IGlmIHNvbWUgb2YgdGhlIGludGVybWVk aWF0ZXMgYXJlIHN0YXRlZnVsIGFuZCBlLmcuDQpjb2xsZWN0IGNoYXJnaW5nIGRhdGEgYnkgdHJh Y2tpbmcgdGhlIHVzZXIgc2Vzc2lvbj8NCg0KQ2hlZXJzLA0KICAgICAgICAgICAgICAgICBKb3Vu aQ0KDQo+IFVsdGltYXRlIHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlIHNlc3Npb24gb3JpZW50ZWQg bWVzc2FnZSANCj4gc2hvdWxkIGxhbmR1cCBhdCB0aGUgc2FtZSBkZXN0aW5hdGlvbiBob3N0IHRv IHdoaWNoIHRoZSBmaXJzdCANCj4gbWVzc2FnZSwgIHdpdGggcmVzcGVjdCB0byB0aGF0IHNlc3Np b24gLCBoYXMgcmVhY2hlZC4gQXMgcGVyIA0KPiBSRkMgdGhlIHN1YnNlcXVlbnQgbWVzc2FnZSBz aGFsbCBoYXZlIHRoZSBkZXN0aW5hdGlvbiBob3N0IA0KPiBlbWJlZGRlZCBpbiB0aGUgbWVzc2Fn ZS4gU28gaXJyZXNwZWN0aXZlIG9mIHRoZSBwYXRoIHdoaWNoIA0KPiBpbnRlcm1lZGlhcnkgbWVz c2FnZSBmb2xsb3csIGlmIGl0IHJlYWNoZXMgdG8gdGhlIHNhbWUgDQo+IGRlc3RpbmF0aW9uIG5v ZGUsIGV2ZXJ5dGhpbmcgc2hhbGwgd29yayBmaW5lLiANCj4gDQo+IE9ubHkgcmVxdWlyZW1lbnQg d2hpY2ggaXMgbWFuZGF0b3J5IGhlcmUgaXMgdGhhdCByZXNwb25zZSANCj4gbWVzc2FnZSBzaG91 bGQgZm9sbG93IHRoZSBzYW1lIHJvdXRlIHdoaWNoIHJlcXVlc3QgbWVzc2FnZSANCj4gaGFzIHRy YXZlcnNlZCwgIHRvIGhhdmUgdGhlIGNvcnJlY3QgZW50cnkgb2YgdGhlIGhvcC1ieS1ob3AgDQo+ IElkLiBBbHNvIHRoZXJlIG5lZWQgdG8gYmUgYSBtZWNoYW5pc20gc28gdGhhdCBtYXBwaW5nIGNy ZWF0ZWQgDQo+IGF0IHRoZSBpbnRlcm1lZGlhcnkgaG9wcyBzaG91bGQgYmUgcGVyaW9kaWNhbGx5 IGRlbGV0ZWQgdG8gDQo+IHRha2UgY2FyZSBvZiB0aGUgc2NlbmFyaW8gb2Ygbm90IHJlY2Vpdmlu ZyByZXNwb25zZSBmcm9tIHRoZSANCj4gc2VydmVyIGV2ZXIuIGkuZSBJZiBzZXJ2ZXIgcmVzcG9u ZHMgdG8gdGhlIHJlc2VudCByZXF1ZXN0IA0KPiBmcm9tIGNsaWVudCAod2hpY2ggZm9sbG93cyB0 aGUgZGlmZmVyZW50IHBhdGgpICBhbmQgb3JpZ2luYWwgDQo+IHJlcXVlc3Qgd2FzIG5ldmVyIGFu c3dlcmVkLiANCj4gDQo+IFBhcmRvbiwgaWYgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyANCj4gDQo+ IFJlZ2FyZHMsDQo+IC1QcmVldGkgDQo+IA0KPiANCj4gDQo+ICJBc3ZlcmVuLCBUb2xnYSIgPHRh c3ZlcmVuQHNvbnVzbmV0LmNvbT4gDQo+IA0KPiAxMi8xMS8yMDA3IDEyOjU2IEFNIA0KPiBUbw0K PiAiR2lsIFNoYWZyYW4iIDxnc2hhZnJhbkB0cmFmZml4c3lzdGVtcy5jb20+LCA8ZGltZUBpZXRm Lm9yZz4gDQo+IGNjDQo+IFN1YmplY3QNCj4gUkU6IFtEaW1lXSBSZXZpZXcgb2YgZHJhZnQtdHNv dS1kaW1lLWJhc2Utcm91dGluZy1leHQtMDMudHh0DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IEhpIEdpbCwNCj4gDQo+IEkgdGhpbmsgZXhwbGljaXQgcm91dGluZyBpc3N1ZSBpcyBtb3JlIHJl bGF0ZWQgd2l0aCB2aXNpdGVkIG5ldHdvcmsNCj4gKGFjdHVhbGx5IGFueSBuZXR3b3JrKSB0cnlp bmcgdG8gbWFrZSBzdXJlIHRoYXQgbWVzc2FnZXMgZm9yIGEgc2Vzc2lvbg0KPiB0cmF2ZXJzZSBz b21lIG9mIHRoZSBpbnRlcm1lZGlhcmllcywgd2hpY2ggd2VyZSB1c2VkIGR1cmluZyByb3V0aW5n IG9mDQo+IHRoZSBpbml0aWFsIHJlcXVlc3QgZm9yIHRoYXQgcGFydGljdWxhciBzZXNzaW9uLiBJ IGRvbid0IHNlZSB0aGlzDQo+IG1lY2hhbmlzbSBhcyB0aGUgb3JpZ2luYXRvciBvZiB0aGUgc2Vz c2lvbiBlbmZvcmNpbmcgYSBwYXRoDQo+IChwb3RlbnRpYWxseS9wYXJ0bHkgaW4gYW5vdGhlciBu ZXR3b3JrKSBiZWZvcmUgdGhlIHNlc3Npb24gaXMNCj4gZXN0YWJsaXNoZWQuIEJUVywgaW50ZXJt ZWRpYXJpZXMgd2hpY2ggZG8gbm90IHdhbnQgdG8gc3RheSBvbiB0aGUgcGF0aA0KPiBkb24ndCBu ZWVkIHRvIHBhcnRpY2lwYXRlLg0KPiANCj4gQSBuZXR3b3JrIHdpdGggYWxsIGVsZW1lbnRzIHN0 YXRlZnVsIHdvbid0IGhhdmUgYW4gaXNzdWUgYnV0IGhlcmUgdGhlDQo+IGtleSBwb2ludCBpcyB0 aGF0ICphbGwqIGVsZW1lbnRzIHNob3VsZCBoYXZlIHRoZSBpbnRlbGxpZ2VuY2UgDQo+IHRvIHNl bGVjdA0KPiB0aGUgc2FtZSBuZXh0LWhvcGUgZm9yIGFsbCByZXF1ZXN0cyBvZiBhIHBhcnRpY3Vs YXIgc2Vzc2lvbi4NCj4gDQo+IFRoYW5rcywNCj4gVG9sZ2ENCj4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBHaWwgU2hhZnJhbiBbbWFpbHRvOmdzaGFmcmFuQHRy YWZmaXhzeXN0ZW1zLmNvbV0NCj4gPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDEwLCAyMDA3IDE6 MDYgUE0NCj4gPiBUbzogZGltZUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbRGltZV0gUmV2 aWV3IG9mIA0KPiBkcmFmdC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0wMy50eHQNCj4gPiAN Cj4gPiBIaSBhbGwsDQo+ID4gDQo+ID4gSU1ITywgdmlzaXRlZCBuZXR3b3JrIGNsaWVudHMgc2hv dWxkIG5vdCBmb3JjZSBhbiBleHBsaWNpdCANCj4gcm91dGluZyBpbg0KPiA+IG5ldHdvcmsgZG9t YWlucyBvZiBvdGhlciBvcGVyYXRvcnMuIEkgYmVsaWV2ZSBvcGVyYXRvcnMgd291bGQgcHJlZmVy DQo+ID4gdG8gZnVsbHkgY29udHJvbCB0aGVpciBsb2FkIGJhbGFuY2luZyBhbmQgcm91dGluZyBp c3N1ZXMuIFRoZXkgY2FuDQo+ID4gYWxzbyBhc3N1cmUgcm91dGluZyB0aHJvdWdoIHRoZWlyIG93 biBzdGF0ZWZ1bCBEaWFtZXRlciANCj4gcHJveGllcy4gVXNpbmcNCj4gPiB0aGUgZXhpc3Rpbmcg RGlhbWV0ZXIgcm91dGluZyBkZWZpbml0aW9ucyAoUkZDIDM1ODgpLCBhbiANCj4gb3BlcmF0b3Ig aGFzDQo+ID4gb25seSByb3VnaCBrbm93bGVkZ2UgYW5kIGNvbnRyb2wgKGRlc3RpbmF0aW9uIHJl YWxtKSBvdmVyIG90aGVyDQo+ID4gbmV0d29ya3MsIHdoaWNoIGlzIGEgZ29vZCBtb2R1bGFyIG1v ZGVsLg0KPiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gR2lsDQo+ID4gDQo+ID4gDQo+ID4gT24gRGVj IDYsIDIwMDcgOToyMCBQTSwgIDxqb3VuaS5rb3Job25lbkB0ZWxpYXNvbmVyYS5jb20+IHdyb3Rl Og0KPiA+ID4gSGFubmVzLA0KPiA+ID4NCj4gPiA+IEZldyBjb21tZW50cyBpbmxpbmUuDQo+ID4g Pg0KPiA+ID4gW3NuaXBdDQo+ID4gPg0KPiA+ID4gPiA+ICAgW1RpbmE6IFRoZXJlIGlzIFJlbGF5 IEFnZW50IGluIERpYW1ldGVyIHJvdXRpbmcgcGF0aCwgYXQNCj4gPiA+ID4gdGhlIHNhbWUgdGlt ZSwgaW4gdGhlIGNhc2UgaXQgaGFzIHJlbGF0aXZlIG1hbnkgbmV4dCBob3ANCj4gPiA+ID4gbm9k ZXMsIHJvdXRpbmcgcHJvYmFibHkgY2hhbmdlcy4NCj4gPiA+ID4gPg0KPiA+ID4gPiBEbyB3ZSBo YXZlIHRoZXNlIHR5cGVzIG9mIERpYW1ldGVyIGRlcGxveW1lbnRzIGFscmVhZHkgdGhhdA0KPiA+ ID4gPiBoYXZlIHNvIG1hbnkgaG9wcz8NCj4gPiA+DQo+ID4gPiBEbyB3ZSBoYXZlIGxhcmdlIGRl cGxveW1lbnRzIGluIGdlbmVyYWwgdGhhdCBoYXZlIGludGVyLW9wZXJhdG9yDQo+ID4gPiBpbnRl cmZhY2VzPyBBdCB0aGlzIHN0YWdlIHJlcXVpcmluZyBkZXBsb3ltZW50IGV4cGVyaWVuY2UgaXMN Cj4gPiA+IGtpbmRhIHdlaXJkLiBJIG1lYW4sIHRoZXJlIGFyZSBpZGVudGlmaWVkIGlzc3VlcyBz bGFzaCBncmV5DQo+ID4gPiBhcmVhcywgc28gd2h5IG5vdCBzdHVkeSBhbmQgZG9jdW1lbnQgdGhv c2UgYmVmb3JlIHdlIGhpdCB0aGVtDQo+ID4gPiBpbiByZWFsIGRlcGxveW1lbnRzPw0KPiA+ID4N Cj4gPiA+ID4gPiAgIEl0IGlzIGJlY2F1c2UgdGhhdCB0aGUgRGlhbWV0ZXIgUmVsYXkgQWdlbnQg aXMgbGlrZWx5IHRvDQo+ID4gPiA+IHNlbGVjdCB0aGUgbmV4dCBob3Agbm9kZSBieSByYW5kb20u DQo+ID4gPiA+ID4NCj4gPiA+ID4gSG1tbS4gUHJvYmFibHkgdGhpcyBpcyB0aGVuIHRoZSBwcm9i bGVtLiBXZSB0aGVuIHNob3VsZG4ndA0KPiA+ID4gPiBkZXZlbG9wIHByb3RvY29sIGV4dGVuc2lv bnMgYnV0IHJhdGhlciB3cml0ZSBhIGRvY3VtZW50IHRoYXQNCj4gPiA+ID4gaW5kaWNhdGVzIHdo YXQgZ29vZCBkZXNpZ24gZm9yIFJlbGF5IEFnZW50cyBpcy4NCj4gPiA+DQo+ID4gPiBJTUhPIHRo YXQgc3RpbGwgZG9lcyBub3QgbWFrZSB0aGUgaXNzdWUgZ28gYXdheS4NCj4gPiA+DQo+ID4gPiBb c25hcF0NCj4gPiA+DQo+ID4gPiA+ID4gICBEbyB3ZSBoYXZlIHNvbWUgcmVhbC13b3JsZCBkYXRh IGluZGljYXRpbmcgdGhhdCB0aGlzIGlzDQo+ID4gPiA+IGluZGVlZCBhIHByb2JsZW0NCj4gPiA+ ID4gPiAgIHJhdGhlciB0aGFuIGFuIGFjYWRlbWljIGV4ZXJjaXNlPw0KPiA+ID4gPiA+ICAgW1Rp bmE6IEhlcmUgYXJlIHNvbWUgYXBwbGljYXRpb24gd2l0aCBzdGF0ZWZ1bCBQcm94eQ0KPiA+ID4g PiBBZ2VudCBpbiAzR1BQIGFuZCBFVFNJIFRJU1BBTi4gSSB0aGluayB0aGF0IGlmIHRoZXJlIGlz DQo+ID4gPiA+IHN0YXRlZnVsIFByb3h5IEFnZW50LCBzdWNoIG1lY2hhbmlzbSBpcyBuZWVkZWQu DQo+ID4gPiA+ID4gICBbVFMyMy4yMzRdDQo+ID4gPiA+ID4gICAgICAgICAgICAgICAgIDNHUFAs ICIzR1BQIHN5c3RlbSB0byBXaXJlbGVzIExvY2FsIEFyZWENCj4gPiA+ID4gTmV0d29yayAoV0xB TikNCj4gPiA+ID4gPiAgICAgICAgICAgICAgICAgaW50ZXJ3b3JraW5nOyBTeXN0ZW0gZGVzY3Jp cHRpb24iLCAzR1BQIFRTDQo+ID4gPiA+IDIzLjIzNCBWZXJzaW9uDQo+ID4gPiA+ID4gICAgICAg ICAgICAgICAgIDcuNC4wIDIwMDYuDQo+ID4gPiA+ID4gICBIZXJlLCAzR1BQIEFBQSBQcm94eSBp cyBhIHN0YXRlZnVsIFByb3h5IEFnZW50Lg0KPiA+ID4NCj4gPiA+IFtjaG9wXQ0KPiA+ID4NCj4g PiA+ID4gSSB3YXMgdG9sZCB0aGF0IHRoZXJlIHdhcyBhIGRpc2N1c3Npb24gaW4gdGhlIDNHUFAg b25jZSBhYm91dA0KPiA+ID4gPiB0aGlzIGFzcGVjdC4gVGhlIFdMQU4gM0cgaW50ZXJ3b3JraW5n IHdhcyBkb25lIGEgbG9uZyB0aW1lDQo+ID4gPiA+IGFnbyBhbmQgd2UgaGF2ZSBuZXZlciBoZWFy ZCBiYWNrIGZyb20gdGhlbS4NCj4gPiA+DQo+ID4gPiBIZWFyZCBiYWNrIHdoYXQ/IEluIDNHUFAg cm91dGluZyBldGMgaXMgYWdhaW4gdW5kZXIgZGlzY3Vzc2lvbg0KPiA+ID4gaW4gcmVsLTggdGlt ZWZyYW1lLiBDb21pbmcgYmFjayB0byBhYm92ZSByZWZlcmVuY2UsIHRoZSBzYW1lDQo+ID4gPiBm YW1pbHkgb2Ygc2Nhcnkgc3BlY3MgYWxzbyB1c2UgTkFJIGRlY29yYXRpb24gYmFzZWQgc291cmNl DQo+ID4gPiByb3V0aW5nIGFzIHBhcnQgb2YgTkFTUkVRICYgRUFQIGFwcGxpY2F0aW9uIGZvciBz ZWxlY3RpbmcgdGhlDQo+ID4gPiBuZXh0IGhvcC4gSSBjYW5ub3QgZmluZCB0aGlzIChtaWdodCBi ZSBhIHJlc3VsdCBvZiBzbG9wcHkgcmVhZGluZykNCj4gPiA+IGZlYXR1cmUgYmVpbmcgZGVzY3Jp YmVkIGFueXdoZXJlIGluIERpYW1ldGVyIHNwZWNpZmljYXRpb24gdGh1cyBJDQo+ID4gPiBzdXNw ZWN0IGl0IHdpbGwgYWN0dWFsbHkgd29yay4gT3IgY2FuIHdlIGp1c3QgYXNzdW1lIHRoYXQgDQo+ IGV2ZXJ5dGhpbmcNCj4gPiA+IGRlZmluZWQgaW4gUkZDNDI4MiBnZXRzIHJlZmxlY3RlZCBiYWNr IHRvIGV4aXN0aW5nIGFwcGxpY2F0aW9ucz8NCj4gPiA+DQo+ID4gPiA+IEkgd291bGQgbGlrZSB0 byBoZWFyIGZyb20gYW4gb3BlcmF0b3IgdGhhdCB0aGV5IGhhdmUgYSBsYXJnZQ0KPiA+ID4gPiBE aWFtZXRlciBuZXR3b3JrIGFuZCB0aGF0IGlzc3VlIHR1cm5lZCBvdXQgdG8gYmUgYSBwcm9ibGVt LiBJDQo+ID4gPiA+IHdvdWxkIGFsc28gYmUgaGFwcHkgdG8gaGVhciBmcm9tIHZlbmRvcnMgd2hh dCB0aGV5IGRvLiBJIHdpbGwNCj4gPiA+ID4gY2VydGFpbmx5IGludmVzdGlnYXRlIHRoaXMgaXNz dWUgd2l0aCB2ZW5kb3JzIGFuZCBvcGVyYXRvcnMuDQo+ID4gPg0KPiA+ID4gUmF0aGVyIGFzay4u ICJhbiBvcGVyYXRvciB0aGF0IGhhdmUgYSBsYXJnZSBEaWFtZXRlciBuZXR3b3JrDQo+ID4gPiB3 aXRoIGludGVyLW9wZXJhdG9yIGludGVyZmFjZXMgaW4gbXVsdGktdmVuZG9yIGVudmlyb25tZW50 IiA7KQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBDaGVlcnMsDQo+ID4gPiAgICAgICAgSm91bmkNCj4g PiA+DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBDaWFvDQo+ID4gPiA+IEhhbm5l cw0KPiA+ID4gPg0KPiA+ID4gPiA+ICAgQ2lhbw0KPiA+ID4gPiA+ICAgSGFubmVzDQo+ID4gPiA+ DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+IERpTUUgbWFpbGluZyBsaXN0DQo+ID4gPiBEaU1FQGlldGYub3JnDQo+ID4g PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+ID4gPg0KPiA+ IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gPiBEaU1FQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRGlNRSBtYWlsaW5nIGxpc3QNCj4gRGlN RUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1l DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKiAgQXJpY2VudC1SZXN0 cmljdGVkICAgKioqKioqKioqKioqKioqKioqKioqKiogDQo+ICJESVNDTEFJTUVSOiBUaGlzIG1l c3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIA0KPiBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgDQo+IHRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVz c2VkLiBJdCBtYXkgY29udGFpbiANCj4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3Jt YXRpb24gYW5kIHNob3VsZCBub3QgYmUgDQo+IGNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1 cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyANCj4gaW50ZW5kZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgDQo+IHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSANCj4gaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQ0KPiBwcm9oaWJp dGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSANCj4g Y29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxp dHkgZm9yIA0KPiBsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5m b3JtYXRpb24gDQo+IHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBm cm9tIHZpcnVzLiINCj4gDQo+IA0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNl bnQtUmVzdHJpY3RlZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhp cyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2Vk LiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBh bmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhl ciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0 ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlm aWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcs IGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFy aWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNp bmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVt YWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 003054FB652573AE_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEpvdW5pICE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIHBlciBSRkMsIHJlbGF5 IG5vZGUgc2hvdWxkIG5vdCBldmVuDQpsb29rIGludG8gdGhlIG1lc3NhZ2UoZXhjZXB0IHRoZSBy b3V0aW5nIEFWUHMpLiBTbyBpbnRlcm1lZGlhcnkgbm9kZXMgc2hvdWxkDQpub3QgdHJ5ICZuYnNw O3RvIGNvbGxlY3QgY2hhcmdpbmcgZGF0YSBieSB0cmFja2luZyB0aGUgdXNlciBzZXNzaW9uLiBJ Zg0KdGhpcyBpcyB0aGUgY2FzZSwgdGhpcyB3b3VsZCBiZSBhZ2FpbnN0IHRoZSBzcGVjPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BcyBwZXIgZGVmaW5p dGlvbiBvZiByZWxheSBhZ2VudCBmcm9tDQpSRkMgMzU4ODwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1Jl bGF5cyBmb3J3YXJkDQpyZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGJhc2VkIG9uIHJvdXRpbmctcmVs YXRlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAm bmJzcDsgJm5ic3A7IEFWUHMgYW5kIHJlYWxtDQpyb3V0aW5nIHRhYmxlIGVudHJpZXMuICZuYnNw O1NpbmNlIDxiPnJlbGF5cyBkbyBub3QgbWFrZTwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBwb2xpY3kgZGVjaXNp b25zLA0KdGhleSBkbyBub3QgZXhhbWluZSBvciBhbHRlciBub24tcm91dGluZyBBVlBzPC9iPi48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7 ICZuYnNwOyBBcyBhIHJlc3VsdCwgcmVsYXlzDQpuZXZlciBvcmlnaW5hdGUgbWVzc2FnZXMsIGRv IG5vdCBuZWVkIHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdW5kZXJzdGFuZCB0aGUNCnNlbWFudGljcyBvZiBtZXNzYWdl cyBvciBub24tcm91dGluZyBBVlBzLCBhbmQgYXJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY2FwYWJsZSBvZiBoYW5kbGlu Zw0KYW55IERpYW1ldGVyIGFwcGxpY2F0aW9uIG9yIG1lc3NhZ2UgdHlwZS48L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+UHJlZXRpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPjxiPiZsdDtqb3VuaS5rb3Job25lbkB0ZWxpYXNvbmVyYS5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEyLzEx LzIwMDcgMTI6MTMgUE08L2ZvbnQ+DQo8YnI+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5QcmVldGkgU2hhbmRpbHlhL0hTU0BIU1MsDQombHQ7dGFzdmVyZW5A c29udXNuZXQuY29tJmd0OzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10 b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtkaW1lQGlldGYub3JnJmd0Oywg Jmx0O2dzaGFmcmFuQHRyYWZmaXhzeXN0ZW1zLmNvbSZndDs8L2ZvbnQ+DQo8dHI+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0PC9m b250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlJFOiBbRGltZV0gUmV2aWV3IG9mIGRyYWZ0LXRzb3UtZGltZS1iYXNlLXJvdXRpbmctZXh0LTAz LnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mj48dHQ+SGkgUHJlZXRpLDxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7IEZyb206IFByZWV0aSBTaGFuZGlseWEgW21haWx0bzpwcmVldGkuc2hhbmRp bHlhQGFyaWNlbnQuY29tXSA8YnI+DQomZ3Q7IFNlbnQ6IDExLiBqb3VsdWt1dXRhIDIwMDcgNjox OTxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSAhIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIG5v dCBzdXJlIHdoeSB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBzdWJzZXF1ZW50IDxicj4NCiZn dDsgc2Vzc2lvbiBvcmllbnRlZCBtZXNzYWdlIHRvIHRyYXZlcnNlIHRoZSBzYW1lIGludGVybWVk aWFyeSA8YnI+DQomZ3Q7IGhvcHMgd2hpY2ggdGhlIGluaXRpYWwgbWVzc2FnZSBoYXMgdHJhdmVy c2VkLiA8YnI+DQo8YnI+DQpXaGF0IGlmIHNvbWUgb2YgdGhlIGludGVybWVkaWF0ZXMgYXJlIHN0 YXRlZnVsIGFuZCBlLmcuPGJyPg0KY29sbGVjdCBjaGFyZ2luZyBkYXRhIGJ5IHRyYWNraW5nIHRo ZSB1c2VyIHNlc3Npb24/PGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpKb3VuaTxicj4NCjxicj4N CiZndDsgVWx0aW1hdGUgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgc2Vzc2lvbiBvcmllbnRlZCBt ZXNzYWdlIDxicj4NCiZndDsgc2hvdWxkIGxhbmR1cCBhdCB0aGUgc2FtZSBkZXN0aW5hdGlvbiBo b3N0IHRvIHdoaWNoIHRoZSBmaXJzdCA8YnI+DQomZ3Q7IG1lc3NhZ2UsICZuYnNwO3dpdGggcmVz cGVjdCB0byB0aGF0IHNlc3Npb24gLCBoYXMgcmVhY2hlZC4gQXMgcGVyDQo8YnI+DQomZ3Q7IFJG QyB0aGUgc3Vic2VxdWVudCBtZXNzYWdlIHNoYWxsIGhhdmUgdGhlIGRlc3RpbmF0aW9uIGhvc3Qg PGJyPg0KJmd0OyBlbWJlZGRlZCBpbiB0aGUgbWVzc2FnZS4gU28gaXJyZXNwZWN0aXZlIG9mIHRo ZSBwYXRoIHdoaWNoIDxicj4NCiZndDsgaW50ZXJtZWRpYXJ5IG1lc3NhZ2UgZm9sbG93LCBpZiBp dCByZWFjaGVzIHRvIHRoZSBzYW1lIDxicj4NCiZndDsgZGVzdGluYXRpb24gbm9kZSwgZXZlcnl0 aGluZyBzaGFsbCB3b3JrIGZpbmUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbmx5IHJlcXVpcmVt ZW50IHdoaWNoIGlzIG1hbmRhdG9yeSBoZXJlIGlzIHRoYXQgcmVzcG9uc2UgPGJyPg0KJmd0OyBt ZXNzYWdlIHNob3VsZCBmb2xsb3cgdGhlIHNhbWUgcm91dGUgd2hpY2ggcmVxdWVzdCBtZXNzYWdl IDxicj4NCiZndDsgaGFzIHRyYXZlcnNlZCwgJm5ic3A7dG8gaGF2ZSB0aGUgY29ycmVjdCBlbnRy eSBvZiB0aGUgaG9wLWJ5LWhvcCA8YnI+DQomZ3Q7IElkLiBBbHNvIHRoZXJlIG5lZWQgdG8gYmUg YSBtZWNoYW5pc20gc28gdGhhdCBtYXBwaW5nIGNyZWF0ZWQgPGJyPg0KJmd0OyBhdCB0aGUgaW50 ZXJtZWRpYXJ5IGhvcHMgc2hvdWxkIGJlIHBlcmlvZGljYWxseSBkZWxldGVkIHRvIDxicj4NCiZn dDsgdGFrZSBjYXJlIG9mIHRoZSBzY2VuYXJpbyBvZiBub3QgcmVjZWl2aW5nIHJlc3BvbnNlIGZy b20gdGhlIDxicj4NCiZndDsgc2VydmVyIGV2ZXIuIGkuZSBJZiBzZXJ2ZXIgcmVzcG9uZHMgdG8g dGhlIHJlc2VudCByZXF1ZXN0IDxicj4NCiZndDsgZnJvbSBjbGllbnQgKHdoaWNoIGZvbGxvd3Mg dGhlIGRpZmZlcmVudCBwYXRoKSAmbmJzcDthbmQgb3JpZ2luYWwNCjxicj4NCiZndDsgcmVxdWVz dCB3YXMgbmV2ZXIgYW5zd2VyZWQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBQYXJkb24sIGlmIEkg YW0gbWlzc2luZyBzb21ldGhpbmcgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0K Jmd0OyAtUHJlZXRpIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg JnF1b3Q7QXN2ZXJlbiwgVG9sZ2EmcXVvdDsgJmx0O3Rhc3ZlcmVuQHNvbnVzbmV0LmNvbSZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEyLzExLzIwMDcgMTI6NTYgQU0gPGJyPg0KJmd0OyBUbzxi cj4NCiZndDsgJnF1b3Q7R2lsIFNoYWZyYW4mcXVvdDsgJmx0O2dzaGFmcmFuQHRyYWZmaXhzeXN0 ZW1zLmNvbSZndDssICZsdDtkaW1lQGlldGYub3JnJmd0Ow0KPGJyPg0KJmd0OyBjYzxicj4NCiZn dDsgU3ViamVjdDxicj4NCiZndDsgUkU6IFtEaW1lXSBSZXZpZXcgb2YgZHJhZnQtdHNvdS1kaW1l LWJhc2Utcm91dGluZy1leHQtMDMudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIEdpbCw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayBleHBsaWNpdCByb3V0aW5nIGlzc3VlIGlzIG1v cmUgcmVsYXRlZCB3aXRoIHZpc2l0ZWQgbmV0d29yazxicj4NCiZndDsgKGFjdHVhbGx5IGFueSBu ZXR3b3JrKSB0cnlpbmcgdG8gbWFrZSBzdXJlIHRoYXQgbWVzc2FnZXMgZm9yIGEgc2Vzc2lvbjxi cj4NCiZndDsgdHJhdmVyc2Ugc29tZSBvZiB0aGUgaW50ZXJtZWRpYXJpZXMsIHdoaWNoIHdlcmUg dXNlZCBkdXJpbmcgcm91dGluZw0Kb2Y8YnI+DQomZ3Q7IHRoZSBpbml0aWFsIHJlcXVlc3QgZm9y IHRoYXQgcGFydGljdWxhciBzZXNzaW9uLiBJIGRvbid0IHNlZSB0aGlzPGJyPg0KJmd0OyBtZWNo YW5pc20gYXMgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIHNlc3Npb24gZW5mb3JjaW5nIGEgcGF0aDxi cj4NCiZndDsgKHBvdGVudGlhbGx5L3BhcnRseSBpbiBhbm90aGVyIG5ldHdvcmspIGJlZm9yZSB0 aGUgc2Vzc2lvbiBpczxicj4NCiZndDsgZXN0YWJsaXNoZWQuIEJUVywgaW50ZXJtZWRpYXJpZXMg d2hpY2ggZG8gbm90IHdhbnQgdG8gc3RheSBvbiB0aGUNCnBhdGg8YnI+DQomZ3Q7IGRvbid0IG5l ZWQgdG8gcGFydGljaXBhdGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEEgbmV0d29yayB3aXRoIGFs bCBlbGVtZW50cyBzdGF0ZWZ1bCB3b24ndCBoYXZlIGFuIGlzc3VlIGJ1dCBoZXJlDQp0aGU8YnI+ DQomZ3Q7IGtleSBwb2ludCBpcyB0aGF0ICphbGwqIGVsZW1lbnRzIHNob3VsZCBoYXZlIHRoZSBp bnRlbGxpZ2VuY2UgPGJyPg0KJmd0OyB0byBzZWxlY3Q8YnI+DQomZ3Q7IHRoZSBzYW1lIG5leHQt aG9wZSBmb3IgYWxsIHJlcXVlc3RzIG9mIGEgcGFydGljdWxhciBzZXNzaW9uLjxicj4NCiZndDsg PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyBUb2xnYTxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZyb206IEdpbCBT aGFmcmFuIFttYWlsdG86Z3NoYWZyYW5AdHJhZmZpeHN5c3RlbXMuY29tXTxicj4NCiZndDsgJmd0 OyBTZW50OiBNb25kYXksIERlY2VtYmVyIDEwLCAyMDA3IDE6MDYgUE08YnI+DQomZ3Q7ICZndDsg VG86IGRpbWVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtEaW1lXSBSZXZp ZXcgb2YgPGJyPg0KJmd0OyBkcmFmdC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0wMy50eHQ8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IElNSE8sIHZpc2l0ZWQgbmV0d29yayBjbGllbnRzIHNob3VsZCBub3QgZm9y Y2UgYW4gZXhwbGljaXQgPGJyPg0KJmd0OyByb3V0aW5nIGluPGJyPg0KJmd0OyAmZ3Q7IG5ldHdv cmsgZG9tYWlucyBvZiBvdGhlciBvcGVyYXRvcnMuIEkgYmVsaWV2ZSBvcGVyYXRvcnMgd291bGQN CnByZWZlcjxicj4NCiZndDsgJmd0OyB0byBmdWxseSBjb250cm9sIHRoZWlyIGxvYWQgYmFsYW5j aW5nIGFuZCByb3V0aW5nIGlzc3Vlcy4gVGhleQ0KY2FuPGJyPg0KJmd0OyAmZ3Q7IGFsc28gYXNz dXJlIHJvdXRpbmcgdGhyb3VnaCB0aGVpciBvd24gc3RhdGVmdWwgRGlhbWV0ZXIgPGJyPg0KJmd0 OyBwcm94aWVzLiBVc2luZzxicj4NCiZndDsgJmd0OyB0aGUgZXhpc3RpbmcgRGlhbWV0ZXIgcm91 dGluZyBkZWZpbml0aW9ucyAoUkZDIDM1ODgpLCBhbiA8YnI+DQomZ3Q7IG9wZXJhdG9yIGhhczxi cj4NCiZndDsgJmd0OyBvbmx5IHJvdWdoIGtub3dsZWRnZSBhbmQgY29udHJvbCAoZGVzdGluYXRp b24gcmVhbG0pIG92ZXIgb3RoZXI8YnI+DQomZ3Q7ICZndDsgbmV0d29ya3MsIHdoaWNoIGlzIGEg Z29vZCBtb2R1bGFyIG1vZGVsLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmVnYXJk cyw8YnI+DQomZ3Q7ICZndDsgR2lsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgT24gRGVjIDYsIDIwMDcgOToyMCBQTSwgJm5ic3A7Jmx0O2pvdW5pLmtvcmhv bmVuQHRlbGlhc29uZXJhLmNvbSZndDsNCndyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7IEhhbm5l cyw8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IEZldyBjb21tZW50cyBp bmxpbmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBbc25pcF08YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgW1Rp bmE6IFRoZXJlIGlzIFJlbGF5IEFnZW50IGluIERpYW1ldGVyDQpyb3V0aW5nIHBhdGgsIGF0PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgc2FtZSB0aW1lLCBpbiB0aGUgY2FzZSBpdCBoYXMg cmVsYXRpdmUgbWFueSBuZXh0DQpob3A8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5vZGVzLCBy b3V0aW5nIHByb2JhYmx5IGNoYW5nZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBEbyB3ZSBoYXZlIHRoZXNlIHR5cGVzIG9mIERpYW1ldGVy IGRlcGxveW1lbnRzIGFscmVhZHkNCnRoYXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGhhdmUg c28gbWFueSBob3BzPzxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRG8g d2UgaGF2ZSBsYXJnZSBkZXBsb3ltZW50cyBpbiBnZW5lcmFsIHRoYXQgaGF2ZSBpbnRlci1vcGVy YXRvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IGludGVyZmFjZXM/IEF0IHRoaXMgc3RhZ2UgcmVxdWly aW5nIGRlcGxveW1lbnQgZXhwZXJpZW5jZQ0KaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyBraW5kYSB3 ZWlyZC4gSSBtZWFuLCB0aGVyZSBhcmUgaWRlbnRpZmllZCBpc3N1ZXMgc2xhc2ggZ3JleTxicj4N CiZndDsgJmd0OyAmZ3Q7IGFyZWFzLCBzbyB3aHkgbm90IHN0dWR5IGFuZCBkb2N1bWVudCB0aG9z ZSBiZWZvcmUgd2UgaGl0DQp0aGVtPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW4gcmVhbCBkZXBsb3lt ZW50cz88YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm bmJzcDsgSXQgaXMgYmVjYXVzZSB0aGF0IHRoZSBEaWFtZXRlciBSZWxheSBBZ2VudA0KaXMgbGlr ZWx5IHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzZWxlY3QgdGhlIG5leHQgaG9wIG5vZGUg YnkgcmFuZG9tLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgSG1tbS4gUHJvYmFibHkgdGhpcyBpcyB0aGVuIHRoZSBwcm9ibGVtLiBXZSB0aGVu IHNob3VsZG4ndDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZGV2ZWxvcCBwcm90b2NvbCBleHRl bnNpb25zIGJ1dCByYXRoZXIgd3JpdGUgYSBkb2N1bWVudA0KdGhhdDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgaW5kaWNhdGVzIHdoYXQgZ29vZCBkZXNpZ24gZm9yIFJlbGF5IEFnZW50cyBpcy48 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IElNSE8gdGhhdCBzdGlsbCBk b2VzIG5vdCBtYWtlIHRoZSBpc3N1ZSBnbyBhd2F5Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgW3NuYXBdPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7IERvIHdlIGhhdmUgc29tZSByZWFsLXdvcmxkIGRhdGEgaW5k aWNhdGluZw0KdGhhdCB0aGlzIGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBpbmRlZWQgYSBw cm9ibGVtPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyByYXRoZXIgdGhhbiBh biBhY2FkZW1pYyBleGVyY2lzZT88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 IFtUaW5hOiBIZXJlIGFyZSBzb21lIGFwcGxpY2F0aW9uIHdpdGggc3RhdGVmdWwNClByb3h5PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBZ2VudCBpbiAzR1BQIGFuZCBFVFNJIFRJU1BBTi4gSSB0 aGluayB0aGF0IGlmIHRoZXJlDQppczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc3RhdGVmdWwg UHJveHkgQWdlbnQsIHN1Y2ggbWVjaGFuaXNtIGlzIG5lZWRlZC48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7IFtUUzIzLjIzNF08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgM0dQUCwgJnF1b3Q7M0dQUCBzeXN0ZW0gdG8gV2lyZWxlcyBMb2NhbCBBcmVhPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBOZXR3b3JrIChXTEFOKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyBpbnRlcndvcmtpbmc7IFN5c3RlbSBkZXNjcmlwdGlvbiZxdW90OywgM0dQUCBUUzxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgMjMuMjM0IFZlcnNpb248YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgNy40LjAgMjAwNi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7 IEhlcmUsIDNHUFAgQUFBIFByb3h5IGlzIGEgc3RhdGVmdWwgUHJveHkNCkFnZW50Ljxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgW2Nob3BdPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgd2FzIHRvbGQgdGhhdCB0aGVyZSB3YXMgYSBk aXNjdXNzaW9uIGluIHRoZSAzR1BQDQpvbmNlIGFib3V0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyB0aGlzIGFzcGVjdC4gVGhlIFdMQU4gM0cgaW50ZXJ3b3JraW5nIHdhcyBkb25lIGEgbG9uZw0K dGltZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYWdvIGFuZCB3ZSBoYXZlIG5ldmVyIGhlYXJk IGJhY2sgZnJvbSB0aGVtLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg SGVhcmQgYmFjayB3aGF0PyBJbiAzR1BQIHJvdXRpbmcgZXRjIGlzIGFnYWluIHVuZGVyIGRpc2N1 c3Npb248YnI+DQomZ3Q7ICZndDsgJmd0OyBpbiByZWwtOCB0aW1lZnJhbWUuIENvbWluZyBiYWNr IHRvIGFib3ZlIHJlZmVyZW5jZSwgdGhlDQpzYW1lPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZmFtaWx5 IG9mIHNjYXJ5IHNwZWNzIGFsc28gdXNlIE5BSSBkZWNvcmF0aW9uIGJhc2VkIHNvdXJjZTxicj4N CiZndDsgJmd0OyAmZ3Q7IHJvdXRpbmcgYXMgcGFydCBvZiBOQVNSRVEgJmFtcDsgRUFQIGFwcGxp Y2F0aW9uIGZvciBzZWxlY3RpbmcNCnRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG5leHQgaG9wLiBJ IGNhbm5vdCBmaW5kIHRoaXMgKG1pZ2h0IGJlIGEgcmVzdWx0IG9mIHNsb3BweQ0KcmVhZGluZyk8 YnI+DQomZ3Q7ICZndDsgJmd0OyBmZWF0dXJlIGJlaW5nIGRlc2NyaWJlZCBhbnl3aGVyZSBpbiBE aWFtZXRlciBzcGVjaWZpY2F0aW9uDQp0aHVzIEk8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdXNwZWN0 IGl0IHdpbGwgYWN0dWFsbHkgd29yay4gT3IgY2FuIHdlIGp1c3QgYXNzdW1lIHRoYXQNCjxicj4N CiZndDsgZXZlcnl0aGluZzxicj4NCiZndDsgJmd0OyAmZ3Q7IGRlZmluZWQgaW4gUkZDNDI4MiBn ZXRzIHJlZmxlY3RlZCBiYWNrIHRvIGV4aXN0aW5nIGFwcGxpY2F0aW9ucz88YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSB3b3VsZCBsaWtlIHRvIGhlYXIgZnJv bSBhbiBvcGVyYXRvciB0aGF0IHRoZXkgaGF2ZQ0KYSBsYXJnZTxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgRGlhbWV0ZXIgbmV0d29yayBhbmQgdGhhdCBpc3N1ZSB0dXJuZWQgb3V0IHRvIGJlIGEN CnByb2JsZW0uIEk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdvdWxkIGFsc28gYmUgaGFwcHkg dG8gaGVhciBmcm9tIHZlbmRvcnMgd2hhdCB0aGV5DQpkby4gSSB3aWxsPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBjZXJ0YWlubHkgaW52ZXN0aWdhdGUgdGhpcyBpc3N1ZSB3aXRoIHZlbmRvcnMg YW5kIG9wZXJhdG9ycy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFJh dGhlciBhc2suLiAmcXVvdDthbiBvcGVyYXRvciB0aGF0IGhhdmUgYSBsYXJnZSBEaWFtZXRlcg0K bmV0d29yazxicj4NCiZndDsgJmd0OyAmZ3Q7IHdpdGggaW50ZXItb3BlcmF0b3IgaW50ZXJmYWNl cyBpbiBtdWx0aS12ZW5kb3IgZW52aXJvbm1lbnQmcXVvdDsNCjspPGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IENoZWVycyw8YnI+DQom Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKb3VuaTxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2lhbzxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgSGFubmVzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgQ2lhbzxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmbmJzcDsgSGFubmVzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBEaU1FIG1haWxpbmcg bGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0 OyBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPGJyPg0KJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IERpTUUgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTxicj4NCiZndDsgPGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKioqKioqKioqKioqKioqKioq KioqKiogJm5ic3A7QXJpY2VudC1SZXN0cmljdGVkICZuYnNwOyAqKioqKioqKioqKioqKioqKioq KioqKg0KPGJyPg0KJmd0OyAmcXVvdDtESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJp ZXRhcnkgdG8gQXJpY2VudCAmbmJzcDthbmQNCmlzIDxicj4NCiZndDsgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIDxicj4NCiZndDsgdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBh ZGRyZXNzZWQuIEl0IG1heSBjb250YWluIDxicj4NCiZndDsgcHJpdmlsZWdlZCBvciBjb25maWRl bnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgPGJyPg0KJmd0OyBjaXJjdWxhdGVk IG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgPGJyPg0K Jmd0OyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9y LCA8YnI+DQomZ3Q7IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElm IHlvdSBhcmUgbm90IHRoZSA8YnI+DQomZ3Q7IGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBu b3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHk8YnI+DQomZ3Q7IHByb2hpYml0ZWQgZnJvbSB1 c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIDxicj4NCiZndDsgY29u dGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkg Zm9yIDxicj4NCiZndDsgbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIDxicj4NCiZndDsgdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRp bmcgZGFtYWdlIGZyb20gdmlydXMuJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+ DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVJlc3RyaWN0ZWQgJm5ic3A7 ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0j ZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdl IGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxk IG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZv ciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2Ug aW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQg eW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5n LCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNj ZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0 aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1 ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 003054FB652573AE_=-- --===============1783300658== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1783300658==-- From dime-bounces@ietf.org Tue Dec 11 04:10:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J218F-0000X1-2m; Tue, 11 Dec 2007 04:10:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J218C-0000Ml-Ur for dime@ietf.org; Tue, 11 Dec 2007 04:10:25 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J218B-0008F7-Au for dime@ietf.org; Tue, 11 Dec 2007 04:10:24 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSV0087ONSQ7G@szxga02-in.huawei.com> for dime@ietf.org; Tue, 11 Dec 2007 17:02:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSV005FFNSEIC@szxga02-in.huawei.com> for dime@ietf.org; Tue, 11 Dec 2007 17:02:50 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSV0099WNSEI2@szxml04-in.huawei.com> for dime@ietf.org; Tue, 11 Dec 2007 17:02:38 +0800 (CST) Date: Tue, 11 Dec 2007 17:02:38 +0800 From: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt To: Glen Zorn , jouni.korhonen@teliasonera.com, preeti.shandilya@aricent.com, tasveren@sonusnet.com Message-id: <018a01c83bd4$9437a780$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> <00a701c83bcb$8f25acf0$ad7106d0$@net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2039106967==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2039106967== Content-type: multipart/alternative; boundary="Boundary_(ID_nsdi2aXDQuWlIAvjIzvG4Q)" This is a multi-part message in MIME format. --Boundary_(ID_nsdi2aXDQuWlIAvjIzvG4Q) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Dear Glen and all, I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me. Use case #1: There are several visiting network, and one home network. Type 1# service should go via intermediate node #a in visiting network A#. Type 2# service should go via intermediate node #b in visiting network B#. ...... This use case can be for both mobile and fix network operator. Use case #2: The charging data should be sent from that node. This use case can be for mobile operator. B. R. Tina ------------------------------------------------------------- You know it is Monday when you see cat hair in your cereal. ----- Original Message ----- From: Glen Zorn To: jouni.korhonen@teliasonera.com ; preeti.shandilya@aricent.com ; tasveren@sonusnet.com Cc: dime@ietf.org ; gshafran@traffixsystems.com Sent: Tuesday, December 11, 2007 3:58 PM Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt ... > I am not sure why there is a requirement for subsequent > session oriented message to traverse the same intermediary > hops which the initial message has traversed. What if some of the intermediates are stateful and e.g. collect charging data by tracking the user session? [gwz] I must admit that I cannot think of a single (real-life) scenario where this kind of thing would be desirable (let alone required). Would you mind describing one in detail? [/gwz] ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_nsdi2aXDQuWlIAvjIzvG4Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Dear Glen and all,
I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me.
 
Use case #1:
There are several visiting network, and one home network.
Type 1# service should go via intermediate node #a in visiting network A#.
Type 2# service should go via intermediate node #b in visiting network B#.
......
This use case can be for both mobile and fix network operator.
 
Use case #2:
The charging data should be sent from that node.
 
This use case can be for mobile operator.
 
B. R.
Tina
-------------------------------------------------------------
You know it is Monday when you see cat hair in your cereal.
----- Original Message -----
From: Glen Zorn
Sent: Tuesday, December 11, 2007 3:58 PM
Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

...

> I am not sure why there is a requirement for subsequent
> session oriented message to traverse the same intermediary
> hops which the initial message has traversed.

What if some of the intermediates are stateful and e.g.
collect charging data by tracking the user session?

[gwz]
I must admit that I cannot think of a single (real-life) scenario where this
kind of thing would be desirable (let alone required).  Would you mind
describing one in detail?
[/gwz]
 
...


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_nsdi2aXDQuWlIAvjIzvG4Q)-- --===============2039106967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============2039106967==-- From dime-bounces@ietf.org Tue Dec 11 05:47:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22eT-0003ii-If; Tue, 11 Dec 2007 05:47:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J22eS-0003id-AK for dime@ietf.org; Tue, 11 Dec 2007 05:47:48 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J22eQ-0005EP-Uc for dime@ietf.org; Tue, 11 Dec 2007 05:47:48 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 11:47:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 11:47:40 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CE4@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg70pOOcM0e98tvSwuAeseQ4DRqsQACRSyg References: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> From: To: X-OriginalArrivalTime: 11 Dec 2007 10:47:45.0363 (UTC) FILETIME=[4359C230:01C83BE3] X-Spam-Score: -4.0 (----) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Preeti, > -----Original Message----- > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 > Sent: 11. joulukuuta 2007 10:47 >=20 > Hi Jouni !=20 >=20 > As per RFC, relay node should not even look into the=20 Should have said that I meant proxy there. /Jouni > message(except the routing AVPs). So intermediary nodes=20 > should not try to collect charging data by tracking the user=20 > session. If this is the case, this would be against the spec=20 >=20 > As per definition of relay agent from RFC 3588=20 >=20 > "Relays forward requests and responses based on routing-related=20 > AVPs and realm routing table entries. Since relays do not make=20 > policy decisions, they do not examine or alter=20 > non-routing AVPs.=20 > As a result, relays never originate messages, do not need to=20 > understand the semantics of messages or non-routing=20 > AVPs, and are=20 > capable of handling any Diameter application or message type."=20 >=20 > regards > Preeti=20 >=20 >=20 >=20 > =20 >=20 > 12/11/2007 12:13 PM=20 > To > Preeti Shandilya/HSS@HSS, =20 > cc > , =20 > Subject > RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > =09 >=20 >=20 >=20 >=20 > Hi Preeti, >=20 > > -----Original Message----- > > From: Preeti Shandilya [mailto:preeti.shandilya@aricent.com]=20 > > Sent: 11. joulukuuta 2007 6:19 > >=20 > > Hi !=20 > >=20 > > I am not sure why there is a requirement for subsequent=20 > > session oriented message to traverse the same intermediary=20 > > hops which the initial message has traversed.=20 >=20 > What if some of the intermediates are stateful and e.g. > collect charging data by tracking the user session? >=20 > Cheers, > Jouni >=20 > > Ultimate requirement is that the session oriented message=20 > > should landup at the same destination host to which the first=20 > > message, with respect to that session , has reached. As per=20 > > RFC the subsequent message shall have the destination host=20 > > embedded in the message. So irrespective of the path which=20 > > intermediary message follow, if it reaches to the same=20 > > destination node, everything shall work fine.=20 > >=20 > > Only requirement which is mandatory here is that response=20 > > message should follow the same route which request message=20 > > has traversed, to have the correct entry of the hop-by-hop=20 > > Id. Also there need to be a mechanism so that mapping created=20 > > at the intermediary hops should be periodically deleted to=20 > > take care of the scenario of not receiving response from the=20 > > server ever. i.e If server responds to the resent request=20 > > from client (which follows the different path) and original=20 > > request was never answered.=20 > >=20 > > Pardon, if I am missing something=20 > >=20 > > Regards, > > -Preeti=20 > >=20 > >=20 > >=20 > > "Asveren, Tolga" =20 > >=20 > > 12/11/2007 12:56 AM=20 > > To > > "Gil Shafran" , =20 > > cc > > Subject > > RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt > >=20 > > =20 > >=20 > >=20 > >=20 > >=20 > > Hi Gil, > >=20 > > I think explicit routing issue is more related with visited network > > (actually any network) trying to make sure that messages=20 > for a session > > traverse some of the intermediaries, which were used during=20 > routing of > > the initial request for that particular session. I don't see this > > mechanism as the originator of the session enforcing a path > > (potentially/partly in another network) before the session is > > established. BTW, intermediaries which do not want to stay=20 > on the path > > don't need to participate. > >=20 > > A network with all elements stateful won't have an issue=20 > but here the > > key point is that *all* elements should have the intelligence=20 > > to select > > the same next-hope for all requests of a particular session. > >=20 > > Thanks, > > Tolga > >=20 > > > -----Original Message----- > > > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > > > Sent: Monday, December 10, 2007 1:06 PM > > > To: dime@ietf.org > > > Subject: Re: [Dime] Review of=20 > > draft-tsou-dime-base-routing-ext-03.txt > > >=20 > > > Hi all, > > >=20 > > > IMHO, visited network clients should not force an explicit=20 > > routing in > > > network domains of other operators. I believe operators=20 > would prefer > > > to fully control their load balancing and routing issues. They can > > > also assure routing through their own stateful Diameter=20 > > proxies. Using > > > the existing Diameter routing definitions (RFC 3588), an=20 > > operator has > > > only rough knowledge and control (destination realm) over other > > > networks, which is a good modular model. > > >=20 > > > Regards, > > > Gil > > >=20 > > >=20 > > > On Dec 6, 2007 9:20 PM, wrote: > > > > Hannes, > > > > > > > > Few comments inline. > > > > > > > > [snip] > > > > > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > > > the same time, in the case it has relative many next hop > > > > > nodes, routing probably changes. > > > > > > > > > > > Do we have these types of Diameter deployments already that > > > > > have so many hops? > > > > > > > > Do we have large deployments in general that have inter-operator > > > > interfaces? At this stage requiring deployment experience is > > > > kinda weird. I mean, there are identified issues slash grey > > > > areas, so why not study and document those before we hit them > > > > in real deployments? > > > > > > > > > > It is because that the Diameter Relay Agent is likely to > > > > > select the next hop node by random. > > > > > > > > > > > Hmmm. Probably this is then the problem. We then shouldn't > > > > > develop protocol extensions but rather write a document that > > > > > indicates what good design for Relay Agents is. > > > > > > > > IMHO that still does not make the issue go away. > > > > > > > > [snap] > > > > > > > > > > Do we have some real-world data indicating that this is > > > > > indeed a problem > > > > > > rather than an academic exercise? > > > > > > [Tina: Here are some application with stateful Proxy > > > > > Agent in 3GPP and ETSI TISPAN. I think that if there is > > > > > stateful Proxy Agent, such mechanism is needed. > > > > > > [TS23.234] > > > > > > 3GPP, "3GPP system to Wireles Local Area > > > > > Network (WLAN) > > > > > > interworking; System description", 3GPP TS > > > > > 23.234 Version > > > > > > 7.4.0 2006. > > > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > > > [chop] > > > > > > > > > I was told that there was a discussion in the 3GPP once about > > > > > this aspect. The WLAN 3G interworking was done a long time > > > > > ago and we have never heard back from them. > > > > > > > > Heard back what? In 3GPP routing etc is again under discussion > > > > in rel-8 timeframe. Coming back to above reference, the same > > > > family of scary specs also use NAI decoration based source > > > > routing as part of NASREQ & EAP application for selecting the > > > > next hop. I cannot find this (might be a result of=20 > sloppy reading) > > > > feature being described anywhere in Diameter=20 > specification thus I > > > > suspect it will actually work. Or can we just assume that=20 > > everything > > > > defined in RFC4282 gets reflected back to existing applications? > > > > > > > > > I would like to hear from an operator that they have a large > > > > > Diameter network and that issue turned out to be a problem. I > > > > > would also be happy to hear from vendors what they do. I will > > > > > certainly investigate this issue with vendors and operators. > > > > > > > > Rather ask.. "an operator that have a large Diameter network > > > > with inter-operator interfaces in multi-vendor environment" ;) > > > > > > > > > > > > Cheers, > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 > >=20 > >=20 > > *********************** Aricent-Restricted =20 > ***********************=20 > > "DISCLAIMER: This message is proprietary to Aricent and is=20 > > intended solely for the use of=20 > > the individual to whom it is addressed. It may contain=20 > > privileged or confidential information and should not be=20 > > circulated or used for any purpose other than for what it is=20 > > intended. If you have received this message in error,=20 > > please notify the originator immediately. If you are not the=20 > > intended recipient, you are notified that you are strictly > > prohibited from using, copying, altering, or disclosing the=20 > > contents of this message. Aricent accepts no responsibility for=20 > > loss or damage arising from the use of the information=20 > > transmitted by this email including damage from virus." > >=20 > >=20 >=20 >=20 >=20 > *********************** Aricent-Restricted ***********************=20 > "DISCLAIMER: This message is proprietary to Aricent and is=20 > intended solely for the use of=20 > the individual to whom it is addressed. It may contain=20 > privileged or confidential information and should not be=20 > circulated or used for any purpose other than for what it is=20 > intended. If you have received this message in error,=20 > please notify the originator immediately. If you are not the=20 > intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the=20 > contents of this message. Aricent accepts no responsibility for=20 > loss or damage arising from the use of the information=20 > transmitted by this email including damage from virus." >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 09:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25hX-0002Va-Qc; Tue, 11 Dec 2007 09:03:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J25hW-0002VV-VB for dime@ietf.org; Tue, 11 Dec 2007 09:03:10 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J25hW-0000eo-5k for dime@ietf.org; Tue, 11 Dec 2007 09:03:10 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lBBE39Mc002253; Tue, 11 Dec 2007 09:03:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 09:03:09 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E750962A@sonusmail04.sonusnet.com> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB0@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1X6yiO+AoLiTfm8vnb3hd0GnQACsyygAAPMaYAAALAHUAAiUxeg References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> <033458F56EC2A64E8D2D7B759FA3E7E7509626@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB0@SEHAN021MB.tcad.telia.se> From: "Asveren, Tolga" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Monday, December 10, 2007 4:49 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt >=20 > Hi Tolga, >=20 > > Hi Jouni, > > > > A bit off topic but one question below. > > > > Thanks, > > Tolga > > > > > > > > Hi Gil, > > > > > > The functionality referenced earlier was actually requested by > > > operators to enable some of their potential roaming and deployment > > > scenarios. "Forcing" next hop is, for example, for > > deployments where a > > > shared NAP advertises a number direct roaming connections > > for realms > > > (say A.com, B.com and C.com) but > > [TOLGA]How does this advertisement work? Capability exchange > > mechanism does not have that type of capability(i.e. > > advertising application support per realm). >=20 > That's typically done before gaining the access to the network. > The access network may for example use RFC4284 to advertise realms > or then some access technology specific way (like .11u, .16g etc). >=20 > I am not actually sure what you are after with your question > related to capability exchange. [TOLGA]I was wondering how this would work from Diameter capability negotiation perspective: a) Does the NAP need to advertise support for certain application for different domains?=20 b) Or does it use a different Diameter identity for each domain? c) Or do the clients assume that NAP provides access for all possible domains? >=20 > Cheers, > Jouni >=20 >=20 > > > none of them match to roaming user's home realm (say D.com). > > > However, the roaming user knows that B.com has an agreement with > > > D.com, thus it asks from NAP for an "authentication route" > > > to D.com through B.com. After this all subsequent messages > > should take > > > the same path (either on realm or actual agent granularity > > depending > > > on the deployment). > > > > > > Cheers, > > > Jouni > > > > > > > > > > > > > -----Original Message----- > > > > From: Gil Shafran [mailto:gshafran@traffixsystems.com] > > > > Sent: 10. joulukuuta 2007 20:06 > > > > To: dime@ietf.org > > > > Subject: Re: [Dime] Review of > > draft-tsou-dime-base-routing-ext-03.txt > > > > > > > > > > > > Hi all, > > > > > > > > IMHO, visited network clients should not force an > > explicit routing > > > > in network domains of other operators. I believe operators would > > > > prefer to fully control their load balancing and routing issues. > > > > They can also assure routing through their own stateful Diameter > > > > proxies. Using the existing Diameter routing definitions > > (RFC 3588), > > > > an operator has only rough knowledge and control > > (destination realm) > > > > over other networks, which is a good modular model. > > > > > > > > Regards, > > > > Gil > > > > > > > > > > > > On Dec 6, 2007 9:20 PM, wrote: > > > > > Hannes, > > > > > > > > > > Few comments inline. > > > > > > > > > > [snip] > > > > > > > > > > > > [Tina: There is Relay Agent in Diameter routing path, at > > > > > > the same time, in the case it has relative many next > > hop nodes, > > > > > > routing probably changes. > > > > > > > > > > > > > Do we have these types of Diameter deployments already > > > > that have so > > > > > > many hops? > > > > > > > > > > Do we have large deployments in general that have > > inter-operator > > > > > interfaces? At this stage requiring deployment > > experience is kinda > > > > > weird. I mean, there are identified issues slash grey areas, so > > why > > > > > not study and document those before we hit them in real > > deployments? > > > > > > > > > > > > It is because that the Diameter Relay Agent is likely to > > > > > > select the next hop node by random. > > > > > > > > > > > > > Hmmm. Probably this is then the problem. We then > > > > shouldn't develop > > > > > > protocol extensions but rather write a document that > > > > indicates what > > > > > > good design for Relay Agents is. > > > > > > > > > > IMHO that still does not make the issue go away. > > > > > > > > > > [snap] > > > > > > > > > > > > Do we have some real-world data indicating that this is > > > > > > indeed a problem > > > > > > > rather than an academic exercise? > > > > > > > [Tina: Here are some application with stateful Proxy > > > > > > Agent in 3GPP and ETSI TISPAN. I think that if there > > is stateful > > > > > > Proxy Agent, such mechanism is needed. > > > > > > > [TS23.234] > > > > > > > 3GPP, "3GPP system to Wireles Local Area > > > > > > Network (WLAN) > > > > > > > interworking; System description", 3GPP TS > > > > > > 23.234 Version > > > > > > > 7.4.0 2006. > > > > > > > Here, 3GPP AAA Proxy is a stateful Proxy Agent. > > > > > > > > > > [chop] > > > > > > > > > > > I was told that there was a discussion in the 3GPP once > > > > about this > > > > > > aspect. The WLAN 3G interworking was done a long time > > ago and we > > > > > > have never heard back from them. > > > > > > > > > > Heard back what? In 3GPP routing etc is again under > > discussion in > > > > > rel-8 timeframe. Coming back to above reference, the same family > > of > > > > > scary specs also use NAI decoration based source routing as part > > of > > > > > NASREQ & EAP application for selecting the next hop. I > > cannot find > > > > > this (might be a result of sloppy reading) feature > > being described > > > > > anywhere in Diameter specification thus I suspect it > > will actually > > > > > work. Or can we just assume that everything defined in RFC4282 > > gets > > > > > reflected back to existing applications? > > > > > > > > > > > I would like to hear from an operator that they have a large > > > > > > Diameter network and that issue turned out to be a > > > > problem. I would > > > > > > also be happy to hear from vendors what they do. I will > > certainly > > > > > > investigate this issue with vendors and operators. > > > > > > > > > > Rather ask.. "an operator that have a large Diameter > > network with > > > > > inter-operator interfaces in multi-vendor environment" ;) > > > > > > > > > > > > > > > Cheers, > > > > > Jouni > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ciao > > > > > > Hannes > > > > > > > > > > > > > Ciao > > > > > > > Hannes > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 10:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27EQ-0008P2-Fo; Tue, 11 Dec 2007 10:41:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J27EO-0008Ot-TY for dime@ietf.org; Tue, 11 Dec 2007 10:41:12 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J27EM-0002mF-ME for dime@ietf.org; Tue, 11 Dec 2007 10:41:12 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 16:41:09 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 16:41:07 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CF1@SEHAN021MB.tcad.telia.se> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E750962A@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7V1X6yiO+AoLiTfm8vnb3hd0GnQACsyygAAPMaYAAALAHUAAiUxegAADNriA= References: <4757153B.2060802@gmx.net><59D7431DE2527D4CB0F1EFEDA5683ED3024F9C38@SEHAN021MB.tcad.telia.se> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CAE@SEHAN021MB.tcad.telia.se> <033458F56EC2A64E8D2D7B759FA3E7E7509626@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB0@SEHAN021MB.tcad.telia.se> <033458F56EC2A64E8D2D7B759FA3E7E750962A@sonusmail04.sonusnet.com> From: To: , X-OriginalArrivalTime: 11 Dec 2007 15:41:09.0388 (UTC) FILETIME=[402ACCC0:01C83C0C] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, [snip] > > > [TOLGA]How does this advertisement work? Capability exchange=20 > > > mechanism does not have that type of capability(i.e. > > > advertising application support per realm). > >=20 > > That's typically done before gaining the access to the network. > > The access network may for example use RFC4284 to advertise=20 > realms or=20 > > then some access technology specific way (like .11u, .16g etc). > >=20 > > I am not actually sure what you are after with your=20 > question related=20 > > to capability exchange. > [TOLGA]I was wondering how this would work from Diameter=20 > capability negotiation perspective: > a) Does the NAP need to advertise support for certain=20 > application for different domains?=20 Don't see a reason for this. > b) Or does it use a different Diameter identity for each domain? NAP has one identity. > c) Or do the clients assume that NAP provides access for all=20 > possible domains? The NAP provides access to those realms it advertises. Cheers, Jouni >=20 > >=20 > > Cheers, > > Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 13:24:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29mE-0008I9-9v; Tue, 11 Dec 2007 13:24:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29mC-0008I4-No for dime@ietf.org; Tue, 11 Dec 2007 13:24:16 -0500 Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J29mC-0004JO-16 for dime@ietf.org; Tue, 11 Dec 2007 13:24:16 -0500 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id PN3R1Y00416AWCU0A0gU00; Tue, 11 Dec 2007 18:24:20 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id PWQJ1Y00653lGY30800000; Tue, 11 Dec 2007 18:24:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=lHSIbCQlPutU3VykrlwA:9 a=RkElPbU2KUNca9IAhfYA:7 a=GI0-MGLy5fMduzRVTNWrjxtcNYgA:4 a=9OHTkwyHC8cA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=KO16Eer1JEDnvy3tIBkA:9 a=lvzbM2OI7V_iA-4XujAA:7 a=yZc56zp9RI6GPw0m_7lHoz0DeqIA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Tina TSOU'" , , , References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> <00a701c83bcb$8f25acf0$ad7106d0$@net> <018a01c83bd4$9437a780$544c460a@china.huawei.com> In-Reply-To: <018a01c83bd4$9437a780$544c460a@china.huawei.com> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 10:21:35 -0800 Message-ID: <007b01c83c22$ab1f50d0$015df270$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg71J4ADDKJFqs3Ss2q5RN3GYiE8AATI9eQ Content-language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526864543==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0526864543== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C83BDF.9CFC10D0" Content-language: en-us This is a multipart message in MIME format. ------=_NextPart_000_007C_01C83BDF.9CFC10D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Glen and all, I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me. Use case #1: There are several visiting network, and one home network. Type 1# service should go via intermediate node #a in visiting network A#. Type 2# service should go via intermediate node #b in visiting network B#. ...... This use case can be for both mobile and fix network operator. [gwz] So what happens if node #a is down? Is Type 1# service disabled/unavailable? If not, what's the point of the routing, given that it is unnecessary; if so, doesn't that sort of defeat the purpose of fail-over? [/gwz] Use case #2: The charging data should be sent from that node. [gwz] Does this mean that the data path must also pass through that node? [/gwz] This use case can be for mobile operator. B. R. Tina ------=_NextPart_000_007C_01C83BDF.9CFC10D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear Gle= n and all,

I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, = Jouni, please correct me.

 

Use case #1:

There are several visiting network, and one home network. =

Type 1# service should go via intermediate node #a in visiting network = A#.

Type 2# service should go via intermediate node #b in visiting network = B#.

......=

This use case can be for both mobile and fix network = operator.

[gwz]

So what happens if node #a is down?  Is Type 1# = service disabled/unavailable?  If not, what's the point of the routing, = given that it is unnecessary; if so, doesn't that sort of defeat the purpose of = fail-over?

[/gwz]

 

Use case #2:

The charging data should be sent from that node.

[gwz]

Does this mean that the data path must also pass through = that node?

[/gwz]

 

This use case can be for mobile operator.

 

B. R.
Tina

------=_NextPart_000_007C_01C83BDF.9CFC10D0-- --===============0526864543== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0526864543==-- From dime-bounces@ietf.org Tue Dec 11 14:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B8O-0004Gw-VF; Tue, 11 Dec 2007 14:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2B8O-0004Gq-C8 for dime@ietf.org; Tue, 11 Dec 2007 14:51:16 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2B8N-0000Gb-0P for dime@ietf.org; Tue, 11 Dec 2007 14:51:16 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lBBJpEWA026315 for ; Tue, 11 Dec 2007 14:51:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Dec 2007 14:51:14 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7509632@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: state recovery draf; 02 version available Thread-Index: Acg8Ly+NvHJfF3uBTXOkAAm/3REEhg== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] state recovery draf; 02 version available X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I just posted a new version of draft-asveren-dime-state-recovery (as it has expired one month ago or so). There are no real changes between 01 and 02 versions.=20 I think it provides a good amount of introductionary information for the state recovery problem (what it is about, what are the parameters to consider, what are different approaches etc...) and a decent summary of what has been already discussed.=20 http://www.ietf.org/internet-drafts/draft-asveren-dime-state-recovery-02 .txt Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 17:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DvT-0006Vd-55; Tue, 11 Dec 2007 17:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DvR-0006VW-CG for dime@ietf.org; Tue, 11 Dec 2007 17:50:05 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2DvQ-0004dO-SM for dime@ietf.org; Tue, 11 Dec 2007 17:50:05 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 23:50:03 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 23:49:49 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CF5@SEHAN021MB.tcad.telia.se> In-Reply-To: <00a701c83bcb$8f25acf0$ad7106d0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Thread-Index: Acg7rRqyLoXOrcABSj+r85aZOywqsQAE3qnwAAKfSfAACYZF0A== References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> <00a701c83bcb$8f25acf0$ad7106d0$@net> From: To: X-OriginalArrivalTime: 11 Dec 2007 22:50:03.0418 (UTC) FILETIME=[2AD827A0:01C83C48] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: preeti.shandilya@aricent.com, dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, > > I am not sure why there is a requirement for subsequent session=20 > > oriented message to traverse the same intermediary hops which the=20 > > initial message has traversed. >=20 > What if some of the intermediates are stateful and e.g. > collect charging data by tracking the user session? >=20 > [gwz] > I must admit that I cannot think of a single (real-life)=20 > scenario where this kind of thing would be desirable (let=20 > alone required). Would you mind describing one in detail? > [/gwz] References to literature were given earlier in this thread ;) Anyway, assume two providers connected via "roaming infrastructure cloud" that cannot guarantee same AAA routes deterministically. The visited provider has outsourced its AAA based roaming charging to third party proxies within the "cloud" (each provider may have their own "third party").=20 /Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 22:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2I3O-0002f1-A7; Tue, 11 Dec 2007 22:14:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2I3N-0002es-BJ for dime@ietf.org; Tue, 11 Dec 2007 22:14:33 -0500 Received: from qmta09.emeryville.ca.mail.comcast.net ([76.96.30.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2I3L-0002dV-1U for dime@ietf.org; Tue, 11 Dec 2007 22:14:33 -0500 Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id PU331Y0070QkzPw0A11t00; Wed, 12 Dec 2007 03:14:35 +0000 Received: from gwzPC ([67.168.164.234]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id PfEZ1Y00853lGY30800000; Wed, 12 Dec 2007 03:14:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=cKVaRudWhOK2VkHbtnIA:9 a=-qc7naSnD_qXzyZD_PgA:7 a=F0xthONA86SrUxYwYbTxZ0_27XAA:4 a=tqucuuI3bnEA:10 From: "Glen Zorn" To: References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> <00a701c83bcb$8f25acf0$ad7106d0$@net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CF5@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CF5@SEHAN021MB.tcad.telia.se> Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Date: Tue, 11 Dec 2007 19:11:47 -0800 Message-ID: <00f701c83c6c$bcdace90$36906bb0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7rRqyLoXOrcABSj+r85aZOywqsQAE3qnwAAKfSfAACYZF0AAe0EGA Content-language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: preeti.shandilya@aricent.com, dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, > > I am not sure why there is a requirement for subsequent session > > oriented message to traverse the same intermediary hops which the > > initial message has traversed. > > What if some of the intermediates are stateful and e.g. > collect charging data by tracking the user session? > > [gwz] > I must admit that I cannot think of a single (real-life) > scenario where this kind of thing would be desirable (let > alone required). Would you mind describing one in detail? > [/gwz] References to literature were given earlier in this thread ;) Anyway, assume two providers connected via "roaming infrastructure cloud" that cannot guarantee same AAA routes deterministically. The visited provider has outsourced its AAA based roaming charging to third party proxies within the "cloud" (each provider may have their own "third party"). [gwz] And? [/gwz] /Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 11 23:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2JEW-0001qU-Ch; Tue, 11 Dec 2007 23:30:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2JEU-0001qM-RN for dime@ietf.org; Tue, 11 Dec 2007 23:30:06 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2JEQ-0004Fo-W5 for dime@ietf.org; Tue, 11 Dec 2007 23:30:06 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBC4JbWB027240 for ; Wed, 12 Dec 2007 09:49:37 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lBC4JVUo027186; Wed, 12 Dec 2007 09:49:32 +0530 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CF5@SEHAN021MB.tcad.telia.se> To: Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Wed, 12 Dec 2007 09:59:09 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 12/12/2007 10:04:45 AM, Serialize complete at 12/12/2007 10:04:45 AM X-Spam-Score: 2.8 (++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573900520==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1573900520== Content-Type: multipart/alternative; boundary="=_alternative 0018B0A3652573AF_=" This is a multipart message in MIME format. --=_alternative 0018B0A3652573AF_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgSm91bmkgIQ0KDQpJbiBteSBvcGluaW9uLCBpZiBpdCBpcyByZXF1aXJlZCB0aGF0IGFsbCB0 aGUgbWVzc2FnZXMgdG8gZm9sbG93IHRoZSBzYW1lIA0KcHJveHkgbm9kZShzbyB0aGF0IHByb3h5 IGNhbiBhcHBseSBjaGFyZ2luZykgLCB0aGlzIHNoYWxsIGJlIHNwZWNpZmljIA0Kbm9kZSdzIHJv dXRpbmcgcG9saWN5LiBpLmUgU291cmNlLCAgd2hpbGUgc2VsZWN0aW5nIGEgcm91dGUsIGl0IHNo b3VsZCANCmFsd2F5cyBlbmQgdXAgc2VsZWN0aW5nIHRoZSBwcm94eSBub2RlIGZvciBzZW5kaW5n IHRoZSBtZXNzYWdlLiBJIGRvbid0IA0KdGhpbmsgdGhlcmUgaXMgYW55IG5lZWQgb2Ygc3RhbmRh cmRpemF0aW9uIG9mIHJvdXRpbmcgcG9saWN5IGZvciB0aGlzIA0Kc3BlY2lmaWMgcHVycG9zZS4g V2hpbGUgc2VsZWN0aW5nIHRoZSByb3V0ZSwgbm9kZXMgY2FuIGxvb2sgaW50byB0aGUgdHlwZSAN Cm9mIHNlcnZpY2UgYWxzbyBpbnNpZGUgdGhlIG1lc3NhZ2Ugd2hpY2ggaXMgdG8gYmUgcm91dGVk IGZ1cnRoZXIuDQoNCnJlZ2FyZHMNCnByZWV0aQ0KDQoNCg0KPGpvdW5pLmtvcmhvbmVuQHRlbGlh c29uZXJhLmNvbT4gDQoxMi8xMi8yMDA3IDA0OjE5IEFNDQoNCg0KVG8NCjxnbGVuem9ybkBjb21j YXN0Lm5ldD4NCmNjDQo8ZGltZUBpZXRmLm9yZz4sIDxnc2hhZnJhbkB0cmFmZml4c3lzdGVtcy5j b20+LCBQcmVldGkgU2hhbmRpbHlhL0hTU0BIU1MsIA0KPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4N ClN1YmplY3QNClJFOiBbRGltZV0gUmV2aWV3IG9mIGRyYWZ0LXRzb3UtZGltZS1iYXNlLXJvdXRp bmctZXh0LTAzLnR4dA0KDQoNCg0KDQoNCg0KDQpHbGVuLA0KDQo+ID4gSSBhbSBub3Qgc3VyZSB3 aHkgdGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3Igc3Vic2VxdWVudCBzZXNzaW9uIA0KPiA+IG9y aWVudGVkIG1lc3NhZ2UgdG8gdHJhdmVyc2UgdGhlIHNhbWUgaW50ZXJtZWRpYXJ5IGhvcHMgd2hp Y2ggdGhlIA0KPiA+IGluaXRpYWwgbWVzc2FnZSBoYXMgdHJhdmVyc2VkLg0KPiANCj4gV2hhdCBp ZiBzb21lIG9mIHRoZSBpbnRlcm1lZGlhdGVzIGFyZSBzdGF0ZWZ1bCBhbmQgZS5nLg0KPiBjb2xs ZWN0IGNoYXJnaW5nIGRhdGEgYnkgdHJhY2tpbmcgdGhlIHVzZXIgc2Vzc2lvbj8NCj4gDQo+IFtn d3pdDQo+IEkgbXVzdCBhZG1pdCB0aGF0IEkgY2Fubm90IHRoaW5rIG9mIGEgc2luZ2xlIChyZWFs LWxpZmUpIA0KPiBzY2VuYXJpbyB3aGVyZSB0aGlzIGtpbmQgb2YgdGhpbmcgd291bGQgYmUgZGVz aXJhYmxlIChsZXQgDQo+IGFsb25lIHJlcXVpcmVkKS4gIFdvdWxkIHlvdSBtaW5kIGRlc2NyaWJp bmcgb25lIGluIGRldGFpbD8NCj4gWy9nd3pdDQoNClJlZmVyZW5jZXMgdG8gbGl0ZXJhdHVyZSB3 ZXJlIGdpdmVuIGVhcmxpZXIgaW4gdGhpcyB0aHJlYWQgOykNCg0KQW55d2F5LCBhc3N1bWUgdHdv IHByb3ZpZGVycyBjb25uZWN0ZWQgdmlhICJyb2FtaW5nIGluZnJhc3RydWN0dXJlDQpjbG91ZCIg dGhhdCBjYW5ub3QgZ3VhcmFudGVlIHNhbWUgQUFBIHJvdXRlcyBkZXRlcm1pbmlzdGljYWxseS4g VGhlDQp2aXNpdGVkIHByb3ZpZGVyIGhhcyBvdXRzb3VyY2VkIGl0cyBBQUEgYmFzZWQgcm9hbWlu ZyBjaGFyZ2luZyB0bw0KdGhpcmQgcGFydHkgcHJveGllcyB3aXRoaW4gdGhlICJjbG91ZCIgKGVh Y2ggcHJvdmlkZXIgbWF5IGhhdmUgdGhlaXINCm93biAidGhpcmQgcGFydHkiKS4gDQoNCi9Kb3Vu aQ0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoq KioqKioqKioqKioqKioqKioqKioqDQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3By aWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg CnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBw cml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAK Y2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0 IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBz dHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNj bG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyBy ZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1h Z2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 0018B0A3652573AF_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEpvdW5pICE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIG15IG9waW5pb24sIGlm IGl0IGlzIHJlcXVpcmVkIHRoYXQNCmFsbCB0aGUgbWVzc2FnZXMgdG8gZm9sbG93IHRoZSBzYW1l IHByb3h5IG5vZGUoc28gdGhhdCBwcm94eSBjYW4gYXBwbHkNCmNoYXJnaW5nKSAsIHRoaXMgc2hh bGwgYmUgc3BlY2lmaWMgbm9kZSdzIHJvdXRpbmcgcG9saWN5LiBpLmUgU291cmNlLCAmbmJzcDt3 aGlsZQ0Kc2VsZWN0aW5nIGEgcm91dGUsIGl0IHNob3VsZCBhbHdheXMgZW5kIHVwIHNlbGVjdGlu ZyB0aGUgcHJveHkgbm9kZSBmb3INCnNlbmRpbmcgdGhlIG1lc3NhZ2UuIEkgZG9uJ3QgdGhpbmsg dGhlcmUgaXMgYW55IG5lZWQgb2Ygc3RhbmRhcmRpemF0aW9uDQpvZiByb3V0aW5nIHBvbGljeSBm b3IgdGhpcyBzcGVjaWZpYyBwdXJwb3NlLiBXaGlsZSBzZWxlY3RpbmcgdGhlIHJvdXRlLA0Kbm9k ZXMgY2FuIGxvb2sgaW50byB0aGUgdHlwZSBvZiBzZXJ2aWNlIGFsc28gaW5zaWRlIHRoZSBtZXNz YWdlIHdoaWNoIGlzDQp0byBiZSByb3V0ZWQgZnVydGhlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnByZWV0aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mbHQ7am91bmkua29yaG9uZW5AdGVsaWFzb25lcmEu Y29tJmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4x Mi8xMi8yMDA3IDA0OjE5IEFNPC9mb250Pg0KPGJyPg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+VG88L2ZvbnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2dsZW56b3JuQGNvbWNhc3QubmV0Jmd0OzwvZm9udD4N Cjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZsdDtkaW1lQGlldGYub3JnJmd0OywgJmx0O2dzaGFmcmFuQHRyYWZmaXhzeXN0 ZW1zLmNvbSZndDssDQpQcmVldGkgU2hhbmRpbHlhL0hTU0BIU1MsICZsdDt0YXN2ZXJlbkBzb251 c25ldC5jb20mZ3Q7PC9mb250Pg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZCB2YWxpZ249 dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW0RpbWVdIFJldmlldyBvZiBk cmFmdC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0wMy50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkdsZW4sPGJyPg0K PGJyPg0KJmd0OyAmZ3Q7IEkgYW0gbm90IHN1cmUgd2h5IHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQg Zm9yIHN1YnNlcXVlbnQgc2Vzc2lvbg0KPGJyPg0KJmd0OyAmZ3Q7IG9yaWVudGVkIG1lc3NhZ2Ug dG8gdHJhdmVyc2UgdGhlIHNhbWUgaW50ZXJtZWRpYXJ5IGhvcHMgd2hpY2gNCnRoZSA8YnI+DQom Z3Q7ICZndDsgaW5pdGlhbCBtZXNzYWdlIGhhcyB0cmF2ZXJzZWQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFdoYXQgaWYgc29tZSBvZiB0aGUgaW50ZXJtZWRpYXRlcyBhcmUgc3RhdGVmdWwgYW5kIGUu Zy48YnI+DQomZ3Q7IGNvbGxlY3QgY2hhcmdpbmcgZGF0YSBieSB0cmFja2luZyB0aGUgdXNlciBz ZXNzaW9uPzxicj4NCiZndDsgPGJyPg0KJmd0OyBbZ3d6XTxicj4NCiZndDsgSSBtdXN0IGFkbWl0 IHRoYXQgSSBjYW5ub3QgdGhpbmsgb2YgYSBzaW5nbGUgKHJlYWwtbGlmZSkgPGJyPg0KJmd0OyBz Y2VuYXJpbyB3aGVyZSB0aGlzIGtpbmQgb2YgdGhpbmcgd291bGQgYmUgZGVzaXJhYmxlIChsZXQg PGJyPg0KJmd0OyBhbG9uZSByZXF1aXJlZCkuICZuYnNwO1dvdWxkIHlvdSBtaW5kIGRlc2NyaWJp bmcgb25lIGluIGRldGFpbD88YnI+DQomZ3Q7IFsvZ3d6XTxicj4NCjxicj4NClJlZmVyZW5jZXMg dG8gbGl0ZXJhdHVyZSB3ZXJlIGdpdmVuIGVhcmxpZXIgaW4gdGhpcyB0aHJlYWQgOyk8YnI+DQo8 YnI+DQpBbnl3YXksIGFzc3VtZSB0d28gcHJvdmlkZXJzIGNvbm5lY3RlZCB2aWEgJnF1b3Q7cm9h bWluZyBpbmZyYXN0cnVjdHVyZTxicj4NCmNsb3VkJnF1b3Q7IHRoYXQgY2Fubm90IGd1YXJhbnRl ZSBzYW1lIEFBQSByb3V0ZXMgZGV0ZXJtaW5pc3RpY2FsbHkuIFRoZTxicj4NCnZpc2l0ZWQgcHJv dmlkZXIgaGFzIG91dHNvdXJjZWQgaXRzIEFBQSBiYXNlZCByb2FtaW5nIGNoYXJnaW5nIHRvPGJy Pg0KdGhpcmQgcGFydHkgcHJveGllcyB3aXRoaW4gdGhlICZxdW90O2Nsb3VkJnF1b3Q7IChlYWNo IHByb3ZpZGVyIG1heSBoYXZlDQp0aGVpcjxicj4NCm93biAmcXVvdDt0aGlyZCBwYXJ0eSZxdW90 OykuIDxicj4NCjxicj4NCi9Kb3VuaTxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAm bmJzcDtBcmljZW50LVJlc3RyaWN0ZWQgJm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9m b250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+ PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQg IGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRv IHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2Vk IGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVk IGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50 cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3Ig Cmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0 cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwv cHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0018B0A3652573AF_=-- --===============1573900520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1573900520==-- From dime-bounces@ietf.org Thu Dec 13 01:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hUl-0002zc-Oh; Thu, 13 Dec 2007 01:24:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hUk-0002zU-23 for dime@ietf.org; Thu, 13 Dec 2007 01:24:30 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2hUj-0001Ep-E7 for dime@ietf.org; Thu, 13 Dec 2007 01:24:29 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00HJC5R874@szxga02-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:23:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00FZB5R8O4@szxga02-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:23:32 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ008XT5R81M@szxml04-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:23:32 +0800 (CST) Date: Thu, 13 Dec 2007 14:23:31 +0800 From: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt To: dime@ietf.org Message-id: <012401c83d50$aede9580$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0922019991==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0922019991== Content-type: multipart/alternative; boundary="Boundary_(ID_gV+iKFPbOVjhN+BGVCkY2w)" This is a multi-part message in MIME format. --Boundary_(ID_gV+iKFPbOVjhN+BGVCkY2w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear all, I would like to re-emphasize Tolga's earlier comment on this (which in my opinion so rightly describes the problem & solution): 1. It is not the originator's, but the visited n/ws business case that its proxy should be in-path for all the messages of the session. So, originator may/need not decide this route, the proxy must have a mechanism to stay in the path. 2. As long as all next hops in the visited n/w are session stateful, the proxy in the visited n/w has no problem to stay in path. The problem comes when there are some session agnostic/stateless agents (read as relays) in between. 3. The explicit routing does not supercede fail over considerations. It will select the same next hop as long as it is available only. B. R. Tina --Boundary_(ID_gV+iKFPbOVjhN+BGVCkY2w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Dear all,
I would like to re-emphasize Tolga's earlier comment on this (which in my opinion so rightly describes the problem & solution):
1. It is not the originator's, but the visited n/ws business case that its proxy should be in-path for all the messages of the session. So, originator may/need not decide this route, the proxy must have a mechanism to stay in the path.
2. As long as all next hops in the visited n/w are session stateful, the proxy in the visited n/w has no problem to stay in path. The problem comes when there are some session agnostic/stateless agents (read as relays) in between.
3. The explicit routing does not supercede fail over considerations. It will select the same next hop as long as it is available only.
 
B. R.
Tina
 
 
--Boundary_(ID_gV+iKFPbOVjhN+BGVCkY2w)-- --===============0922019991== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0922019991==-- From dime-bounces@ietf.org Thu Dec 13 01:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hiR-000690-9f; Thu, 13 Dec 2007 01:38:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hiQ-0005zy-8Z for dime@ietf.org; Thu, 13 Dec 2007 01:38:38 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2hiM-0001WF-Ux for dime@ietf.org; Thu, 13 Dec 2007 01:38:38 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ002CN6F0J6@szxga04-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:48 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ00FW86EZ4L@szxga04-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:48 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00CGV6EZH4@szxml03-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:37:47 +0800 (CST) Date: Thu, 13 Dec 2007 14:37:47 +0800 From: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt To: Preeti Shandilya , jouni.korhonen@teliasonera.com Message-id: <013301c83d52$ace0ded0$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657849467==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1657849467== Content-type: multipart/alternative; boundary="Boundary_(ID_3qwURGSP9epg/tgHzptXcw)" This is a multi-part message in MIME format. --Boundary_(ID_3qwURGSP9epg/tgHzptXcw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear Preeti, My comments are below demarked with [Tina: ...]. B. R. Tina ----- Original Message ----- From: Preeti Shandilya To: jouni.korhonen@teliasonera.com Cc: dime@ietf.org ; gshafran@traffixsystems.com Sent: Wednesday, December 12, 2007 12:29 PM Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Hi Jouni ! In my opinion, if it is required that all the messages to follow the same proxy node(so that proxy can apply charging) , this shall be specific node's routing policy. i.e Source, while selecting a route, it should always end up selecting the proxy node for sending the message. I don't think there is any need of standardization of routing policy for this specific purpose. While selecting the route, nodes can look into the type of service also inside the message which is to be routed further. [Tina: Stateful proxy agent routing is a common problem. Basing on service type doesn't' work, as maybe many nodes will process same service. This is the issue this I-D will resolve, how to select among multiple service nodes.] regards preeti 12/12/2007 04:19 AM To cc , , Preeti Shandilya/HSS@HSS, Subject RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Glen, > > I am not sure why there is a requirement for subsequent session > > oriented message to traverse the same intermediary hops which the > > initial message has traversed. > > What if some of the intermediates are stateful and e.g. > collect charging data by tracking the user session? > > [gwz] > I must admit that I cannot think of a single (real-life) > scenario where this kind of thing would be desirable (let > alone required). Would you mind describing one in detail? > [/gwz] References to literature were given earlier in this thread ;) Anyway, assume two providers connected via "roaming infrastructure cloud" that cannot guarantee same AAA routes deterministically. The visited provider has outsourced its AAA based roaming charging to third party proxies within the "cloud" (each provider may have their own "third party"). /Jouni *********************** Aricent-Restricted *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_3qwURGSP9epg/tgHzptXcw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear = Preeti,
My comments are below = demarked with=20 [Tina: ...].
 
B. = R.
Tina
----- Original Message -----
From:=20 Preeti Shandilya =
To: jouni.korhonen@teliasonera= .com=20
Cc: dime@ietf.org ; gshafran@traffixsystems.com=20
Sent: Wednesday, December 12, = 2007 12:29=20 PM
Subject: RE: [Dime] Review of=20 draft-tsou-dime-base-routing-ext-03.txt


Hi Jouni ! =

In my opinion, if it is required that all = the messages=20 to follow the same proxy node(so that proxy can apply charging) , this = shall=20 be specific node's routing policy. i.e Source,  while selecting a = route,=20 it should always end up selecting the proxy node for sending the = message. I=20 don't think there is any need of standardization of routing policy for = this=20 specific purpose. While selecting the route, nodes can look into the = type of=20 service also inside the message which is to be routed further.=20
[Tina: Stateful proxy = agent routing=20 is a common problem. Basing on service type doesn=92t=92 work, as = maybe many nodes=20 will process same service. This is the issue this I-D will resolve, = how to=20 select among multiple service nodes.]

regards
preeti=20


<jouni.korhonen@teliasonera.com>

12/12/2007 04:19 AM =

To
<glenzorn@comcast.net>=20
cc
<dime@ietf.org>,=20 <gshafran@traffixsystems.com>, Preeti = Shandilya/HSS@HSS,=20 <tasveren@sonusnet.com>=20
Subject
RE: [Dime] = Review of=20 = draft-tsou-dime-base-routing-ext-03.txt

=





Glen,

> > I am not sure why there is a = requirement=20 for subsequent session
> > oriented message to traverse the = same=20 intermediary hops which the
> > initial message has=20 traversed.
>
> What if some of the intermediates are = stateful and=20 e.g.
> collect charging data by tracking the user = session?
>=20
> [gwz]
> I must admit that I cannot think of a single=20 (real-life)
> scenario where this kind of thing would be = desirable (let=20
> alone required).  Would you mind describing one in=20 detail?
> [/gwz]

References to literature were given = earlier in=20 this thread ;)

Anyway, assume two providers connected via = "roaming=20 infrastructure
cloud" that cannot guarantee same AAA routes=20 deterministically. The
visited provider has outsourced its AAA = based=20 roaming charging to
third party proxies within the "cloud" (each = provider=20 may have their
own "third party"). =

/Jouni



***********************=20  Aricent-Restricted   ***********************=20 
"DISCLAIMER: This =
message is proprietary to Aricent  and is intended solely for the use of =

the individual to whom it is addressed. It may contain privileged or =
confidential information and should not be=20
circulated or used for any purpose other than for what it is intended. =
If you have received this message in error,=20
please notify the originator immediately. If you are not the intended =
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of =
this message. Aricent accepts no responsibility for=20
loss or damage arising from the use of the information transmitted by =
this email including damage from virus."

_______________________________________________
DiME mailing = = list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
<= /BLOCKQUOTE> --Boundary_(ID_3qwURGSP9epg/tgHzptXcw)-- --===============1657849467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1657849467==-- From dime-bounces@ietf.org Thu Dec 13 01:46:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hqO-00075b-QJ; Thu, 13 Dec 2007 01:46:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hqO-00075W-Dj for dime@ietf.org; Thu, 13 Dec 2007 01:46:52 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2hqN-0001lD-83 for dime@ietf.org; Thu, 13 Dec 2007 01:46:52 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ008JT6QVS3@szxga01-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:44:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSZ009AN6QU1F@szxga01-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:44:55 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSZ00CUM6QUH4@szxml03-in.huawei.com> for dime@ietf.org; Thu, 13 Dec 2007 14:44:54 +0800 (CST) Date: Thu, 13 Dec 2007 14:44:54 +0800 From: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt To: Glen Zorn , jouni.korhonen@teliasonera.com, preeti.shandilya@aricent.com, tasveren@sonusnet.com Message-id: <015401c83d53$ab40cdf0$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <033458F56EC2A64E8D2D7B759FA3E7E7509625@sonusmail04.sonusnet.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9CB8@SEHAN021MB.tcad.telia.se> <00a701c83bcb$8f25acf0$ad7106d0$@net> <018a01c83bd4$9437a780$544c460a@china.huawei.com> <007b01c83c22$ab1f50d0$015df270$@net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: dime@ietf.org, gshafran@traffixsystems.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1443537643==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1443537643== Content-type: multipart/alternative; boundary="Boundary_(ID_h1Npdevd7Te/pUWldp/hvg)" This is a multi-part message in MIME format. --Boundary_(ID_h1Npdevd7Te/pUWldp/hvg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear Glen, My comments are below demarked with [Tina: ...]. B. R. Tina ----- Original Message ----- From: Glen Zorn To: 'Tina TSOU' ; jouni.korhonen@teliasonera.com ; preeti.shandilya@aricent.com ; tasveren@sonusnet.com Cc: dime@ietf.org ; gshafran@traffixsystems.com Sent: Wednesday, December 12, 2007 2:21 AM Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt Dear Glen and all, I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me. Use case #1: There are several visiting network, and one home network. Type 1# service should go via intermediate node #a in visiting network A#. Type 2# service should go via intermediate node #b in visiting network B#. ...... This use case can be for both mobile and fix network operator. [gwz] So what happens if node #a is down? Is Type 1# service disabled/unavailable? If not, what's the point of the routing, given that it is unnecessary; if so, doesn't that sort of defeat the purpose of fail-over? [/gwz] [Tina: Ongoing session will disable/unavailable. But the service can use another stateful proxy agent. It is like one server fails. If one server fails, ongoing session will fail, but another server maybe can take over new session process.] Use case #2: The charging data should be sent from that node. [gwz] Does this mean that the data path must also pass through that node? [/gwz] [Tina: It is unnecessary, the node maybe just do charging base on session time.] This use case can be for mobile operator. B. R. Tina --Boundary_(ID_h1Npdevd7Te/pUWldp/hvg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Dear Glen,
My comments are below demarked with [Tina: ...].
 
B. R.
Tina
----- Original Message -----
From: Glen Zorn
Sent: Wednesday, December 12, 2007 2:21 AM
Subject: RE: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

Dear Glen and all,

I know Jouni has two use cases. Jouni, Steve and I talked about them in Vancouver. I am trying to describe as below. If it is not precise, Jouni, please correct me.

 

Use case #1:

There are several visiting network, and one home network.

Type 1# service should go via intermediate node #a in visiting network A#.

Type 2# service should go via intermediate node #b in visiting network B#.

......

This use case can be for both mobile and fix network operator.

[gwz]

So what happens if node #a is down?  Is Type 1# service disabled/unavailable?  If not, what's the point of the routing, given that it is unnecessary; if so, doesn't that sort of defeat the purpose of fail-over?

[/gwz]

[Tina: Ongoing session will disable/unavailable. But the service can use another stateful proxy agent. It is like one server fails. If one server fails, ongoing session will fail, but another server maybe can take over new session process.] 

 

Use case #2:

The charging data should be sent from that node.

[gwz]

Does this mean that the data path must also pass through that node?

[/gwz]

[Tina: It is unnecessary, the node maybe just do charging base on session time.] 

 

This use case can be for mobile operator.

 

B. R.
Tina

--Boundary_(ID_h1Npdevd7Te/pUWldp/hvg)-- --===============1443537643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1443537643==-- From dime-bounces@ietf.org Sun Dec 16 10:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vIl-0007Jj-En; Sun, 16 Dec 2007 10:21:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3vIk-0007JX-1E for dime@ietf.org; Sun, 16 Dec 2007 10:21:10 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J3vIj-0004Mt-GP for dime@ietf.org; Sun, 16 Dec 2007 10:21:09 -0500 Received: (qmail invoked by alias); 16 Dec 2007 15:21:07 -0000 Received: from p54985EA8.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.94.168] by mail.gmx.net (mp039) with SMTP; 16 Dec 2007 16:21:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+z5Js+3suzaGBJQzAZGQp425iEYKGXyDkVLbOO/h YqsmVkjG4D6J7X Message-ID: <4765426E.6000408@gmx.net> Date: Sun, 16 Dec 2007 16:21:18 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: marcelo bagnulo braun References: <2B84BB5E-4194-4CB6-884A-8006F5A95533@it.uc3m.es> In-Reply-To: <2B84BB5E-4194-4CB6-884A-8006F5A95533@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dime@ietf.org, mext@ietf.org Subject: [Dime] Re: [MEXT] draft-ietf-mip6-aaa-ha-goals next steps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Marcelo, I would appreciate faster processing given that the corresponding DIME working group documents already went through their WGLCs. Hence, I would suggest to * "motivate" the draft authors to submit a new draft version immediately, as promised * start a WGLC asap * submit the document in Jan. 2008 to the IESG This is not a complicate document with 5 draft authors. The last draft version was published 2006-09-12 despite repeated announcements that a new draft version is imminent. I cannot believe that none of the authors had time to made the minor editorial changes in more than a year!!! I am not amused. Ciao Hannes PS: I put Dan, the responsible AD for DIME, on CC to let him know that the processing of our DIME mobility documents might experience delays during IESG processing due to this requirements draft. marcelo bagnulo braun wrote: > Hi, > > according to what we agreed in the MEXT meeting in Vancouver, a new > version of draft-ietf-mip6-aaa-ha-goals should be submitted right > after Vancouver and we will issue a WGLC for this document once this > is done > > We are suppose to submit this document to the IESG for Feb 2008 > > When do you think we will be able to issue the WGLC? > > Thanks, marcelo > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www1.ietf.org/mailman/listinfo/mext _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Dec 16 16:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41F5-0000nH-Ng; Sun, 16 Dec 2007 16:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J41F3-0000iY-Ol for dime@ietf.org; Sun, 16 Dec 2007 16:41:45 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J41F3-0002vG-DI for dime@ietf.org; Sun, 16 Dec 2007 16:41:45 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBGLf8rL016098; Sun, 16 Dec 2007 16:41:09 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47659B74.6040407@tari.toshiba.com> Date: Sun, 16 Dec 2007 16:41:08 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jouni Korhonen , Mark Jones , MORAND Lionel RD-CORE-ISS , Glen Zorn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: dime@ietf.org Subject: [Dime] RFC3588bis Document Review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark/Lionel/Jouni/Glen, This is a reminder that the WGLC for 3588bis will finish in the next few days so as designated reviewers of this document, your timely comments is greatly appreciated. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 17 05:11:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Cwp-0004zY-Gp; Mon, 17 Dec 2007 05:11:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Cwo-0004zP-Qm; Mon, 17 Dec 2007 05:11:42 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Cwo-0001ZS-2y; Mon, 17 Dec 2007 05:11:42 -0500 X-IronPort-AV: E=Sophos;i="4.24,175,1196658000"; d="url'?txt'208?scan'208,208";a="80399877" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Dec 2007 05:11:38 -0500 X-IronPort-AV: E=Sophos;i="4.24,175,1196658000"; d="url'?txt'208?scan'208,208";a="134500984" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Dec 2007 05:10:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C84095.1D487FF5" Date: Mon, 17 Dec 2007 11:10:55 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-brenner-dime-peem-00.txt Thread-Index: Acg/KLoMBL2eH5OKQjiIuzbepX0kKABa/ayg From: "Romascanu, Dan (Dan)" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: "Brenner, Michael Ralf \(Michael\)" Subject: [Dime] FW: I-D Action:draft-brenner-dime-peem-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C84095.1D487FF5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The following Internet-Draft was submitted and its editor requested to be published as an Area Director-sponsored Informational RFC.=20 Please provide your comments until December 24, 2007.=20 Thanks and Regards, Dan =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Saturday, December 15, 2007 4:40 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-brenner-dime-peem-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Policy Processing Application Author(s) : M. Brenner Filename : draft-brenner-dime-peem-00.txt Pages : 6 Date : 2007-12-15 This document describes the Diameter protocol application used for invocation of Policy Processing (Policy Evaluation, or Evaluation and Enforcement). This application is needed as one of the implementations of the Open Mobile Aliance (OMA) Policy Evaluation, Enforcement and Management (PEEM) enabler, namely for the PEM-1 interface used to send a request/responses for Policy Processing. When combined with the Diameter Base protocol, this application specification satisfies the OMA PEEM requirements for sending a request for policy processing and receiving a response with the policy processing result. The Diameter realization of this application assumes the use of Diameter Base protocol, as per RFC 3588, and extends it only for the with an application using a vendor-id, a vendor-specific application ID, a new Command Code, and a new AVP defined in the vendor-specific namespace. Input to policy processing are being passed through a new AVP, and policy results are being passed through a combination of the same new AVP, and the Experimental-Result AVP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brenner-dime-peem-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-brenner-dime-peem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-brenner-dime-peem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C84095.1D487FF5 Content-Type: application/octet-stream; name="ATT869681.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT869681.TXT Content-Disposition: attachment; filename="ATT869681.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0xMi0xNTA5Mzc1NS5JLURAaWV0Zi5vcmc+DQoNCkVO Q09ESU5HIG1pbWUNCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1icmVubmVyLWRpbWUtcGVl bS0wMC50eHQNCg== ------_=_NextPart_001_01C84095.1D487FF5 Content-Type: application/octet-stream; name="draft-brenner-dime-peem-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-brenner-dime-peem-00.URL Content-Disposition: attachment; filename="draft-brenner-dime-peem-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1icmVubmVyLWRpbWUtcGVlbS0wMC50eHQNCg== ------_=_NextPart_001_01C84095.1D487FF5 Content-Type: text/plain; name="ATT869682.txt" Content-Transfer-Encoding: base64 Content-Description: ATT869682.txt Content-Disposition: attachment; filename="ATT869682.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C84095.1D487FF5 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C84095.1D487FF5-- From dime-bounces@ietf.org Mon Dec 17 09:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4H9t-0002z2-Uu; Mon, 17 Dec 2007 09:41:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4H9t-0002yr-0d for dime@ietf.org; Mon, 17 Dec 2007 09:41:29 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4H9q-0004XG-F0 for dime@ietf.org; Mon, 17 Dec 2007 09:41:28 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBHEf3Eh018957 for ; Mon, 17 Dec 2007 09:41:03 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47668A75.2090307@tari.toshiba.com> Date: Mon, 17 Dec 2007 09:40:53 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------070104060103070904060002" X-Spam-Score: -1.4 (-) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Subject: [Dime] [Fwd: draft-ietf-dime-rfc3588bis-09.txt comments] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --------------070104060103070904060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------070104060103070904060002 Content-Type: message/rfc822; name="draft-ietf-dime-rfc3588bis-09.txt comments" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-dime-rfc3588bis-09.txt comments" X-Account-Key: account5 Return-Path: Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.240.51]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBEAi9lk006055 for ; Fri, 14 Dec 2007 05:44:09 -0500 (EST) (envelope-from german.blanco@ericsson.com) X-VirusChecked: Checked X-Env-Sender: german.blanco@ericsson.com X-Msg-Ref: server-5.tower-63.messagelabs.com!1197629041!21654066!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [193.180.251.62] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE Received: (qmail 30595 invoked from network); 14 Dec 2007 10:44:02 -0000 Received: from mailgw4.ericsson.se (HELO mailgw4.ericsson.se) (193.180.251.62) by server-5.tower-63.messagelabs.com with AES256-SHA encrypted SMTP; 14 Dec 2007 10:44:02 -0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 27C2521CEC for ; Fri, 14 Dec 2007 11:41:49 +0100 (CET) X-AuditID: c1b4fb3e-aee9fbb00000459d-37-47625dedc7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 06DBF20104 for ; Fri, 14 Dec 2007 11:41:49 +0100 (CET) Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 11:41:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83E3D.DD458F38" Subject: draft-ietf-dime-rfc3588bis-09.txt comments Date: Fri, 14 Dec 2007 11:41:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-rfc3588bis-09.txt comments Thread-Index: Acg+Pdz7YMU4kvNuRp+EdFh/9oaPJQ== From: "German Blanco" To: "Victor Fajardo" X-OriginalArrivalTime: 14 Dec 2007 10:41:48.0867 (UTC) FILETIME=[EE1A0930:01C83E3D] X-Brightmail-Tracker: AAAAAA== This is a multi-part message in MIME format. ------_=_NextPart_001_01C83E3D.DD458F38 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Victor, congratulations for this good work :-) After reading the draft, I found a few things that seem to be mistakes: - There is a hanging sentece in section 9.3. in the second paragraph of "Split Accounting Service": "Accounting messages which uses the Diameter base accounting application identifier in its header as well as in the Acct- Application-Id AVP." At least for me it looks out of context. - I can't understand the text in parenthesis in the end of 2.1."The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised).". Does it mean that there is a risk not to have a graceful closure? - The text in the last sentence of 6.9. is a bit strange : "If present in a message other than CER and CEA, the value of the Acct-Application-Id AVP MUST match the application id present in the diameter message header except when used in a CER or CEA messages. " If it is present in a message other than CER and CEA, then we don't need to state again "except when used in a CER or CEA messages", or? Editorial: - The "AVP" is missing in title of 9.8.2 - in the end of 6.1.8. there is a "used againts" instead of a "used against" I also have a question about the addition of commands to applications: Was it ever consider, now that extendibility of applications by adding commands is enabled, to enable the use of *optional* commands? That is, wouldn't it be possible to add a command to an application that is not strictly required for the application to work, and to add that command without changing the application id? I understand that this question should in any case to to the WG list, but I would like to please have your opinion beforehand if you don't mind. Best regards, German Blanco Ericsson mailto: german.blanco@ericsson.com phone: + 34 630 739143 ------_=_NextPart_001_01C83E3D.DD458F38 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-dime-rfc3588bis-09.txt comments

Hello Victor,

congratulations for this good work = :-)

After reading the draft, I found a few = things that seem to be mistakes:

- There is a hanging sentece in section = 9.3. in the second paragraph of "Split Accounting = Service":
"Accounting messages which uses = the Diameter base accounting
      = application identifier in its header as well as in the Acct-
      = Application-Id AVP."
  At least for me it looks out of = context.

- I can't understand the text in = parenthesis in the end of 2.1."The transport connection MUST be closed using a RESET call (send = a TCP RST bit) or an SCTP ABORT message (graceful closure is = compromised).". Does it mean = that there is a risk not to have a graceful closure?

- The text in the last sentence of 6.9. = is a bit strange : "If = present in a message other than CER and CEA, the value of the = Acct-Application-Id AVP MUST match the application id present in the = diameter message header except when used in a CER or CEA = messages. " If it is present = in a message other than CER and CEA, then we don't need to state again = "except when used in a CER or = CEA messages", or?

Editorial:
- The "AVP" is missing in = title of 9.8.2

- in the end of 6.1.8. there is a = "used againts" instead of a "used against"

I also have a question about the = addition of commands to applications: Was it ever consider, now that = extendibility of applications by adding commands is enabled, to enable = the use of *optional* commands?

That is, wouldn't it be possible to add = a command to an application that is not strictly required for the = application to work, and to add that command without changing the = application id?

I understand that this question should = in any case to to the WG list, but I would like to please have your = opinion beforehand if you don't mind.

Best regards,

German Blanco
Ericsson
mailto: = german.blanco@ericsson.com
phone: + 34 630 739143

------_=_NextPart_001_01C83E3D.DD458F38-- --------------070104060103070904060002 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --------------070104060103070904060002-- From dime-bounces@ietf.org Mon Dec 17 17:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Oau-00089V-WB; Mon, 17 Dec 2007 17:37:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Oat-00083n-An for dime@ietf.org; Mon, 17 Dec 2007 17:37:51 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4Oas-0003U0-UC for dime@ietf.org; Mon, 17 Dec 2007 17:37:51 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBHMWK8F021285; Mon, 17 Dec 2007 17:32:20 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4766F8F0.2040809@tari.toshiba.com> Date: Mon, 17 Dec 2007 17:32:16 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "German Blanco (E2/EEM)" Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis-09.txt comments] References: <47668A75.2090307@tari.toshiba.com> In-Reply-To: <47668A75.2090307@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi German, > After reading the draft, I found a few things that seem to be mistakes: > > - There is a hanging sentece in section 9.3. in the second paragraph > of "Split Accounting Service": > "Accounting messages which uses the Diameter base accounting > application identifier in its header as well as in the Acct- > Application-Id AVP." > At least for me it looks out of context. > Ok. We can make a quick editorial fix. > - I can't understand the text in parenthesis in the end of 2.1."The > transport connection MUST be closed using a RESET call (send a TCP RST > bit) or an SCTP ABORT message (graceful closure is compromised).". > Does it mean that there is a risk not to have a graceful closure? > Yes. I guess the basic assumption for the last sentence is that the connection has already been compromised because the peer received garbled messages. A reset is used by a node so it can be a means to notify the peer that something has gone wrong. > - The text in the last sentence of 6.9. is a bit strange : "If present > in a message other than CER and CEA, the value of the > Acct-Application-Id AVP MUST match the application id present in the > diameter message header except when used in a CER or CEA messages. " > If it is present in a message other than CER and CEA, then we don't > need to state again "except when used in a CER or CEA messages", or? > Sure. We can fix this as well. > Editorial: > - The "AVP" is missing in title of 9.8.2 > > - in the end of 6.1.8. there is a "used againts" instead of a "used > against" > Ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 18 06:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4aUU-0007Ki-48; Tue, 18 Dec 2007 06:20:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4aUS-0007KC-83 for dime@ietf.org; Tue, 18 Dec 2007 06:20:00 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4aUR-0006No-Bd for dime@ietf.org; Tue, 18 Dec 2007 06:19:59 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Dec 2007 12:19:57 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Dec 2007 12:19:56 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9E3E@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of Diameter App Guidelines Thread-Index: AchBZ+ttk8YmZnkdTxyDHl+cGI925Q== From: To: X-OriginalArrivalTime: 18 Dec 2007 11:19:57.0762 (UTC) FILETIME=[EC0AB220:01C84167] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Subject: [Dime] Review of Diameter App Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org During last IETF I volunteered to review the draft-ietf-dime-app-design-guife-05 draft. IMHO the draft is in pretty good shape, at least it appears so to me. Few editorial & substantial nits: o Application ID is written in several ways depending on the section it appears at. Use consistent style. o section 1. intro "various attempts to extend Diameter applications where designers have no clear answer on whether to even define a new application or not." s/even/ o section 3. brief overview.. "As it is currently interpreted and practiced, the Diameter Base protocol is a two-layer protocol. The lower layer is mainly" s/interpreted/specified o section 3. brief overview.. "applications reside. This model is in line with a Diameter node having an application layer and a peer-to-peer delivery layer. The" s/peer-to-peer delivery/peer-to-peer message delivery o section 4. rules extending.. "Extending Diameter can mean the reuse of commands, AVPs and AVP values in any combination for the purpose of inheriting the features of an existing Diameter applications. This section discusses the rules on how such reuse can be done." In section 1 item 3 we also listed creating a new application. This should be added to above text. o section 4. rules extending.. "1. Minimal - which typically means adding optional AVPs to existing commands." I would add here "Does not necessarily require a new application." just for the clarity. 2. Invasive - where addition or deletion of commands and/or AVPs, and/or AVP values (in the case where the AVP is of type Enumerated). I would add here "Always requires a new application." just for the clarity. o section 4.1.1 adding a new.. "In general, it is difficult to come to a hard and fast guideline, and so a case by case study of each application requirement should be" =20 s/to a hard and fast/up with a general purpose, yet short and solid"=20 o section 4.1.1 adding a new.. "initial proposal for Diameter MIPv6 split scenario (see [2]) where authorization and authentication is separated." Actually the current split is not entirely clear on auth & authz=20 separation. It is advocated in the intro but in the body of the text auth/authz is combined for RFC4877 & RFC5026 bootstrapping. From Diameter perspective that is.. o section 4.2 reusing existing.. "This section deals with a little more granularity than Section 4.1." Deals with what? Rephrase. o section 4.2.1 adding AVPs.. "o Do the AVPs change the state machine of the application ? o Would the presence of the AVPs cause additional message round- trips; effectively changing the state machine of the application ?" The above two bullets could be combined to a one. o section 4.2.1 adding AVPs.. "o An optional AVPs with dual purpose; i.e.; to carry applications data as well as to indicate support for one or more features. This has a tendency to introduce interpretation issues." This is what the dime-mip6-integrated actually does. You should give a reference to it as a bad design example ;) It could be emphasized here that if the "dual purpose" can be made entirely backwards compatible, it is ok.. like in mip6-integrated case o section 5.5 end-to-end.. "applications itself. Examples of this can be found in [2] and [3]." Add a reference to dime-mip6-integrated here. o section 6.4 system arch.. "o For general AAA applications, Diameter requires more message exchanges for the same set of services compared to RADIUS." Is it really so after the CER/CEA exchange? o section 6.4 system arch.. "o Application design should be agnostic to any Diameter topology. Application designers should not always assume a particular Diameter topology; i.e., assume that there will always be application proxies in the path or assume that only intra-domain routing is applicable." I would like to see some more text in general about impacts of AVPs that affect request routing. Especially in situations when those are attempted to be used with existing application. A good example is NAI decoration. Basically a new application is required when other AVPs than those listed in DBP for request routing affect routing decisions.. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 18 17:07:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kb9-0006io-RP; Tue, 18 Dec 2007 17:07:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4kb8-0006ib-Kb for dime@ietf.org; Tue, 18 Dec 2007 17:07:34 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4kb8-0000O6-2D for dime@ietf.org; Tue, 18 Dec 2007 17:07:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Dec 2007 17:07:33 -0500 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Dime] Review of draft-ietf-dime-rfc3588bis-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here are my comments on the 3588bis-09 draft. They are largely editorial and I found no showstoppers. --- 1.1. Diameter Protocol "Extensibility, through addition of new commands and AVPs (required in [RFC2989])." Extensibility is also achieved through addition of new applications. 1.1.1. Description of the Document Set Suggest replacing "Currently" with "At the time of publication/writing". This section contains the list of IETF applications. Should we mention that Diameter allows vendor-specific applications and refer to IANA for the list of those? This section also refers to more recent applications like Credit Control, EAP and SIP but they are not mentioned in other sections which refer only to NASREQ/MIPv4, e.g. the list of Application Identifiers in section 2.4.=20 1.2.2. Creating New AVPs "If an appropriate derived data type is already defined, it MAY be used instead of the base data type." Suggest strengthening the MAY to a SHOULD to encourage derived data type reuse. 1.2.3. Creating New Commands Typo (probably mine): defintion -> definition 1.2.4. Creating New Authentication Applications "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." An implementation can add non-mandatory AVPs only if allowed by the command ABNF, i.e. it has the "* [ AVP ]" element. 2.3. Diameter Application Compliance "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs." Same comment as above for 1.2.4.=20 2.9. Diameter Path Authorization " Diameter sessions MUST be routed only through authorized nodes that have advertised support for the Diameter application required by the session." Or advertised support for the Relay application. 3.3. Diameter Command Naming Conventions "Once the receiver has completed the request it issues the corresponding answer, which includes a result code that communicates one of the following:" Suggest "corresponding answer with the R-bit cleared,..." 6.1.8. Redirecting requests Typo in 5th paragraph: againts -> against 6.3. Origin-Host AVP Typo in 4th paragraph: remove "6.10" 6.8. Auth-Application-Id AVP Typo: diameter -> Diameter 6.9. Acct-Application-Id AVP Typo: diameter -> Diameter 7.1.3. Protocol Errors Typo: maybe -> may be 8. Diameter User Sessions Typo in 7th paragraph: statemachines -> state machines 8.8. Session-Id AVP "At startup, the high 32 bits of the 64-bit value MAY be initialized to the time" Suggest adding "in NTP timestamp format [RFC4330]" 8.13. Session-Timeout AVP Incorrect xref in 2nd paragraph: Section 8.9 -> Section 8.11 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 19 09:02:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zUw-0007cU-So; Wed, 19 Dec 2007 09:02:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zUv-0007cK-IJ for dime@ietf.org; Wed, 19 Dec 2007 09:02:09 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zUu-00068l-Ug for dime@ietf.org; Wed, 19 Dec 2007 09:02:09 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBJE1jrr031021; Wed, 19 Dec 2007 09:01:45 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47692439.7070207@tari.toshiba.com> Date: Wed, 19 Dec 2007 09:01:29 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9E3E@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9E3E@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: dime@ietf.org Subject: [Dime] Re: Review of Diameter App Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, Thanks for the review. Comments inline: > During last IETF I volunteered to review the > draft-ietf-dime-app-design-guife-05 draft. IMHO > the draft is in pretty good shape, at least it > appears so to me. > Ok. thanks. > Few editorial & substantial nits: > > o Application ID is written in several ways depending > on the section it appears at. Use consistent style. > > o section 1. intro > > "various attempts to extend Diameter applications where designers have > no clear answer on whether to even define a new application or not." > > s/even/ > > o section 3. brief overview.. > > "As it is currently interpreted and practiced, the Diameter Base > protocol is a two-layer protocol. The lower layer is mainly" > > s/interpreted/specified > > o section 3. brief overview.. > > "applications reside. This model is in line with a Diameter node > having an application layer and a peer-to-peer delivery layer. The" > > s/peer-to-peer delivery/peer-to-peer message delivery > Above editorials are ok. > o section 4. rules extending.. > > "Extending Diameter can mean the reuse of commands, AVPs and AVP > values in any combination for the purpose of inheriting the features > of an existing Diameter applications. This section discusses the > rules on how such reuse can be done." > > In section 1 item 3 we also listed creating a new application. This > should be added to above text. > Ok > o section 4. rules extending.. > > "1. Minimal - which typically means adding optional AVPs to existing > commands." > > I would add here "Does not necessarily require a new application." > just for the clarity. > > 2. Invasive - where addition or deletion of commands and/or AVPs, > and/or AVP values (in the case where the AVP is of type > Enumerated). > > I would add here "Always requires a new application." > just for the clarity. > Sure. > > o section 4.1.1 adding a new.. > > "In general, it is difficult to come to a hard and fast guideline, and > so a case by case study of each application requirement should be" > > s/to a hard and fast/up with a general purpose, yet short and solid" > > o section 4.1.1 adding a new.. > > "initial proposal for Diameter MIPv6 split scenario (see [2]) where > authorization and authentication is separated." > > Actually the current split is not entirely clear on auth & authz > separation. It is advocated in the intro but in the body of the > text auth/authz is combined for RFC4877 & RFC5026 bootstrapping. > From Diameter perspective that is.. > I see. Ok I'll fix the text. > o section 4.2 reusing existing.. > > "This section deals with a little more granularity than Section 4.1." > > Deals with what? Rephrase. > Ok. > o section 4.2.1 adding AVPs.. > > "o Do the AVPs change the state machine of the application ? > > o Would the presence of the AVPs cause additional message round- > trips; effectively changing the state machine of the application > ?" > > The above two bullets could be combined to a one. > Ok. > o section 4.2.1 adding AVPs.. > > "o An optional AVPs with dual purpose; i.e.; to carry applications > data as well as to indicate support for one or more features. > This has a tendency to introduce interpretation issues." > > This is what the dime-mip6-integrated actually does. You should > give a reference to it as a bad design example ;) It could be > emphasized here that if the "dual purpose" can be made entirely > backwards compatible, it is ok.. like in mip6-integrated case > :) we can use mip6-integrated as a corner case where it is possible to do "dual purpose". In general, its probably not a good practice. > o section 5.5 end-to-end.. > > "applications itself. Examples of this can be found in [2] and [3]." > > Add a reference to dime-mip6-integrated here. > > o section 6.4 system arch.. > > "o For general AAA applications, Diameter requires more message > exchanges for the same set of services compared to RADIUS." > > Is it really so after the CER/CEA exchange? > Mainly because of session maintenance (STR/STAs, ASR/ASAs ..) and peer maintenance (DWR/DWAs) etc ... > o section 6.4 system arch.. > > "o Application design should be agnostic to any Diameter topology. > Application designers should not always assume a particular > Diameter topology; i.e., assume that there will always be > application proxies in the path or assume that only intra-domain > routing is applicable." > > I would like to see some more text in general about impacts of AVPs > that affect request routing. Especially in situations when those are > attempted to be used with existing application. A good example is > NAI decoration. Basically a new application is required when other > AVPs than those listed in DBP for request routing affect routing > decisions.. > I see. I guess we can add text on routing impacts to highlight possible issues. thanks, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 19 09:18:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zkL-0004zW-UV; Wed, 19 Dec 2007 09:18:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zkK-0004zN-Sw for dime@ietf.org; Wed, 19 Dec 2007 09:18:04 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4zkK-0006Wb-E9 for dime@ietf.org; Wed, 19 Dec 2007 09:18:04 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBJEHckG031083; Wed, 19 Dec 2007 09:17:38 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <476927F2.3030903@tari.toshiba.com> Date: Wed, 19 Dec 2007 09:17:22 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark, Thanks for the review. Comments inline: > Here are my comments on the 3588bis-09 draft. They are largely editorial > and I found no showstoppers. > > --- > > 1.1. Diameter Protocol > > "Extensibility, through addition of new commands and AVPs (required > in [RFC2989])." > > Extensibility is also achieved through addition of new applications. > Sure. > 1.1.1. Description of the Document Set > > Suggest replacing "Currently" with "At the time of publication/writing". > > This section contains the list of IETF applications. Should we mention > that Diameter allows vendor-specific applications and refer to IANA for > the list of those? > Maybe not in this section since its only a "document set". Though, I agree we have to do some cleanup on this section. > This section also refers to more recent applications like Credit > Control, EAP and SIP but they are not mentioned in other sections which > refer only to NASREQ/MIPv4, e.g. the list of Application Identifiers in > section 2.4. > > > 1.2.2. Creating New AVPs > > "If an appropriate derived data type is already defined, > it MAY be used instead of the base data type." > > Suggest strengthening the MAY to a SHOULD to encourage derived data type > reuse. > Moving to "SHOULD" implies that we have to justify why it is a SHOULD. We can add that good design practice is a good enough reason for it to be a SHOULD. > > 1.2.3. Creating New Commands > > Typo (probably mine): defintion -> definition > > > 1.2.4. Creating New Authentication Applications > > > "An implementation MAY add arbitrary non-mandatory AVPs to any command > defined in an application, including vendor-specific AVPs without > needing to define a new application." > > An implementation can add non-mandatory AVPs only if allowed by the > command ABNF, i.e. it has the "* [ AVP ]" element. > Good catch. > > 2.3. Diameter Application Compliance > > "An implementation MAY add arbitrary non-mandatory AVPs to any > command > defined in an application, including vendor-specific AVPs." > > Same comment as above for 1.2.4. > > > 2.9. Diameter Path Authorization > > " Diameter sessions > MUST be routed only through authorized nodes that have advertised > support for the Diameter application required by the session." > > Or advertised support for the Relay application. > by definition, relays already advertises support for all applications. so it maybe a bit redundant. > > 3.3. Diameter Command Naming Conventions > > "Once > the receiver has completed the request it issues the corresponding > answer, which includes a result code that communicates one of the > following:" > > Suggest "corresponding answer with the R-bit cleared,..." > > > 6.1.8. Redirecting requests > > Typo in 5th paragraph: againts -> against > > 6.3. Origin-Host AVP > > Typo in 4th paragraph: remove "6.10" > > 6.8. Auth-Application-Id AVP > > Typo: diameter -> Diameter > > 6.9. Acct-Application-Id AVP > > Typo: diameter -> Diameter > > 7.1.3. Protocol Errors > > Typo: maybe -> may be > > 8. Diameter User Sessions > > Typo in 7th paragraph: statemachines -> state machines > Above editorials are ok. > 8.8. Session-Id AVP > > "At startup, the high 32 bits of the 64-bit value MAY be > initialized to the time" > > Suggest adding "in NTP timestamp format [RFC4330]" > Good point. The current text actually suggests it but not in a clear fashion. > 8.13. Session-Timeout AVP > > Incorrect xref in 2nd paragraph: Section 8.9 -> Section 8.11 > Ok. Thanks again, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 19 20:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J59le-0005zq-CM; Wed, 19 Dec 2007 20:00:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J59ld-0005zl-RX for dime@ietf.org; Wed, 19 Dec 2007 20:00:05 -0500 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J59lb-0004Hl-GY for dime@ietf.org; Wed, 19 Dec 2007 20:00:05 -0500 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBK0xZFK022236 for ; Thu, 20 Dec 2007 13:59:40 +1300 Message-ID: <4769BE77.5060304@eservglobal.co.nz> Date: Thu, 20 Dec 2007 13:59:35 +1300 From: Ralph Loader User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5184/Thu Dec 20 12:49:24 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org The definition given for the Vendor-Specific-Application-Id does not follow the grammar specification that "MUST" be used according to section 4.4. The grammar given in section 4.4 does not include '/' or parenthesis; but those are used in 6.11. [While 4.4 does refer to RFC2434, the text makes it clear that it is the grammar given in section 4.4 that MUST be used.] My preferred fix would be to alter the Vendor-Specific-Application-Id: ::= < AVP Header: 260 > { Vendor-Id } [ Auth-Application-Id ] [ Acct-Application-Id ] And add new text imposing additional constraints; something like: "A Vendor-Specific-Application-Id AVP MUST contain exactly one of Auth-Application-Id and Acct-Application_id. If a request containing a Vendor-Specific-Application-Id with neither of these two sub-AVPs is received, the recipient SHOULD generate a reply with DIAMETER_MISSING_AVP result code, within which the Failed-AVP should contain either a Auth-Application-Id AVP or a Acct-Application-Id AVP. If a request containing a Vendor-Specific-Application-Id with both Auth-Application-Id and Acct-Application-Id is received, then the recipient SHOULD generate a reply with DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP contains the second occurrence of the Auth-Application-Id and Acct-Application-Id AVPs." Alternatives: 1. Do nothing, in which case author or implementors of Diameter applications may take "MUST"s less seriously. 2. Allow the '( / )' construct either by including it in section 4.4 or by altering the section 4.4 to allow any RFC2434 notation. If this is done, then section 7 will need some rework to cover the new error cases that arise from the extended grammar. Ralph. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 19 22:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CIF-0006C7-7u; Wed, 19 Dec 2007 22:41:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CID-0006C1-Tf for dime@ietf.org; Wed, 19 Dec 2007 22:41:53 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5CIC-0006p1-A0 for dime@ietf.org; Wed, 19 Dec 2007 22:41:53 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBK3fA0n034578; Wed, 19 Dec 2007 22:41:11 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4769E455.6070508@tari.toshiba.com> Date: Wed, 19 Dec 2007 22:41:09 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Ralph Loader Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <4769BE77.5060304@eservglobal.co.nz> In-Reply-To: <4769BE77.5060304@eservglobal.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ralph, > The definition given for the Vendor-Specific-Application-Id does not > follow the grammar specification that "MUST" be used according to > section 4.4. > > The grammar given in section 4.4 does not include '/' or parenthesis; > but those are used in 6.11. [While 4.4 does refer to RFC2434, the > text makes it clear that it is the grammar given in section 4.4 that > MUST be used.] > > My preferred fix would be to alter the Vendor-Specific-Application-Id: > > ::= < AVP Header: 260 > > { Vendor-Id } > [ Auth-Application-Id ] > [ Acct-Application-Id ] I think adding references to 2434 in section 4.4 should regarding the '/' should be sufficient. > > And add new text imposing additional constraints; something like: > > "A Vendor-Specific-Application-Id AVP MUST contain exactly one of > Auth-Application-Id and Acct-Application_id. Sure, we can re-iterate this again. > > If a request containing a Vendor-Specific-Application-Id with neither > of these two sub-AVPs is received, the recipient SHOULD generate a > reply with DIAMETER_MISSING_AVP result code, within which the > Failed-AVP should contain either a Auth-Application-Id AVP or a > Acct-Application-Id AVP. > > If a request containing a Vendor-Specific-Application-Id with both > Auth-Application-Id and Acct-Application-Id is received, then the > recipient SHOULD generate a reply with > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the > Failed-AVP contains the second occurrence of the Auth-Application-Id > and Acct-Application-Id AVPs." I think this is redundant. If we make section 4.4 clear then the appropriate errors associated with any parsing violations against any ABNF will be implied as it is now. Otherwise, we risk writing a lot of text enumerating and describing every single error condition (like above) for every ABNF that is defined. regards, victor > > > Alternatives: > > 1. Do nothing, in which case author or implementors of Diameter > applications may take "MUST"s less seriously. > > 2. Allow the '( / )' construct either by including it in section 4.4 > or by altering the section 4.4 to allow any RFC2434 notation. If this > is done, then section 7 will need some rework to cover the new error > cases that arise from the extended grammar. > > Ralph. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 19 22:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CXZ-0000P6-Rz; Wed, 19 Dec 2007 22:57:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5CXY-0000Ox-29 for dime@ietf.org; Wed, 19 Dec 2007 22:57:44 -0500 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5CXX-0007B4-Aa for dime@ietf.org; Wed, 19 Dec 2007 22:57:43 -0500 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBK3v6Zb001799; Thu, 20 Dec 2007 16:57:11 +1300 Message-ID: <4769E812.4010204@eservglobal.co.nz> Date: Thu, 20 Dec 2007 16:57:06 +1300 From: Ralph Loader User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <4769BE77.5060304@eservglobal.co.nz> <4769E455.6070508@tari.toshiba.com> In-Reply-To: <4769E455.6070508@tari.toshiba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5185/Thu Dec 20 13:56:10 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > I think adding references to 2434 in section 4.4 should regarding the > '/' should be sufficient. It's a major extension to the grammar for a single case that can be handled perfectly well without [it might be textually small, but e.g., it's a very major change for those of us who process the grammar with automated tools]. I'd prefer the more conservative approach of handling this special case as a special case. > I think this is redundant. If we make section 4.4 clear then the > appropriate errors associated with any parsing violations against any > ABNF will be implied as it is now. The trouble with extending the grammar specification is that the current error handling seems to assume the 4.4 grammar specification. E.g., the current definition of DIAMETER_MISSING_AVP assumes that you can identify what AVP is missing. > Otherwise, we risk writing a lot of > text enumerating and describing every single error condition (like > above) for every ABNF that is defined. This is already the route the diameter error handling has taken; by specifying different result codes for different violations of grammars. If you extend the grammar specification, then yes, you do need to extend the error handling. Ralph. > > regards, > victor > >> >> >> Alternatives: >> >> 1. Do nothing, in which case author or implementors of Diameter >> applications may take "MUST"s less seriously. >> >> 2. Allow the '( / )' construct either by including it in section 4.4 >> or by altering the section 4.4 to allow any RFC2434 notation. If this >> is done, then section 7 will need some rework to cover the new error >> cases that arise from the extended grammar. >> >> Ralph. >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 20 02:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5FVO-0000A8-Io; Thu, 20 Dec 2007 02:07:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5FVN-0000A2-BL for dime@ietf.org; Thu, 20 Dec 2007 02:07:41 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5FVM-0002B9-MZ for dime@ietf.org; Thu, 20 Dec 2007 02:07:41 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC008WI6FH5P@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Dec 2007 15:06:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JTC008H86FH0R@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Dec 2007 15:06:53 +0800 (CST) Received: from huawei1515 ([10.18.23.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JTC00HTS6FGRL@szxml04-in.huawei.com> for dime@ietf.org; Thu, 20 Dec 2007 15:06:53 +0800 (CST) Date: Thu, 20 Dec 2007 12:36:49 +0530 From: Rajith R Subject: RE: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. In-reply-to: <4769BE77.5060304@eservglobal.co.nz> To: 'Ralph Loader' , dime@ietf.org Message-id: <003e01c842d6$e44ceba0$3a17120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AchCo7HKb9UsxOd4QyWw8VpnxVfX5gAMwOMQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajithr@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org If a request containing a Vendor-Specific-Application-Id with both Auth-Application-Id and Acct-Application-Id is received, then the recipient SHOULD generate a reply with DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP contains the second occurrence of the Auth-Application-Id and Acct-Application-Id AVPs Should not this be considered as contradicting AVPs? Rajith -----Original Message----- From: Ralph Loader [mailto:rloader@eservglobal.com] Sent: Thursday, December 20, 2007 6:30 AM To: dime@ietf.org Subject: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. The definition given for the Vendor-Specific-Application-Id does not follow the grammar specification that "MUST" be used according to section 4.4. The grammar given in section 4.4 does not include '/' or parenthesis; but those are used in 6.11. [While 4.4 does refer to RFC2434, the text makes it clear that it is the grammar given in section 4.4 that MUST be used.] My preferred fix would be to alter the Vendor-Specific-Application-Id: ::= < AVP Header: 260 > { Vendor-Id } [ Auth-Application-Id ] [ Acct-Application-Id ] And add new text imposing additional constraints; something like: "A Vendor-Specific-Application-Id AVP MUST contain exactly one of Auth-Application-Id and Acct-Application_id. If a request containing a Vendor-Specific-Application-Id with neither of these two sub-AVPs is received, the recipient SHOULD generate a reply with DIAMETER_MISSING_AVP result code, within which the Failed-AVP should contain either a Auth-Application-Id AVP or a Acct-Application-Id AVP. If a request containing a Vendor-Specific-Application-Id with both Auth-Application-Id and Acct-Application-Id is received, then the recipient SHOULD generate a reply with DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP contains the second occurrence of the Auth-Application-Id and Acct-Application-Id AVPs." Alternatives: 1. Do nothing, in which case author or implementors of Diameter applications may take "MUST"s less seriously. 2. Allow the '( / )' construct either by including it in section 4.4 or by altering the section 4.4 to allow any RFC2434 notation. If this is done, then section 7 will need some rework to cover the new error cases that arise from the extended grammar. Ralph. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 20 08:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5LbG-0001qZ-0g; Thu, 20 Dec 2007 08:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5LbD-0001Y3-Vv for dime@ietf.org; Thu, 20 Dec 2007 08:38:08 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5LbD-0000Nc-Lj for dime@ietf.org; Thu, 20 Dec 2007 08:38:07 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBKDb7Ml036110; Thu, 20 Dec 2007 08:37:07 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <476A7003.1010303@tari.toshiba.com> Date: Thu, 20 Dec 2007 08:37:07 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Ralph Loader Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <4769BE77.5060304@eservglobal.co.nz> <4769E455.6070508@tari.toshiba.com> <4769E812.4010204@eservglobal.co.nz> In-Reply-To: <4769E812.4010204@eservglobal.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ralph, Thanks for the review. > > I think adding references to 2434 in section 4.4 should regarding the > > '/' should be sufficient. > > It's a major extension to the grammar for a single case that can be > handled perfectly well without [it might be textually small, but e.g., > it's a very major change for those of us who process the grammar with > automated tools]. I'd prefer the more conservative approach of > handling this special case as a special case. > Sorry I meant if we put references to "RFC4234" (numbers got jumbled up) which already contains rules for alternatives (3.2). So I don't really consider it an extension since it already exist. We can also re-iterate the "\" rules in bis 4.4 to make the point clear. Since 4234 is the basis for ABNF parsing, I would expect your automated tools already handle such things. >> I think this is redundant. If we make section 4.4 clear then the >> appropriate errors associated with any parsing violations against any >> ABNF will be implied as it is now. > > The trouble with extending the grammar specification is that the > current error handling seems to assume the 4.4 grammar specification. > E.g., the current definition of DIAMETER_MISSING_AVP assumes that you > can identify what AVP is missing. See above. > >> Otherwise, we risk writing a lot of text enumerating and describing >> every single error condition (like above) for every ABNF that is >> defined. > > This is already the route the diameter error handling has taken; by > specifying different result codes for different violations of grammars. Yes but you don't have to repeat the text everytime everywhere you find an ABNF. > > If you extend the grammar specification, then yes, you do need to > extend the error handling. See above. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 20 13:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QWh-0002n6-JO; Thu, 20 Dec 2007 13:53:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QWf-0002mz-Jc for dime@ietf.org; Thu, 20 Dec 2007 13:53:45 -0500 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5QWe-0004vz-MS for dime@ietf.org; Thu, 20 Dec 2007 13:53:45 -0500 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBKIquqw027531; Fri, 21 Dec 2007 07:53:11 +1300 Message-ID: <476ABA08.9010401@eservglobal.co.nz> Date: Fri, 21 Dec 2007 07:52:56 +1300 From: Ralph Loader User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <4769BE77.5060304@eservglobal.co.nz> <4769E455.6070508@tari.toshiba.com> <4769E812.4010204@eservglobal.co.nz> <476A7003.1010303@tari.toshiba.com> In-Reply-To: <476A7003.1010303@tari.toshiba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5193/Fri Dec 21 06:48:33 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Victor, > Hi Ralph, > > Thanks for the review. > >> > I think adding references to 2434 in section 4.4 should regarding the >> > '/' should be sufficient. >> >> It's a major extension to the grammar for a single case that can be >> handled perfectly well without [it might be textually small, but e.g., >> it's a very major change for those of us who process the grammar with >> automated tools]. I'd prefer the more conservative approach of >> handling this special case as a special case. >> > > Sorry I meant if we put references to "RFC4234" (numbers got jumbled up) > which already contains rules for alternatives (3.2). So I don't really > consider it an extension since it already exist. We can also re-iterate > the "\" rules in bis 4.4 to make the point clear. Since 4234 is the > basis for ABNF parsing, As far as I can understand your email, you are claiming that RFC3588 allows Diameter applications to use arbitrary RFC 4234 ABNF to describe their AVPs? That is NOT what the 3588 wording says: Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [RFC4234] (with modifications), as defined below Based in rfc4234 yes, "with modifications" [that severely restrict the grammar]. The grammar that "MUST" be used is that "defined below" the sentence. I can't see any reasonable reading of that sentence that allows ABNF beyond that explicitly listed in section 4.4. I would expect your automated tools already > handle such things. I'm not sure on what grounds you have an expectation on code that that you've never hand any contact with whatsoever. If I need to start supporting Diameter applications that use general RFC 4234 ABNF I will when the need arises... until then, Diameter is quite complicated enough and I've no desire to generate unnecessary work for myself. > > >>> I think this is redundant. If we make section 4.4 clear then the >>> appropriate errors associated with any parsing violations against any >>> ABNF will be implied as it is now. >> >> The trouble with extending the grammar specification is that the >> current error handling seems to assume the 4.4 grammar specification. >> E.g., the current definition of DIAMETER_MISSING_AVP assumes that you >> can identify what AVP is missing. > > See above. Just to re-iterate, the current section 7 error handling does not cover many error cases that can arise if Diameter application writers use arbitrary RFC4234 ABNF. If 4.4 is to be interpreted or re-written to allow arbitrary ABNF, then section 7 needs revision [or ad hoc error handling needs to be done for AVPs that require it.] > Yes but you don't have to repeat the text everytime everywhere you find > an ABNF. As far as I can see, section 7 doesn't cover the error handling required for Vendor-Specific-Application-Id. Specifically, the current DIAMETER_MISSING_AVP text assumes that the recipient can identify a specific AVP that is required but not present; that is not the case with a V-S-A-I that contains neither a Auth-Application-Id nor a Acct-Application-Id [but does contain a Vendor-Id]. Ralph. > >> >> If you extend the grammar specification, then yes, you do need to >> extend the error handling. > > > See above. > > regards, > victor > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 20 13:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QYA-00047U-JO; Thu, 20 Dec 2007 13:55:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QY9-00046g-AP for dime@ietf.org; Thu, 20 Dec 2007 13:55:17 -0500 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5QY8-0004xt-ES for dime@ietf.org; Thu, 20 Dec 2007 13:55:17 -0500 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBKIst7c027556; Fri, 21 Dec 2007 07:55:01 +1300 Message-ID: <476ABA7F.9090304@eservglobal.co.nz> Date: Fri, 21 Dec 2007 07:54:55 +1300 From: Ralph Loader User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <003e01c842d6$e44ceba0$3a17120a@china.huawei.com> In-Reply-To: <003e01c842d6$e44ceba0$3a17120a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5193/Fri Dec 21 06:48:33 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Rajith R wrote: > > > If a request containing a Vendor-Specific-Application-Id with both > Auth-Application-Id and Acct-Application-Id is received, then the > recipient SHOULD generate a reply with > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP > contains the second occurrence of the Auth-Application-Id and > Acct-Application-Id AVPs > > Should not this be considered as contradicting AVPs? Yes, you are right. DIAMETER_CONTRADICTING_AVPS is better, and the section 7 text already covers this case, so there is no need to repeat it. Ralph. > > Rajith > -----Original Message----- > From: Ralph Loader [mailto:rloader@eservglobal.com] > Sent: Thursday, December 20, 2007 6:30 AM > To: dime@ietf.org > Subject: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. > > The definition given for the Vendor-Specific-Application-Id does not > follow the grammar specification that "MUST" be used according to > section 4.4. > > The grammar given in section 4.4 does not include '/' or parenthesis; > but those are used in 6.11. [While 4.4 does refer to RFC2434, the text > makes it clear that it is the grammar given in section 4.4 that MUST be > used.] > > My preferred fix would be to alter the Vendor-Specific-Application-Id: > > ::= < AVP Header: 260 > > { Vendor-Id } > [ Auth-Application-Id ] > [ Acct-Application-Id ] > > And add new text imposing additional constraints; something like: > > "A Vendor-Specific-Application-Id AVP MUST contain exactly one of > Auth-Application-Id and Acct-Application_id. > > If a request containing a Vendor-Specific-Application-Id with neither of > these two sub-AVPs is received, the recipient SHOULD generate a reply > with DIAMETER_MISSING_AVP result code, within which the Failed-AVP > should contain either a Auth-Application-Id AVP or a Acct-Application-Id > AVP. > > If a request containing a Vendor-Specific-Application-Id with both > Auth-Application-Id and Acct-Application-Id is received, then the > recipient SHOULD generate a reply with > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP > contains the second occurrence of the Auth-Application-Id and > Acct-Application-Id AVPs." > > > Alternatives: > > 1. Do nothing, in which case author or implementors of Diameter > applications may take "MUST"s less seriously. > > 2. Allow the '( / )' construct either by including it in section 4.4 or > by altering the section 4.4 to allow any RFC2434 notation. If this is > done, then section 7 will need some rework to cover the new error cases > that arise from the extended grammar. > > Ralph. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 20 14:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Qom-0000Wp-8q; Thu, 20 Dec 2007 14:12:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Qol-0000Wj-DP for dime@ietf.org; Thu, 20 Dec 2007 14:12:27 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5Qol-00082v-5L for dime@ietf.org; Thu, 20 Dec 2007 14:12:27 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lBKJBhJk037697; Thu, 20 Dec 2007 14:11:44 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <476ABE80.7040106@tari.toshiba.com> Date: Thu, 20 Dec 2007 14:12:00 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Ralph Loader Subject: Re: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs. References: <4769BE77.5060304@eservglobal.co.nz> <4769E455.6070508@tari.toshiba.com> <4769E812.4010204@eservglobal.co.nz> <476A7003.1010303@tari.toshiba.com> <476ABA08.9010401@eservglobal.co.nz> In-Reply-To: <476ABA08.9010401@eservglobal.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ralph, > > As far as I can understand your email, you are claiming that RFC3588 > allows Diameter applications to use arbitrary RFC 4234 ABNF to > describe their AVPs? That is NOT what the 3588 wording says: > > Every Grouped AVP defined MUST include a corresponding grammar, using > ABNF [RFC4234] (with modifications), as defined below > > Based in rfc4234 yes, "with modifications" [that severely restrict the > grammar]. The grammar that "MUST" be used is that "defined below" the > sentence. I can't see any reasonable reading of that sentence that > allows ABNF beyond that explicitly listed in section 4.4. Ok. I see your point. We can update the rules in 4.4 and update the error codes in section 7 to support the new rules. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Dec 22 03:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5zRu-0007z7-0W; Sat, 22 Dec 2007 03:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5zRs-0007z1-MU for dime@ietf.org; Sat, 22 Dec 2007 03:11:08 -0500 Received: from gw02.mail.saunalahti.fi ([195.197.172.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5zRq-0008Qk-OI for dime@ietf.org; Sat, 22 Dec 2007 03:11:08 -0500 Received: from [88.112.141.24] (a88-112-141-24.elisa-laajakaista.fi [88.112.141.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 9A2101396E8; Sat, 22 Dec 2007 10:11:02 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jouni Korhonen Date: Sat, 22 Dec 2007 10:10:59 +0200 To: dime@ietf.org, vfajardo@tari.toshiba.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.3 (+) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Subject: [Dime] (no subject) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I promised to do some reading of rfc3588bis. Mark already did cover most of the stuff but few initial nits below. More to follow probably. Cheers, Jouni ------------------ o This bis version e.g. deprecates a few things from the RFC3588 like E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are considerable changes in the security department. I would like to see a small section actually describing the major changes. For a new reader that would be a nice quick-start. o Application Id has been written using 3-4 different conventions in the text. Pick one and stay with it ;) Section 4.1. AVP Header I would actually leave the P-flag in place but have a description in flags related text stating something like "The 'P' bit has been deprecated and MUST be set to zero when sending and ignored on receiving". IMHO this is more cleaner way than changing it to 'r' bit. Section 4.3. Derived AVP Data Formats "The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the ASCII charset. Packets may be filtered based on the following information that is associated with it:" o I would suggest rewriting: "The IPFilterRule format is derived from the OctetString AVP Base Format and uses the ASCII charset. The rule syntax is a modified subset of ipfw(8) from FreeBSD. Packets may be filtered based on the following information that is associated with it:" o And revome the following one sentence paragraph. "The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations." 6.11. Vendor-Specific-Application-Id AVP ".. The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor-specific Diameter application. It MUST NOT be used as a means of defining a completely separate vendor-specific application identifier space. o A question.. now that section 11.3. under IANA considerations say: "Vendor-Specific Application Identifiers, are for Private Use. Vendor- Specific Application Identifiers are assigned on a First Come, First Served basis by IANA." o what is the actual value of having Vendor-Id AVP in the group if the vendor specific application Ids need to be reserved from AINA anyway? If it is just FYI, couldn't that be removed..? though that might hurt backwards compatibility, slightly ;) 6.11. Vendor-Specific-Application-Id AVP ::= < AVP Header: 260 > { Vendor-Id } ({ Auth-Application-Id } / { Acct-Application-Id }) o I think the above does not comply with the ABNF described in section 3.2. 8.4.2. Session-Termination-Answer * [ Redirect-Host ] [ Redirect-Host-Usage ] ^ [ Redirect-Max-Cache-Time ] o what is this '^' ? 11. IANA Considerations o Text references to DIME WG should be removed. Once DIME completes there is probably no mailing list to post any requests etc. Suggested rewrite of " ...For Designated Expert with Specification Required, the request is posted to the DIME WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a pointer to a public specification." to " ...For Designated Expert with Specification Required, the request is posted to a mailing list maintaining Diameter or one designated by the Area Director) for comment and review, and MUST include a pointer to a public specification." 11.6. NAPTR Service Fields "transport protocol. For example - "New Connectionless Transport Protocol (NCTP), RFC 5766"." o We'll probably reach RFC 5766 in two years or something. Use some other fictional number or convention as an example, like RFC 0000, RFC xyz or similar truly not existing number 14.1. Normative References [IPV4] Postel, J., "Internet Protocol", RFC 791, September 1981. [TCP] Postel, J., "Transmission Control Protocol", RFC 793, January 1981. o Inconsistent style compared to other RFC references Appendix B. NAPTR Example ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com ... o The layout in both examples (NAPTR & SRV) is a bit off?? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Dec 22 03:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5zaU-0001IW-RF; Sat, 22 Dec 2007 03:20:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5zaT-0001IJ-QI for dime@ietf.org; Sat, 22 Dec 2007 03:20:01 -0500 Received: from gw02.mail.saunalahti.fi ([195.197.172.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5zaS-0000Pz-VV for dime@ietf.org; Sat, 22 Dec 2007 03:20:01 -0500 Received: from [88.112.141.24] (a88-112-141-24.elisa-laajakaista.fi [88.112.141.24]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 6D720139621; Sat, 22 Dec 2007 10:19:58 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2DA96CD9-305A-4E73-8C76-B897A7CCBE4D@iki.fi> Content-Transfer-Encoding: 7bit From: Jouni Korhonen Subject: 3588bis review was: Re: [Dime] (no subject) Date: Sat, 22 Dec 2007 10:19:54 +0200 To: dime@ietf.org, vfajardo@tari.toshiba.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org D'oh.. forgot the subject line ;) Jouni On Dec 22, 2007, at 10:10 AM, Jouni Korhonen wrote: > > Hi all, > > I promised to do some reading of rfc3588bis. Mark already did cover > most of the stuff but few initial nits below. More to follow probably. > > Cheers, > Jouni > > > ------------------ > > o This bis version e.g. deprecates a few things from the RFC3588 like > E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are considerable > changes in the security department. I would like to see a small > section actually describing the major changes. For a new reader that > would be a nice quick-start. > > o Application Id has been written using 3-4 different conventions > in the text. Pick one and stay with it ;) > > > Section 4.1. AVP Header > > I would actually leave the P-flag in place but have a description > in flags related text stating something like "The 'P' bit has been > deprecated and MUST be set to zero when sending and ignored on > receiving". IMHO this is more cleaner way than changing it to 'r' > bit. > > Section 4.3. Derived AVP Data Formats > > "The IPFilterRule format is derived from the OctetString AVP Base > Format. It uses the ASCII charset. Packets may be filtered > based > on the following information that is associated with it:" > > o I would suggest rewriting: > > "The IPFilterRule format is derived from the OctetString AVP Base > Format and uses the ASCII charset. The rule syntax is a modified > subset of ipfw(8) from FreeBSD. Packets may be filtered based on > the following information that is associated with it:" > > o And revome the following one sentence paragraph. > > "The rule syntax is a modified subset of ipfw(8) from FreeBSD, > and > the ipfw.c code may provide a useful base for implementations." > > > 6.11. Vendor-Specific-Application-Id AVP > > ".. > The Vendor-Id AVP is an informational AVP pertaining to the vendor > who may have authorship of the vendor-specific Diameter application. > It MUST NOT be used as a means of defining a completely separate > vendor-specific application identifier space. > > o A question.. now that section 11.3. under IANA considerations say: > > "Vendor-Specific Application Identifiers, are for Private Use. > Vendor- > Specific Application Identifiers are assigned on a First Come, > First > Served basis by IANA." > > o what is the actual value of having Vendor-Id AVP in the group if > the vendor specific application Ids need to be reserved from AINA > anyway? If it is just FYI, couldn't that be removed..? though that > might hurt backwards compatibility, slightly ;) > > 6.11. Vendor-Specific-Application-Id AVP > > ::= < AVP Header: 260 > > { Vendor-Id } > ({ Auth-Application-Id } / > { Acct-Application-Id }) > > o I think the above does not comply with the ABNF described in > section 3.2. > > > 8.4.2. Session-Termination-Answer > > * [ Redirect-Host ] > [ Redirect-Host-Usage ] > ^ > [ Redirect-Max-Cache-Time ] > > o what is this '^' ? > > > 11. IANA Considerations > > o Text references to DIME WG should be removed. Once DIME completes > there is probably no mailing list to post any requests etc. > Suggested rewrite of > > > " ...For Designated Expert with Specification > Required, the request is posted to the DIME WG mailing list (or, if > it has been disbanded, a successor designated by the Area Director) > for comment and review, and MUST include a pointer to a public > specification." > > to > > " ...For Designated Expert with Specification > Required, the request is posted to a mailing list maintaining > Diameter or one designated by the Area Director) for comment > and review, and MUST include a pointer to a public specification." > > 11.6. NAPTR Service Fields > > "transport protocol. For example - "New Connectionless Transport > Protocol (NCTP), RFC 5766"." > > o We'll probably reach RFC 5766 in two years or something. Use > some other fictional number or convention as an example, like > RFC 0000, RFC xyz or similar truly not existing number > > 14.1. Normative References > > [IPV4] Postel, J., "Internet Protocol", RFC 791, September > 1981. > > [TCP] Postel, J., "Transmission Control Protocol", RFC 793, > January 1981. > > o Inconsistent style compared to other RFC references > > > Appendix B. NAPTR Example > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "AAA+D2S" "" > _diameter._sctp.example.com IN NAPTR 100 50 "s" "AAA+D2T" > "" _aaa._tcp.example.com > ... > > > o The layout in both examples (NAPTR & SRV) is a bit off?? > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 26 18:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7fKF-0003tN-8L; Wed, 26 Dec 2007 18:06:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7fKD-0003t7-Fv; Wed, 26 Dec 2007 18:06:09 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J7fKB-0000hY-JP; Wed, 26 Dec 2007 18:06:09 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lBQN63e5022562; Wed, 26 Dec 2007 17:06:03 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Dec 2007 17:06:03 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Date: Wed, 26 Dec 2007 17:05:57 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D01170015@ILEXC2U01.ndc.lucent.com> In-Reply-To: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Thread-Index: Acf0dHQKWp2qsJGwRai0fTjEutBfxxTmOAqg References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> From: "Sun, Dong \(Dong\)" To: "Francois Le Faucheur" , X-OriginalArrivalTime: 26 Dec 2007 23:06:03.0471 (UTC) FILETIME=[E346DDF0:01C84813] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: d1330b60dd48fa5cb1958a0aa669d18b Cc: tsvwg tsvwg X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0523265070==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0523265070== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84813.E3026A31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C84813.E3026A31 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 I have no disagreement to make NEs serve as QoS signaling proxy and support non-e2e signaling scenarios. However, not sure if I understood your examples correctly, it seems the Authorizing entity is required to instruct the NE for initiating and/or terminating the QoS signaling, which makes AE become a QoS signaling aware entity.=20 =20 IMHO, it would be better to allow NE itself decide how to operate on QoS signaling based on the policy decisions from AE for the following reasons: - It is more flexible to make AE as a transport signaling independent entity, especially for support of various signalings used by different transport networks, including RSVP, NSIS, even ANCP and others since AE is usually an overlay logical (and off path) Diameter node per se, and in certain circumstances e.g. inter-domain case, it is awkward to have AE involved in the decision and instruction of QoS signaling handling across the administrative domain. - According to the current modeling (see fig. 2 in "qos-01"), there is a resource management function (and other signaling processing functions) co-located with Diameter client in the NE, it would be more appropriate to handle this kind of function by these underneath blocks rather than Diameter nodes. =20 In order to reflect this kind of capability (i.e. support non-e2e QoS signaling), the examples in section 7 of "qos-02" can be edited to indicate that NE should be able to initiate and/or terminate the QoS signaling based on policy decisions received from Authorizing entity (it seems no need to add additional example call flows dedicatedly for this feature).=20 =20 Best Regards, Dong ________________________________ From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 Sent: Tuesday, September 11, 2007 8:55 AM To: dime@ietf.org Cc: Le Faucheur Francois; tsvwg tsvwg Subject: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Hello,=20 dime-diameter-qos-01 defines a Diameter application for QoS reservations. When dealing with QoS signaling (such as RSVP or NSIS), it seems to assume that reservation signaling always takes place end-to-end. However, there are useful QoS reservation deployment models where reservation signaling does not quite happen end-to-end. Instead QoS signaling may be initiated by a Signaling Sender Proxy (on behalf of the actual sender) or terminated by a Signaling Receiver Proxy (on behalf of the actual receiver). draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy entities. I believe it would be very useful if the "Diameter Application for QoS reservations" could be extended to deal with scenarios involving QoS Reservation Proxies operating inside the AAA-controlled Network Elements. Two key example additional capabilities I would see are: *A* ability for the AAA Authorizing Entity to instruct a Network Element (eg the sender-facing NE) to initiate QoS signaling on behalf of the sender (e.g. instructing the NE to behave as a RSVP Sender Proxy). *B* on receipt of a QoS Authorization Request from a NE, ability for the AAA Authorizing Entity to instruct the NE to close the signaling loop on behalf of the receiver (e.g. instructing the NE to behave as a RSVP Receiver Proxy). Just for illustration, *A* could perhaps look something like this: Authorizing End-Host Network Element Entity requesting QoS ( Diameter ( Diameter QoS Client) QoS Server) | | | | | +--------+--------------+ | | | Authorize new flow | | | | .... | | | | Sig Sender Proxy needed| | | +--------+--------------+ | |< - - - - XXX - - - - - -+ | | (...Sender-Proxy) | | +-------+---------+ | |Install QoS state| | | + | | | Initiate QoS | | | Reservation | QoS Responder | | | Node | +-------+---------+ | | +----------QoS-Reserve---....--->| | | | | |<---------QoS-Response--....----| | | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | Just for illustration, *B* could perhaps look something like this: Authorizing End-Host Network Element Entity requesting QoS ( Diameter ( Diameter QoS Client) QoS Server) | | | +---QoS-Reserve---->| | | +- - - - - QAR - - - - - >| | |(QoS-Resources,Cost, | | | QoS-Auth-Data,User-ID)| | | +--------+--------------+ | | | Authorize request | | | | ... | | | | Sig Receiver Proxy needed| | | +--------+--------------+ | |< - - - - YYY - - - - - -+ | |(Result-Code,CC-Time,Cost| | |... Receiver-Proxy)| | +-------+---------+ | |Install QoS state| | | + | | | Authz. session | | | /Authz-time, | QoS Responder | | CC-Time,Cost/ | Node | |+ Receiver Proxy | | | +-------+---------+ | | + | | | | | | | |<--QoS-Response----+ | | | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>| | | | +- - - - - ACR - - - - - >| | |(START,QoS-Resources,Cost| | |CC-Time,Acc-Multisess-id)| | | +--------+--------------+ | | | Report for successful | | | | QoS reservation | | | |Update of reserved QoS | | | | resources | | | +--------+--------------+ | |< - - - - ACA - - - - - -+ | | | Using the terminology of section 3.2 of dime-diameter-qos-01: - *A* above can be used to support the Push model augmented with QoS reservation inside the network. It is applicable to sender endpoints of Category 1, 2 and 3. - *B* above can be used to support the Push Model augmented with QoS reservation inside the network. It is applicable to receiver endpoints of Category 1, 2 and 3. - *B* above can also be used to support the Pull Model even with non-QoS_signaling Capable Receiver endpoints (ie of Category 1 and 2) Would the DIME WG be willing to address these QOS reservation proxy scenarios in dime-diameter-qos? Thank you FRancois ------_=_NextPart_001_01C84813.E3026A31 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
I have no disagreement to make NEs serve as = QoS=20 signaling proxy and support non-e2e signaling scenarios. However, = not sure=20 if I understood your examples correctly, it seems the Authorizing entity = is=20 required to instruct the NE for initiating and/or terminating the QoS = signaling,=20 which makes AE become a QoS signaling aware entity.
 
IMHO, it would be better to allow NE itself = decide how=20 to operate on QoS signaling based on the policy decisions from AE for = the=20 following reasons:
- It is more flexible to make AE as a = transport=20 signaling independent entity, especially for support of various = signalings used=20 by different transport networks, including RSVP, NSIS, even ANCP = and others=20 since AE is usually an overlay logical (and off path) Diameter = node=20 per se, and in certain circumstances e.g. inter-domain case, it is = awkward to=20 have AE involved in the decision and instruction of QoS signaling = handling=20 across the administrative domain.
- According to the current modeling (see fig. = 2 in=20 "qos-01"), there is a resource management function (and other signaling=20 processing functions) co-located with Diameter client in the = NE, it=20 would be more appropriate to handle this kind of function by these = underneath=20 blocks rather than Diameter nodes.
 
In order to reflect this kind of capability = (i.e.=20 support non-e2e QoS signaling), the examples in section 7 of "qos-02" = can be=20 edited to indicate that NE should be able to initiate and/or terminate = the QoS=20 signaling based on policy decisions received from Authorizing entity (it = seems=20 no need to add additional example call flows dedicatedly for this = feature).=20
 
Best Regards,
Dong

From: Francois Le Faucheur=20 [mailto:flefauch@cisco.com]
Sent: Tuesday, September 11, 2007 = 8:55=20 AM
To: dime@ietf.org
Cc: Le Faucheur Francois; tsvwg = tsvwg
Subject: [Dime] dime-diameter-qos-01 handling of QoS = Signaling=20 Proxies

Hello,
dime-diameter-qos-01 = defines a=20 Diameter application for QoS reservations. When dealing with QoS = signaling (such=20 as RSVP or NSIS), it seems to assume that reservation signaling always = takes=20 place end-to-end. However, there are useful QoS reservation deployment = models=20 where reservation signaling does not quite happen end-to-end. Instead = QoS=20 signaling may be initiated by a Signaling Sender Proxy (on behalf = of the=20 actual sender) or terminated by a Signaling Receiver Proxy (on behalf=20 of the actual receiver).
draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP = Sender Proxy=20 and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling proxy=20 entities.
I believe it would be = very useful=20 if the "Diameter Application for QoS reservations" could be extended to = deal=20 with scenarios involving QoS Reservation Proxies operating inside the=20 AAA-controlled Network Elements. Two key example additional capabilities = I would see are:
*A* ability for the AAA = Authorizing Entity=20 to instruct a Network Element (eg the sender-facing NE) to initiate QoS=20 signaling on behalf of the sender (e.g. instructing the NE to behave as = a RSVP=20 Sender Proxy).
*B* on receipt of a = QoS Authorization=20 Request from a NE, ability for the AAA Authorizing Entity to = instruct the=20 NE to close the signaling loop on behalf of the receiver (e.g. = instructing the=20 NE to behave as a RSVP Receiver Proxy).
Just for = illustration, *A* could=20 perhaps look something like this:
      =  =20                     =  =20                 =20 Authorizing
    =20 End-Host         Network Element    =  =20        Entity
   = requesting QoS =20     ( Diameter              = (=20 Diameter
      =  =20                 QoS = Client)   =20          QoS Server)
    =   =20 |                   = | =20                    =20    |
   =   =20  |                =   =20 |               =20 +--------+--------------+
    =   =20 |                   = | =20               |  Authorize new=20 flow   |
   =   =20  |                =   =20 |                |   =20     ....         =20  |
   =   =20  |                =   =20 |                | Sig Sender = Proxy=20 needed|
   =   =20  |                =   =20 |               =20 +--------+--------------+
    =   =20 |                   = |< - -=20 - - XXX - - - - - -+
   =   =20  |                =    |=20    (...Sender-Proxy)    |
    =   =20 |           = +-------+---------+
    =   =20 |           |Install QoS = state|
    =   =20 |           |       = + =20        |
    =   =20 |           | Initiate QoS  =20  |
    =   =20 |           | Reservation   =20  |                QoS=20 Responder
    =   =20 |           |      =20           |      =    =20           Node
    =   =20 |           +-------+---------+  =  =20                   = |
    =   =20 |                  =20 +----------QoS-Reserve---....--->|
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |                  =20 |<---------QoS-Response--....----|
   =   =20  |                =   =20 |                    =  =20           |
    =   =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
    =   =20 |                  =20 |
    =   =20 |                   +- = - - - -=20 ACR - - - - - >|
    =   =20 |                  =20 |(START,QoS-Resources,Cost|
    =   =20 |                  =20 |CC-Time,Acc-Multisess-id)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               | Report for successful = |
    =   =20 |                   = | =20               |   QoS=20 reservation     |
    =   =20 |                   = | =20               |Update of reserved QoS = |
    =   =20 |                   = | =20               |     =20 resources        |
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< - -=20 - - ACA - - - - - -+
    =   =20 |                   = | =20                    =20    |
Just for = illustration, *B* could=20 perhaps look something like this:
    =   =20                =   =20                =   =20     Authorizing
    =20 End-Host         Network Element    =  =20        Entity
   = requesting QoS =20     ( Diameter              = (=20 Diameter
      =  =20                 QoS = Client)   =20          QoS Server)
    =   =20 |                   = | =20                    =20    |
    =   =20 +---QoS-Reserve---->|              =  =20          |
    =   =20 |                   +- = - - - -=20 QAR - - - - - >|
    =   =20 |                  =20 |(QoS-Resources,Cost,     |
    =   =20 |                  =20 |   QoS-Auth-Data,User-ID)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               |  Authorize = request =20   |
    =   =20 |                   = | =20               |     =20    ...          =  |
   =   =20  |                =   =20 |                | Sig Receiver = Proxy=20 needed|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< - -=20 - - YYY - - - - - -+
    =   =20 |                  =20 |(Result-Code,CC-Time,Cost|
    =   =20 |                   = |...=20 Receiver-Proxy)|
    =   =20 |           = +-------+---------+
    =   =20 |           |Install QoS = state|
    =   =20 |           |       = + =20        |
    =   =20 |           | Authz. session  = |
    =   =20 |           | /Authz-time,    = | =20               QoS = Responder
    =   =20 |           |  CC-Time,Cost/  = | =20                   = Node
   =   =20  |           |+ Receiver Proxy | =  =20                =   =20  |
   =   =20  |           = +-------+---------+   =20                   = |
    =   =20 |                   = + =20                 =20              |
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |                   = | =20                 =20              |
    =   =20 |<--QoS-Response----+              =  =20                 |
    =   =20 |                   = | =20                     =  =20         |
    =   =20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DData = Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
    =   =20 |                  =20 |
    =   =20 |                   +- = - - - -=20 ACR - - - - - >|
    =   =20 |                  =20 |(START,QoS-Resources,Cost|
    =   =20 |                  =20 |CC-Time,Acc-Multisess-id)|
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = | =20               | Report for successful = |
    =   =20 |                   = | =20               |   QoS=20 reservation     |
    =   =20 |                   = | =20               |Update of reserved QoS = |
    =   =20 |                   = | =20               |     =20 resources        |
    =   =20 |                   = | =20              =20 +--------+--------------+
    =   =20 |                   = |< - -=20 - - ACA - - - - - -+
    =   =20 |                   = | =20                    =20    |
Using the terminology = of section=20 3.2 of dime-diameter-qos-01:
- *A* above can be used to support the = Push=20 model augmented with QoS reservation inside the network. It is = applicable to sender endpoints of Category 1, 2 and 3.
- *B* above can be used to support the = Push=20 Model augmented with QoS reservation inside the network. It is = applicable=20 to receiver endpoints of Category 1, 2 and 3.
- *B* above can also be used to = support the=20 Pull Model even with non-QoS_signaling Capable Receiver endpoints (ie=20 of Category 1 = and=20 2)
Would the DIME WG be = willing to=20 address these QOS reservation proxy scenarios in = dime-diameter-qos?
Thank = you
FRancois
------_=_NextPart_001_01C84813.E3026A31-- --===============0523265070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0523265070==-- From dime-bounces@ietf.org Thu Dec 27 05:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7pgr-0004fH-Nn; Thu, 27 Dec 2007 05:10:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7pgp-0004f1-BY; Thu, 27 Dec 2007 05:10:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7pgn-0004vF-93; Thu, 27 Dec 2007 05:10:11 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Dec 2007 05:10:09 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lBRAA8Fm003255; Thu, 27 Dec 2007 05:10:08 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBRAA4YG000160; Thu, 27 Dec 2007 10:10:04 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 05:10:04 -0500 Received: from [10.0.0.15] ([10.61.81.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Dec 2007 05:10:02 -0500 In-Reply-To: <09C9068466B79E4C938DC7737562404D01170015@ILEXC2U01.ndc.lucent.com> References: <8CA3470D-D813-4184-9F09-66766FA33ED1@cisco.com> <09C9068466B79E4C938DC7737562404D01170015@ILEXC2U01.ndc.lucent.com> Mime-Version: 1.0 (Apple Message framework v753) Message-Id: <48864988-1E39-4E55-A087-A0FDFC974C50@cisco.com> From: Francois Le Faucheur IMAP Subject: Re: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies Date: Thu, 27 Dec 2007 11:09:59 +0100 To: "Sun, Dong ((Dong))" X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 27 Dec 2007 10:10:02.0591 (UTC) FILETIME=[A53E26F0:01C84870] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=40153; t=1198750209; x=1199614209; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20dime-diameter-qos-01=20handlin g=20of=20QoS=20Signaling=20Proxies |Sender:=20 |To:=20=22Sun,=20Dong=20((Dong))=22=20; bh=w+oNx2ToiS5VnOoZVvFHaClV0T3XVTeSNatkyoaQk1Q=; b=eifBCUKndSdk+O/lZCBNiGdiJxnsS1mJ5Wty9cGxDXtg37v02Vr13ankQw sBnyzbckzIYV7f/BmsX+p8jTRm72GI6PM7BCGGKPwuV9ygNXgWqKc8guZfz+ 1fDjKTum4y; Authentication-Results: rtp-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e Cc: dime@ietf.org, tsvwg tsvwg X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1754828298==" Errors-To: dime-bounces@ietf.org --===============1754828298== Content-Type: multipart/alternative; boundary=Apple-Mail-7--747816590 --Apple-Mail-7--747816590 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Dong, Thanks for looking into how to incorporate handling of signaling proxies into Diameter QoS Application. Thoughts embedded below: On 27 Dec 2007, at 00:05, Sun, Dong ((Dong)) wrote: > Hi Francois, > > I have no disagreement to make NEs serve as QoS signaling proxy and > support non-e2e signaling scenarios. Great. > However, not sure if I understood your examples correctly, it seems > the Authorizing entity is required to instruct the NE for > initiating and/or terminating the QoS signaling, which makes AE > become a QoS signaling aware entity. The idea is not to turn the AE into a QoS signaling aware entity. However, I think the AE has to be aware of a few very very basic things related to QoS signaling. I don't see this as a departure from the current model of DQA operation in the case of e2e signaling. With e2e signaling, the AE is not really QoS signaling aware, however the AE understands just enough to realize that it needs to authorize the user to request an e2e reservation (ie not just a local resource reservation). Similarly in the case of signaling proxies, again the AE is not really QoS signaling aware, but it would understand a few very basic things about QoS signaling. For example, in the scenario where the AE is used to trigger signaling initiation on the signaling _sender_ proxy, the AE has to be sufficiently aware of what it is trying to do in order to initiate a DQA Push towards the Network Element on the sender side (as opposed to the NE on the receiver side). And in this case, I think the AE simply has to be able to say inside the DQA push message: "I authorize the QoS resources, and the corresponding reservation needs to be established". Similarly, in the scenario where the AE is used to authorize a QoS signaling reservation in the Pull-model, it would be useful for the AE to be able to provide a hint in the response as to whether signaling should be terminated by a receiver proxy or not. This is because the need to activate receiver proxy behavior (or not) may depend on the per-user-policy (so the NE cannot know, while AE does). > > IMHO, it would be better to allow NE itself decide how to operate > on QoS signaling based on the policy decisions from AE for the > following reasons: > - It is more flexible to make AE as a transport signaling > independent entity, especially for support of various signalings > used by different transport networks, including RSVP, NSIS, even > ANCP and others since AE is usually an overlay logical (and off > path) Diameter node per se, and in certain circumstances e.g. inter- > domain case, it is awkward to have AE involved in the decision and > instruction of QoS signaling handling across the administrative > domain. > - According to the current modeling (see fig. 2 in "qos-01"), there > is a resource management function (and other signaling processing > functions) co-located with Diameter client in the NE, it would be > more appropriate to handle this kind of function by these > underneath blocks rather than Diameter nodes. > > In order to reflect this kind of capability (i.e. support non-e2e > QoS signaling), the examples in section 7 of "qos-02" can be edited > to indicate that NE should be able to initiate and/or terminate the > QoS signaling based on policy decisions received from Authorizing > entity I think I am agreeing with the statement above that "the NE should be able to initiate/terminate the QoS signaling based on policy decisions received from AE". But I am saying that this "policy decision received from the AE" needs to contain a few hints about whether source proxy/receiver proxy behavior should be activated by NE. I have no opinion about how the hints should be conveyed (new flags/ fields in existing AVP, new AVP,...), as long as the information is conveyed. I think the information that needs to be conveyed boils down to: * sender proxy behavior requested/not-requested * receiver proxy behavior requested/not-requested Makes sense? Francois > (it seems no need to add additional example call flows dedicatedly > for this feature). > > Best Regards, > Dong > > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Tuesday, September 11, 2007 8:55 AM > To: dime@ietf.org > Cc: Le Faucheur Francois; tsvwg tsvwg > Subject: [Dime] dime-diameter-qos-01 handling of QoS Signaling Proxies > > Hello, > > dime-diameter-qos-01 defines a Diameter application for QoS > reservations. When dealing with QoS signaling (such as RSVP or > NSIS), it seems to assume that reservation signaling always takes > place end-to-end. However, there are useful QoS reservation > deployment models where reservation signaling does not quite happen > end-to-end. Instead QoS signaling may be initiated by a Signaling > Sender Proxy (on behalf of the actual sender) or terminated by a > Signaling Receiver Proxy (on behalf of the actual receiver). > > draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP Sender Proxy > and RSVP Receiver Proxy. NSIS has defined similar NSIS signaling > proxy entities. > > I believe it would be very useful if the "Diameter Application for > QoS reservations" could be extended to deal with scenarios > involving QoS Reservation Proxies operating inside the AAA- > controlled Network Elements. Two key example additional > capabilities I would see are: > *A* ability for the AAA Authorizing Entity to instruct a Network > Element (eg the sender-facing NE) to initiate QoS signaling on > behalf of the sender (e.g. instructing the NE to behave as a RSVP > Sender Proxy). > *B* on receipt of a QoS Authorization Request from a NE, ability > for the AAA Authorizing Entity to instruct the NE to close the > signaling loop on behalf of the receiver (e.g. instructing the NE > to behave as a RSVP Receiver Proxy). > > Just for illustration, *A* could perhaps look something like this: > > Authorizing > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > | | +--------+--------------+ > | | | Authorize new flow | > | | | .... | > | | | Sig Sender Proxy needed| > | | +--------+--------------+ > | |< - - - - XXX - - - - - -+ > | | (...Sender-Proxy) | > | +-------+---------+ > | |Install QoS state| > | | + | > | | Initiate QoS | > | | Reservation | QoS Responder > | | | Node > | +-------+---------+ | > | +----------QoS-Reserve---....--->| > | | | > | |<---------QoS-Response--....----| > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > > Just for illustration, *B* could perhaps look something like this: > > Authorizing > End-Host Network Element Entity > requesting QoS ( Diameter ( Diameter > QoS Client) QoS Server) > | | | > +---QoS-Reserve---->| | > | +- - - - - QAR - - - - - >| > | |(QoS-Resources,Cost, | > | | QoS-Auth-Data,User-ID)| > | | +--------+--------------+ > | | | Authorize request | > | | | ... | > | | | Sig Receiver Proxy > needed| > | | +--------+--------------+ > | |< - - - - YYY - - - - - -+ > | |(Result-Code,CC-Time,Cost| > | |... Receiver-Proxy)| > | +-------+---------+ > | |Install QoS state| > | | + | > | | Authz. session | > | | /Authz-time, | QoS Responder > | | CC-Time,Cost/ | Node > | |+ Receiver Proxy | | > | +-------+---------+ | > | + | > | | | > | | | > |<--QoS-Response----+ | > | | | > |=====================Data Flow==============....===>| > | | > | +- - - - - ACR - - - - - >| > | |(START,QoS-Resources,Cost| > | |CC-Time,Acc-Multisess-id)| > | | +--------+--------------+ > | | | Report for successful | > | | | QoS reservation | > | | |Update of reserved QoS | > | | | resources | > | | +--------+--------------+ > | |< - - - - ACA - - - - - -+ > | | | > > > Using the terminology of section 3.2 of dime-diameter-qos-01: > - *A* above can be used to support the Push model augmented with > QoS reservation inside the network. It is applicable to sender > endpoints of Category 1, 2 and 3. > - *B* above can be used to support the Push Model augmented with > QoS reservation inside the network. It is applicable to receiver > endpoints of Category 1, 2 and 3. > - *B* above can also be used to support the Pull Model even with > non-QoS_signaling Capable Receiver endpoints (ie of Category 1 and 2) > > Would the DIME WG be willing to address these QOS reservation proxy > scenarios in dime-diameter-qos? > > Thank you > > FRancois > --Apple-Mail-7--747816590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello Dong,

Thanks = for looking into how to incorporate handling of signaling proxies into = Diameter QoS Application.=A0
Thoughts embedded = below:

On 27 Dec 2007, at 00:05, Sun, Dong = ((Dong)) wrote:

Hi = Francois,
=A0
I have no disagreement to make NEs serve as = QoS signaling proxy and support non-e2e signaling = scenarios.=A0

Great.

However, = not sure if I understood your examples correctly, it seems the = Authorizing entity is required to instruct the NE for initiating and/or = terminating the QoS signaling, which makes AE become a QoS signaling = aware entity.

The idea is not to turn = the AE into a QoS signaling aware entity.=A0

However, I think the AE = has to be aware of a few very very basic things related to QoS = signaling. I don't see this as a departure from the current model of DQA = operation in the case of e2e signaling. With e2e signaling, the AE is = not really QoS signaling aware, however the AE understands just enough = to realize that it needs to authorize the user to request an e2e = reservation (ie not just a local resource reservation).=A0

Similarly in the case of = signaling proxies, again the AE is not really QoS signaling aware, but = it would understand a few very basic things about QoS = signaling.
For example, in the scenario where the AE is used = to trigger signaling initiation on the signaling _sender_ proxy, the AE = has to be sufficiently aware of what it is trying to do in order to = initiate a DQA Push towards the Network Element on the sender side (as = opposed to the NE on the receiver side).
And in this case, I = think the AE simply has to be able to say inside the DQA push message: = "I authorize the QoS resources, and the corresponding reservation needs = to be established".=A0

Similarly, in the scenario = where the AE is used to=A0authorize=A0a QoS signaling reservation in the = Pull-model, it would be useful for the AE to be able to provide a hint = in the response as to whether signaling should be terminated by a = receiver proxy or not. This is because the need to activate receiver = proxy behavior (or not) may depend on the per-user-policy (so the NE = cannot know, while AE = does).


=A0
=
IMHO, it would be better = to allow NE itself decide how to operate on QoS signaling based on the = policy decisions from AE for the following reasons:
=
- It is more flexible to = make AE as a transport signaling independent entity, especially for = support of various signalings used by different=A0transport networks, = including RSVP, NSIS, even ANCP and others since AE is usually=A0an = overlay logical (and off path)=A0Diameter node per se, and in certain = circumstances e.g. inter-domain case, it is awkward to have AE involved = in the decision and instruction of QoS signaling handling across the = administrative domain.
- According to the current modeling (see = fig. 2 in "qos-01"), there is a resource management function (and other = signaling processing functions)=A0co-located with=A0Diameter client in = the NE, it would be more appropriate to handle this kind of function by = these underneath blocks rather than Diameter nodes.
=
=A0
=
In order to reflect this = kind of capability (i.e. support non-e2e QoS signaling), the examples in = section 7 of "qos-02" can be edited to indicate that NE should be able = to initiate and/or terminate the QoS signaling based on policy decisions = received from Authorizing = entity

I think I am agreeing = with the statement above that "the NE should be able to = initiate/terminate the QoS signaling based on policy decisions received = from AE".=A0
But I am saying that this "policy decision = received from the AE" needs to contain a few hints about whether source = proxy/receiver proxy behavior should be activated by NE.=A0
I = have no opinion about how the hints should be conveyed (new flags/fields = in existing AVP, new AVP,...), as long as=A0the=A0information is = conveyed.

I = think the information that needs to be conveyed boils down = to:
= * sender proxy behavior requested/not-requested
* = receiver proxy behavior requested/not-requested

Makes sense?

Francois

(it = seems no need to add additional example call flows dedicatedly for this = feature). =
=A0
Best Regards,
Dong

=
From: Francois Le Faucheur [mailto:flefauch@cisco.com] =
Sent: Tuesday, September 11, 2007 8:55 AM
To: dime@ietf.org
Cc: Le = Faucheur Francois; tsvwg tsvwg
Subject: [Dime] = dime-diameter-qos-01 handling of QoS Signaling = Proxies

Hello,

=
dime-diameter-qos-01 defines a Diameter application for = QoS reservations. When dealing with QoS signaling (such as RSVP or = NSIS), it seems to assume that reservation signaling always takes place = end-to-end. However, there are useful QoS reservation deployment models = where reservation signaling does not quite happen end-to-end. Instead = QoS signaling may be initiated by a Signaling Sender Proxy (on behalf = of=A0the actual sender) or terminated by a Signaling Receiver Proxy (on = behalf of=A0the actual receiver).

draft-ietf-tsvwg-rsvp-proxy-approaches discusses RSVP = Sender Proxy and RSVP Receiver Proxy. NSIS has defined similar NSIS = signaling proxy entities.

I believe it would be very = useful if the "Diameter Application for QoS reservations" could be = extended to deal with scenarios involving QoS Reservation Proxies = operating inside the AAA-controlled Network Elements. Two key example = additional capabilities I=A0would see are:
*A* ability for the AAA = Authorizing Entity to instruct a Network Element (eg the sender-facing = NE) to initiate QoS signaling on behalf of the sender (e.g. instructing = the NE to behave as a RSVP Sender Proxy).
*B* on receipt of a = QoS=A0Authorization Request from a NE, ability for the AAA=A0Authorizing = Entity to instruct the NE to close the signaling loop on behalf of the = receiver (e.g. instructing the NE to behave as a RSVP Receiver = Proxy).

=
Just for = illustration, *A* could perhaps look something like this:
=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = Authorizing
=A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 = =A0 =A0 =A0 =A0 =A0=A0 Entity
=A0=A0 requesting QoS=A0 =A0 = =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Diameter
=
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS Client)=A0 =A0 =A0 =A0 =A0 =A0=A0 QoS = Server)
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=
=A0=A0 =A0=A0 =A0|=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 = Authorize new flow=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0=A0= =A0....=A0 =A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Sig Sender Proxy needed|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - XXX - - - - - -+
=
=A0=A0 =A0=A0 =A0|=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 | =A0 =A0(...Sender-Proxy) =A0 = =A0|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0=A0 |Install QoS state|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Initiate QoS =A0 =A0|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Reservation=A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Responder
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Node
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 = +----------QoS-Reserve---....--->|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |<---------QoS-Response--....----|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3DData Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D..= ..=3D=3D=3D>|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - - - = - - >|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |CC-Time,Acc-Multisess-id)|
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Report for = successful |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |Update of reserved QoS |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = resources=A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - - - - - -+
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0 |

=


Just for illustration, *B* = could perhaps look something like this:

=A0 =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0Authorizing
=A0 =A0=A0 End-Host=A0 =A0 =A0 =A0=A0 Network Element=A0 = =A0 =A0 =A0 =A0 =A0=A0 Entity
=A0=A0 requesting QoS=A0 =A0 = =A0 ( Diameter=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Diameter
=
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS Client)=A0 =A0 =A0 =A0 =A0 =A0=A0 QoS = Server)
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=
=A0 =A0 =A0=A0 = +---QoS-Reserve---->|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0= |
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - QAR - - - = - - >|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(QoS-Resources,Cost,=A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0=A0 QoS-Auth-Data,User-ID)|
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 = Authorize request=A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0=A0 = =A0=A0 ...=A0 =A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Sig = Receiver Proxy needed|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +--------+--------------+
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - YYY - - - - - = -+
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(Result-Code,CC-Time,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |... Receiver-Proxy)|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 +-------+---------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |Install QoS state|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 |=A0 =A0 =A0=A0 +=A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | Authz. session=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0=A0 | /Authz-time,=A0 =A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 QoS = Responder
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0=A0 |=A0 = CC-Time,Cost/=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Node
=A0=A0 =A0=A0 =A0|=A0 =A0 =A0 =A0 =A0=A0 |+ Receiver = Proxy | =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=
=A0=A0 =A0=A0 =A0|=A0= =A0 =A0 =A0 =A0=A0 +-------+---------+=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = +=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|
=A0= =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0 =A0 =A0=A0 = |<--QoS-Response----+=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = |
=A0 = =A0 =A0=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Data Flow=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D....=3D=3D=3D>|
=A0 =A0 = =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 +- - - - - ACR - - - - - >|
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |(START,QoS-Resources,Cost|
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |CC-Time,Acc-Multisess-id)|
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Report for = successful |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 = |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0=A0 QoS reservation=A0 =A0=A0 = |
=A0 = =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |Update of reserved QoS |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=A0 =A0 =A0 = resources=A0 =A0 =A0 =A0 |
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = +--------+--------------+
=A0 =A0 =A0=A0 |=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=A0 |< - - - - ACA - - - - - -+
=
=A0 =A0 =A0=A0 |=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 |=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0 |

=

Using the terminology of = section 3.2 of dime-diameter-qos-01:
- *A* above can be used to support = the Push model augmented with QoS reservation inside=A0the=A0network. It = is applicable to sender endpoints of Category 1, 2 and 3.
=
- *B* above = can be used to support the Push Model augmented with QoS reservation = inside the network.=A0It is applicable to receiver endpoints of Category = 1, 2 and 3.
- *B* above can also be used = to support the Pull Model even with non-QoS_signaling Capable Receiver = endpoints (ie of=A0Category 1 and 2)

Would the DIME WG be willing = to address these QOS reservation proxy scenarios in = dime-diameter-qos?

=
Thank = you

=
FRancois


= --Apple-Mail-7--747816590-- --===============1754828298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1754828298==--