From dime-bounces@ietf.org Sat Jul 01 02:28:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwYyH-0006M2-0i; Sat, 01 Jul 2006 02:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwYyF-0006LZ-KW for dime@ietf.org; Sat, 01 Jul 2006 02:28:47 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwYpT-00033L-DA for dime@ietf.org; Sat, 01 Jul 2006 02:19:45 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k616Jco6026254; Sat, 1 Jul 2006 09:19:41 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Jul 2006 09:19:31 +0300 Received: from [127.0.0.1] ([10.162.20.139]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 1 Jul 2006 09:19:31 +0300 Message-ID: <44A613F5.80307@nokia.com> Date: Sat, 01 Jul 2006 09:19:33 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] RFC 3588bis Issue Tracker References: <44A5364A.8050700@gmx.net> In-Reply-To: <44A5364A.8050700@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2006 06:19:31.0706 (UTC) FILETIME=[50AC95A0:01C69CD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: My draft about the AAA URI could easily fit into this category. I don't think I need to repeat what the issues are. Instead, I would recommend folks to read the draft: http://www.ietf.org/internet-drafts/draft-garcia-dime-aaa-uri-00.txt /Miguel Hannes Tschofenig wrote: > Hi all, > > we got the impression that it would be good to create a separate issue > tracker for RFC3588bis issues. You can find the issue tracker here: > > http://www.tschofenig.priv.at:8080/rfc3588bis > > We will also use it to collect text proposals. > > Some of the issues captured during the Diameter interop event > (see http://www.tschofenig.priv.at:8080/diameter-interop ) > will be moved to the new issue tracker. > > Ciao > Hannes & John > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jul 01 14:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwk93-0006Xk-NB; Sat, 01 Jul 2006 14:24:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwk92-0006Xf-C0 for dime@ietf.org; Sat, 01 Jul 2006 14:24:40 -0400 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 1Fwk90-0003IZ-DR for dime@ietf.org; Sat, 01 Jul 2006 14:24:40 -0400 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 k61IO3Eb001216; Sat, 1 Jul 2006 14:24:03 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44A6BDC3.70708@tari.toshiba.com> Date: Sat, 01 Jul 2006 14:24:03 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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, Theres probably a multitude of ways to achieve strict routing and most of them have more or less the same efficiency/performance. However, the proposals in the draft attempts to follow a well know, well understood mechanism that already exist in other protocols (IP SSR, SIP route-record etc.) which will hopefully lead to a clearer and more coherent way of doing things. It is also a bit more beneficial to separate route records into it's own set of avps to aid in debugging routing problems when using such scheme and it does not have to introduce duality in the purpose or meaning of existing avps such as origin-host which may or may not be used by the application to indicate the true endpoint of the message. many thanks, victor > While studying the mechanics of achiveing strict routing in > draft-tsou-dime-base-routing-ext, the following came to my mind: > > 1) Requests are sent by client regularly > 2) Stateless intermediaries just relay the message > 3) If an intermediary wants to stay in the path for a session, it does the > following with the messages for that session: > i- For the first answer, it saves the Origin-Host/Origin-Realm AVP values > in the message and replaces them with its own Host/Realm values. > ii- Subsequent requests received by this intermediary will have its > Host/Realm value in Destination-Host/Destination-Realm AVPs of the request. > They are replaced with the values stored in i-. > > Considering that proxies which want to stay on the path will be stateful, 3) > shouldn't be a problem. > > This is very similar to what is explained in the draft, except the state is > kept in proxies rather than in the message. > > Thanks, > Tolga > > > _______________________________________________ > 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 Sat Jul 01 15:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlG8-0003oK-7A; Sat, 01 Jul 2006 15:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwlG7-0003oE-Bn for dime@ietf.org; Sat, 01 Jul 2006 15:36:03 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwlG5-0007c6-Tz for dime@ietf.org; Sat, 01 Jul 2006 15:36:03 -0400 Received: (qmail invoked by alias); 01 Jul 2006 19:36:00 -0000 Received: from p549851A0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.81.160] by mail.gmx.net (mp001) with SMTP; 01 Jul 2006 21:36:00 +0200 X-Authenticated: #29516787 Message-ID: <44A6CE9F.4080404@gmx.net> Date: Sat, 01 Jul 2006 21:35:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Dime] RFC 3588bis Issue Tracker References: <44A5364A.8050700@gmx.net> <44A613F5.80307@nokia.com> In-Reply-To: <44A613F5.80307@nokia.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: 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 Miguel, I understood your mail as: "Please add one issue about AAA URIs to the tracker with a pointer to the indicated draft" That's fine. We don't need to compile everything from scratch. Ciao Hannes Miguel Garcia wrote: > Hi Hannes: > > My draft about the AAA URI could easily fit into this category. I don't > think I need to repeat what the issues are. Instead, I would recommend > folks to read the draft: > > http://www.ietf.org/internet-drafts/draft-garcia-dime-aaa-uri-00.txt > > /Miguel > > Hannes Tschofenig wrote: > >> Hi all, >> >> we got the impression that it would be good to create a separate issue >> tracker for RFC3588bis issues. You can find the issue tracker here: >> >> http://www.tschofenig.priv.at:8080/rfc3588bis >> >> We will also use it to collect text proposals. >> >> Some of the issues captured during the Diameter interop event >> (see http://www.tschofenig.priv.at:8080/diameter-interop ) >> will be moved to the new issue tracker. >> >> Ciao >> Hannes & John >> >> _______________________________________________ >> 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 Sun Jul 02 22:30:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxECG-0004hp-0m; Sun, 02 Jul 2006 22:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxECE-0004hk-FY for dime@ietf.org; Sun, 02 Jul 2006 22:29:58 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxECC-0008S9-MS for dime@ietf.org; Sun, 02 Jul 2006 22:29:58 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1T008MG2ZV9E@szxga01-in.huawei.com> for dime@ietf.org; Mon, 03 Jul 2006 10:31:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1T0088J2ZUDW@szxga01-in.huawei.com> for dime@ietf.org; Mon, 03 Jul 2006 10:31:07 +0800 (CST) Received: from z26452a ([10.70.145.55]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1T00KYZ3EZ4F@szxml04-in.huawei.com> for dime@ietf.org; Mon, 03 Jul 2006 10:40:11 +0800 (CST) Date: Mon, 03 Jul 2006 10:29:10 +0800 From: Tony Zhang Subject: Re: [Dime] yet another way of achieving strict routing To: Tolga Asveren , dime@ietf.org Message-id: <00a901c69e48$7799f450$3791460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: (1) Some Request in session are sent by server.so should each proxy repalce first request Origin-Host/Origin-Realm then maybe will achieve this. (2)if client send request to one realm,but another realm give answer,maybe will confusion. Thanks Tony ----- Original Message ----- From: "Tolga Asveren" To: Sent: Saturday, July 01, 2006 5:08 AM Subject: [Dime] yet another way of achieving strict routing > While studying the mechanics of achiveing strict routing in > draft-tsou-dime-base-routing-ext, the following came to my mind: > > 1) Requests are sent by client regularly > 2) Stateless intermediaries just relay the message > 3) If an intermediary wants to stay in the path for a session, it does the > following with the messages for that session: > i- For the first answer, it saves the Origin-Host/Origin-Realm AVP values > in the message and replaces them with its own Host/Realm values. > ii- Subsequent requests received by this intermediary will have its > Host/Realm value in Destination-Host/Destination-Realm AVPs of the request. > They are replaced with the values stored in i-. > > Considering that proxies which want to stay on the path will be stateful, 3) > shouldn't be a problem. > > This is very similar to what is explained in the draft, except the state is > kept in proxies rather than in the message. > > Thanks, > Tolga > > > _______________________________________________ > 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 Jul 03 01:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxH6S-0004Yo-5F; Mon, 03 Jul 2006 01:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxH6Q-0004Yj-5i for dime@ietf.org; Mon, 03 Jul 2006 01:36:10 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxH6N-0006S4-Kt for dime@ietf.org; Mon, 03 Jul 2006 01:36:10 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k635a5qB024321; Mon, 3 Jul 2006 08:36:05 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 08:36:05 +0300 Received: from [127.0.0.1] ([172.21.35.95]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 Jul 2006 08:36:05 +0300 Message-ID: <44A8ACC3.4040008@nokia.com> Date: Mon, 03 Jul 2006 08:36:03 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] RFC 3588bis Issue Tracker References: <44A5364A.8050700@gmx.net> <44A613F5.80307@nokia.com> <44A6CE9F.4080404@gmx.net> In-Reply-To: <44A6CE9F.4080404@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2006 05:36:05.0226 (UTC) FILETIME=[93EACCA0:01C69E62] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Yo got it correctly. Thanks. /Miguel Hannes Tschofenig wrote: > Hi Miguel, > > I understood your mail as: "Please add one issue about AAA URIs to the > tracker with a pointer to the indicated draft" > > That's fine. We don't need to compile everything from scratch. > > Ciao > Hannes > > Miguel Garcia wrote: >> Hi Hannes: >> >> My draft about the AAA URI could easily fit into this category. I >> don't think I need to repeat what the issues are. Instead, I would >> recommend folks to read the draft: >> >> http://www.ietf.org/internet-drafts/draft-garcia-dime-aaa-uri-00.txt >> >> /Miguel >> >> Hannes Tschofenig wrote: >> >>> Hi all, >>> >>> we got the impression that it would be good to create a separate >>> issue tracker for RFC3588bis issues. You can find the issue tracker >>> here: >>> >>> http://www.tschofenig.priv.at:8080/rfc3588bis >>> >>> We will also use it to collect text proposals. >>> >>> Some of the issues captured during the Diameter interop event >>> (see http://www.tschofenig.priv.at:8080/diameter-interop ) >>> will be moved to the new issue tracker. >>> >>> Ciao >>> Hannes & John >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >> > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 05 08:48:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6nh-0003FN-NT; Wed, 05 Jul 2006 08:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6ng-0003FI-EC for dime@ietf.org; Wed, 05 Jul 2006 08:48:16 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy6ne-0002dd-3O for dime@ietf.org; Wed, 05 Jul 2006 08:48:16 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id C524B3D07D; Wed, 5 Jul 2006 08:48:11 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k65Cm1CD004023; Wed, 5 Jul 2006 08:48:03 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" Subject: RE: [Dime] yet another way of achieving strict routing Date: Wed, 5 Jul 2006 08:24:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44A6BDC3.70708@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Victor, I agree that there may be different ways of achieving strict routing but I also believe any draft/RFC -at least after they are an official WG item - should give a realistic and balanced view of the issues addressed. IMHO, it is a good idea to list all of the meaningful solutions we can think of as a guideline for people. To me, any solution, which requires only local processing within boundaries of the existing procotol definition is very valuable as well. Just my two cents... Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Saturday, July 01, 2006 2:24 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Hi Tolga, > > Theres probably a multitude of ways to achieve strict routing and most > of them have more or less the same efficiency/performance. However, the > proposals in the draft attempts to follow a well know, well understood > mechanism that already exist in other protocols (IP SSR, SIP > route-record etc.) which will hopefully lead to a clearer and more > coherent way of doing things. It is also a bit more beneficial to > separate route records into it's own set of avps to aid in debugging > routing problems when using such scheme and it does not have to > introduce duality in the purpose or meaning of existing avps such as > origin-host which may or may not be used by the application to indicate > the true endpoint of the message. > > many thanks, > victor > > While studying the mechanics of achiveing strict routing in > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > 1) Requests are sent by client regularly > > 2) Stateless intermediaries just relay the message > > 3) If an intermediary wants to stay in the path for a session, > it does the > > following with the messages for that session: > > i- For the first answer, it saves the > Origin-Host/Origin-Realm AVP values > > in the message and replaces them with its own Host/Realm values. > > ii- Subsequent requests received by this intermediary will have its > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > the request. > > They are replaced with the values stored in i-. > > > > Considering that proxies which want to stay on the path will be > stateful, 3) > > shouldn't be a problem. > > > > This is very similar to what is explained in the draft, except > the state is > > kept in proxies rather than in the message. > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > 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 Jul 05 09:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7Mt-0005mx-SS; Wed, 05 Jul 2006 09:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7Ms-0005iT-Oq for dime@ietf.org; Wed, 05 Jul 2006 09:24:38 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7Mq-0007eA-15 for dime@ietf.org; Wed, 05 Jul 2006 09:24:38 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 090A55D063; Wed, 5 Jul 2006 09:24:34 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k65DOSa8007481; Wed, 5 Jul 2006 09:24:29 -0400 (EDT) From: "Tolga Asveren" To: "Tony Zhang" , Subject: RE: [Dime] yet another way of achieving strict routing Date: Wed, 5 Jul 2006 09:01:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <00a901c69e48$7799f450$3791460a@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Tony, > -----Original Message----- > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > Sent: Sunday, July 02, 2006 10:29 PM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Hi Tolga: > (1) Some Request in session are sent by server.so should each > proxy repalce first request Origin-Host/Origin-Realm then maybe > will achieve this. [TOLGA]That is really a good point. The solution is probably real proxying of the requests: Both Origin/Destination AVP information needs to be replaced with the identity of the proxy entity. In that model, from client point of view, it is the proxy which provides the service, and this is my understanding of a proxy in the generic sense. This would mean, proxies need to provide duplicate detection as well because it relies on Origin-Host AVP value, but that IMO is logical considering that proxy acts as a node providing a service. > (2)if client send request to one realm,but another realm give > answer,maybe will confusion. [TOLGA]That IMHO shouldn't be an issue from protocol mechanics point of view. > Thanks > Tony > ----- Original Message ----- > From: "Tolga Asveren" > To: > Sent: Saturday, July 01, 2006 5:08 AM > Subject: [Dime] yet another way of achieving strict routing > > > > While studying the mechanics of achiveing strict routing in > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > 1) Requests are sent by client regularly > > 2) Stateless intermediaries just relay the message > > 3) If an intermediary wants to stay in the path for a session, > it does the > > following with the messages for that session: > > i- For the first answer, it saves the Origin-Host/Origin-Realm > AVP values > > in the message and replaces them with its own Host/Realm values. > > ii- Subsequent requests received by this intermediary will have its > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > the request. > > They are replaced with the values stored in i-. > > > > Considering that proxies which want to stay on the path will be > stateful, 3) > > shouldn't be a problem. > > > > This is very similar to what is explained in the draft, except > the state is > > kept in proxies rather than in the message. > > > > Thanks, > > Tolga > > > > > > > > _______________________________________________ > > 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 Jul 05 10:38:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8WY-00088F-N4; Wed, 05 Jul 2006 10:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy8WX-00088A-Fg for dime@ietf.org; Wed, 05 Jul 2006 10:38:41 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8WW-0006vk-0p for dime@ietf.org; Wed, 05 Jul 2006 10:38:41 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7B68BD9421; Wed, 5 Jul 2006 10:38:35 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k65EcY86014946; Wed, 5 Jul 2006 10:38:34 -0400 (EDT) From: "Tolga Asveren" To: "Tony Zhang" , Subject: RE: [Dime] yet another way of achieving strict routing Date: Wed, 5 Jul 2006 10:15:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 One quick note on duplicat detection in the setup we are discussing: Proxy probably doesn't need to provide duplicate detection, as long as it generates a new request for each request it is proxying. the new request would have a new End-to-ed Identifier assigned by the proxy. Thanks, Tolga > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: Wednesday, July 05, 2006 9:01 AM > To: Tony Zhang; dime@ietf.org > Subject: RE: [Dime] yet another way of achieving strict routing > > > Hi Tony, > > > -----Original Message----- > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > Sent: Sunday, July 02, 2006 10:29 PM > > To: Tolga Asveren; dime@ietf.org > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > Hi Tolga: > > (1) Some Request in session are sent by server.so should each > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > will achieve this. > [TOLGA]That is really a good point. The solution is probably real proxying > of the requests: Both Origin/Destination AVP information needs to be > replaced with the identity of the proxy entity. In that model, from client > point of view, it is the proxy which provides the service, and this is my > understanding of a proxy in the generic sense. This would mean, > proxies need > to provide duplicate detection as well because it relies on > Origin-Host AVP > value, but that IMO is logical considering that proxy acts as a node > providing a service. > > (2)if client send request to one realm,but another realm give > > answer,maybe will confusion. > [TOLGA]That IMHO shouldn't be an issue from protocol mechanics point of > view. > > Thanks > > Tony > > ----- Original Message ----- > > From: "Tolga Asveren" > > To: > > Sent: Saturday, July 01, 2006 5:08 AM > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > While studying the mechanics of achiveing strict routing in > > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > > > 1) Requests are sent by client regularly > > > 2) Stateless intermediaries just relay the message > > > 3) If an intermediary wants to stay in the path for a session, > > it does the > > > following with the messages for that session: > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > AVP values > > > in the message and replaces them with its own Host/Realm values. > > > ii- Subsequent requests received by this intermediary will have its > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > the request. > > > They are replaced with the values stored in i-. > > > > > > Considering that proxies which want to stay on the path will be > > stateful, 3) > > > shouldn't be a problem. > > > > > > This is very similar to what is explained in the draft, except > > the state is > > > kept in proxies rather than in the message. > > > > > > Thanks, > > > Tolga > > > > > > > > > > > > > _______________________________________________ > > > 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 Wed Jul 05 11:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9Rd-0004PX-Ts; Wed, 05 Jul 2006 11:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9Rd-0004PS-Cw for dime@ietf.org; Wed, 05 Jul 2006 11:37:41 -0400 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 1Fy9Rb-0004Mn-Cz for dime@ietf.org; Wed, 05 Jul 2006 11:37:41 -0400 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 k65FFOlO013806; Wed, 5 Jul 2006 11:15:25 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44ABD78F.5040605@tari.toshiba.com> Date: Wed, 05 Jul 2006 11:15:27 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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, This is true and maybe we should have text that represents this especially in this case where there could be multiple application specific solutions. regards, victor > Hi Victor, > > I agree that there may be different ways of achieving strict routing but I > also believe any draft/RFC -at least after they are an official WG item - > should give a realistic and balanced view of the issues addressed. IMHO, it > is a good idea to list all of the meaningful solutions we can think of as a > guideline for people. To me, any solution, which requires only local > processing within boundaries of the existing procotol definition is very > valuable as well. > > Just my two cents... > > Thanks, > Tolga > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Saturday, July 01, 2006 2:24 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] yet another way of achieving strict routing >> >> >> Hi Tolga, >> >> Theres probably a multitude of ways to achieve strict routing and most >> of them have more or less the same efficiency/performance. However, the >> proposals in the draft attempts to follow a well know, well understood >> mechanism that already exist in other protocols (IP SSR, SIP >> route-record etc.) which will hopefully lead to a clearer and more >> coherent way of doing things. It is also a bit more beneficial to >> separate route records into it's own set of avps to aid in debugging >> routing problems when using such scheme and it does not have to >> introduce duality in the purpose or meaning of existing avps such as >> origin-host which may or may not be used by the application to indicate >> the true endpoint of the message. >> >> many thanks, >> victor >> >>> While studying the mechanics of achiveing strict routing in >>> draft-tsou-dime-base-routing-ext, the following came to my mind: >>> >>> 1) Requests are sent by client regularly >>> 2) Stateless intermediaries just relay the message >>> 3) If an intermediary wants to stay in the path for a session, >>> >> it does the >> >>> following with the messages for that session: >>> i- For the first answer, it saves the >>> >> Origin-Host/Origin-Realm AVP values >> >>> in the message and replaces them with its own Host/Realm values. >>> ii- Subsequent requests received by this intermediary will have its >>> Host/Realm value in Destination-Host/Destination-Realm AVPs of >>> >> the request. >> >>> They are replaced with the values stored in i-. >>> >>> Considering that proxies which want to stay on the path will be >>> >> stateful, 3) >> >>> shouldn't be a problem. >>> >>> This is very similar to what is explained in the draft, except >>> >> the state is >> >>> kept in proxies rather than in the message. >>> >>> Thanks, >>> Tolga >>> >>> >>> _______________________________________________ >>> 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 Jul 06 09:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyU94-0006OT-Vx; Thu, 06 Jul 2006 09:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyU93-0006OO-T4 for dime@ietf.org; Thu, 06 Jul 2006 09:43:53 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyU92-0005I5-3p for dime@ietf.org; Thu, 06 Jul 2006 09:43:53 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k66Dhm4n022279; Thu, 6 Jul 2006 22:43:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k66Dhmv4025493; Thu, 6 Jul 2006 22:43:48 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id YAA25459; Thu, 6 Jul 2006 22:43:48 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k66Dhlx2003485; Thu, 6 Jul 2006 22:43:47 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k66DhleR024946; Thu, 6 Jul 2006 22:43:47 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J1Z00D6QI4S2WM0@mail.po.toshiba.co.jp>; Thu, 06 Jul 2006 22:43:47 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FyU8h-0004To-9c; Thu, 06 Jul 2006 06:43:31 -0700 Date: Thu, 06 Jul 2006 09:43:31 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] yet another way of achieving strict routing In-reply-to: To: Tolga Asveren Message-id: <20060706134331.GA16420@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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 RFC 3588 has explicit text that prohibits replacing the End-to-End Identifier: "The End-to-End Identifier MUST NOT be modified by Diameter agents of any kind." Note: if the proxy replaces the End-to-End Identifier AVP, the ultimate receiver of the request message will not able to detect a duplicate request if the original request is routed via the proxy while a dup of the original request is not routed via the proxy. For the same reason, Origin-Host AVP should not be modified by the proxy. (RFC 3588 has explicit text that prohibits modification of Origin-Host AVP by relay agents in Section 6.3, but the text should be revised to prohibit modification of Origin-Host AVP by any Diameter agents of any kind.) Yoshihiro Ohba On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > One quick note on duplicat detection in the setup we are discussing: > Proxy probably doesn't need to provide duplicate detection, as long as it > generates a new request for each request it is proxying. the new request > would have a new End-to-ed Identifier assigned by the proxy. > > Thanks, > Tolga > > > -----Original Message----- > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > Sent: Wednesday, July 05, 2006 9:01 AM > > To: Tony Zhang; dime@ietf.org > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > Hi Tony, > > > > > -----Original Message----- > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > Sent: Sunday, July 02, 2006 10:29 PM > > > To: Tolga Asveren; dime@ietf.org > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > Hi Tolga: > > > (1) Some Request in session are sent by server.so should each > > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > > will achieve this. > > [TOLGA]That is really a good point. The solution is probably real proxying > > of the requests: Both Origin/Destination AVP information needs to be > > replaced with the identity of the proxy entity. In that model, from client > > point of view, it is the proxy which provides the service, and this is my > > understanding of a proxy in the generic sense. This would mean, > > proxies need > > to provide duplicate detection as well because it relies on > > Origin-Host AVP > > value, but that IMO is logical considering that proxy acts as a node > > providing a service. > > > (2)if client send request to one realm,but another realm give > > > answer,maybe will confusion. > > [TOLGA]That IMHO shouldn't be an issue from protocol mechanics point of > > view. > > > Thanks > > > Tony > > > ----- Original Message ----- > > > From: "Tolga Asveren" > > > To: > > > Sent: Saturday, July 01, 2006 5:08 AM > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > While studying the mechanics of achiveing strict routing in > > > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > > > > > 1) Requests are sent by client regularly > > > > 2) Stateless intermediaries just relay the message > > > > 3) If an intermediary wants to stay in the path for a session, > > > it does the > > > > following with the messages for that session: > > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > > AVP values > > > > in the message and replaces them with its own Host/Realm values. > > > > ii- Subsequent requests received by this intermediary will have its > > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > > the request. > > > > They are replaced with the values stored in i-. > > > > > > > > Considering that proxies which want to stay on the path will be > > > stateful, 3) > > > > shouldn't be a problem. > > > > > > > > This is very similar to what is explained in the draft, except > > > the state is > > > > kept in proxies rather than in the message. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 Jul 06 11:11:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVVi-0001Hc-CO; Thu, 06 Jul 2006 11:11:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyVVi-0001HX-0h for dime@ietf.org; Thu, 06 Jul 2006 11:11:22 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyVVh-0000TY-IY for dime@ietf.org; Thu, 06 Jul 2006 11:11:21 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 074544858C; Thu, 6 Jul 2006 11:11:21 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k66FBJfK025988; Thu, 6 Jul 2006 11:11:19 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Thu, 6 Jul 2006 10:48:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060706134331.GA16420@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Yoshihiro, If the proxy creates a corresponding but new request for a request it is proxying, I don't see why there should be a problem from duplicate detection point of view. In that case, there are two Diameter signaling relationships, one between the client and the proxy and the other one between the proxy and the server, i.e. client sees proxy as server and server sees proxy as client. OTOH, one could argue whether that type of behavior is overlapping with the definition of proxy in RFC3588, but I believe one can mix and match any type of functionality in any node as long as interoperability is not broken. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, July 06, 2006 9:44 AM > To: Tolga Asveren > Cc: Tony Zhang; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > Identifier: > > "The End-to-End Identifier MUST NOT be modified by Diameter agents > of any kind." > > Note: if the proxy replaces the End-to-End Identifier AVP, the > ultimate receiver of the request message will not able to detect a > duplicate request if the original request is routed via the proxy > while a dup of the original request is not routed via the proxy. For > the same reason, Origin-Host AVP should not be modified by the proxy. > (RFC 3588 has explicit text that prohibits modification of Origin-Host > AVP by relay agents in Section 6.3, but the text should be revised to > prohibit modification of Origin-Host AVP by any Diameter agents of any > kind.) > > Yoshihiro Ohba > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > One quick note on duplicat detection in the setup we are discussing: > > Proxy probably doesn't need to provide duplicate detection, as > long as it > > generates a new request for each request it is proxying. the new request > > would have a new End-to-ed Identifier assigned by the proxy. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > To: Tony Zhang; dime@ietf.org > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > Hi Tony, > > > > > > > -----Original Message----- > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > To: Tolga Asveren; dime@ietf.org > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > Hi Tolga: > > > > (1) Some Request in session are sent by server.so should each > > > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > > > will achieve this. > > > [TOLGA]That is really a good point. The solution is probably > real proxying > > > of the requests: Both Origin/Destination AVP information needs to be > > > replaced with the identity of the proxy entity. In that > model, from client > > > point of view, it is the proxy which provides the service, > and this is my > > > understanding of a proxy in the generic sense. This would mean, > > > proxies need > > > to provide duplicate detection as well because it relies on > > > Origin-Host AVP > > > value, but that IMO is logical considering that proxy acts as a node > > > providing a service. > > > > (2)if client send request to one realm,but another realm give > > > > answer,maybe will confusion. > > > [TOLGA]That IMHO shouldn't be an issue from protocol > mechanics point of > > > view. > > > > Thanks > > > > Tony > > > > ----- Original Message ----- > > > > From: "Tolga Asveren" > > > > To: > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > While studying the mechanics of achiveing strict routing in > > > > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > > > > > > > 1) Requests are sent by client regularly > > > > > 2) Stateless intermediaries just relay the message > > > > > 3) If an intermediary wants to stay in the path for a session, > > > > it does the > > > > > following with the messages for that session: > > > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > > > AVP values > > > > > in the message and replaces them with its own Host/Realm values. > > > > > ii- Subsequent requests received by this intermediary > will have its > > > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > > > the request. > > > > > They are replaced with the values stored in i-. > > > > > > > > > > Considering that proxies which want to stay on the path will be > > > > stateful, 3) > > > > > shouldn't be a problem. > > > > > > > > > > This is very similar to what is explained in the draft, except > > > > the state is > > > > > kept in proxies rather than in the message. > > > > > > > > > > Thanks, > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 Jul 06 12:17:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWXG-0007Ib-LV; Thu, 06 Jul 2006 12:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWXF-0007IM-6C for dime@ietf.org; Thu, 06 Jul 2006 12:17:01 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWXE-0002sm-Bp for dime@ietf.org; Thu, 06 Jul 2006 12:17:01 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k66GGuZH014578; Fri, 7 Jul 2006 01:16:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k66GGvo2017940; Fri, 7 Jul 2006 01:16:57 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id BAA17904; Fri, 7 Jul 2006 01:16:57 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k66GGtZN013953; Fri, 7 Jul 2006 01:16:55 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k66GGtiD017170; Fri, 7 Jul 2006 01:16:55 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J1Z001JQP81F930@mail.po.toshiba.co.jp>; Fri, 07 Jul 2006 01:16:55 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FyWWs-0001y4-Oo; Thu, 06 Jul 2006 09:16:38 -0700 Date: Thu, 06 Jul 2006 12:16:37 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] yet another way of achieving strict routing In-reply-to: To: Tolga Asveren Message-id: <20060706161636.GI16420@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060706134331.GA16420@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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 Allowing a Diameter node to creates a request with modifying End-to-End Identifier and Origin-Host AVP can break interoperability, because the server cannot distinguish the original request and the modified request. As a result, the server will process the two requests differently and generate two different answers as oppose to the original requester's expectation that only one request should be processed by a given server and that no multiple non-duplicated answers are received for the same request. Yoshihiro Ohba On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > Hi Yoshihiro, > > If the proxy creates a corresponding but new request for a request it is > proxying, I don't see why there should be a problem from duplicate detection > point of view. In that case, there are two Diameter signaling relationships, > one between the client and the proxy and the other one between the proxy and > the server, i.e. client sees proxy as server and server sees proxy as > client. > > OTOH, one could argue whether that type of behavior is overlapping with the > definition of proxy in RFC3588, but I believe one can mix and match any type > of functionality in any node as long as interoperability is not broken. > > Thanks, > Tolga > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, July 06, 2006 9:44 AM > > To: Tolga Asveren > > Cc: Tony Zhang; dime@ietf.org > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > > Identifier: > > > > "The End-to-End Identifier MUST NOT be modified by Diameter agents > > of any kind." > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > ultimate receiver of the request message will not able to detect a > > duplicate request if the original request is routed via the proxy > > while a dup of the original request is not routed via the proxy. For > > the same reason, Origin-Host AVP should not be modified by the proxy. > > (RFC 3588 has explicit text that prohibits modification of Origin-Host > > AVP by relay agents in Section 6.3, but the text should be revised to > > prohibit modification of Origin-Host AVP by any Diameter agents of any > > kind.) > > > > Yoshihiro Ohba > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > One quick note on duplicat detection in the setup we are discussing: > > > Proxy probably doesn't need to provide duplicate detection, as > > long as it > > > generates a new request for each request it is proxying. the new request > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > To: Tony Zhang; dime@ietf.org > > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > Hi Tony, > > > > > > > > > -----Original Message----- > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > To: Tolga Asveren; dime@ietf.org > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > Hi Tolga: > > > > > (1) Some Request in session are sent by server.so should each > > > > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > > > > will achieve this. > > > > [TOLGA]That is really a good point. The solution is probably > > real proxying > > > > of the requests: Both Origin/Destination AVP information needs to be > > > > replaced with the identity of the proxy entity. In that > > model, from client > > > > point of view, it is the proxy which provides the service, > > and this is my > > > > understanding of a proxy in the generic sense. This would mean, > > > > proxies need > > > > to provide duplicate detection as well because it relies on > > > > Origin-Host AVP > > > > value, but that IMO is logical considering that proxy acts as a node > > > > providing a service. > > > > > (2)if client send request to one realm,but another realm give > > > > > answer,maybe will confusion. > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > mechanics point of > > > > view. > > > > > Thanks > > > > > Tony > > > > > ----- Original Message ----- > > > > > From: "Tolga Asveren" > > > > > To: > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict routing in > > > > > > draft-tsou-dime-base-routing-ext, the following came to my mind: > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > 2) Stateless intermediaries just relay the message > > > > > > 3) If an intermediary wants to stay in the path for a session, > > > > > it does the > > > > > > following with the messages for that session: > > > > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > > > > AVP values > > > > > > in the message and replaces them with its own Host/Realm values. > > > > > > ii- Subsequent requests received by this intermediary > > will have its > > > > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > > > > the request. > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > Considering that proxies which want to stay on the path will be > > > > > stateful, 3) > > > > > > shouldn't be a problem. > > > > > > > > > > > > This is very similar to what is explained in the draft, except > > > > > the state is > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 Jul 06 12:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWeT-0007bX-6R; Thu, 06 Jul 2006 12:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyWeR-0007bS-Lv for dime@ietf.org; Thu, 06 Jul 2006 12:24:27 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyWeR-00035M-5c for dime@ietf.org; Thu, 06 Jul 2006 12:24:27 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 95CC5A85A5; Thu, 6 Jul 2006 12:24:26 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k66GOPW5003662; Thu, 6 Jul 2006 12:24:25 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Thu, 6 Jul 2006 12:01:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060706161636.GI16420@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 If the intermediary node uses the same End-to-End identifier for the original and retransmission request, this shouldn't be a problem. Server would receive two requests with the same Origin-Host and End-to-End values and could detect the duplicate. > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, July 06, 2006 12:17 PM > To: Tolga Asveren > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Allowing a Diameter node to creates a request with modifying > End-to-End Identifier and Origin-Host AVP can break interoperability, > because the server cannot distinguish the original request and the > modified request. As a result, the server will process the two > requests differently and generate two different answers as oppose to > the original requester's expectation that only one request should be > processed by a given server and that no multiple non-duplicated > answers are received for the same request. > > Yoshihiro Ohba > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > > Hi Yoshihiro, > > > > If the proxy creates a corresponding but new request for a request it is > > proxying, I don't see why there should be a problem from > duplicate detection > > point of view. In that case, there are two Diameter signaling > relationships, > > one between the client and the proxy and the other one between > the proxy and > > the server, i.e. client sees proxy as server and server sees proxy as > > client. > > > > OTOH, one could argue whether that type of behavior is > overlapping with the > > definition of proxy in RFC3588, but I believe one can mix and > match any type > > of functionality in any node as long as interoperability is not broken. > > > > Thanks, > > Tolga > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, July 06, 2006 9:44 AM > > > To: Tolga Asveren > > > Cc: Tony Zhang; dime@ietf.org > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > > > Identifier: > > > > > > "The End-to-End Identifier MUST NOT be modified by Diameter agents > > > of any kind." > > > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > > ultimate receiver of the request message will not able to detect a > > > duplicate request if the original request is routed via the proxy > > > while a dup of the original request is not routed via the proxy. For > > > the same reason, Origin-Host AVP should not be modified by the proxy. > > > (RFC 3588 has explicit text that prohibits modification of Origin-Host > > > AVP by relay agents in Section 6.3, but the text should be revised to > > > prohibit modification of Origin-Host AVP by any Diameter agents of any > > > kind.) > > > > > > Yoshihiro Ohba > > > > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > > One quick note on duplicat detection in the setup we are discussing: > > > > Proxy probably doesn't need to provide duplicate detection, as > > > long as it > > > > generates a new request for each request it is proxying. > the new request > > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > To: Tony Zhang; dime@ietf.org > > > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > -----Original Message----- > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > Hi Tolga: > > > > > > (1) Some Request in session are sent by server.so should each > > > > > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > > > > > will achieve this. > > > > > [TOLGA]That is really a good point. The solution is probably > > > real proxying > > > > > of the requests: Both Origin/Destination AVP information > needs to be > > > > > replaced with the identity of the proxy entity. In that > > > model, from client > > > > > point of view, it is the proxy which provides the service, > > > and this is my > > > > > understanding of a proxy in the generic sense. This would mean, > > > > > proxies need > > > > > to provide duplicate detection as well because it relies on > > > > > Origin-Host AVP > > > > > value, but that IMO is logical considering that proxy > acts as a node > > > > > providing a service. > > > > > > (2)if client send request to one realm,but another realm give > > > > > > answer,maybe will confusion. > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > > mechanics point of > > > > > view. > > > > > > Thanks > > > > > > Tony > > > > > > ----- Original Message ----- > > > > > > From: "Tolga Asveren" > > > > > > To: > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict routing in > > > > > > > draft-tsou-dime-base-routing-ext, the following came > to my mind: > > > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > > 2) Stateless intermediaries just relay the message > > > > > > > 3) If an intermediary wants to stay in the path for a session, > > > > > > it does the > > > > > > > following with the messages for that session: > > > > > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > > > > > AVP values > > > > > > > in the message and replaces them with its own > Host/Realm values. > > > > > > > ii- Subsequent requests received by this intermediary > > > will have its > > > > > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > > > > > the request. > > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > > > Considering that proxies which want to stay on the > path will be > > > > > > stateful, 3) > > > > > > > shouldn't be a problem. > > > > > > > > > > > > > > This is very similar to what is explained in the draft, except > > > > > > the state is > > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > > > Thanks, > > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Jul 06 13:59:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY8E-0004eC-Ar; Thu, 06 Jul 2006 13:59:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyY8D-0004cm-Ar for dime@ietf.org; Thu, 06 Jul 2006 13:59:17 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyY8B-0000WQ-F1 for dime@ietf.org; Thu, 06 Jul 2006 13:59:17 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k66HxBUQ028700; Fri, 7 Jul 2006 02:59:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k66HxCk4006785; Fri, 7 Jul 2006 02:59:12 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id CAA06772; Fri, 7 Jul 2006 02:59:12 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k66HxAxt002306; Fri, 7 Jul 2006 02:59:10 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k66HxAjH014611; Fri, 7 Jul 2006 02:59:10 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J1Z001C7TY0F950@mail.po.toshiba.co.jp>; Fri, 07 Jul 2006 02:59:10 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FyY7Z-0002FN-3P; Thu, 06 Jul 2006 10:58:37 -0700 Date: Thu, 06 Jul 2006 13:58:36 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] yet another way of achieving strict routing In-reply-to: To: Tolga Asveren Message-id: <20060706175836.GK16420@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060706161636.GI16420@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > If the intermediary node uses the same End-to-End identifier for the > original and retransmission request, this shouldn't be a problem. Server > would receive two requests with the same Origin-Host and End-to-End values > and could detect the duplicate. You are assuming that the two requests go through the same intermediary, which is not always true. Retransmission can also happen at the original sender. +-----B----+ / \ A D \ / +-----C----+ Assume that the orignial request is forwarded A->B->D. If failover happens at A, A may retransmit the request to a different path, say A->C->D. If B modifies the Origin-Host and End-to-End values of the original request, the original and retransmitted requests will have different Origin-Host or End-to-End values. This is the problem I was mentioning. Yoshihiro Ohba > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, July 06, 2006 12:17 PM > > To: Tolga Asveren > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > Allowing a Diameter node to creates a request with modifying > > End-to-End Identifier and Origin-Host AVP can break interoperability, > > because the server cannot distinguish the original request and the > > modified request. As a result, the server will process the two > > requests differently and generate two different answers as oppose to > > the original requester's expectation that only one request should be > > processed by a given server and that no multiple non-duplicated > > answers are received for the same request. > > > > Yoshihiro Ohba > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > > > Hi Yoshihiro, > > > > > > If the proxy creates a corresponding but new request for a request it is > > > proxying, I don't see why there should be a problem from > > duplicate detection > > > point of view. In that case, there are two Diameter signaling > > relationships, > > > one between the client and the proxy and the other one between > > the proxy and > > > the server, i.e. client sees proxy as server and server sees proxy as > > > client. > > > > > > OTOH, one could argue whether that type of behavior is > > overlapping with the > > > definition of proxy in RFC3588, but I believe one can mix and > > match any type > > > of functionality in any node as long as interoperability is not broken. > > > > > > Thanks, > > > Tolga > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > To: Tolga Asveren > > > > Cc: Tony Zhang; dime@ietf.org > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > > > > Identifier: > > > > > > > > "The End-to-End Identifier MUST NOT be modified by Diameter agents > > > > of any kind." > > > > > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > > > ultimate receiver of the request message will not able to detect a > > > > duplicate request if the original request is routed via the proxy > > > > while a dup of the original request is not routed via the proxy. For > > > > the same reason, Origin-Host AVP should not be modified by the proxy. > > > > (RFC 3588 has explicit text that prohibits modification of Origin-Host > > > > AVP by relay agents in Section 6.3, but the text should be revised to > > > > prohibit modification of Origin-Host AVP by any Diameter agents of any > > > > kind.) > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > > > One quick note on duplicat detection in the setup we are discussing: > > > > > Proxy probably doesn't need to provide duplicate detection, as > > > > long as it > > > > > generates a new request for each request it is proxying. > > the new request > > > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > > > > > Thanks, > > > > > Tolga > > > > > > > > > > > -----Original Message----- > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > > To: Tony Zhang; dime@ietf.org > > > > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > > > > Hi Tolga: > > > > > > > (1) Some Request in session are sent by server.so should each > > > > > > > proxy repalce first request Origin-Host/Origin-Realm then maybe > > > > > > > will achieve this. > > > > > > [TOLGA]That is really a good point. The solution is probably > > > > real proxying > > > > > > of the requests: Both Origin/Destination AVP information > > needs to be > > > > > > replaced with the identity of the proxy entity. In that > > > > model, from client > > > > > > point of view, it is the proxy which provides the service, > > > > and this is my > > > > > > understanding of a proxy in the generic sense. This would mean, > > > > > > proxies need > > > > > > to provide duplicate detection as well because it relies on > > > > > > Origin-Host AVP > > > > > > value, but that IMO is logical considering that proxy > > acts as a node > > > > > > providing a service. > > > > > > > (2)if client send request to one realm,but another realm give > > > > > > > answer,maybe will confusion. > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > > > mechanics point of > > > > > > view. > > > > > > > Thanks > > > > > > > Tony > > > > > > > ----- Original Message ----- > > > > > > > From: "Tolga Asveren" > > > > > > > To: > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict routing in > > > > > > > > draft-tsou-dime-base-routing-ext, the following came > > to my mind: > > > > > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > > > 2) Stateless intermediaries just relay the message > > > > > > > > 3) If an intermediary wants to stay in the path for a session, > > > > > > > it does the > > > > > > > > following with the messages for that session: > > > > > > > > i- For the first answer, it saves the Origin-Host/Origin-Realm > > > > > > > AVP values > > > > > > > > in the message and replaces them with its own > > Host/Realm values. > > > > > > > > ii- Subsequent requests received by this intermediary > > > > will have its > > > > > > > > Host/Realm value in Destination-Host/Destination-Realm AVPs of > > > > > > > the request. > > > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > > > > > Considering that proxies which want to stay on the > > path will be > > > > > > > stateful, 3) > > > > > > > > shouldn't be a problem. > > > > > > > > > > > > > > > > This is very similar to what is explained in the draft, except > > > > > > > the state is > > > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > 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 Jul 06 14:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYRQ-0006La-7i; Thu, 06 Jul 2006 14:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyYRP-0006LV-Bz for dime@ietf.org; Thu, 06 Jul 2006 14:19:07 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyYRO-0001d8-FE for dime@ietf.org; Thu, 06 Jul 2006 14:19:07 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 30F1FB4968; Thu, 6 Jul 2006 14:19:05 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k66IJ2wo013998; Thu, 6 Jul 2006 14:19:02 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Thu, 6 Jul 2006 13:55:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060706175836.GK16420@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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 O.K., now I got what you mean. And yes, this will be a problem unless B and C work in a synchronized way, where they share state. I think, this they need to do anyhow, because they keep some application level state, otherwise they wouldn't want to stay on the path. Basically, in the model I described, B and C act as endnodes. If there are intermediaries, which don't share state, I would expect them to abort the session after a failover -when they receive messages for an unknown session-, because they can't perform their application level processing regarding that session. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, July 06, 2006 1:59 PM > To: Tolga Asveren > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > > If the intermediary node uses the same End-to-End identifier for the > > original and retransmission request, this shouldn't be a problem. Server > > would receive two requests with the same Origin-Host and > End-to-End values > > and could detect the duplicate. > > You are assuming that the two requests go through the same > intermediary, which is not always true. Retransmission can also > happen at the original sender. > > +-----B----+ > / \ > A D > \ / > +-----C----+ > > Assume that the orignial request is forwarded A->B->D. > > If failover happens at A, A may retransmit the request to a different > path, say A->C->D. > > If B modifies the Origin-Host and End-to-End values of the original > request, the original and retransmitted requests will have different > Origin-Host or End-to-End values. This is the problem I was > mentioning. > > Yoshihiro Ohba > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, July 06, 2006 12:17 PM > > > To: Tolga Asveren > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > Allowing a Diameter node to creates a request with modifying > > > End-to-End Identifier and Origin-Host AVP can break interoperability, > > > because the server cannot distinguish the original request and the > > > modified request. As a result, the server will process the two > > > requests differently and generate two different answers as oppose to > > > the original requester's expectation that only one request should be > > > processed by a given server and that no multiple non-duplicated > > > answers are received for the same request. > > > > > > Yoshihiro Ohba > > > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > > > > Hi Yoshihiro, > > > > > > > > If the proxy creates a corresponding but new request for a > request it is > > > > proxying, I don't see why there should be a problem from > > > duplicate detection > > > > point of view. In that case, there are two Diameter signaling > > > relationships, > > > > one between the client and the proxy and the other one between > > > the proxy and > > > > the server, i.e. client sees proxy as server and server > sees proxy as > > > > client. > > > > > > > > OTOH, one could argue whether that type of behavior is > > > overlapping with the > > > > definition of proxy in RFC3588, but I believe one can mix and > > > match any type > > > > of functionality in any node as long as interoperability is > not broken. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > > To: Tolga Asveren > > > > > Cc: Tony Zhang; dime@ietf.org > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > > > > > Identifier: > > > > > > > > > > "The End-to-End Identifier MUST NOT be modified by > Diameter agents > > > > > of any kind." > > > > > > > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > > > > ultimate receiver of the request message will not able to detect a > > > > > duplicate request if the original request is routed via the proxy > > > > > while a dup of the original request is not routed via the > proxy. For > > > > > the same reason, Origin-Host AVP should not be modified > by the proxy. > > > > > (RFC 3588 has explicit text that prohibits modification > of Origin-Host > > > > > AVP by relay agents in Section 6.3, but the text should > be revised to > > > > > prohibit modification of Origin-Host AVP by any Diameter > agents of any > > > > > kind.) > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > > > > One quick note on duplicat detection in the setup we > are discussing: > > > > > > Proxy probably doesn't need to provide duplicate detection, as > > > > > long as it > > > > > > generates a new request for each request it is proxying. > > > the new request > > > > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > > > To: Tony Zhang; dime@ietf.org > > > > > > > Subject: RE: [Dime] yet another way of achieving > strict routing > > > > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > > > > Subject: Re: [Dime] yet another way of achieving > strict routing > > > > > > > > > > > > > > > > > > > > > > > > Hi Tolga: > > > > > > > > (1) Some Request in session are sent by > server.so should each > > > > > > > > proxy repalce first request > Origin-Host/Origin-Realm then maybe > > > > > > > > will achieve this. > > > > > > > [TOLGA]That is really a good point. The solution is probably > > > > > real proxying > > > > > > > of the requests: Both Origin/Destination AVP information > > > needs to be > > > > > > > replaced with the identity of the proxy entity. In that > > > > > model, from client > > > > > > > point of view, it is the proxy which provides the service, > > > > > and this is my > > > > > > > understanding of a proxy in the generic sense. This > would mean, > > > > > > > proxies need > > > > > > > to provide duplicate detection as well because it relies on > > > > > > > Origin-Host AVP > > > > > > > value, but that IMO is logical considering that proxy > > > acts as a node > > > > > > > providing a service. > > > > > > > > (2)if client send request to one realm,but > another realm give > > > > > > > > answer,maybe will confusion. > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > > > > mechanics point of > > > > > > > view. > > > > > > > > Thanks > > > > > > > > Tony > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Tolga Asveren" > > > > > > > > To: > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict > routing in > > > > > > > > > draft-tsou-dime-base-routing-ext, the following came > > > to my mind: > > > > > > > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > > > > 2) Stateless intermediaries just relay the message > > > > > > > > > 3) If an intermediary wants to stay in the path > for a session, > > > > > > > > it does the > > > > > > > > > following with the messages for that session: > > > > > > > > > i- For the first answer, it saves the > Origin-Host/Origin-Realm > > > > > > > > AVP values > > > > > > > > > in the message and replaces them with its own > > > Host/Realm values. > > > > > > > > > ii- Subsequent requests received by this intermediary > > > > > will have its > > > > > > > > > Host/Realm value in > Destination-Host/Destination-Realm AVPs of > > > > > > > > the request. > > > > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > > > > > > > Considering that proxies which want to stay on the > > > path will be > > > > > > > > stateful, 3) > > > > > > > > > shouldn't be a problem. > > > > > > > > > > > > > > > > > > This is very similar to what is explained in the > draft, except > > > > > > > > the state is > > > > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > 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 Jul 06 16:02:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fya3a-0001Wj-TE; Thu, 06 Jul 2006 16:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fya3Z-0001We-L5 for dime@ietf.org; Thu, 06 Jul 2006 16:02:37 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fya3Y-00027C-J2 for dime@ietf.org; Thu, 06 Jul 2006 16:02:37 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k66K2UrX028149; Fri, 7 Jul 2006 05:02:30 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k66K41kn024589; Fri, 7 Jul 2006 05:04:01 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id FAA24585; Fri, 7 Jul 2006 05:04:01 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k66K2Tqx000271; Fri, 7 Jul 2006 05:02:29 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k66K2SU3012167; Fri, 7 Jul 2006 05:02:28 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J1Z001WHZNZF970@mail.po.toshiba.co.jp>; Fri, 07 Jul 2006 05:02:28 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fya3H-0002bT-2e; Thu, 06 Jul 2006 13:02:19 -0700 Date: Thu, 06 Jul 2006 16:02:18 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] yet another way of achieving strict routing In-reply-to: To: Tolga Asveren Message-id: <20060706200218.GN16420@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060706175836.GK16420@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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, Is the sceanario you described is an application layer gateway for (like SIP B2BUA)? If so, we should not mix it up with a proxy and I believe it is orthogonal to the strict routing issue. Yoshihiro Ohba On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > O.K., now I got what you mean. And yes, this will be a problem unless B and > C work in a synchronized way, where they share state. I think, this they > need to do anyhow, because they keep some application level state, otherwise > they wouldn't want to stay on the path. Basically, in the model I described, > B and C act as endnodes. If there are intermediaries, which don't share > state, I would expect them to abort the session after a failover -when they > receive messages for an unknown session-, because they can't perform their > application level processing regarding that session. > > Thanks, > Tolga > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, July 06, 2006 1:59 PM > > To: Tolga Asveren > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > > > If the intermediary node uses the same End-to-End identifier for the > > > original and retransmission request, this shouldn't be a problem. Server > > > would receive two requests with the same Origin-Host and > > End-to-End values > > > and could detect the duplicate. > > > > You are assuming that the two requests go through the same > > intermediary, which is not always true. Retransmission can also > > happen at the original sender. > > > > +-----B----+ > > / \ > > A D > > \ / > > +-----C----+ > > > > Assume that the orignial request is forwarded A->B->D. > > > > If failover happens at A, A may retransmit the request to a different > > path, say A->C->D. > > > > If B modifies the Origin-Host and End-to-End values of the original > > request, the original and retransmitted requests will have different > > Origin-Host or End-to-End values. This is the problem I was > > mentioning. > > > > Yoshihiro Ohba > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Thursday, July 06, 2006 12:17 PM > > > > To: Tolga Asveren > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > Allowing a Diameter node to creates a request with modifying > > > > End-to-End Identifier and Origin-Host AVP can break interoperability, > > > > because the server cannot distinguish the original request and the > > > > modified request. As a result, the server will process the two > > > > requests differently and generate two different answers as oppose to > > > > the original requester's expectation that only one request should be > > > > processed by a given server and that no multiple non-duplicated > > > > answers are received for the same request. > > > > > > > > Yoshihiro Ohba > > > > > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > > > > > Hi Yoshihiro, > > > > > > > > > > If the proxy creates a corresponding but new request for a > > request it is > > > > > proxying, I don't see why there should be a problem from > > > > duplicate detection > > > > > point of view. In that case, there are two Diameter signaling > > > > relationships, > > > > > one between the client and the proxy and the other one between > > > > the proxy and > > > > > the server, i.e. client sees proxy as server and server > > sees proxy as > > > > > client. > > > > > > > > > > OTOH, one could argue whether that type of behavior is > > > > overlapping with the > > > > > definition of proxy in RFC3588, but I believe one can mix and > > > > match any type > > > > > of functionality in any node as long as interoperability is > > not broken. > > > > > > > > > > Thanks, > > > > > Tolga > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > > > To: Tolga Asveren > > > > > > Cc: Tony Zhang; dime@ietf.org > > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > RFC 3588 has explicit text that prohibits replacing the End-to-End > > > > > > Identifier: > > > > > > > > > > > > "The End-to-End Identifier MUST NOT be modified by > > Diameter agents > > > > > > of any kind." > > > > > > > > > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > > > > > ultimate receiver of the request message will not able to detect a > > > > > > duplicate request if the original request is routed via the proxy > > > > > > while a dup of the original request is not routed via the > > proxy. For > > > > > > the same reason, Origin-Host AVP should not be modified > > by the proxy. > > > > > > (RFC 3588 has explicit text that prohibits modification > > of Origin-Host > > > > > > AVP by relay agents in Section 6.3, but the text should > > be revised to > > > > > > prohibit modification of Origin-Host AVP by any Diameter > > agents of any > > > > > > kind.) > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > > > > > One quick note on duplicat detection in the setup we > > are discussing: > > > > > > > Proxy probably doesn't need to provide duplicate detection, as > > > > > > long as it > > > > > > > generates a new request for each request it is proxying. > > > > the new request > > > > > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > > > > > > > > > Thanks, > > > > > > > Tolga > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > > > > To: Tony Zhang; dime@ietf.org > > > > > > > > Subject: RE: [Dime] yet another way of achieving > > strict routing > > > > > > > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > > > > > Subject: Re: [Dime] yet another way of achieving > > strict routing > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tolga: > > > > > > > > > (1) Some Request in session are sent by > > server.so should each > > > > > > > > > proxy repalce first request > > Origin-Host/Origin-Realm then maybe > > > > > > > > > will achieve this. > > > > > > > > [TOLGA]That is really a good point. The solution is probably > > > > > > real proxying > > > > > > > > of the requests: Both Origin/Destination AVP information > > > > needs to be > > > > > > > > replaced with the identity of the proxy entity. In that > > > > > > model, from client > > > > > > > > point of view, it is the proxy which provides the service, > > > > > > and this is my > > > > > > > > understanding of a proxy in the generic sense. This > > would mean, > > > > > > > > proxies need > > > > > > > > to provide duplicate detection as well because it relies on > > > > > > > > Origin-Host AVP > > > > > > > > value, but that IMO is logical considering that proxy > > > > acts as a node > > > > > > > > providing a service. > > > > > > > > > (2)if client send request to one realm,but > > another realm give > > > > > > > > > answer,maybe will confusion. > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > > > > > mechanics point of > > > > > > > > view. > > > > > > > > > Thanks > > > > > > > > > Tony > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Tolga Asveren" > > > > > > > > > To: > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > > > > > Subject: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict > > routing in > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following came > > > > to my mind: > > > > > > > > > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > > > > > 2) Stateless intermediaries just relay the message > > > > > > > > > > 3) If an intermediary wants to stay in the path > > for a session, > > > > > > > > > it does the > > > > > > > > > > following with the messages for that session: > > > > > > > > > > i- For the first answer, it saves the > > Origin-Host/Origin-Realm > > > > > > > > > AVP values > > > > > > > > > > in the message and replaces them with its own > > > > Host/Realm values. > > > > > > > > > > ii- Subsequent requests received by this intermediary > > > > > > will have its > > > > > > > > > > Host/Realm value in > > Destination-Host/Destination-Realm AVPs of > > > > > > > > > the request. > > > > > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > > > > > > > > > Considering that proxies which want to stay on the > > > > path will be > > > > > > > > > stateful, 3) > > > > > > > > > > shouldn't be a problem. > > > > > > > > > > > > > > > > > > > > This is very similar to what is explained in the > > draft, except > > > > > > > > > the state is > > > > > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 Jul 06 16:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaLt-0000vO-HQ; Thu, 06 Jul 2006 16:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyaLr-0000vJ-TO for dime@ietf.org; Thu, 06 Jul 2006 16:21:31 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyaLr-0007Up-9a for dime@ietf.org; Thu, 06 Jul 2006 16:21:31 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D865C1C1CC; Thu, 6 Jul 2006 16:21:30 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k66KLPIa025029; Thu, 6 Jul 2006 16:21:26 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Thu, 6 Jul 2006 15:58:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060706200218.GN16420@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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 Yoshihiro, Yes, it is analogical to a SIP B2BUA. Actually in my world of ideas this is the definition of a proxy in the generic sense -I am not speaking of SIP/Diameter proxies-: A proxy is an entity, which acts on behalf of another entity. Proxy as defined in SIP -or as defined in Diameter- is more a glorified relay node, but I agree with you that the node I describe is not the "proxy" defined in RFC3588. (Diameter proxy is more similar to the concept of proxy in my mind because it has more authority in terms of changing the contents of the message, so I probably would classify it somewhere between relay and proxy) IMHO, this is not orthogonal to strict routing issue because it is one way of dealing with scenarios presented as the reason for strict routing. Actually, if one considers the application logic running on such nodes, it seems to me a reasonable solution but picking one approach over another one is obviously an implementation decision. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, July 06, 2006 4:02 PM > To: Tolga Asveren > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Hi Tolga, > > Is the sceanario you described is an application layer gateway for > (like SIP B2BUA)? If so, we should not mix it up with a proxy and I > believe it is orthogonal to the strict routing issue. > > Yoshihiro Ohba > > > On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > > O.K., now I got what you mean. And yes, this will be a problem > unless B and > > C work in a synchronized way, where they share state. I think, this they > > need to do anyhow, because they keep some application level > state, otherwise > > they wouldn't want to stay on the path. Basically, in the model > I described, > > B and C act as endnodes. If there are intermediaries, which don't share > > state, I would expect them to abort the session after a > failover -when they > > receive messages for an unknown session-, because they can't > perform their > > application level processing regarding that session. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, July 06, 2006 1:59 PM > > > To: Tolga Asveren > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > > > > If the intermediary node uses the same End-to-End identifier for the > > > > original and retransmission request, this shouldn't be a > problem. Server > > > > would receive two requests with the same Origin-Host and > > > End-to-End values > > > > and could detect the duplicate. > > > > > > You are assuming that the two requests go through the same > > > intermediary, which is not always true. Retransmission can also > > > happen at the original sender. > > > > > > +-----B----+ > > > / \ > > > A D > > > \ / > > > +-----C----+ > > > > > > Assume that the orignial request is forwarded A->B->D. > > > > > > If failover happens at A, A may retransmit the request to a different > > > path, say A->C->D. > > > > > > If B modifies the Origin-Host and End-to-End values of the original > > > request, the original and retransmitted requests will have different > > > Origin-Host or End-to-End values. This is the problem I was > > > mentioning. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > Sent: Thursday, July 06, 2006 12:17 PM > > > > > To: Tolga Asveren > > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > Allowing a Diameter node to creates a request with modifying > > > > > End-to-End Identifier and Origin-Host AVP can break > interoperability, > > > > > because the server cannot distinguish the original request and the > > > > > modified request. As a result, the server will process the two > > > > > requests differently and generate two different answers > as oppose to > > > > > the original requester's expectation that only one > request should be > > > > > processed by a given server and that no multiple non-duplicated > > > > > answers are received for the same request. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga Asveren wrote: > > > > > > Hi Yoshihiro, > > > > > > > > > > > > If the proxy creates a corresponding but new request for a > > > request it is > > > > > > proxying, I don't see why there should be a problem from > > > > > duplicate detection > > > > > > point of view. In that case, there are two Diameter signaling > > > > > relationships, > > > > > > one between the client and the proxy and the other one between > > > > > the proxy and > > > > > > the server, i.e. client sees proxy as server and server > > > sees proxy as > > > > > > client. > > > > > > > > > > > > OTOH, one could argue whether that type of behavior is > > > > > overlapping with the > > > > > > definition of proxy in RFC3588, but I believe one can mix and > > > > > match any type > > > > > > of functionality in any node as long as interoperability is > > > not broken. > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > > > > To: Tolga Asveren > > > > > > > Cc: Tony Zhang; dime@ietf.org > > > > > > > Subject: Re: [Dime] yet another way of achieving > strict routing > > > > > > > > > > > > > > > > > > > > > RFC 3588 has explicit text that prohibits replacing > the End-to-End > > > > > > > Identifier: > > > > > > > > > > > > > > "The End-to-End Identifier MUST NOT be modified by > > > Diameter agents > > > > > > > of any kind." > > > > > > > > > > > > > > Note: if the proxy replaces the End-to-End Identifier AVP, the > > > > > > > ultimate receiver of the request message will not > able to detect a > > > > > > > duplicate request if the original request is routed > via the proxy > > > > > > > while a dup of the original request is not routed via the > > > proxy. For > > > > > > > the same reason, Origin-Host AVP should not be modified > > > by the proxy. > > > > > > > (RFC 3588 has explicit text that prohibits modification > > > of Origin-Host > > > > > > > AVP by relay agents in Section 6.3, but the text should > > > be revised to > > > > > > > prohibit modification of Origin-Host AVP by any Diameter > > > agents of any > > > > > > > kind.) > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga Asveren wrote: > > > > > > > > One quick note on duplicat detection in the setup we > > > are discussing: > > > > > > > > Proxy probably doesn't need to provide duplicate > detection, as > > > > > > > long as it > > > > > > > > generates a new request for each request it is proxying. > > > > > the new request > > > > > > > > would have a new End-to-ed Identifier assigned by the proxy. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Tolga > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > > > > > To: Tony Zhang; dime@ietf.org > > > > > > > > > Subject: RE: [Dime] yet another way of achieving > > > strict routing > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > > > > > > Subject: Re: [Dime] yet another way of achieving > > > strict routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tolga: > > > > > > > > > > (1) Some Request in session are sent by > > > server.so should each > > > > > > > > > > proxy repalce first request > > > Origin-Host/Origin-Realm then maybe > > > > > > > > > > will achieve this. > > > > > > > > > [TOLGA]That is really a good point. The solution > is probably > > > > > > > real proxying > > > > > > > > > of the requests: Both Origin/Destination AVP information > > > > > needs to be > > > > > > > > > replaced with the identity of the proxy entity. In that > > > > > > > model, from client > > > > > > > > > point of view, it is the proxy which provides the service, > > > > > > > and this is my > > > > > > > > > understanding of a proxy in the generic sense. This > > > would mean, > > > > > > > > > proxies need > > > > > > > > > to provide duplicate detection as well because it > relies on > > > > > > > > > Origin-Host AVP > > > > > > > > > value, but that IMO is logical considering that proxy > > > > > acts as a node > > > > > > > > > providing a service. > > > > > > > > > > (2)if client send request to one realm,but > > > another realm give > > > > > > > > > > answer,maybe will confusion. > > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > > > > > > > mechanics point of > > > > > > > > > view. > > > > > > > > > > Thanks > > > > > > > > > > Tony > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Tolga Asveren" > > > > > > > > > > To: > > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > > > > > > Subject: [Dime] yet another way of achieving > strict routing > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While studying the mechanics of achiveing strict > > > routing in > > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following came > > > > > to my mind: > > > > > > > > > > > > > > > > > > > > > > 1) Requests are sent by client regularly > > > > > > > > > > > 2) Stateless intermediaries just relay the message > > > > > > > > > > > 3) If an intermediary wants to stay in the path > > > for a session, > > > > > > > > > > it does the > > > > > > > > > > > following with the messages for that session: > > > > > > > > > > > i- For the first answer, it saves the > > > Origin-Host/Origin-Realm > > > > > > > > > > AVP values > > > > > > > > > > > in the message and replaces them with its own > > > > > Host/Realm values. > > > > > > > > > > > ii- Subsequent requests received by this intermediary > > > > > > > will have its > > > > > > > > > > > Host/Realm value in > > > Destination-Host/Destination-Realm AVPs of > > > > > > > > > > the request. > > > > > > > > > > > They are replaced with the values stored in i-. > > > > > > > > > > > > > > > > > > > > > > Considering that proxies which want to stay on the > > > > > path will be > > > > > > > > > > stateful, 3) > > > > > > > > > > > shouldn't be a problem. > > > > > > > > > > > > > > > > > > > > > > This is very similar to what is explained in the > > > draft, except > > > > > > > > > > the state is > > > > > > > > > > > kept in proxies rather than in the message. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Tolga > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > 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 Fri Jul 07 00:14:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhjQ-0002g9-TH; Fri, 07 Jul 2006 00:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyhjP-0002fy-C8 for dime@ietf.org; Fri, 07 Jul 2006 00:14:19 -0400 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 1FyhjO-0000MW-0S for dime@ietf.org; Fri, 07 Jul 2006 00:14:19 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k674DQd6021468; Fri, 7 Jul 2006 00:13:26 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Fri, 7 Jul 2006 00:13:20 -0400 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing Message-ID: <20060707041320.GA14292@steelhead> References: <20060706200218.GN16420@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 25 X-Spam-Score: -2.4 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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, On Thu, Jul 06, 2006 at 03:58:11PM -0400, Tolga Asveren wrote: (snip) > > IMHO, this is not orthogonal to strict routing issue because it is one way > of dealing with scenarios presented as the reason for strict routing. > Actually, if one considers the application logic running on such nodes, it > seems to me a reasonable solution but picking one approach over another one > is obviously an implementation decision. I am not sure if application layer gateway provides strict routing. A------B------C-----E \ / +----D---+ Assume that B is an application layer gateway. C and D may be a proxy or an application layer gateway. A can forward a request to B, but how can A specify that the request should then forwarded to C and not to D? Regards, Yoshihiro Ohba _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 07 09:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyqVT-0004ec-2D; Fri, 07 Jul 2006 09:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyqVR-0004eX-8c for dime@ietf.org; Fri, 07 Jul 2006 09:36:29 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyqVP-00013t-V1 for dime@ietf.org; Fri, 07 Jul 2006 09:36:29 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id AD42381C8B; Fri, 7 Jul 2006 09:36:27 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k67DaIAI024135; Fri, 7 Jul 2006 09:36:20 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Fri, 7 Jul 2006 09:12:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060707041320.GA14292@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Yoshihiro, (I will call the node we are discussing ALG for lack of better terminology right now) All nodes, which want to stay on the path -for some application layer processing- need to be ALGs. In the example you draw below, if there is a need that messages follow the path A->B->C, this can be achieved through configuration on A and B. A should know that for App=X, Realm=a.net, messages need to be sent to B -B could be one of the many possible adjacent nodes, that it stays always on the path is guranteed by B itself-, similarly B need to know through configuration that for App=X, Realm=a.net, messages need to be sent to C -again C is probably one of the many in the list-. Basically it will be intermediaries which decide to stay on the path. I don't know whether there are cases where the client needs to decide for all nodes to be traversed but to my understanding, the real life examples discussed so far do not require that type of behavior. BTW, let me reemphasize that I think the ALG approach is only one of the possible solutions, I am not claiming it should be "the solution". Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Friday, July 07, 2006 12:13 AM > To: Tolga Asveren > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Hi Tolga, > > On Thu, Jul 06, 2006 at 03:58:11PM -0400, Tolga Asveren wrote: > (snip) > > > > IMHO, this is not orthogonal to strict routing issue because it > is one way > > of dealing with scenarios presented as the reason for strict routing. > > Actually, if one considers the application logic running on > such nodes, it > > seems to me a reasonable solution but picking one approach over > another one > > is obviously an implementation decision. > > I am not sure if application layer gateway provides strict routing. > > A------B------C-----E > \ / > +----D---+ > > Assume that B is an application layer gateway. C and D may be a proxy > or an application layer gateway. A can forward a request to B, but > how can A specify that the request should then forwarded to C and not > to D? > > Regards, > Yoshihiro Ohba _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 07 10:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrOd-0002yv-4T; Fri, 07 Jul 2006 10:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyrOc-0002yj-2B for dime@ietf.org; Fri, 07 Jul 2006 10:33:30 -0400 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 1FyrOb-0007Tx-Kx for dime@ietf.org; Fri, 07 Jul 2006 10:33:30 -0400 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 k67EWn2m023121; Fri, 7 Jul 2006 10:32:49 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44AE7091.907@tari.toshiba.com> Date: Fri, 07 Jul 2006 10:32:49 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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, It may just be a matter of terminology (though I don't have a strong opinion on this) but to me 'strict source routing' means that the real end-point destination is the true consumer of the original message. To me, an ALG is half server, half client. The server half consumes the original message and generates a NEW message towards the end-point. my two cents ... victor > Hi Yoshihiro, > > (I will call the node we are discussing ALG for lack of better terminology > right now) > All nodes, which want to stay on the path -for some application layer > processing- need to be ALGs. > > In the example you draw below, if there is a need that messages follow the > path A->B->C, this can be achieved through configuration on A and B. A > should know that for App=X, Realm=a.net, messages need to be sent to B -B > could be one of the many possible adjacent nodes, that it stays always on > the path is guranteed by B itself-, similarly B need to know through > configuration that for App=X, Realm=a.net, messages need to be sent to > C -again C is probably one of the many in the list-. > > Basically it will be intermediaries which decide to stay on the path. I > don't know whether there are cases where the client needs to decide for all > nodes to be traversed but to my understanding, the real life examples > discussed so far do not require that type of behavior. > > BTW, let me reemphasize that I think the ALG approach is only one of the > possible solutions, I am not claiming it should be "the solution". > > Thanks, > Tolga > > > > >> -----Original Message----- >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> Sent: Friday, July 07, 2006 12:13 AM >> To: Tolga Asveren >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> Subject: Re: [Dime] yet another way of achieving strict routing >> >> >> Hi Tolga, >> >> On Thu, Jul 06, 2006 at 03:58:11PM -0400, Tolga Asveren wrote: >> (snip) >> >>> IMHO, this is not orthogonal to strict routing issue because it >>> >> is one way >> >>> of dealing with scenarios presented as the reason for strict routing. >>> Actually, if one considers the application logic running on >>> >> such nodes, it >> >>> seems to me a reasonable solution but picking one approach over >>> >> another one >> >>> is obviously an implementation decision. >>> >> I am not sure if application layer gateway provides strict routing. >> >> A------B------C-----E >> \ / >> +----D---+ >> >> Assume that B is an application layer gateway. C and D may be a proxy >> or an application layer gateway. A can forward a request to B, but >> how can A specify that the request should then forwarded to C and not >> to D? >> >> Regards, >> Yoshihiro Ohba >> > > > _______________________________________________ > 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 Fri Jul 07 16:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx38-0004O1-Q5; Fri, 07 Jul 2006 16:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx38-0004No-3p for dime@ietf.org; Fri, 07 Jul 2006 16:35:42 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyx36-0002k0-MZ for dime@ietf.org; Fri, 07 Jul 2006 16:35:42 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9DA8347A11; Fri, 7 Jul 2006 16:35:40 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k67KZcvB003795; Fri, 7 Jul 2006 16:35:39 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" Subject: RE: [Dime] yet another way of achieving strict routing Date: Fri, 7 Jul 2006 16:12:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <44AE7091.907@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, July 07, 2006 10:33 AM > To: Tolga Asveren > Cc: Yoshihiro Ohba; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Hi, > > It may just be a matter of terminology (though I don't have a strong > opinion on this) but to me 'strict source routing' means that the real > end-point destination is the true consumer of the original message. To > me, an ALG is half server, half client. The server half consumes the > original message and generates a NEW message towards the end-point. [TOLGA]I agree with you that from functionality point of view an ALG is not equivalent to a proxy which supports the Diameter strict routing extension, both of them can provide a working solution for certain configurations though. Probably I better called this thread "yet another way of staying in the message path". > > my two cents ... > victor > > Hi Yoshihiro, > > > > (I will call the node we are discussing ALG for lack of better > terminology > > right now) > > All nodes, which want to stay on the path -for some application layer > > processing- need to be ALGs. > > > > In the example you draw below, if there is a need that messages > follow the > > path A->B->C, this can be achieved through configuration on A and B. A > > should know that for App=X, Realm=a.net, messages need to be > sent to B -B > > could be one of the many possible adjacent nodes, that it stays > always on > > the path is guranteed by B itself-, similarly B need to know through > > configuration that for App=X, Realm=a.net, messages need to be sent to > > C -again C is probably one of the many in the list-. > > > > Basically it will be intermediaries which decide to stay on the path. I > > don't know whether there are cases where the client needs to > decide for all > > nodes to be traversed but to my understanding, the real life examples > > discussed so far do not require that type of behavior. > > > > BTW, let me reemphasize that I think the ALG approach is only one of the > > possible solutions, I am not claiming it should be "the solution". > > > > Thanks, > > Tolga > > > > > > > > > >> -----Original Message----- > >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> Sent: Friday, July 07, 2006 12:13 AM > >> To: Tolga Asveren > >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> Subject: Re: [Dime] yet another way of achieving strict routing > >> > >> > >> Hi Tolga, > >> > >> On Thu, Jul 06, 2006 at 03:58:11PM -0400, Tolga Asveren wrote: > >> (snip) > >> > >>> IMHO, this is not orthogonal to strict routing issue because it > >>> > >> is one way > >> > >>> of dealing with scenarios presented as the reason for strict routing. > >>> Actually, if one considers the application logic running on > >>> > >> such nodes, it > >> > >>> seems to me a reasonable solution but picking one approach over > >>> > >> another one > >> > >>> is obviously an implementation decision. > >>> > >> I am not sure if application layer gateway provides strict routing. > >> > >> A------B------C-----E > >> \ / > >> +----D---+ > >> > >> Assume that B is an application layer gateway. C and D may be a proxy > >> or an application layer gateway. A can forward a request to B, but > >> how can A specify that the request should then forwarded to C and not > >> to D? > >> > >> Regards, > >> Yoshihiro Ohba > >> > > > > > > _______________________________________________ > > 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 Sun Jul 09 14:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzdrB-0003ZW-Gn; Sun, 09 Jul 2006 14:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzdr9-0003RC-Ns for dime@ietf.org; Sun, 09 Jul 2006 14:18:11 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fzdr8-0004u5-7n for dime@ietf.org; Sun, 09 Jul 2006 14:18:11 -0400 Received: (qmail invoked by alias); 09 Jul 2006 18:18:08 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp002) with SMTP; 09 Jul 2006 20:18:08 +0200 X-Authenticated: #29516787 Message-ID: <44B14850.5030507@gmx.net> Date: Sun, 09 Jul 2006 20:17:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS , dime@ietf.org, radiusext@ops.ietf.org, tsvwg Subject: [Fwd: [Dime] Diameter QoS Dinner] 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: 538aad3a3c4f01d8b6a6477ca4248793 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 all, please do not forget the QoS dinner Sunday evening, 19:30 at the registration desk. Ciao Hannes -------- Original Message -------- Subject: [Dime] Diameter QoS Dinner Date: Mon, 19 Jun 2006 14:14:39 +0200 From: Tschofenig, Hannes To: Hi all, it would be good to meet Diameter QoS interested folks at the next IETF for a discussion about possible next steps before the DIME session. The DIME WG session will be on***** MONDAY, July 10, 2006** * *1740-1840 Afternoon Session III* Room 519B APP _widex_ Widget Description Exchange Service WG Room 520ABC INT _softwire_ Softwires WG Room 519A IRTF NMRG Network Management Research Group Charter *Room 513C-F OPS **_dime_* * Diameter Maintenance and Extensions WG *Room 520DEF RAI rtpsec Securing the Real-time Transport Protocol BOF Room 513B SEC _sasl_ Simple Authentication and Security Layer WG Room 518AB TSV _tsvwg_ Transport Area Working Group WG _https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66_ Hence, there is only time after the Welcome Reception on Sunday. My proposal would be to meet at the registration desk at 19:30. Please send me a mail if you are interested. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 10:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwMk-0005FH-39; Mon, 10 Jul 2006 10:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzwMi-0005FC-6s for dime@ietf.org; Mon, 10 Jul 2006 10:04:00 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwMh-0000Nu-8N for dime@ietf.org; Mon, 10 Jul 2006 10:04:00 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6AE3sTm030369; Mon, 10 Jul 2006 17:03:57 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:03:09 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 17:03:09 +0300 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] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 17:03:07 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] yet another way of achieving strict routing Thread-Index: AcakJ9ao9selz3T9RfaRcpWnRz3aLAAARivg From: To: , X-OriginalArrivalTime: 10 Jul 2006 14:03:09.0144 (UTC) FILETIME=[92E08580:01C6A429] X-Spam-Score: 0.2 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 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 Tolga, Understood. What I am cautioning against is when provider C who is running the Diameter ALG is between two providers -=20 A & B. As it is possible that C could modify Diameter packets without A & B knowing it, potentially mis-representing the actual traffic. During the initial standardization of Diameter, one AD particularly was against proxy mode, for this behavior. end-to-end message encryption is one way to to get around this behavior, so you don't encrypt the transport, just the message contents. If this is a non-issue for users deploying Diameter, then perhaps it is a non-issue. John >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 10 July, 2006 09:27 >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com >Cc: dime@ietf.org >Subject: RE: [Dime] yet another way of achieving strict routing > >Hi John, > >One important point regarding B2BUA (or ALG or whatever we=20 >want to name it) is that it does not require any changes to=20 >the existing protocol definition, i.e. it is not violating=20 >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a=20 >protocol issue but an administrative/deployment issue whether=20 >one wants to deploy it -and thus IETF can't do anything about it ;-) -. > >From security point of view, I guess it won't cause a=20 >practical problem for most of the cases. I would think, the=20 >application level processing which needs to be performed on=20 >such nodes -whether it be ALG or proxy- anyhow will require=20 >inspection of AVPs and some preestablished trust relationship.=20 >It could be the case that people want certain AVPs to be=20 >end-to-end secured, but I don't think this will be majority of=20 >the cases and I agree that ALG approach won't provide a=20 >satisfactory solution if that is required. > >I think, it is worthwile to make people aware that this (ALG, B2BCS >[Back-to-Back-Client-Server]) is an option, if it suits their=20 >needs. If mentioning of such functionality wouldn't be blessed=20 >by IETF because it breaks end-to-end security (Actually there=20 >are different ways of seeing this as well, from Diameter Base=20 >Protocol point of view, ALG is and endpoint, well actually two=20 >endpoints and hence does not violate end-to-end security), I=20 >hope this thread was informative enough for people (at least=20 >for me it was). > > Thanks, > Tolga > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Monday, July 10, 2006 9:15 AM >> To: asveren@ulticom.com; yohba@tari.toshiba.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] yet another way of achieving strict routing >> >> >> Hi all, >> >> I basically side with Yoshihiro so far. About Diameter "B2BUA" >> funtionality, this would be officially frowned upon in the=20 >IETF, as it=20 >> does cause problems with security. If we would bring back the=20 >> end-to-end security for Diameter (CMS work), then this kind of=20 >> deployment would be easier to digest. >> >> John >> >> >-----Original Message----- >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] >> >Sent: 06 July, 2006 15:58 >> >To: Yoshihiro Ohba >> >Cc: dime@ietf.org >> >Subject: RE: [Dime] yet another way of achieving strict routing >> > >> >Hi Yoshihiro, >> > >> >Yes, it is analogical to a SIP B2BUA. Actually in my world of ideas=20 >> >this is the definition of a proxy in the generic sense -I am not=20 >> >speaking of SIP/Diameter proxies-: A proxy is an entity, which acts=20 >> >on behalf of another entity. Proxy as defined in SIP -or as defined=20 >> >in Diameter- is more a glorified relay node, but I agree with you=20 >> >that the node I describe is not the "proxy" defined in RFC3588.=20 >> >(Diameter proxy is more similar to the concept of proxy in my mind=20 >> >because it has more authority in terms of changing the contents of=20 >> >the message, so I probably would classify it somewhere=20 >between relay=20 >> >and proxy) >> > >> >IMHO, this is not orthogonal to strict routing issue because it is=20 >> >one way of dealing with scenarios presented as the reason=20 >for strict=20 >> >routing. >> >Actually, if one considers the application logic running on such=20 >> >nodes, it seems to me a reasonable solution but picking one=20 >approach=20 >> >over another one is obviously an implementation decision. >> > >> > Thanks, >> > Tolga >> > >> >> -----Original Message----- >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> >> Sent: Thursday, July 06, 2006 4:02 PM >> >> To: Tolga Asveren >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> >> Subject: Re: [Dime] yet another way of achieving strict routing >> >> >> >> >> >> Hi Tolga, >> >> >> >> Is the sceanario you described is an application layer=20 >gateway for=20 >> >> (like SIP B2BUA)? If so, we should not mix it up with a=20 >proxy and=20 >> >> I believe it is orthogonal to the strict routing issue. >> >> >> >> Yoshihiro Ohba >> >> >> >> >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: >> >> > O.K., now I got what you mean. And yes, this will be a problem >> >> unless B and >> >> > C work in a synchronized way, where they share state. I >> >think, this >> >> > they need to do anyhow, because they keep some application level >> >> state, otherwise >> >> > they wouldn't want to stay on the path. Basically, in the model >> >> I described, >> >> > B and C act as endnodes. If there are intermediaries,=20 >which don't=20 >> >> > share state, I would expect them to abort the session after a >> >> failover -when they >> >> > receive messages for an unknown session-, because they can't >> >> perform their >> >> > application level processing regarding that session. >> >> > >> >> > Thanks, >> >> > Tolga >> >> > >> >> > > -----Original Message----- >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> >> > > Sent: Thursday, July 06, 2006 1:59 PM >> >> > > To: Tolga Asveren >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> >> > > Subject: Re: [Dime] yet another way of achieving=20 >strict routing >> >> > > >> >> > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: >> >> > > > If the intermediary node uses the same End-to-End >> >identifier for >> >> > > > the original and retransmission request, this shouldn't be a >> >> problem. Server >> >> > > > would receive two requests with the same Origin-Host and >> >> > > End-to-End values >> >> > > > and could detect the duplicate. >> >> > > >> >> > > You are assuming that the two requests go through the same=20 >> >> > > intermediary, which is not always true. Retransmission can=20 >> >> > > also happen at the original sender. >> >> > > >> >> > > +-----B----+ >> >> > > / \ >> >> > > A D >> >> > > \ / >> >> > > +-----C----+ >> >> > > >> >> > > Assume that the orignial request is forwarded A->B->D. >> >> > > >> >> > > If failover happens at A, A may retransmit the request to a=20 >> >> > > different path, say A->C->D. >> >> > > >> >> > > If B modifies the Origin-Host and End-to-End values of the=20 >> >> > > original request, the original and retransmitted=20 >requests will=20 >> >> > > have different Origin-Host or End-to-End values. This is the=20 >> >> > > problem I was mentioning. >> >> > > >> >> > > Yoshihiro Ohba >> >> > > >> >> > > >> >> > > >> >> > > > > -----Original Message----- >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM >> >> > > > > To: Tolga Asveren >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> >> > > > > Subject: Re: [Dime] yet another way of achieving strict=20 >> >> > > > > routing >> >> > > > > >> >> > > > > >> >> > > > > Allowing a Diameter node to creates a request with=20 >> >> > > > > modifying End-to-End Identifier and Origin-Host AVP can=20 >> >> > > > > break >> >> interoperability, >> >> > > > > because the server cannot distinguish the original >> >request and >> >> > > > > the modified request. As a result, the server=20 >will process=20 >> >> > > > > the two requests differently and generate two different=20 >> >> > > > > answers >> >> as oppose to >> >> > > > > the original requester's expectation that only one >> >> request should be >> >> > > > > processed by a given server and that no multiple=20 >> >> > > > > non-duplicated answers are received for the same request. >> >> > > > > >> >> > > > > Yoshihiro Ohba >> >> > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga >> >Asveren wrote: >> >> > > > > > Hi Yoshihiro, >> >> > > > > > >> >> > > > > > If the proxy creates a corresponding but new=20 >request for=20 >> >> > > > > > a >> >> > > request it is >> >> > > > > > proxying, I don't see why there should be a problem from >> >> > > > > duplicate detection >> >> > > > > > point of view. In that case, there are two Diameter=20 >> >> > > > > > signaling >> >> > > > > relationships, >> >> > > > > > one between the client and the proxy and the other one=20 >> >> > > > > > between >> >> > > > > the proxy and >> >> > > > > > the server, i.e. client sees proxy as server and server >> >> > > sees proxy as >> >> > > > > > client. >> >> > > > > > >> >> > > > > > OTOH, one could argue whether that type of behavior is >> >> > > > > overlapping with the >> >> > > > > > definition of proxy in RFC3588, but I believe=20 >one can mix=20 >> >> > > > > > and >> >> > > > > match any type >> >> > > > > > of functionality in any node as long as=20 >interoperability=20 >> >> > > > > > is >> >> > > not broken. >> >> > > > > > >> >> > > > > > Thanks, >> >> > > > > > Tolga >> >> > > > > > >> >> > > > > > >> >> > > > > > > -----Original Message----- >> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM >> >> > > > > > > To: Tolga Asveren >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving >> >> strict routing >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > RFC 3588 has explicit text that prohibits replacing >> >> the End-to-End >> >> > > > > > > Identifier: >> >> > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT be modified by >> >> > > Diameter agents >> >> > > > > > > of any kind." >> >> > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End >> >Identifier AVP, >> >> > > > > > > the ultimate receiver of the request message will not >> >> able to detect a >> >> > > > > > > duplicate request if the original request is routed >> >> via the proxy >> >> > > > > > > while a dup of the original request is not routed via=20 >> >> > > > > > > the >> >> > > proxy. For >> >> > > > > > > the same reason, Origin-Host AVP should not=20 >be modified >> >> > > by the proxy. >> >> > > > > > > (RFC 3588 has explicit text that prohibits=20 >modification >> >> > > of Origin-Host >> >> > > > > > > AVP by relay agents in Section 6.3, but the=20 >text should >> >> > > be revised to >> >> > > > > > > prohibit modification of Origin-Host AVP by any=20 >> >> > > > > > > Diameter >> >> > > agents of any >> >> > > > > > > kind.) >> >> > > > > > > >> >> > > > > > > Yoshihiro Ohba >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga >> >Asveren wrote: >> >> > > > > > > > One quick note on duplicat detection in the setup we >> >> > > are discussing: >> >> > > > > > > > Proxy probably doesn't need to provide duplicate >> >> detection, as >> >> > > > > > > long as it >> >> > > > > > > > generates a new request for each request it is >> >proxying. >> >> > > > > the new request >> >> > > > > > > > would have a new End-to-ed Identifier assigned >> >by the proxy. >> >> > > > > > > > >> >> > > > > > > > Thanks, >> >> > > > > > > > Tolga >> >> > > > > > > > >> >> > > > > > > > > -----Original Message----- >> >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org >> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving >> >> > > strict routing >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > > > Hi Tony, >> >> > > > > > > > > >> >> > > > > > > > > > -----Original Message----- >> >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org >> >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving >> >> > > strict routing >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: >> >> > > > > > > > > > (1) Some Request in session are sent by >> >> > > server.so should each >> >> > > > > > > > > > proxy repalce first request >> >> > > Origin-Host/Origin-Realm then maybe >> >> > > > > > > > > > will achieve this. >> >> > > > > > > > > [TOLGA]That is really a good point. The solution >> >> is probably >> >> > > > > > > real proxying >> >> > > > > > > > > of the requests: Both Origin/Destination AVP=20 >> >> > > > > > > > > information >> >> > > > > needs to be >> >> > > > > > > > > replaced with the identity of the proxy=20 >entity. In=20 >> >> > > > > > > > > that >> >> > > > > > > model, from client >> >> > > > > > > > > point of view, it is the proxy which provides the=20 >> >> > > > > > > > > service, >> >> > > > > > > and this is my >> >> > > > > > > > > understanding of a proxy in the generic=20 >sense. This >> >> > > would mean, >> >> > > > > > > > > proxies need >> >> > > > > > > > > to provide duplicate detection as well because it >> >> relies on >> >> > > > > > > > > Origin-Host AVP >> >> > > > > > > > > value, but that IMO is logical considering that=20 >> >> > > > > > > > > proxy >> >> > > > > acts as a node >> >> > > > > > > > > providing a service. >> >> > > > > > > > > > (2)if client send request to one realm,but >> >> > > another realm give >> >> > > > > > > > > > answer,maybe will confusion. >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from=20 >> >> > > > > > > > > protocol >> >> > > > > > > mechanics point of >> >> > > > > > > > > view. >> >> > > > > > > > > > Thanks >> >> > > > > > > > > > Tony >> >> > > > > > > > > > ----- Original Message ----- >> >> > > > > > > > > > From: "Tolga Asveren" >> >> > > > > > > > > > To: >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM >> >> > > > > > > > > > Subject: [Dime] yet another way of achieving >> >> strict routing >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of achiveing=20 >> >> > > > > > > > > > > strict >> >> > > routing in >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the=20 >following=20 >> >> > > > > > > > > > > came >> >> > > > > to my mind: >> >> > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly >> >> > > > > > > > > > > 2) Stateless intermediaries just relay >> >the message >> >> > > > > > > > > > > 3) If an intermediary wants to stay=20 >in the path >> >> > > for a session, >> >> > > > > > > > > > it does the >> >> > > > > > > > > > > following with the messages for that session: >> >> > > > > > > > > > > i- For the first answer, it saves the >> >> > > Origin-Host/Origin-Realm >> >> > > > > > > > > > AVP values >> >> > > > > > > > > > > in the message and replaces them with its own >> >> > > > > Host/Realm values. >> >> > > > > > > > > > > ii- Subsequent requests received by this=20 >> >> > > > > > > > > > > intermediary >> >> > > > > > > will have its >> >> > > > > > > > > > > Host/Realm value in >> >> > > Destination-Host/Destination-Realm AVPs of >> >> > > > > > > > > > the request. >> >> > > > > > > > > > > They are replaced with the values=20 >stored in i-. >> >> > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to >> >stay on the >> >> > > > > path will be >> >> > > > > > > > > > stateful, 3) >> >> > > > > > > > > > > shouldn't be a problem. >> >> > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is explained in=20 >> >> > > > > > > > > > > the >> >> > > draft, except >> >> > > > > > > > > > the state is >> >> > > > > > > > > > > kept in proxies rather than in the message. >> >> > > > > > > > > > > >> >> > > > > > > > > > > Thanks, >> >> > > > > > > > > > > Tolga >> >> > > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > >=20 >_______________________________________________ >> >> > > > > > > > > > > DiME mailing list DiME@ietf.org=20 >> >> > > > > > > > > > > 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 >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 10:27:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwjj-0002iS-Ve; Mon, 10 Jul 2006 10:27:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzwjj-0002iN-Cj for dime@ietf.org; Mon, 10 Jul 2006 10:27:47 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzwji-0001t8-Ed for dime@ietf.org; Mon, 10 Jul 2006 10:27:47 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 946018E3F9; Mon, 10 Jul 2006 10:27:43 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6AERLgI024731; Mon, 10 Jul 2006 10:27:26 -0400 (EDT) From: "Tolga Asveren" To: , Subject: RE: [Dime] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 10:03:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d6c15d82a53e26283536b4a751453103 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 John, I agree that this is a valid concern, which may be applicable for certain configurations. At the end, it will be operators, which decide for their own security needs and they will use necessary tools to achieve it. One more point regarding this issue, in terms of how that type of security may be provided when using an ALG: Actually it is probably no more different than what a proxy would do. Let's say some AVPs are end-to-end encrypted. Those will be directly included in the new message ALG is generating against the server as is, without encrytion/decryption. ALG wouldn't need to decrypt them because they wouldn't be necessary for the application logic running on the ALG. Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, July 10, 2006 10:03 AM > To: asveren@ulticom.com; yohba@tari.toshiba.com > Cc: dime@ietf.org > Subject: RE: [Dime] yet another way of achieving strict routing > > > Tolga, > > Understood. What I am cautioning against is when provider C > who is running the Diameter ALG is between two providers - > A & B. As it is possible that C could modify Diameter packets > without A & B knowing it, potentially mis-representing the actual > traffic. During the initial standardization of Diameter, one > AD particularly was against proxy mode, for this behavior. > end-to-end message encryption is one way to to get around this > behavior, so you don't encrypt the transport, just the message > contents. > > If this is a non-issue for users deploying Diameter, then perhaps > it is a non-issue. > > John > > >-----Original Message----- > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >Sent: 10 July, 2006 09:27 > >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com > >Cc: dime@ietf.org > >Subject: RE: [Dime] yet another way of achieving strict routing > > > >Hi John, > > > >One important point regarding B2BUA (or ALG or whatever we > >want to name it) is that it does not require any changes to > >the existing protocol definition, i.e. it is not violating > >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a > >protocol issue but an administrative/deployment issue whether > >one wants to deploy it -and thus IETF can't do anything about it ;-) -. > > > >From security point of view, I guess it won't cause a > >practical problem for most of the cases. I would think, the > >application level processing which needs to be performed on > >such nodes -whether it be ALG or proxy- anyhow will require > >inspection of AVPs and some preestablished trust relationship. > >It could be the case that people want certain AVPs to be > >end-to-end secured, but I don't think this will be majority of > >the cases and I agree that ALG approach won't provide a > >satisfactory solution if that is required. > > > >I think, it is worthwile to make people aware that this (ALG, B2BCS > >[Back-to-Back-Client-Server]) is an option, if it suits their > >needs. If mentioning of such functionality wouldn't be blessed > >by IETF because it breaks end-to-end security (Actually there > >are different ways of seeing this as well, from Diameter Base > >Protocol point of view, ALG is and endpoint, well actually two > >endpoints and hence does not violate end-to-end security), I > >hope this thread was informative enough for people (at least > >for me it was). > > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > >> Sent: Monday, July 10, 2006 9:15 AM > >> To: asveren@ulticom.com; yohba@tari.toshiba.com > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] yet another way of achieving strict routing > >> > >> > >> Hi all, > >> > >> I basically side with Yoshihiro so far. About Diameter "B2BUA" > >> funtionality, this would be officially frowned upon in the > >IETF, as it > >> does cause problems with security. If we would bring back the > >> end-to-end security for Diameter (CMS work), then this kind of > >> deployment would be easier to digest. > >> > >> John > >> > >> >-----Original Message----- > >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >> >Sent: 06 July, 2006 15:58 > >> >To: Yoshihiro Ohba > >> >Cc: dime@ietf.org > >> >Subject: RE: [Dime] yet another way of achieving strict routing > >> > > >> >Hi Yoshihiro, > >> > > >> >Yes, it is analogical to a SIP B2BUA. Actually in my world of ideas > >> >this is the definition of a proxy in the generic sense -I am not > >> >speaking of SIP/Diameter proxies-: A proxy is an entity, which acts > >> >on behalf of another entity. Proxy as defined in SIP -or as defined > >> >in Diameter- is more a glorified relay node, but I agree with you > >> >that the node I describe is not the "proxy" defined in RFC3588. > >> >(Diameter proxy is more similar to the concept of proxy in my mind > >> >because it has more authority in terms of changing the contents of > >> >the message, so I probably would classify it somewhere > >between relay > >> >and proxy) > >> > > >> >IMHO, this is not orthogonal to strict routing issue because it is > >> >one way of dealing with scenarios presented as the reason > >for strict > >> >routing. > >> >Actually, if one considers the application logic running on such > >> >nodes, it seems to me a reasonable solution but picking one > >approach > >> >over another one is obviously an implementation decision. > >> > > >> > Thanks, > >> > Tolga > >> > > >> >> -----Original Message----- > >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> >> Sent: Thursday, July 06, 2006 4:02 PM > >> >> To: Tolga Asveren > >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> >> Subject: Re: [Dime] yet another way of achieving strict routing > >> >> > >> >> > >> >> Hi Tolga, > >> >> > >> >> Is the sceanario you described is an application layer > >gateway for > >> >> (like SIP B2BUA)? If so, we should not mix it up with a > >proxy and > >> >> I believe it is orthogonal to the strict routing issue. > >> >> > >> >> Yoshihiro Ohba > >> >> > >> >> > >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > >> >> > O.K., now I got what you mean. And yes, this will be a problem > >> >> unless B and > >> >> > C work in a synchronized way, where they share state. I > >> >think, this > >> >> > they need to do anyhow, because they keep some application level > >> >> state, otherwise > >> >> > they wouldn't want to stay on the path. Basically, in the model > >> >> I described, > >> >> > B and C act as endnodes. If there are intermediaries, > >which don't > >> >> > share state, I would expect them to abort the session after a > >> >> failover -when they > >> >> > receive messages for an unknown session-, because they can't > >> >> perform their > >> >> > application level processing regarding that session. > >> >> > > >> >> > Thanks, > >> >> > Tolga > >> >> > > >> >> > > -----Original Message----- > >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> >> > > Sent: Thursday, July 06, 2006 1:59 PM > >> >> > > To: Tolga Asveren > >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> >> > > Subject: Re: [Dime] yet another way of achieving > >strict routing > >> >> > > > >> >> > > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > >> >> > > > If the intermediary node uses the same End-to-End > >> >identifier for > >> >> > > > the original and retransmission request, this shouldn't be a > >> >> problem. Server > >> >> > > > would receive two requests with the same Origin-Host and > >> >> > > End-to-End values > >> >> > > > and could detect the duplicate. > >> >> > > > >> >> > > You are assuming that the two requests go through the same > >> >> > > intermediary, which is not always true. Retransmission can > >> >> > > also happen at the original sender. > >> >> > > > >> >> > > +-----B----+ > >> >> > > / \ > >> >> > > A D > >> >> > > \ / > >> >> > > +-----C----+ > >> >> > > > >> >> > > Assume that the orignial request is forwarded A->B->D. > >> >> > > > >> >> > > If failover happens at A, A may retransmit the request to a > >> >> > > different path, say A->C->D. > >> >> > > > >> >> > > If B modifies the Origin-Host and End-to-End values of the > >> >> > > original request, the original and retransmitted > >requests will > >> >> > > have different Origin-Host or End-to-End values. This is the > >> >> > > problem I was mentioning. > >> >> > > > >> >> > > Yoshihiro Ohba > >> >> > > > >> >> > > > >> >> > > > >> >> > > > > -----Original Message----- > >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > >> >> > > > > To: Tolga Asveren > >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> >> > > > > Subject: Re: [Dime] yet another way of achieving strict > >> >> > > > > routing > >> >> > > > > > >> >> > > > > > >> >> > > > > Allowing a Diameter node to creates a request with > >> >> > > > > modifying End-to-End Identifier and Origin-Host AVP can > >> >> > > > > break > >> >> interoperability, > >> >> > > > > because the server cannot distinguish the original > >> >request and > >> >> > > > > the modified request. As a result, the server > >will process > >> >> > > > > the two requests differently and generate two different > >> >> > > > > answers > >> >> as oppose to > >> >> > > > > the original requester's expectation that only one > >> >> request should be > >> >> > > > > processed by a given server and that no multiple > >> >> > > > > non-duplicated answers are received for the same request. > >> >> > > > > > >> >> > > > > Yoshihiro Ohba > >> >> > > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > >> >Asveren wrote: > >> >> > > > > > Hi Yoshihiro, > >> >> > > > > > > >> >> > > > > > If the proxy creates a corresponding but new > >request for > >> >> > > > > > a > >> >> > > request it is > >> >> > > > > > proxying, I don't see why there should be a problem from > >> >> > > > > duplicate detection > >> >> > > > > > point of view. In that case, there are two Diameter > >> >> > > > > > signaling > >> >> > > > > relationships, > >> >> > > > > > one between the client and the proxy and the other one > >> >> > > > > > between > >> >> > > > > the proxy and > >> >> > > > > > the server, i.e. client sees proxy as server and server > >> >> > > sees proxy as > >> >> > > > > > client. > >> >> > > > > > > >> >> > > > > > OTOH, one could argue whether that type of behavior is > >> >> > > > > overlapping with the > >> >> > > > > > definition of proxy in RFC3588, but I believe > >one can mix > >> >> > > > > > and > >> >> > > > > match any type > >> >> > > > > > of functionality in any node as long as > >interoperability > >> >> > > > > > is > >> >> > > not broken. > >> >> > > > > > > >> >> > > > > > Thanks, > >> >> > > > > > Tolga > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > -----Original Message----- > >> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > >> >> > > > > > > To: Tolga Asveren > >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org > >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving > >> >> strict routing > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > RFC 3588 has explicit text that prohibits replacing > >> >> the End-to-End > >> >> > > > > > > Identifier: > >> >> > > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT be modified by > >> >> > > Diameter agents > >> >> > > > > > > of any kind." > >> >> > > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End > >> >Identifier AVP, > >> >> > > > > > > the ultimate receiver of the request message will not > >> >> able to detect a > >> >> > > > > > > duplicate request if the original request is routed > >> >> via the proxy > >> >> > > > > > > while a dup of the original request is not routed via > >> >> > > > > > > the > >> >> > > proxy. For > >> >> > > > > > > the same reason, Origin-Host AVP should not > >be modified > >> >> > > by the proxy. > >> >> > > > > > > (RFC 3588 has explicit text that prohibits > >modification > >> >> > > of Origin-Host > >> >> > > > > > > AVP by relay agents in Section 6.3, but the > >text should > >> >> > > be revised to > >> >> > > > > > > prohibit modification of Origin-Host AVP by any > >> >> > > > > > > Diameter > >> >> > > agents of any > >> >> > > > > > > kind.) > >> >> > > > > > > > >> >> > > > > > > Yoshihiro Ohba > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > >> >Asveren wrote: > >> >> > > > > > > > One quick note on duplicat detection in the setup we > >> >> > > are discussing: > >> >> > > > > > > > Proxy probably doesn't need to provide duplicate > >> >> detection, as > >> >> > > > > > > long as it > >> >> > > > > > > > generates a new request for each request it is > >> >proxying. > >> >> > > > > the new request > >> >> > > > > > > > would have a new End-to-ed Identifier assigned > >> >by the proxy. > >> >> > > > > > > > > >> >> > > > > > > > Thanks, > >> >> > > > > > > > Tolga > >> >> > > > > > > > > >> >> > > > > > > > > -----Original Message----- > >> >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org > >> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving > >> >> > > strict routing > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > Hi Tony, > >> >> > > > > > > > > > >> >> > > > > > > > > > -----Original Message----- > >> >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving > >> >> > > strict routing > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: > >> >> > > > > > > > > > (1) Some Request in session are sent by > >> >> > > server.so should each > >> >> > > > > > > > > > proxy repalce first request > >> >> > > Origin-Host/Origin-Realm then maybe > >> >> > > > > > > > > > will achieve this. > >> >> > > > > > > > > [TOLGA]That is really a good point. The solution > >> >> is probably > >> >> > > > > > > real proxying > >> >> > > > > > > > > of the requests: Both Origin/Destination AVP > >> >> > > > > > > > > information > >> >> > > > > needs to be > >> >> > > > > > > > > replaced with the identity of the proxy > >entity. In > >> >> > > > > > > > > that > >> >> > > > > > > model, from client > >> >> > > > > > > > > point of view, it is the proxy which provides the > >> >> > > > > > > > > service, > >> >> > > > > > > and this is my > >> >> > > > > > > > > understanding of a proxy in the generic > >sense. This > >> >> > > would mean, > >> >> > > > > > > > > proxies need > >> >> > > > > > > > > to provide duplicate detection as well because it > >> >> relies on > >> >> > > > > > > > > Origin-Host AVP > >> >> > > > > > > > > value, but that IMO is logical considering that > >> >> > > > > > > > > proxy > >> >> > > > > acts as a node > >> >> > > > > > > > > providing a service. > >> >> > > > > > > > > > (2)if client send request to one realm,but > >> >> > > another realm give > >> >> > > > > > > > > > answer,maybe will confusion. > >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from > >> >> > > > > > > > > protocol > >> >> > > > > > > mechanics point of > >> >> > > > > > > > > view. > >> >> > > > > > > > > > Thanks > >> >> > > > > > > > > > Tony > >> >> > > > > > > > > > ----- Original Message ----- > >> >> > > > > > > > > > From: "Tolga Asveren" > >> >> > > > > > > > > > To: > >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > >> >> > > > > > > > > > Subject: [Dime] yet another way of achieving > >> >> strict routing > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of achiveing > >> >> > > > > > > > > > > strict > >> >> > > routing in > >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the > >following > >> >> > > > > > > > > > > came > >> >> > > > > to my mind: > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly > >> >> > > > > > > > > > > 2) Stateless intermediaries just relay > >> >the message > >> >> > > > > > > > > > > 3) If an intermediary wants to stay > >in the path > >> >> > > for a session, > >> >> > > > > > > > > > it does the > >> >> > > > > > > > > > > following with the messages for that session: > >> >> > > > > > > > > > > i- For the first answer, it saves the > >> >> > > Origin-Host/Origin-Realm > >> >> > > > > > > > > > AVP values > >> >> > > > > > > > > > > in the message and replaces them with its own > >> >> > > > > Host/Realm values. > >> >> > > > > > > > > > > ii- Subsequent requests received by this > >> >> > > > > > > > > > > intermediary > >> >> > > > > > > will have its > >> >> > > > > > > > > > > Host/Realm value in > >> >> > > Destination-Host/Destination-Realm AVPs of > >> >> > > > > > > > > > the request. > >> >> > > > > > > > > > > They are replaced with the values > >stored in i-. > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to > >> >stay on the > >> >> > > > > path will be > >> >> > > > > > > > > > stateful, 3) > >> >> > > > > > > > > > > shouldn't be a problem. > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is explained in > >> >> > > > > > > > > > > the > >> >> > > draft, except > >> >> > > > > > > > > > the state is > >> >> > > > > > > > > > > kept in proxies rather than in the message. > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > Thanks, > >> >> > > > > > > > > > > Tolga > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >_______________________________________________ > >> >> > > > > > > > > > > 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 > >> > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 11:32:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxkd-0006EN-Jx; Mon, 10 Jul 2006 11:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzxkd-0006EI-2E for dime@ietf.org; Mon, 10 Jul 2006 11:32:47 -0400 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 1Fzxkc-000555-3p for dime@ietf.org; Mon, 10 Jul 2006 11:32:47 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6AFW7Pg031628; Mon, 10 Jul 2006 11:32:07 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Mon, 10 Jul 2006 11:31:56 -0400 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing Message-ID: <20060710153156.GE7198@steelhead> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 497 X-Spam-Score: -2.4 (--) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 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 Tolga, I think you are still mixing up ALG and proxy. The ALG is a really the termination point of Diameter end-to-end communication, and thus all encrypted AVPs need to be decrypted by the ALG and passed to the application. Yoshihiro Ohba On Mon, Jul 10, 2006 at 10:03:40AM -0400, Tolga Asveren wrote: > John, > > I agree that this is a valid concern, which may be applicable for certain > configurations. At the end, it will be operators, which decide for their own > security needs and they will use necessary tools to achieve it. > > One more point regarding this issue, in terms of how that type of security > may be provided when using an ALG: > Actually it is probably no more different than what a proxy would do. Let's > say some AVPs are end-to-end encrypted. Those will be directly included in > the new message ALG is generating against the server as is, without > encrytion/decryption. ALG wouldn't need to decrypt them because they > wouldn't be necessary for the application logic running on the ALG. > > Thanks, > Tolga > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Monday, July 10, 2006 10:03 AM > > To: asveren@ulticom.com; yohba@tari.toshiba.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > Tolga, > > > > Understood. What I am cautioning against is when provider C > > who is running the Diameter ALG is between two providers - > > A & B. As it is possible that C could modify Diameter packets > > without A & B knowing it, potentially mis-representing the actual > > traffic. During the initial standardization of Diameter, one > > AD particularly was against proxy mode, for this behavior. > > end-to-end message encryption is one way to to get around this > > behavior, so you don't encrypt the transport, just the message > > contents. > > > > If this is a non-issue for users deploying Diameter, then perhaps > > it is a non-issue. > > > > John > > > > >-----Original Message----- > > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > >Sent: 10 July, 2006 09:27 > > >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com > > >Cc: dime@ietf.org > > >Subject: RE: [Dime] yet another way of achieving strict routing > > > > > >Hi John, > > > > > >One important point regarding B2BUA (or ALG or whatever we > > >want to name it) is that it does not require any changes to > > >the existing protocol definition, i.e. it is not violating > > >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a > > >protocol issue but an administrative/deployment issue whether > > >one wants to deploy it -and thus IETF can't do anything about it ;-) -. > > > > > >From security point of view, I guess it won't cause a > > >practical problem for most of the cases. I would think, the > > >application level processing which needs to be performed on > > >such nodes -whether it be ALG or proxy- anyhow will require > > >inspection of AVPs and some preestablished trust relationship. > > >It could be the case that people want certain AVPs to be > > >end-to-end secured, but I don't think this will be majority of > > >the cases and I agree that ALG approach won't provide a > > >satisfactory solution if that is required. > > > > > >I think, it is worthwile to make people aware that this (ALG, B2BCS > > >[Back-to-Back-Client-Server]) is an option, if it suits their > > >needs. If mentioning of such functionality wouldn't be blessed > > >by IETF because it breaks end-to-end security (Actually there > > >are different ways of seeing this as well, from Diameter Base > > >Protocol point of view, ALG is and endpoint, well actually two > > >endpoints and hence does not violate end-to-end security), I > > >hope this thread was informative enough for people (at least > > >for me it was). > > > > > > Thanks, > > > Tolga > > > > > > > > >> -----Original Message----- > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > >> Sent: Monday, July 10, 2006 9:15 AM > > >> To: asveren@ulticom.com; yohba@tari.toshiba.com > > >> Cc: dime@ietf.org > > >> Subject: RE: [Dime] yet another way of achieving strict routing > > >> > > >> > > >> Hi all, > > >> > > >> I basically side with Yoshihiro so far. About Diameter "B2BUA" > > >> funtionality, this would be officially frowned upon in the > > >IETF, as it > > >> does cause problems with security. If we would bring back the > > >> end-to-end security for Diameter (CMS work), then this kind of > > >> deployment would be easier to digest. > > >> > > >> John > > >> > > >> >-----Original Message----- > > >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > >> >Sent: 06 July, 2006 15:58 > > >> >To: Yoshihiro Ohba > > >> >Cc: dime@ietf.org > > >> >Subject: RE: [Dime] yet another way of achieving strict routing > > >> > > > >> >Hi Yoshihiro, > > >> > > > >> >Yes, it is analogical to a SIP B2BUA. Actually in my world of ideas > > >> >this is the definition of a proxy in the generic sense -I am not > > >> >speaking of SIP/Diameter proxies-: A proxy is an entity, which acts > > >> >on behalf of another entity. Proxy as defined in SIP -or as defined > > >> >in Diameter- is more a glorified relay node, but I agree with you > > >> >that the node I describe is not the "proxy" defined in RFC3588. > > >> >(Diameter proxy is more similar to the concept of proxy in my mind > > >> >because it has more authority in terms of changing the contents of > > >> >the message, so I probably would classify it somewhere > > >between relay > > >> >and proxy) > > >> > > > >> >IMHO, this is not orthogonal to strict routing issue because it is > > >> >one way of dealing with scenarios presented as the reason > > >for strict > > >> >routing. > > >> >Actually, if one considers the application logic running on such > > >> >nodes, it seems to me a reasonable solution but picking one > > >approach > > >> >over another one is obviously an implementation decision. > > >> > > > >> > Thanks, > > >> > Tolga > > >> > > > >> >> -----Original Message----- > > >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > >> >> Sent: Thursday, July 06, 2006 4:02 PM > > >> >> To: Tolga Asveren > > >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > >> >> Subject: Re: [Dime] yet another way of achieving strict routing > > >> >> > > >> >> > > >> >> Hi Tolga, > > >> >> > > >> >> Is the sceanario you described is an application layer > > >gateway for > > >> >> (like SIP B2BUA)? If so, we should not mix it up with a > > >proxy and > > >> >> I believe it is orthogonal to the strict routing issue. > > >> >> > > >> >> Yoshihiro Ohba > > >> >> > > >> >> > > >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > > >> >> > O.K., now I got what you mean. And yes, this will be a problem > > >> >> unless B and > > >> >> > C work in a synchronized way, where they share state. I > > >> >think, this > > >> >> > they need to do anyhow, because they keep some application level > > >> >> state, otherwise > > >> >> > they wouldn't want to stay on the path. Basically, in the model > > >> >> I described, > > >> >> > B and C act as endnodes. If there are intermediaries, > > >which don't > > >> >> > share state, I would expect them to abort the session after a > > >> >> failover -when they > > >> >> > receive messages for an unknown session-, because they can't > > >> >> perform their > > >> >> > application level processing regarding that session. > > >> >> > > > >> >> > Thanks, > > >> >> > Tolga > > >> >> > > > >> >> > > -----Original Message----- > > >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > >> >> > > Sent: Thursday, July 06, 2006 1:59 PM > > >> >> > > To: Tolga Asveren > > >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > >> >> > > Subject: Re: [Dime] yet another way of achieving > > >strict routing > > >> >> > > > > >> >> > > > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > > >> >> > > > If the intermediary node uses the same End-to-End > > >> >identifier for > > >> >> > > > the original and retransmission request, this shouldn't be a > > >> >> problem. Server > > >> >> > > > would receive two requests with the same Origin-Host and > > >> >> > > End-to-End values > > >> >> > > > and could detect the duplicate. > > >> >> > > > > >> >> > > You are assuming that the two requests go through the same > > >> >> > > intermediary, which is not always true. Retransmission can > > >> >> > > also happen at the original sender. > > >> >> > > > > >> >> > > +-----B----+ > > >> >> > > / \ > > >> >> > > A D > > >> >> > > \ / > > >> >> > > +-----C----+ > > >> >> > > > > >> >> > > Assume that the orignial request is forwarded A->B->D. > > >> >> > > > > >> >> > > If failover happens at A, A may retransmit the request to a > > >> >> > > different path, say A->C->D. > > >> >> > > > > >> >> > > If B modifies the Origin-Host and End-to-End values of the > > >> >> > > original request, the original and retransmitted > > >requests will > > >> >> > > have different Origin-Host or End-to-End values. This is the > > >> >> > > problem I was mentioning. > > >> >> > > > > >> >> > > Yoshihiro Ohba > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > -----Original Message----- > > >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > > >> >> > > > > To: Tolga Asveren > > >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > >> >> > > > > Subject: Re: [Dime] yet another way of achieving strict > > >> >> > > > > routing > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > Allowing a Diameter node to creates a request with > > >> >> > > > > modifying End-to-End Identifier and Origin-Host AVP can > > >> >> > > > > break > > >> >> interoperability, > > >> >> > > > > because the server cannot distinguish the original > > >> >request and > > >> >> > > > > the modified request. As a result, the server > > >will process > > >> >> > > > > the two requests differently and generate two different > > >> >> > > > > answers > > >> >> as oppose to > > >> >> > > > > the original requester's expectation that only one > > >> >> request should be > > >> >> > > > > processed by a given server and that no multiple > > >> >> > > > > non-duplicated answers are received for the same request. > > >> >> > > > > > > >> >> > > > > Yoshihiro Ohba > > >> >> > > > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > > >> >Asveren wrote: > > >> >> > > > > > Hi Yoshihiro, > > >> >> > > > > > > > >> >> > > > > > If the proxy creates a corresponding but new > > >request for > > >> >> > > > > > a > > >> >> > > request it is > > >> >> > > > > > proxying, I don't see why there should be a problem from > > >> >> > > > > duplicate detection > > >> >> > > > > > point of view. In that case, there are two Diameter > > >> >> > > > > > signaling > > >> >> > > > > relationships, > > >> >> > > > > > one between the client and the proxy and the other one > > >> >> > > > > > between > > >> >> > > > > the proxy and > > >> >> > > > > > the server, i.e. client sees proxy as server and server > > >> >> > > sees proxy as > > >> >> > > > > > client. > > >> >> > > > > > > > >> >> > > > > > OTOH, one could argue whether that type of behavior is > > >> >> > > > > overlapping with the > > >> >> > > > > > definition of proxy in RFC3588, but I believe > > >one can mix > > >> >> > > > > > and > > >> >> > > > > match any type > > >> >> > > > > > of functionality in any node as long as > > >interoperability > > >> >> > > > > > is > > >> >> > > not broken. > > >> >> > > > > > > > >> >> > > > > > Thanks, > > >> >> > > > > > Tolga > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > -----Original Message----- > > >> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > >> >> > > > > > > To: Tolga Asveren > > >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org > > >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving > > >> >> strict routing > > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > RFC 3588 has explicit text that prohibits replacing > > >> >> the End-to-End > > >> >> > > > > > > Identifier: > > >> >> > > > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT be modified by > > >> >> > > Diameter agents > > >> >> > > > > > > of any kind." > > >> >> > > > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End > > >> >Identifier AVP, > > >> >> > > > > > > the ultimate receiver of the request message will not > > >> >> able to detect a > > >> >> > > > > > > duplicate request if the original request is routed > > >> >> via the proxy > > >> >> > > > > > > while a dup of the original request is not routed via > > >> >> > > > > > > the > > >> >> > > proxy. For > > >> >> > > > > > > the same reason, Origin-Host AVP should not > > >be modified > > >> >> > > by the proxy. > > >> >> > > > > > > (RFC 3588 has explicit text that prohibits > > >modification > > >> >> > > of Origin-Host > > >> >> > > > > > > AVP by relay agents in Section 6.3, but the > > >text should > > >> >> > > be revised to > > >> >> > > > > > > prohibit modification of Origin-Host AVP by any > > >> >> > > > > > > Diameter > > >> >> > > agents of any > > >> >> > > > > > > kind.) > > >> >> > > > > > > > > >> >> > > > > > > Yoshihiro Ohba > > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > > >> >Asveren wrote: > > >> >> > > > > > > > One quick note on duplicat detection in the setup we > > >> >> > > are discussing: > > >> >> > > > > > > > Proxy probably doesn't need to provide duplicate > > >> >> detection, as > > >> >> > > > > > > long as it > > >> >> > > > > > > > generates a new request for each request it is > > >> >proxying. > > >> >> > > > > the new request > > >> >> > > > > > > > would have a new End-to-ed Identifier assigned > > >> >by the proxy. > > >> >> > > > > > > > > > >> >> > > > > > > > Thanks, > > >> >> > > > > > > > Tolga > > >> >> > > > > > > > > > >> >> > > > > > > > > -----Original Message----- > > >> >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org > > >> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving > > >> >> > > strict routing > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > Hi Tony, > > >> >> > > > > > > > > > > >> >> > > > > > > > > > -----Original Message----- > > >> >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > > >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving > > >> >> > > strict routing > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: > > >> >> > > > > > > > > > (1) Some Request in session are sent by > > >> >> > > server.so should each > > >> >> > > > > > > > > > proxy repalce first request > > >> >> > > Origin-Host/Origin-Realm then maybe > > >> >> > > > > > > > > > will achieve this. > > >> >> > > > > > > > > [TOLGA]That is really a good point. The solution > > >> >> is probably > > >> >> > > > > > > real proxying > > >> >> > > > > > > > > of the requests: Both Origin/Destination AVP > > >> >> > > > > > > > > information > > >> >> > > > > needs to be > > >> >> > > > > > > > > replaced with the identity of the proxy > > >entity. In > > >> >> > > > > > > > > that > > >> >> > > > > > > model, from client > > >> >> > > > > > > > > point of view, it is the proxy which provides the > > >> >> > > > > > > > > service, > > >> >> > > > > > > and this is my > > >> >> > > > > > > > > understanding of a proxy in the generic > > >sense. This > > >> >> > > would mean, > > >> >> > > > > > > > > proxies need > > >> >> > > > > > > > > to provide duplicate detection as well because it > > >> >> relies on > > >> >> > > > > > > > > Origin-Host AVP > > >> >> > > > > > > > > value, but that IMO is logical considering that > > >> >> > > > > > > > > proxy > > >> >> > > > > acts as a node > > >> >> > > > > > > > > providing a service. > > >> >> > > > > > > > > > (2)if client send request to one realm,but > > >> >> > > another realm give > > >> >> > > > > > > > > > answer,maybe will confusion. > > >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from > > >> >> > > > > > > > > protocol > > >> >> > > > > > > mechanics point of > > >> >> > > > > > > > > view. > > >> >> > > > > > > > > > Thanks > > >> >> > > > > > > > > > Tony > > >> >> > > > > > > > > > ----- Original Message ----- > > >> >> > > > > > > > > > From: "Tolga Asveren" > > >> >> > > > > > > > > > To: > > >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > >> >> > > > > > > > > > Subject: [Dime] yet another way of achieving > > >> >> strict routing > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of achiveing > > >> >> > > > > > > > > > > strict > > >> >> > > routing in > > >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the > > >following > > >> >> > > > > > > > > > > came > > >> >> > > > > to my mind: > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly > > >> >> > > > > > > > > > > 2) Stateless intermediaries just relay > > >> >the message > > >> >> > > > > > > > > > > 3) If an intermediary wants to stay > > >in the path > > >> >> > > for a session, > > >> >> > > > > > > > > > it does the > > >> >> > > > > > > > > > > following with the messages for that session: > > >> >> > > > > > > > > > > i- For the first answer, it saves the > > >> >> > > Origin-Host/Origin-Realm > > >> >> > > > > > > > > > AVP values > > >> >> > > > > > > > > > > in the message and replaces them with its own > > >> >> > > > > Host/Realm values. > > >> >> > > > > > > > > > > ii- Subsequent requests received by this > > >> >> > > > > > > > > > > intermediary > > >> >> > > > > > > will have its > > >> >> > > > > > > > > > > Host/Realm value in > > >> >> > > Destination-Host/Destination-Realm AVPs of > > >> >> > > > > > > > > > the request. > > >> >> > > > > > > > > > > They are replaced with the values > > >stored in i-. > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to > > >> >stay on the > > >> >> > > > > path will be > > >> >> > > > > > > > > > stateful, 3) > > >> >> > > > > > > > > > > shouldn't be a problem. > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is explained in > > >> >> > > > > > > > > > > the > > >> >> > > draft, except > > >> >> > > > > > > > > > the state is > > >> >> > > > > > > > > > > kept in proxies rather than in the message. > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > Thanks, > > >> >> > > > > > > > > > > Tolga > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > >_______________________________________________ > > >> >> > > > > > > > > > > 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 > > >> > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 12:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzySu-0006ZO-Nu; Mon, 10 Jul 2006 12:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzySt-0006Z4-Re for dime@ietf.org; Mon, 10 Jul 2006 12:18:31 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzySs-0001bd-RM for dime@ietf.org; Mon, 10 Jul 2006 12:18:31 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F401C5F238; Mon, 10 Jul 2006 12:18:30 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6AGIKPH008391; Mon, 10 Jul 2006 12:18:21 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 11:54:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060710153156.GE7198@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 919970d5fe16e84197d564bf094e8b04 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 Yoshihiro, Afterall, ALG is some piece of software, which will do, whatevery you want it to do. The end-to-end security aware ALG could look just into the AVPs it needs to look for the processing it needs to perform and can leave end-to-end encrypted AVPs as is. I don't see why it must decrypt all those AVPs. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Monday, July 10, 2006 11:32 AM > To: Tolga Asveren > Cc: john.loughney@nokia.com; yohba@tari.toshiba.com; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > Tolga, > > I think you are still mixing up ALG and proxy. The ALG is a really > the termination point of Diameter end-to-end communication, and thus > all encrypted AVPs need to be decrypted by the ALG and passed to the > application. > > Yoshihiro Ohba > > > > On Mon, Jul 10, 2006 at 10:03:40AM -0400, Tolga Asveren wrote: > > John, > > > > I agree that this is a valid concern, which may be applicable > for certain > > configurations. At the end, it will be operators, which decide > for their own > > security needs and they will use necessary tools to achieve it. > > > > One more point regarding this issue, in terms of how that type > of security > > may be provided when using an ALG: > > Actually it is probably no more different than what a proxy > would do. Let's > > say some AVPs are end-to-end encrypted. Those will be directly > included in > > the new message ALG is generating against the server as is, without > > encrytion/decryption. ALG wouldn't need to decrypt them because they > > wouldn't be necessary for the application logic running on the ALG. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > Sent: Monday, July 10, 2006 10:03 AM > > > To: asveren@ulticom.com; yohba@tari.toshiba.com > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > Tolga, > > > > > > Understood. What I am cautioning against is when provider C > > > who is running the Diameter ALG is between two providers - > > > A & B. As it is possible that C could modify Diameter packets > > > without A & B knowing it, potentially mis-representing the actual > > > traffic. During the initial standardization of Diameter, one > > > AD particularly was against proxy mode, for this behavior. > > > end-to-end message encryption is one way to to get around this > > > behavior, so you don't encrypt the transport, just the message > > > contents. > > > > > > If this is a non-issue for users deploying Diameter, then perhaps > > > it is a non-issue. > > > > > > John > > > > > > >-----Original Message----- > > > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > >Sent: 10 July, 2006 09:27 > > > >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com > > > >Cc: dime@ietf.org > > > >Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > >Hi John, > > > > > > > >One important point regarding B2BUA (or ALG or whatever we > > > >want to name it) is that it does not require any changes to > > > >the existing protocol definition, i.e. it is not violating > > > >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a > > > >protocol issue but an administrative/deployment issue whether > > > >one wants to deploy it -and thus IETF can't do anything > about it ;-) -. > > > > > > > >From security point of view, I guess it won't cause a > > > >practical problem for most of the cases. I would think, the > > > >application level processing which needs to be performed on > > > >such nodes -whether it be ALG or proxy- anyhow will require > > > >inspection of AVPs and some preestablished trust relationship. > > > >It could be the case that people want certain AVPs to be > > > >end-to-end secured, but I don't think this will be majority of > > > >the cases and I agree that ALG approach won't provide a > > > >satisfactory solution if that is required. > > > > > > > >I think, it is worthwile to make people aware that this (ALG, B2BCS > > > >[Back-to-Back-Client-Server]) is an option, if it suits their > > > >needs. If mentioning of such functionality wouldn't be blessed > > > >by IETF because it breaks end-to-end security (Actually there > > > >are different ways of seeing this as well, from Diameter Base > > > >Protocol point of view, ALG is and endpoint, well actually two > > > >endpoints and hence does not violate end-to-end security), I > > > >hope this thread was informative enough for people (at least > > > >for me it was). > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > >> -----Original Message----- > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > >> Sent: Monday, July 10, 2006 9:15 AM > > > >> To: asveren@ulticom.com; yohba@tari.toshiba.com > > > >> Cc: dime@ietf.org > > > >> Subject: RE: [Dime] yet another way of achieving strict routing > > > >> > > > >> > > > >> Hi all, > > > >> > > > >> I basically side with Yoshihiro so far. About Diameter "B2BUA" > > > >> funtionality, this would be officially frowned upon in the > > > >IETF, as it > > > >> does cause problems with security. If we would bring back the > > > >> end-to-end security for Diameter (CMS work), then this kind of > > > >> deployment would be easier to digest. > > > >> > > > >> John > > > >> > > > >> >-----Original Message----- > > > >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > >> >Sent: 06 July, 2006 15:58 > > > >> >To: Yoshihiro Ohba > > > >> >Cc: dime@ietf.org > > > >> >Subject: RE: [Dime] yet another way of achieving strict routing > > > >> > > > > >> >Hi Yoshihiro, > > > >> > > > > >> >Yes, it is analogical to a SIP B2BUA. Actually in my > world of ideas > > > >> >this is the definition of a proxy in the generic sense -I am not > > > >> >speaking of SIP/Diameter proxies-: A proxy is an entity, > which acts > > > >> >on behalf of another entity. Proxy as defined in SIP -or > as defined > > > >> >in Diameter- is more a glorified relay node, but I agree with you > > > >> >that the node I describe is not the "proxy" defined in RFC3588. > > > >> >(Diameter proxy is more similar to the concept of proxy in my mind > > > >> >because it has more authority in terms of changing the contents of > > > >> >the message, so I probably would classify it somewhere > > > >between relay > > > >> >and proxy) > > > >> > > > > >> >IMHO, this is not orthogonal to strict routing issue because it is > > > >> >one way of dealing with scenarios presented as the reason > > > >for strict > > > >> >routing. > > > >> >Actually, if one considers the application logic running on such > > > >> >nodes, it seems to me a reasonable solution but picking one > > > >approach > > > >> >over another one is obviously an implementation decision. > > > >> > > > > >> > Thanks, > > > >> > Tolga > > > >> > > > > >> >> -----Original Message----- > > > >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > >> >> Sent: Thursday, July 06, 2006 4:02 PM > > > >> >> To: Tolga Asveren > > > >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > >> >> Subject: Re: [Dime] yet another way of achieving strict routing > > > >> >> > > > >> >> > > > >> >> Hi Tolga, > > > >> >> > > > >> >> Is the sceanario you described is an application layer > > > >gateway for > > > >> >> (like SIP B2BUA)? If so, we should not mix it up with a > > > >proxy and > > > >> >> I believe it is orthogonal to the strict routing issue. > > > >> >> > > > >> >> Yoshihiro Ohba > > > >> >> > > > >> >> > > > >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > > > >> >> > O.K., now I got what you mean. And yes, this will be a problem > > > >> >> unless B and > > > >> >> > C work in a synchronized way, where they share state. I > > > >> >think, this > > > >> >> > they need to do anyhow, because they keep some > application level > > > >> >> state, otherwise > > > >> >> > they wouldn't want to stay on the path. Basically, in > the model > > > >> >> I described, > > > >> >> > B and C act as endnodes. If there are intermediaries, > > > >which don't > > > >> >> > share state, I would expect them to abort the session after a > > > >> >> failover -when they > > > >> >> > receive messages for an unknown session-, because they can't > > > >> >> perform their > > > >> >> > application level processing regarding that session. > > > >> >> > > > > >> >> > Thanks, > > > >> >> > Tolga > > > >> >> > > > > >> >> > > -----Original Message----- > > > >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > >> >> > > Sent: Thursday, July 06, 2006 1:59 PM > > > >> >> > > To: Tolga Asveren > > > >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > >> >> > > Subject: Re: [Dime] yet another way of achieving > > > >strict routing > > > >> >> > > > > > >> >> > > > > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga > Asveren wrote: > > > >> >> > > > If the intermediary node uses the same End-to-End > > > >> >identifier for > > > >> >> > > > the original and retransmission request, this > shouldn't be a > > > >> >> problem. Server > > > >> >> > > > would receive two requests with the same Origin-Host and > > > >> >> > > End-to-End values > > > >> >> > > > and could detect the duplicate. > > > >> >> > > > > > >> >> > > You are assuming that the two requests go through the same > > > >> >> > > intermediary, which is not always true. Retransmission can > > > >> >> > > also happen at the original sender. > > > >> >> > > > > > >> >> > > +-----B----+ > > > >> >> > > / \ > > > >> >> > > A D > > > >> >> > > \ / > > > >> >> > > +-----C----+ > > > >> >> > > > > > >> >> > > Assume that the orignial request is forwarded A->B->D. > > > >> >> > > > > > >> >> > > If failover happens at A, A may retransmit the request to a > > > >> >> > > different path, say A->C->D. > > > >> >> > > > > > >> >> > > If B modifies the Origin-Host and End-to-End values of the > > > >> >> > > original request, the original and retransmitted > > > >requests will > > > >> >> > > have different Origin-Host or End-to-End values. > This is the > > > >> >> > > problem I was mentioning. > > > >> >> > > > > > >> >> > > Yoshihiro Ohba > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > -----Original Message----- > > > >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > > > >> >> > > > > To: Tolga Asveren > > > >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > >> >> > > > > Subject: Re: [Dime] yet another way of achieving strict > > > >> >> > > > > routing > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > Allowing a Diameter node to creates a request with > > > >> >> > > > > modifying End-to-End Identifier and Origin-Host AVP can > > > >> >> > > > > break > > > >> >> interoperability, > > > >> >> > > > > because the server cannot distinguish the original > > > >> >request and > > > >> >> > > > > the modified request. As a result, the server > > > >will process > > > >> >> > > > > the two requests differently and generate two different > > > >> >> > > > > answers > > > >> >> as oppose to > > > >> >> > > > > the original requester's expectation that only one > > > >> >> request should be > > > >> >> > > > > processed by a given server and that no multiple > > > >> >> > > > > non-duplicated answers are received for the > same request. > > > >> >> > > > > > > > >> >> > > > > Yoshihiro Ohba > > > >> >> > > > > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > > > >> >Asveren wrote: > > > >> >> > > > > > Hi Yoshihiro, > > > >> >> > > > > > > > > >> >> > > > > > If the proxy creates a corresponding but new > > > >request for > > > >> >> > > > > > a > > > >> >> > > request it is > > > >> >> > > > > > proxying, I don't see why there should be a > problem from > > > >> >> > > > > duplicate detection > > > >> >> > > > > > point of view. In that case, there are two Diameter > > > >> >> > > > > > signaling > > > >> >> > > > > relationships, > > > >> >> > > > > > one between the client and the proxy and the other one > > > >> >> > > > > > between > > > >> >> > > > > the proxy and > > > >> >> > > > > > the server, i.e. client sees proxy as server > and server > > > >> >> > > sees proxy as > > > >> >> > > > > > client. > > > >> >> > > > > > > > > >> >> > > > > > OTOH, one could argue whether that type of behavior is > > > >> >> > > > > overlapping with the > > > >> >> > > > > > definition of proxy in RFC3588, but I believe > > > >one can mix > > > >> >> > > > > > and > > > >> >> > > > > match any type > > > >> >> > > > > > of functionality in any node as long as > > > >interoperability > > > >> >> > > > > > is > > > >> >> > > not broken. > > > >> >> > > > > > > > > >> >> > > > > > Thanks, > > > >> >> > > > > > Tolga > > > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > > > -----Original Message----- > > > >> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > >> >> > > > > > > To: Tolga Asveren > > > >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org > > > >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving > > > >> >> strict routing > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > RFC 3588 has explicit text that prohibits replacing > > > >> >> the End-to-End > > > >> >> > > > > > > Identifier: > > > >> >> > > > > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT be modified by > > > >> >> > > Diameter agents > > > >> >> > > > > > > of any kind." > > > >> >> > > > > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End > > > >> >Identifier AVP, > > > >> >> > > > > > > the ultimate receiver of the request > message will not > > > >> >> able to detect a > > > >> >> > > > > > > duplicate request if the original request is routed > > > >> >> via the proxy > > > >> >> > > > > > > while a dup of the original request is not > routed via > > > >> >> > > > > > > the > > > >> >> > > proxy. For > > > >> >> > > > > > > the same reason, Origin-Host AVP should not > > > >be modified > > > >> >> > > by the proxy. > > > >> >> > > > > > > (RFC 3588 has explicit text that prohibits > > > >modification > > > >> >> > > of Origin-Host > > > >> >> > > > > > > AVP by relay agents in Section 6.3, but the > > > >text should > > > >> >> > > be revised to > > > >> >> > > > > > > prohibit modification of Origin-Host AVP by any > > > >> >> > > > > > > Diameter > > > >> >> > > agents of any > > > >> >> > > > > > > kind.) > > > >> >> > > > > > > > > > >> >> > > > > > > Yoshihiro Ohba > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > > > >> >Asveren wrote: > > > >> >> > > > > > > > One quick note on duplicat detection in > the setup we > > > >> >> > > are discussing: > > > >> >> > > > > > > > Proxy probably doesn't need to provide duplicate > > > >> >> detection, as > > > >> >> > > > > > > long as it > > > >> >> > > > > > > > generates a new request for each request it is > > > >> >proxying. > > > >> >> > > > > the new request > > > >> >> > > > > > > > would have a new End-to-ed Identifier assigned > > > >> >by the proxy. > > > >> >> > > > > > > > > > > >> >> > > > > > > > Thanks, > > > >> >> > > > > > > > Tolga > > > >> >> > > > > > > > > > > >> >> > > > > > > > > -----Original Message----- > > > >> >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org > > > >> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving > > > >> >> > > strict routing > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > Hi Tony, > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > -----Original Message----- > > > >> >> > > > > > > > > > From: Tony Zhang > [mailto:zhangtao_hw@huawei.com] > > > >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way > of achieving > > > >> >> > > strict routing > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: > > > >> >> > > > > > > > > > (1) Some Request in session are sent by > > > >> >> > > server.so should each > > > >> >> > > > > > > > > > proxy repalce first request > > > >> >> > > Origin-Host/Origin-Realm then maybe > > > >> >> > > > > > > > > > will achieve this. > > > >> >> > > > > > > > > [TOLGA]That is really a good point. The solution > > > >> >> is probably > > > >> >> > > > > > > real proxying > > > >> >> > > > > > > > > of the requests: Both Origin/Destination AVP > > > >> >> > > > > > > > > information > > > >> >> > > > > needs to be > > > >> >> > > > > > > > > replaced with the identity of the proxy > > > >entity. In > > > >> >> > > > > > > > > that > > > >> >> > > > > > > model, from client > > > >> >> > > > > > > > > point of view, it is the proxy which > provides the > > > >> >> > > > > > > > > service, > > > >> >> > > > > > > and this is my > > > >> >> > > > > > > > > understanding of a proxy in the generic > > > >sense. This > > > >> >> > > would mean, > > > >> >> > > > > > > > > proxies need > > > >> >> > > > > > > > > to provide duplicate detection as well > because it > > > >> >> relies on > > > >> >> > > > > > > > > Origin-Host AVP > > > >> >> > > > > > > > > value, but that IMO is logical considering that > > > >> >> > > > > > > > > proxy > > > >> >> > > > > acts as a node > > > >> >> > > > > > > > > providing a service. > > > >> >> > > > > > > > > > (2)if client send request to one realm,but > > > >> >> > > another realm give > > > >> >> > > > > > > > > > answer,maybe will confusion. > > > >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from > > > >> >> > > > > > > > > protocol > > > >> >> > > > > > > mechanics point of > > > >> >> > > > > > > > > view. > > > >> >> > > > > > > > > > Thanks > > > >> >> > > > > > > > > > Tony > > > >> >> > > > > > > > > > ----- Original Message ----- > > > >> >> > > > > > > > > > From: "Tolga Asveren" > > > >> >> > > > > > > > > > To: > > > >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > >> >> > > > > > > > > > Subject: [Dime] yet another way of achieving > > > >> >> strict routing > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of achiveing > > > >> >> > > > > > > > > > > strict > > > >> >> > > routing in > > > >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the > > > >following > > > >> >> > > > > > > > > > > came > > > >> >> > > > > to my mind: > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly > > > >> >> > > > > > > > > > > 2) Stateless intermediaries just relay > > > >> >the message > > > >> >> > > > > > > > > > > 3) If an intermediary wants to stay > > > >in the path > > > >> >> > > for a session, > > > >> >> > > > > > > > > > it does the > > > >> >> > > > > > > > > > > following with the messages for > that session: > > > >> >> > > > > > > > > > > i- For the first answer, it saves the > > > >> >> > > Origin-Host/Origin-Realm > > > >> >> > > > > > > > > > AVP values > > > >> >> > > > > > > > > > > in the message and replaces them > with its own > > > >> >> > > > > Host/Realm values. > > > >> >> > > > > > > > > > > ii- Subsequent requests received by this > > > >> >> > > > > > > > > > > intermediary > > > >> >> > > > > > > will have its > > > >> >> > > > > > > > > > > Host/Realm value in > > > >> >> > > Destination-Host/Destination-Realm AVPs of > > > >> >> > > > > > > > > > the request. > > > >> >> > > > > > > > > > > They are replaced with the values > > > >stored in i-. > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to > > > >> >stay on the > > > >> >> > > > > path will be > > > >> >> > > > > > > > > > stateful, 3) > > > >> >> > > > > > > > > > > shouldn't be a problem. > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is explained in > > > >> >> > > > > > > > > > > the > > > >> >> > > draft, except > > > >> >> > > > > > > > > > the state is > > > >> >> > > > > > > > > > > kept in proxies rather than in the message. > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > Thanks, > > > >> >> > > > > > > > > > > Tolga > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >_______________________________________________ > > > >> >> > > > > > > > > > > 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 > > > >> > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 13:27:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzXp-0008Ah-Fq; Mon, 10 Jul 2006 13:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzXn-0008AT-L9 for dime@ietf.org; Mon, 10 Jul 2006 13:27:39 -0400 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 1FzzXm-0005zm-KY for dime@ietf.org; Mon, 10 Jul 2006 13:27:39 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6AHQxMw031971; Mon, 10 Jul 2006 13:27:00 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Mon, 10 Jul 2006 13:26:49 -0400 To: Tolga Asveren Subject: Re: [Dime] yet another way of achieving strict routing Message-ID: <20060710172649.GA8886@steelhead> References: <20060710153156.GE7198@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 554 X-Spam-Score: -2.4 (--) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 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 guess you are assuming Diameter-application layer encryption which works across DIameter ALG. That would need a new Diameter application with its own security that can work across ALG. I'd suggest not discuss it unless you really want to standardize it. I feel we are not doing productive discusion here. Yoshihiro Ohba On Mon, Jul 10, 2006 at 11:54:39AM -0400, Tolga Asveren wrote: > Yoshihiro, > > Afterall, ALG is some piece of software, which will do, whatevery you want > it to do. The end-to-end security aware ALG could look just into the AVPs it > needs to look for the processing it needs to perform and can leave > end-to-end encrypted AVPs as is. I don't see why it must decrypt all those > AVPs. > > Thanks, > Tolga > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Monday, July 10, 2006 11:32 AM > > To: Tolga Asveren > > Cc: john.loughney@nokia.com; yohba@tari.toshiba.com; dime@ietf.org > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > Tolga, > > > > I think you are still mixing up ALG and proxy. The ALG is a really > > the termination point of Diameter end-to-end communication, and thus > > all encrypted AVPs need to be decrypted by the ALG and passed to the > > application. > > > > Yoshihiro Ohba > > > > > > > > On Mon, Jul 10, 2006 at 10:03:40AM -0400, Tolga Asveren wrote: > > > John, > > > > > > I agree that this is a valid concern, which may be applicable > > for certain > > > configurations. At the end, it will be operators, which decide > > for their own > > > security needs and they will use necessary tools to achieve it. > > > > > > One more point regarding this issue, in terms of how that type > > of security > > > may be provided when using an ALG: > > > Actually it is probably no more different than what a proxy > > would do. Let's > > > say some AVPs are end-to-end encrypted. Those will be directly > > included in > > > the new message ALG is generating against the server as is, without > > > encrytion/decryption. ALG wouldn't need to decrypt them because they > > > wouldn't be necessary for the application logic running on the ALG. > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > Sent: Monday, July 10, 2006 10:03 AM > > > > To: asveren@ulticom.com; yohba@tari.toshiba.com > > > > Cc: dime@ietf.org > > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > Tolga, > > > > > > > > Understood. What I am cautioning against is when provider C > > > > who is running the Diameter ALG is between two providers - > > > > A & B. As it is possible that C could modify Diameter packets > > > > without A & B knowing it, potentially mis-representing the actual > > > > traffic. During the initial standardization of Diameter, one > > > > AD particularly was against proxy mode, for this behavior. > > > > end-to-end message encryption is one way to to get around this > > > > behavior, so you don't encrypt the transport, just the message > > > > contents. > > > > > > > > If this is a non-issue for users deploying Diameter, then perhaps > > > > it is a non-issue. > > > > > > > > John > > > > > > > > >-----Original Message----- > > > > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > > >Sent: 10 July, 2006 09:27 > > > > >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com > > > > >Cc: dime@ietf.org > > > > >Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > >Hi John, > > > > > > > > > >One important point regarding B2BUA (or ALG or whatever we > > > > >want to name it) is that it does not require any changes to > > > > >the existing protocol definition, i.e. it is not violating > > > > >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a > > > > >protocol issue but an administrative/deployment issue whether > > > > >one wants to deploy it -and thus IETF can't do anything > > about it ;-) -. > > > > > > > > > >From security point of view, I guess it won't cause a > > > > >practical problem for most of the cases. I would think, the > > > > >application level processing which needs to be performed on > > > > >such nodes -whether it be ALG or proxy- anyhow will require > > > > >inspection of AVPs and some preestablished trust relationship. > > > > >It could be the case that people want certain AVPs to be > > > > >end-to-end secured, but I don't think this will be majority of > > > > >the cases and I agree that ALG approach won't provide a > > > > >satisfactory solution if that is required. > > > > > > > > > >I think, it is worthwile to make people aware that this (ALG, B2BCS > > > > >[Back-to-Back-Client-Server]) is an option, if it suits their > > > > >needs. If mentioning of such functionality wouldn't be blessed > > > > >by IETF because it breaks end-to-end security (Actually there > > > > >are different ways of seeing this as well, from Diameter Base > > > > >Protocol point of view, ALG is and endpoint, well actually two > > > > >endpoints and hence does not violate end-to-end security), I > > > > >hope this thread was informative enough for people (at least > > > > >for me it was). > > > > > > > > > > Thanks, > > > > > Tolga > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > >> Sent: Monday, July 10, 2006 9:15 AM > > > > >> To: asveren@ulticom.com; yohba@tari.toshiba.com > > > > >> Cc: dime@ietf.org > > > > >> Subject: RE: [Dime] yet another way of achieving strict routing > > > > >> > > > > >> > > > > >> Hi all, > > > > >> > > > > >> I basically side with Yoshihiro so far. About Diameter "B2BUA" > > > > >> funtionality, this would be officially frowned upon in the > > > > >IETF, as it > > > > >> does cause problems with security. If we would bring back the > > > > >> end-to-end security for Diameter (CMS work), then this kind of > > > > >> deployment would be easier to digest. > > > > >> > > > > >> John > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > > >> >Sent: 06 July, 2006 15:58 > > > > >> >To: Yoshihiro Ohba > > > > >> >Cc: dime@ietf.org > > > > >> >Subject: RE: [Dime] yet another way of achieving strict routing > > > > >> > > > > > >> >Hi Yoshihiro, > > > > >> > > > > > >> >Yes, it is analogical to a SIP B2BUA. Actually in my > > world of ideas > > > > >> >this is the definition of a proxy in the generic sense -I am not > > > > >> >speaking of SIP/Diameter proxies-: A proxy is an entity, > > which acts > > > > >> >on behalf of another entity. Proxy as defined in SIP -or > > as defined > > > > >> >in Diameter- is more a glorified relay node, but I agree with you > > > > >> >that the node I describe is not the "proxy" defined in RFC3588. > > > > >> >(Diameter proxy is more similar to the concept of proxy in my mind > > > > >> >because it has more authority in terms of changing the contents of > > > > >> >the message, so I probably would classify it somewhere > > > > >between relay > > > > >> >and proxy) > > > > >> > > > > > >> >IMHO, this is not orthogonal to strict routing issue because it is > > > > >> >one way of dealing with scenarios presented as the reason > > > > >for strict > > > > >> >routing. > > > > >> >Actually, if one considers the application logic running on such > > > > >> >nodes, it seems to me a reasonable solution but picking one > > > > >approach > > > > >> >over another one is obviously an implementation decision. > > > > >> > > > > > >> > Thanks, > > > > >> > Tolga > > > > >> > > > > > >> >> -----Original Message----- > > > > >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > >> >> Sent: Thursday, July 06, 2006 4:02 PM > > > > >> >> To: Tolga Asveren > > > > >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > >> >> Subject: Re: [Dime] yet another way of achieving strict routing > > > > >> >> > > > > >> >> > > > > >> >> Hi Tolga, > > > > >> >> > > > > >> >> Is the sceanario you described is an application layer > > > > >gateway for > > > > >> >> (like SIP B2BUA)? If so, we should not mix it up with a > > > > >proxy and > > > > >> >> I believe it is orthogonal to the strict routing issue. > > > > >> >> > > > > >> >> Yoshihiro Ohba > > > > >> >> > > > > >> >> > > > > >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > > > > >> >> > O.K., now I got what you mean. And yes, this will be a problem > > > > >> >> unless B and > > > > >> >> > C work in a synchronized way, where they share state. I > > > > >> >think, this > > > > >> >> > they need to do anyhow, because they keep some > > application level > > > > >> >> state, otherwise > > > > >> >> > they wouldn't want to stay on the path. Basically, in > > the model > > > > >> >> I described, > > > > >> >> > B and C act as endnodes. If there are intermediaries, > > > > >which don't > > > > >> >> > share state, I would expect them to abort the session after a > > > > >> >> failover -when they > > > > >> >> > receive messages for an unknown session-, because they can't > > > > >> >> perform their > > > > >> >> > application level processing regarding that session. > > > > >> >> > > > > > >> >> > Thanks, > > > > >> >> > Tolga > > > > >> >> > > > > > >> >> > > -----Original Message----- > > > > >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > >> >> > > Sent: Thursday, July 06, 2006 1:59 PM > > > > >> >> > > To: Tolga Asveren > > > > >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > >> >> > > Subject: Re: [Dime] yet another way of achieving > > > > >strict routing > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga > > Asveren wrote: > > > > >> >> > > > If the intermediary node uses the same End-to-End > > > > >> >identifier for > > > > >> >> > > > the original and retransmission request, this > > shouldn't be a > > > > >> >> problem. Server > > > > >> >> > > > would receive two requests with the same Origin-Host and > > > > >> >> > > End-to-End values > > > > >> >> > > > and could detect the duplicate. > > > > >> >> > > > > > > >> >> > > You are assuming that the two requests go through the same > > > > >> >> > > intermediary, which is not always true. Retransmission can > > > > >> >> > > also happen at the original sender. > > > > >> >> > > > > > > >> >> > > +-----B----+ > > > > >> >> > > / \ > > > > >> >> > > A D > > > > >> >> > > \ / > > > > >> >> > > +-----C----+ > > > > >> >> > > > > > > >> >> > > Assume that the orignial request is forwarded A->B->D. > > > > >> >> > > > > > > >> >> > > If failover happens at A, A may retransmit the request to a > > > > >> >> > > different path, say A->C->D. > > > > >> >> > > > > > > >> >> > > If B modifies the Origin-Host and End-to-End values of the > > > > >> >> > > original request, the original and retransmitted > > > > >requests will > > > > >> >> > > have different Origin-Host or End-to-End values. > > This is the > > > > >> >> > > problem I was mentioning. > > > > >> >> > > > > > > >> >> > > Yoshihiro Ohba > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > -----Original Message----- > > > > >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > > > > >> >> > > > > To: Tolga Asveren > > > > >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > >> >> > > > > Subject: Re: [Dime] yet another way of achieving strict > > > > >> >> > > > > routing > > > > >> >> > > > > > > > > >> >> > > > > > > > > >> >> > > > > Allowing a Diameter node to creates a request with > > > > >> >> > > > > modifying End-to-End Identifier and Origin-Host AVP can > > > > >> >> > > > > break > > > > >> >> interoperability, > > > > >> >> > > > > because the server cannot distinguish the original > > > > >> >request and > > > > >> >> > > > > the modified request. As a result, the server > > > > >will process > > > > >> >> > > > > the two requests differently and generate two different > > > > >> >> > > > > answers > > > > >> >> as oppose to > > > > >> >> > > > > the original requester's expectation that only one > > > > >> >> request should be > > > > >> >> > > > > processed by a given server and that no multiple > > > > >> >> > > > > non-duplicated answers are received for the > > same request. > > > > >> >> > > > > > > > > >> >> > > > > Yoshihiro Ohba > > > > >> >> > > > > > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > > > > >> >Asveren wrote: > > > > >> >> > > > > > Hi Yoshihiro, > > > > >> >> > > > > > > > > > >> >> > > > > > If the proxy creates a corresponding but new > > > > >request for > > > > >> >> > > > > > a > > > > >> >> > > request it is > > > > >> >> > > > > > proxying, I don't see why there should be a > > problem from > > > > >> >> > > > > duplicate detection > > > > >> >> > > > > > point of view. In that case, there are two Diameter > > > > >> >> > > > > > signaling > > > > >> >> > > > > relationships, > > > > >> >> > > > > > one between the client and the proxy and the other one > > > > >> >> > > > > > between > > > > >> >> > > > > the proxy and > > > > >> >> > > > > > the server, i.e. client sees proxy as server > > and server > > > > >> >> > > sees proxy as > > > > >> >> > > > > > client. > > > > >> >> > > > > > > > > > >> >> > > > > > OTOH, one could argue whether that type of behavior is > > > > >> >> > > > > overlapping with the > > > > >> >> > > > > > definition of proxy in RFC3588, but I believe > > > > >one can mix > > > > >> >> > > > > > and > > > > >> >> > > > > match any type > > > > >> >> > > > > > of functionality in any node as long as > > > > >interoperability > > > > >> >> > > > > > is > > > > >> >> > > not broken. > > > > >> >> > > > > > > > > > >> >> > > > > > Thanks, > > > > >> >> > > > > > Tolga > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > -----Original Message----- > > > > >> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > >> >> > > > > > > To: Tolga Asveren > > > > >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org > > > > >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving > > > > >> >> strict routing > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > RFC 3588 has explicit text that prohibits replacing > > > > >> >> the End-to-End > > > > >> >> > > > > > > Identifier: > > > > >> >> > > > > > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT be modified by > > > > >> >> > > Diameter agents > > > > >> >> > > > > > > of any kind." > > > > >> >> > > > > > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End > > > > >> >Identifier AVP, > > > > >> >> > > > > > > the ultimate receiver of the request > > message will not > > > > >> >> able to detect a > > > > >> >> > > > > > > duplicate request if the original request is routed > > > > >> >> via the proxy > > > > >> >> > > > > > > while a dup of the original request is not > > routed via > > > > >> >> > > > > > > the > > > > >> >> > > proxy. For > > > > >> >> > > > > > > the same reason, Origin-Host AVP should not > > > > >be modified > > > > >> >> > > by the proxy. > > > > >> >> > > > > > > (RFC 3588 has explicit text that prohibits > > > > >modification > > > > >> >> > > of Origin-Host > > > > >> >> > > > > > > AVP by relay agents in Section 6.3, but the > > > > >text should > > > > >> >> > > be revised to > > > > >> >> > > > > > > prohibit modification of Origin-Host AVP by any > > > > >> >> > > > > > > Diameter > > > > >> >> > > agents of any > > > > >> >> > > > > > > kind.) > > > > >> >> > > > > > > > > > > >> >> > > > > > > Yoshihiro Ohba > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > > > > >> >Asveren wrote: > > > > >> >> > > > > > > > One quick note on duplicat detection in > > the setup we > > > > >> >> > > are discussing: > > > > >> >> > > > > > > > Proxy probably doesn't need to provide duplicate > > > > >> >> detection, as > > > > >> >> > > > > > > long as it > > > > >> >> > > > > > > > generates a new request for each request it is > > > > >> >proxying. > > > > >> >> > > > > the new request > > > > >> >> > > > > > > > would have a new End-to-ed Identifier assigned > > > > >> >by the proxy. > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > Thanks, > > > > >> >> > > > > > > > Tolga > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > -----Original Message----- > > > > >> >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > > > >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org > > > > >> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving > > > > >> >> > > strict routing > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > Hi Tony, > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > > -----Original Message----- > > > > >> >> > > > > > > > > > From: Tony Zhang > > [mailto:zhangtao_hw@huawei.com] > > > > >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way > > of achieving > > > > >> >> > > strict routing > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: > > > > >> >> > > > > > > > > > (1) Some Request in session are sent by > > > > >> >> > > server.so should each > > > > >> >> > > > > > > > > > proxy repalce first request > > > > >> >> > > Origin-Host/Origin-Realm then maybe > > > > >> >> > > > > > > > > > will achieve this. > > > > >> >> > > > > > > > > [TOLGA]That is really a good point. The solution > > > > >> >> is probably > > > > >> >> > > > > > > real proxying > > > > >> >> > > > > > > > > of the requests: Both Origin/Destination AVP > > > > >> >> > > > > > > > > information > > > > >> >> > > > > needs to be > > > > >> >> > > > > > > > > replaced with the identity of the proxy > > > > >entity. In > > > > >> >> > > > > > > > > that > > > > >> >> > > > > > > model, from client > > > > >> >> > > > > > > > > point of view, it is the proxy which > > provides the > > > > >> >> > > > > > > > > service, > > > > >> >> > > > > > > and this is my > > > > >> >> > > > > > > > > understanding of a proxy in the generic > > > > >sense. This > > > > >> >> > > would mean, > > > > >> >> > > > > > > > > proxies need > > > > >> >> > > > > > > > > to provide duplicate detection as well > > because it > > > > >> >> relies on > > > > >> >> > > > > > > > > Origin-Host AVP > > > > >> >> > > > > > > > > value, but that IMO is logical considering that > > > > >> >> > > > > > > > > proxy > > > > >> >> > > > > acts as a node > > > > >> >> > > > > > > > > providing a service. > > > > >> >> > > > > > > > > > (2)if client send request to one realm,but > > > > >> >> > > another realm give > > > > >> >> > > > > > > > > > answer,maybe will confusion. > > > > >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from > > > > >> >> > > > > > > > > protocol > > > > >> >> > > > > > > mechanics point of > > > > >> >> > > > > > > > > view. > > > > >> >> > > > > > > > > > Thanks > > > > >> >> > > > > > > > > > Tony > > > > >> >> > > > > > > > > > ----- Original Message ----- > > > > >> >> > > > > > > > > > From: "Tolga Asveren" > > > > >> >> > > > > > > > > > To: > > > > >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > >> >> > > > > > > > > > Subject: [Dime] yet another way of achieving > > > > >> >> strict routing > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of achiveing > > > > >> >> > > > > > > > > > > strict > > > > >> >> > > routing in > > > > >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the > > > > >following > > > > >> >> > > > > > > > > > > came > > > > >> >> > > > > to my mind: > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly > > > > >> >> > > > > > > > > > > 2) Stateless intermediaries just relay > > > > >> >the message > > > > >> >> > > > > > > > > > > 3) If an intermediary wants to stay > > > > >in the path > > > > >> >> > > for a session, > > > > >> >> > > > > > > > > > it does the > > > > >> >> > > > > > > > > > > following with the messages for > > that session: > > > > >> >> > > > > > > > > > > i- For the first answer, it saves the > > > > >> >> > > Origin-Host/Origin-Realm > > > > >> >> > > > > > > > > > AVP values > > > > >> >> > > > > > > > > > > in the message and replaces them > > with its own > > > > >> >> > > > > Host/Realm values. > > > > >> >> > > > > > > > > > > ii- Subsequent requests received by this > > > > >> >> > > > > > > > > > > intermediary > > > > >> >> > > > > > > will have its > > > > >> >> > > > > > > > > > > Host/Realm value in > > > > >> >> > > Destination-Host/Destination-Realm AVPs of > > > > >> >> > > > > > > > > > the request. > > > > >> >> > > > > > > > > > > They are replaced with the values > > > > >stored in i-. > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to > > > > >> >stay on the > > > > >> >> > > > > path will be > > > > >> >> > > > > > > > > > stateful, 3) > > > > >> >> > > > > > > > > > > shouldn't be a problem. > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is explained in > > > > >> >> > > > > > > > > > > the > > > > >> >> > > draft, except > > > > >> >> > > > > > > > > > the state is > > > > >> >> > > > > > > > > > > kept in proxies rather than in the message. > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > Thanks, > > > > >> >> > > > > > > > > > > Tolga > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >_______________________________________________ > > > > >> >> > > > > > > > > > > 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 > > > > >> > > > > > > > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 13:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzzca-0000M5-EW; Mon, 10 Jul 2006 13:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzcZ-0000Lv-4L for dime@ietf.org; Mon, 10 Jul 2006 13:32:35 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzcY-0006Jw-6L for dime@ietf.org; Mon, 10 Jul 2006 13:32:35 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 47D0126B59; Mon, 10 Jul 2006 13:32:33 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6AHW1a4014625; Mon, 10 Jul 2006 13:32:02 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" Subject: RE: [Dime] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 13:08:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20060710172649.GA8886@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f9ac37b081a3249085c4867ee1404d4 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 am not assuming a specific encryption type. My only assumption is if a proxy can copy certain encrypted AVPs as is, an ALG can do it as well. I don't think this requires to define something specifically for ALG case. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Monday, July 10, 2006 1:27 PM > To: Tolga Asveren > Cc: Yoshihiro Ohba; john.loughney@nokia.com; dime@ietf.org > Subject: Re: [Dime] yet another way of achieving strict routing > > > I guess you are assuming Diameter-application layer encryption which > works across DIameter ALG. That would need a new Diameter application > with its own security that can work across ALG. I'd suggest not > discuss it unless you really want to standardize it. I feel we are not > doing productive discusion here. > > Yoshihiro Ohba > > > On Mon, Jul 10, 2006 at 11:54:39AM -0400, Tolga Asveren wrote: > > Yoshihiro, > > > > Afterall, ALG is some piece of software, which will do, > whatevery you want > > it to do. The end-to-end security aware ALG could look just > into the AVPs it > > needs to look for the processing it needs to perform and can leave > > end-to-end encrypted AVPs as is. I don't see why it must > decrypt all those > > AVPs. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Monday, July 10, 2006 11:32 AM > > > To: Tolga Asveren > > > Cc: john.loughney@nokia.com; yohba@tari.toshiba.com; dime@ietf.org > > > Subject: Re: [Dime] yet another way of achieving strict routing > > > > > > > > > Tolga, > > > > > > I think you are still mixing up ALG and proxy. The ALG is a really > > > the termination point of Diameter end-to-end communication, and thus > > > all encrypted AVPs need to be decrypted by the ALG and passed to the > > > application. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Mon, Jul 10, 2006 at 10:03:40AM -0400, Tolga Asveren wrote: > > > > John, > > > > > > > > I agree that this is a valid concern, which may be applicable > > > for certain > > > > configurations. At the end, it will be operators, which decide > > > for their own > > > > security needs and they will use necessary tools to achieve it. > > > > > > > > One more point regarding this issue, in terms of how that type > > > of security > > > > may be provided when using an ALG: > > > > Actually it is probably no more different than what a proxy > > > would do. Let's > > > > say some AVPs are end-to-end encrypted. Those will be directly > > > included in > > > > the new message ALG is generating against the server as is, without > > > > encrytion/decryption. ALG wouldn't need to decrypt them because they > > > > wouldn't be necessary for the application logic running on the ALG. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > -----Original Message----- > > > > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > > Sent: Monday, July 10, 2006 10:03 AM > > > > > To: asveren@ulticom.com; yohba@tari.toshiba.com > > > > > Cc: dime@ietf.org > > > > > Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > > > > > Tolga, > > > > > > > > > > Understood. What I am cautioning against is when provider C > > > > > who is running the Diameter ALG is between two providers - > > > > > A & B. As it is possible that C could modify Diameter packets > > > > > without A & B knowing it, potentially mis-representing the actual > > > > > traffic. During the initial standardization of Diameter, one > > > > > AD particularly was against proxy mode, for this behavior. > > > > > end-to-end message encryption is one way to to get around this > > > > > behavior, so you don't encrypt the transport, just the message > > > > > contents. > > > > > > > > > > If this is a non-issue for users deploying Diameter, then perhaps > > > > > it is a non-issue. > > > > > > > > > > John > > > > > > > > > > >-----Original Message----- > > > > > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > > > >Sent: 10 July, 2006 09:27 > > > > > >To: Loughney John (Nokia-NRC/Helsinki); yohba@tari.toshiba.com > > > > > >Cc: dime@ietf.org > > > > > >Subject: RE: [Dime] yet another way of achieving strict routing > > > > > > > > > > > >Hi John, > > > > > > > > > > > >One important point regarding B2BUA (or ALG or whatever we > > > > > >want to name it) is that it does not require any changes to > > > > > >the existing protocol definition, i.e. it is not violating > > > > > >on-the-wire aspects of RFC3588 AFAICS. Basically it is not a > > > > > >protocol issue but an administrative/deployment issue whether > > > > > >one wants to deploy it -and thus IETF can't do anything > > > about it ;-) -. > > > > > > > > > > > >From security point of view, I guess it won't cause a > > > > > >practical problem for most of the cases. I would think, the > > > > > >application level processing which needs to be performed on > > > > > >such nodes -whether it be ALG or proxy- anyhow will require > > > > > >inspection of AVPs and some preestablished trust relationship. > > > > > >It could be the case that people want certain AVPs to be > > > > > >end-to-end secured, but I don't think this will be majority of > > > > > >the cases and I agree that ALG approach won't provide a > > > > > >satisfactory solution if that is required. > > > > > > > > > > > >I think, it is worthwile to make people aware that this > (ALG, B2BCS > > > > > >[Back-to-Back-Client-Server]) is an option, if it suits their > > > > > >needs. If mentioning of such functionality wouldn't be blessed > > > > > >by IETF because it breaks end-to-end security (Actually there > > > > > >are different ways of seeing this as well, from Diameter Base > > > > > >Protocol point of view, ALG is and endpoint, well actually two > > > > > >endpoints and hence does not violate end-to-end security), I > > > > > >hope this thread was informative enough for people (at least > > > > > >for me it was). > > > > > > > > > > > > Thanks, > > > > > > Tolga > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > > > > >> Sent: Monday, July 10, 2006 9:15 AM > > > > > >> To: asveren@ulticom.com; yohba@tari.toshiba.com > > > > > >> Cc: dime@ietf.org > > > > > >> Subject: RE: [Dime] yet another way of achieving strict routing > > > > > >> > > > > > >> > > > > > >> Hi all, > > > > > >> > > > > > >> I basically side with Yoshihiro so far. About Diameter "B2BUA" > > > > > >> funtionality, this would be officially frowned upon in the > > > > > >IETF, as it > > > > > >> does cause problems with security. If we would bring back the > > > > > >> end-to-end security for Diameter (CMS work), then this kind of > > > > > >> deployment would be easier to digest. > > > > > >> > > > > > >> John > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > > > > >> >Sent: 06 July, 2006 15:58 > > > > > >> >To: Yoshihiro Ohba > > > > > >> >Cc: dime@ietf.org > > > > > >> >Subject: RE: [Dime] yet another way of achieving > strict routing > > > > > >> > > > > > > >> >Hi Yoshihiro, > > > > > >> > > > > > > >> >Yes, it is analogical to a SIP B2BUA. Actually in my > > > world of ideas > > > > > >> >this is the definition of a proxy in the generic > sense -I am not > > > > > >> >speaking of SIP/Diameter proxies-: A proxy is an entity, > > > which acts > > > > > >> >on behalf of another entity. Proxy as defined in SIP -or > > > as defined > > > > > >> >in Diameter- is more a glorified relay node, but I > agree with you > > > > > >> >that the node I describe is not the "proxy" defined > in RFC3588. > > > > > >> >(Diameter proxy is more similar to the concept of > proxy in my mind > > > > > >> >because it has more authority in terms of changing > the contents of > > > > > >> >the message, so I probably would classify it somewhere > > > > > >between relay > > > > > >> >and proxy) > > > > > >> > > > > > > >> >IMHO, this is not orthogonal to strict routing issue > because it is > > > > > >> >one way of dealing with scenarios presented as the reason > > > > > >for strict > > > > > >> >routing. > > > > > >> >Actually, if one considers the application logic > running on such > > > > > >> >nodes, it seems to me a reasonable solution but picking one > > > > > >approach > > > > > >> >over another one is obviously an implementation decision. > > > > > >> > > > > > > >> > Thanks, > > > > > >> > Tolga > > > > > >> > > > > > > >> >> -----Original Message----- > > > > > >> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > >> >> Sent: Thursday, July 06, 2006 4:02 PM > > > > > >> >> To: Tolga Asveren > > > > > >> >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > > >> >> Subject: Re: [Dime] yet another way of achieving > strict routing > > > > > >> >> > > > > > >> >> > > > > > >> >> Hi Tolga, > > > > > >> >> > > > > > >> >> Is the sceanario you described is an application layer > > > > > >gateway for > > > > > >> >> (like SIP B2BUA)? If so, we should not mix it up with a > > > > > >proxy and > > > > > >> >> I believe it is orthogonal to the strict routing issue. > > > > > >> >> > > > > > >> >> Yoshihiro Ohba > > > > > >> >> > > > > > >> >> > > > > > >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga > Asveren wrote: > > > > > >> >> > O.K., now I got what you mean. And yes, this will > be a problem > > > > > >> >> unless B and > > > > > >> >> > C work in a synchronized way, where they share state. I > > > > > >> >think, this > > > > > >> >> > they need to do anyhow, because they keep some > > > application level > > > > > >> >> state, otherwise > > > > > >> >> > they wouldn't want to stay on the path. Basically, in > > > the model > > > > > >> >> I described, > > > > > >> >> > B and C act as endnodes. If there are intermediaries, > > > > > >which don't > > > > > >> >> > share state, I would expect them to abort the > session after a > > > > > >> >> failover -when they > > > > > >> >> > receive messages for an unknown session-, because > they can't > > > > > >> >> perform their > > > > > >> >> > application level processing regarding that session. > > > > > >> >> > > > > > > >> >> > Thanks, > > > > > >> >> > Tolga > > > > > >> >> > > > > > > >> >> > > -----Original Message----- > > > > > >> >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > >> >> > > Sent: Thursday, July 06, 2006 1:59 PM > > > > > >> >> > > To: Tolga Asveren > > > > > >> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > > >> >> > > Subject: Re: [Dime] yet another way of achieving > > > > > >strict routing > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga > > > Asveren wrote: > > > > > >> >> > > > If the intermediary node uses the same End-to-End > > > > > >> >identifier for > > > > > >> >> > > > the original and retransmission request, this > > > shouldn't be a > > > > > >> >> problem. Server > > > > > >> >> > > > would receive two requests with the same > Origin-Host and > > > > > >> >> > > End-to-End values > > > > > >> >> > > > and could detect the duplicate. > > > > > >> >> > > > > > > > >> >> > > You are assuming that the two requests go > through the same > > > > > >> >> > > intermediary, which is not always true. > Retransmission can > > > > > >> >> > > also happen at the original sender. > > > > > >> >> > > > > > > > >> >> > > +-----B----+ > > > > > >> >> > > / \ > > > > > >> >> > > A D > > > > > >> >> > > \ / > > > > > >> >> > > +-----C----+ > > > > > >> >> > > > > > > > >> >> > > Assume that the orignial request is forwarded A->B->D. > > > > > >> >> > > > > > > > >> >> > > If failover happens at A, A may retransmit the > request to a > > > > > >> >> > > different path, say A->C->D. > > > > > >> >> > > > > > > > >> >> > > If B modifies the Origin-Host and End-to-End > values of the > > > > > >> >> > > original request, the original and retransmitted > > > > > >requests will > > > > > >> >> > > have different Origin-Host or End-to-End values. > > > This is the > > > > > >> >> > > problem I was mentioning. > > > > > >> >> > > > > > > > >> >> > > Yoshihiro Ohba > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > -----Original Message----- > > > > > >> >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > >> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > > > > > >> >> > > > > To: Tolga Asveren > > > > > >> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > > > > > >> >> > > > > Subject: Re: [Dime] yet another way of > achieving strict > > > > > >> >> > > > > routing > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > Allowing a Diameter node to creates a request with > > > > > >> >> > > > > modifying End-to-End Identifier and > Origin-Host AVP can > > > > > >> >> > > > > break > > > > > >> >> interoperability, > > > > > >> >> > > > > because the server cannot distinguish the original > > > > > >> >request and > > > > > >> >> > > > > the modified request. As a result, the server > > > > > >will process > > > > > >> >> > > > > the two requests differently and generate > two different > > > > > >> >> > > > > answers > > > > > >> >> as oppose to > > > > > >> >> > > > > the original requester's expectation that only one > > > > > >> >> request should be > > > > > >> >> > > > > processed by a given server and that no multiple > > > > > >> >> > > > > non-duplicated answers are received for the > > > same request. > > > > > >> >> > > > > > > > > > >> >> > > > > Yoshihiro Ohba > > > > > >> >> > > > > > > > > > >> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > > > > > >> >Asveren wrote: > > > > > >> >> > > > > > Hi Yoshihiro, > > > > > >> >> > > > > > > > > > > >> >> > > > > > If the proxy creates a corresponding but new > > > > > >request for > > > > > >> >> > > > > > a > > > > > >> >> > > request it is > > > > > >> >> > > > > > proxying, I don't see why there should be a > > > problem from > > > > > >> >> > > > > duplicate detection > > > > > >> >> > > > > > point of view. In that case, there are > two Diameter > > > > > >> >> > > > > > signaling > > > > > >> >> > > > > relationships, > > > > > >> >> > > > > > one between the client and the proxy and > the other one > > > > > >> >> > > > > > between > > > > > >> >> > > > > the proxy and > > > > > >> >> > > > > > the server, i.e. client sees proxy as server > > > and server > > > > > >> >> > > sees proxy as > > > > > >> >> > > > > > client. > > > > > >> >> > > > > > > > > > > >> >> > > > > > OTOH, one could argue whether that type > of behavior is > > > > > >> >> > > > > overlapping with the > > > > > >> >> > > > > > definition of proxy in RFC3588, but I believe > > > > > >one can mix > > > > > >> >> > > > > > and > > > > > >> >> > > > > match any type > > > > > >> >> > > > > > of functionality in any node as long as > > > > > >interoperability > > > > > >> >> > > > > > is > > > > > >> >> > > not broken. > > > > > >> >> > > > > > > > > > > >> >> > > > > > Thanks, > > > > > >> >> > > > > > Tolga > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > -----Original Message----- > > > > > >> >> > > > > > > From: Yoshihiro Ohba > [mailto:yohba@tari.toshiba.com] > > > > > >> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > > > > > >> >> > > > > > > To: Tolga Asveren > > > > > >> >> > > > > > > Cc: Tony Zhang; dime@ietf.org > > > > > >> >> > > > > > > Subject: Re: [Dime] yet another way of achieving > > > > > >> >> strict routing > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > RFC 3588 has explicit text that > prohibits replacing > > > > > >> >> the End-to-End > > > > > >> >> > > > > > > Identifier: > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > "The End-to-End Identifier MUST NOT > be modified by > > > > > >> >> > > Diameter agents > > > > > >> >> > > > > > > of any kind." > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > Note: if the proxy replaces the End-to-End > > > > > >> >Identifier AVP, > > > > > >> >> > > > > > > the ultimate receiver of the request > > > message will not > > > > > >> >> able to detect a > > > > > >> >> > > > > > > duplicate request if the original > request is routed > > > > > >> >> via the proxy > > > > > >> >> > > > > > > while a dup of the original request is not > > > routed via > > > > > >> >> > > > > > > the > > > > > >> >> > > proxy. For > > > > > >> >> > > > > > > the same reason, Origin-Host AVP should not > > > > > >be modified > > > > > >> >> > > by the proxy. > > > > > >> >> > > > > > > (RFC 3588 has explicit text that prohibits > > > > > >modification > > > > > >> >> > > of Origin-Host > > > > > >> >> > > > > > > AVP by relay agents in Section 6.3, but the > > > > > >text should > > > > > >> >> > > be revised to > > > > > >> >> > > > > > > prohibit modification of Origin-Host AVP by any > > > > > >> >> > > > > > > Diameter > > > > > >> >> > > agents of any > > > > > >> >> > > > > > > kind.) > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > Yoshihiro Ohba > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > > > > > > >> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > > > > > >> >Asveren wrote: > > > > > >> >> > > > > > > > One quick note on duplicat detection in > > > the setup we > > > > > >> >> > > are discussing: > > > > > >> >> > > > > > > > Proxy probably doesn't need to > provide duplicate > > > > > >> >> detection, as > > > > > >> >> > > > > > > long as it > > > > > >> >> > > > > > > > generates a new request for each request it is > > > > > >> >proxying. > > > > > >> >> > > > > the new request > > > > > >> >> > > > > > > > would have a new End-to-ed Identifier assigned > > > > > >> >by the proxy. > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > Thanks, > > > > > >> >> > > > > > > > Tolga > > > > > >> >> > > > > > > > > > > > > >> >> > > > > > > > > -----Original Message----- > > > > > >> >> > > > > > > > > From: Tolga Asveren > [mailto:asveren@ulticom.com] > > > > > >> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > > > > > >> >> > > > > > > > > To: Tony Zhang; dime@ietf.org > > > > > >> >> > > > > > > > > Subject: RE: [Dime] yet another way > of achieving > > > > > >> >> > > strict routing > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > Hi Tony, > > > > > >> >> > > > > > > > > > > > > > >> >> > > > > > > > > > -----Original Message----- > > > > > >> >> > > > > > > > > > From: Tony Zhang > > > [mailto:zhangtao_hw@huawei.com] > > > > > >> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > > > > > >> >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > > > > > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way > > > of achieving > > > > > >> >> > > strict routing > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > Hi Tolga: > > > > > >> >> > > > > > > > > > (1) Some Request in session are sent by > > > > > >> >> > > server.so should each > > > > > >> >> > > > > > > > > > proxy repalce first request > > > > > >> >> > > Origin-Host/Origin-Realm then maybe > > > > > >> >> > > > > > > > > > will achieve this. > > > > > >> >> > > > > > > > > [TOLGA]That is really a good point. > The solution > > > > > >> >> is probably > > > > > >> >> > > > > > > real proxying > > > > > >> >> > > > > > > > > of the requests: Both Origin/Destination AVP > > > > > >> >> > > > > > > > > information > > > > > >> >> > > > > needs to be > > > > > >> >> > > > > > > > > replaced with the identity of the proxy > > > > > >entity. In > > > > > >> >> > > > > > > > > that > > > > > >> >> > > > > > > model, from client > > > > > >> >> > > > > > > > > point of view, it is the proxy which > > > provides the > > > > > >> >> > > > > > > > > service, > > > > > >> >> > > > > > > and this is my > > > > > >> >> > > > > > > > > understanding of a proxy in the generic > > > > > >sense. This > > > > > >> >> > > would mean, > > > > > >> >> > > > > > > > > proxies need > > > > > >> >> > > > > > > > > to provide duplicate detection as well > > > because it > > > > > >> >> relies on > > > > > >> >> > > > > > > > > Origin-Host AVP > > > > > >> >> > > > > > > > > value, but that IMO is logical > considering that > > > > > >> >> > > > > > > > > proxy > > > > > >> >> > > > > acts as a node > > > > > >> >> > > > > > > > > providing a service. > > > > > >> >> > > > > > > > > > (2)if client send request to > one realm,but > > > > > >> >> > > another realm give > > > > > >> >> > > > > > > > > > answer,maybe will confusion. > > > > > >> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from > > > > > >> >> > > > > > > > > protocol > > > > > >> >> > > > > > > mechanics point of > > > > > >> >> > > > > > > > > view. > > > > > >> >> > > > > > > > > > Thanks > > > > > >> >> > > > > > > > > > Tony > > > > > >> >> > > > > > > > > > ----- Original Message ----- > > > > > >> >> > > > > > > > > > From: "Tolga Asveren" > > > > > > >> >> > > > > > > > > > To: > > > > > >> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > > > > > >> >> > > > > > > > > > Subject: [Dime] yet another way > of achieving > > > > > >> >> strict routing > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > While studying the mechanics of > achiveing > > > > > >> >> > > > > > > > > > > strict > > > > > >> >> > > routing in > > > > > >> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the > > > > > >following > > > > > >> >> > > > > > > > > > > came > > > > > >> >> > > > > to my mind: > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > 1) Requests are sent by client regularly > > > > > >> >> > > > > > > > > > > 2) Stateless intermediaries just relay > > > > > >> >the message > > > > > >> >> > > > > > > > > > > 3) If an intermediary wants to stay > > > > > >in the path > > > > > >> >> > > for a session, > > > > > >> >> > > > > > > > > > it does the > > > > > >> >> > > > > > > > > > > following with the messages for > > > that session: > > > > > >> >> > > > > > > > > > > i- For the first answer, it saves the > > > > > >> >> > > Origin-Host/Origin-Realm > > > > > >> >> > > > > > > > > > AVP values > > > > > >> >> > > > > > > > > > > in the message and replaces them > > > with its own > > > > > >> >> > > > > Host/Realm values. > > > > > >> >> > > > > > > > > > > ii- Subsequent requests received by this > > > > > >> >> > > > > > > > > > > intermediary > > > > > >> >> > > > > > > will have its > > > > > >> >> > > > > > > > > > > Host/Realm value in > > > > > >> >> > > Destination-Host/Destination-Realm AVPs of > > > > > >> >> > > > > > > > > > the request. > > > > > >> >> > > > > > > > > > > They are replaced with the values > > > > > >stored in i-. > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > Considering that proxies which want to > > > > > >> >stay on the > > > > > >> >> > > > > path will be > > > > > >> >> > > > > > > > > > stateful, 3) > > > > > >> >> > > > > > > > > > > shouldn't be a problem. > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > This is very similar to what is > explained in > > > > > >> >> > > > > > > > > > > the > > > > > >> >> > > draft, except > > > > > >> >> > > > > > > > > > the state is > > > > > >> >> > > > > > > > > > > kept in proxies rather than in > the message. > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > Thanks, > > > > > >> >> > > > > > > > > > > Tolga > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > > >> >> > > > > > > > > > > > > > > > >_______________________________________________ > > > > > >> >> > > > > > > > > > > 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 > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 14:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Ml-0006Bh-GY; Mon, 10 Jul 2006 14:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00Mk-0006B0-NF for dime@ietf.org; Mon, 10 Jul 2006 14:20:18 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G00Mj-0004Ea-Dn for dime@ietf.org; Mon, 10 Jul 2006 14:20:18 -0400 Received: (qmail invoked by alias); 10 Jul 2006 18:20:15 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp010) with SMTP; 10 Jul 2006 20:20:15 +0200 X-Authenticated: #29516787 Message-ID: <44B29A62.9050703@gmx.net> Date: Mon, 10 Jul 2006 20:20:18 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org, John Loughney 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Dime] Slides, please 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, please us your slides to upload them to the IETF 66 Preliminary & Interim Materials webpage https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 16:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0283-0003Zw-Cq; Mon, 10 Jul 2006 16:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0281-0003ZM-K4 for dime@ietf.org; Mon, 10 Jul 2006 16:13:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzvkj-00041p-Pf for dime@ietf.org; Mon, 10 Jul 2006 09:24:45 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FzvcL-0000WO-9q for dime@ietf.org; Mon, 10 Jul 2006 09:16:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6ADFvha015941; Mon, 10 Jul 2006 16:16:02 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:15:03 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 16:15:03 +0300 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] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 16:15:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] yet another way of achieving strict routing Thread-Index: AcahOef1eV0L7bxISoeliMv4qba8MgC6HAOg From: To: , X-OriginalArrivalTime: 10 Jul 2006 13:15:03.0635 (UTC) FILETIME=[DAFACA30:01C6A422] X-Spam-Score: -2.3 (--) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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 all, I basically side with Yoshihiro so far. About Diameter "B2BUA" funtionality, this would be officially frowned upon in the IETF, as it does cause problems with security. If we would bring back the end-to-end security for Diameter (CMS work), then this kind of deployment would be easier to digest. =20 John >-----Original Message----- >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: 06 July, 2006 15:58 >To: Yoshihiro Ohba >Cc: dime@ietf.org >Subject: RE: [Dime] yet another way of achieving strict routing > >Hi Yoshihiro, > >Yes, it is analogical to a SIP B2BUA. Actually in my world of=20 >ideas this is the definition of a proxy in the generic sense=20 >-I am not speaking of SIP/Diameter proxies-: A proxy is an=20 >entity, which acts on behalf of another entity. Proxy as=20 >defined in SIP -or as defined in Diameter- is more a glorified=20 >relay node, but I agree with you that the node I describe is=20 >not the "proxy" defined in RFC3588. (Diameter proxy is more=20 >similar to the concept of proxy in my mind because it has more=20 >authority in terms of changing the contents of the message, so=20 >I probably would classify it somewhere between relay and proxy) > >IMHO, this is not orthogonal to strict routing issue because=20 >it is one way of dealing with scenarios presented as the=20 >reason for strict routing. >Actually, if one considers the application logic running on=20 >such nodes, it seems to me a reasonable solution but picking=20 >one approach over another one is obviously an implementation decision. > > Thanks, > Tolga > >> -----Original Message----- >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> Sent: Thursday, July 06, 2006 4:02 PM >> To: Tolga Asveren >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> Subject: Re: [Dime] yet another way of achieving strict routing >> >> >> Hi Tolga, >> >> Is the sceanario you described is an application layer gateway for=20 >> (like SIP B2BUA)? If so, we should not mix it up with a proxy and I=20 >> believe it is orthogonal to the strict routing issue. >> >> Yoshihiro Ohba >> >> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: >> > O.K., now I got what you mean. And yes, this will be a problem >> unless B and >> > C work in a synchronized way, where they share state. I=20 >think, this=20 >> > they need to do anyhow, because they keep some application level >> state, otherwise >> > they wouldn't want to stay on the path. Basically, in the model >> I described, >> > B and C act as endnodes. If there are intermediaries, which don't=20 >> > share state, I would expect them to abort the session after a >> failover -when they >> > receive messages for an unknown session-, because they can't >> perform their >> > application level processing regarding that session. >> > >> > Thanks, >> > Tolga >> > >> > > -----Original Message----- >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> > > Sent: Thursday, July 06, 2006 1:59 PM >> > > To: Tolga Asveren >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> > > Subject: Re: [Dime] yet another way of achieving strict routing >> > > >> > > >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: >> > > > If the intermediary node uses the same End-to-End=20 >identifier for=20 >> > > > the original and retransmission request, this shouldn't be a >> problem. Server >> > > > would receive two requests with the same Origin-Host and >> > > End-to-End values >> > > > and could detect the duplicate. >> > > >> > > You are assuming that the two requests go through the same=20 >> > > intermediary, which is not always true. Retransmission can also=20 >> > > happen at the original sender. >> > > >> > > +-----B----+ >> > > / \ >> > > A D >> > > \ / >> > > +-----C----+ >> > > >> > > Assume that the orignial request is forwarded A->B->D. >> > > >> > > If failover happens at A, A may retransmit the request to a=20 >> > > different path, say A->C->D. >> > > >> > > If B modifies the Origin-Host and End-to-End values of the=20 >> > > original request, the original and retransmitted requests will=20 >> > > have different Origin-Host or End-to-End values. This is the=20 >> > > problem I was mentioning. >> > > >> > > Yoshihiro Ohba >> > > >> > > >> > > >> > > > > -----Original Message----- >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> > > > > Sent: Thursday, July 06, 2006 12:17 PM >> > > > > To: Tolga Asveren >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org >> > > > > Subject: Re: [Dime] yet another way of achieving strict=20 >> > > > > routing >> > > > > >> > > > > >> > > > > Allowing a Diameter node to creates a request with modifying=20 >> > > > > End-to-End Identifier and Origin-Host AVP can break >> interoperability, >> > > > > because the server cannot distinguish the original=20 >request and=20 >> > > > > the modified request. As a result, the server will process=20 >> > > > > the two requests differently and generate two different=20 >> > > > > answers >> as oppose to >> > > > > the original requester's expectation that only one >> request should be >> > > > > processed by a given server and that no multiple=20 >> > > > > non-duplicated answers are received for the same request. >> > > > > >> > > > > Yoshihiro Ohba >> > > > > >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga=20 >Asveren wrote: >> > > > > > Hi Yoshihiro, >> > > > > > >> > > > > > If the proxy creates a corresponding but new request for a >> > > request it is >> > > > > > proxying, I don't see why there should be a problem from >> > > > > duplicate detection >> > > > > > point of view. In that case, there are two Diameter=20 >> > > > > > signaling >> > > > > relationships, >> > > > > > one between the client and the proxy and the other one=20 >> > > > > > between >> > > > > the proxy and >> > > > > > the server, i.e. client sees proxy as server and server >> > > sees proxy as >> > > > > > client. >> > > > > > >> > > > > > OTOH, one could argue whether that type of behavior is >> > > > > overlapping with the >> > > > > > definition of proxy in RFC3588, but I believe one can mix=20 >> > > > > > and >> > > > > match any type >> > > > > > of functionality in any node as long as interoperability is >> > > not broken. >> > > > > > >> > > > > > Thanks, >> > > > > > Tolga >> > > > > > >> > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM >> > > > > > > To: Tolga Asveren >> > > > > > > Cc: Tony Zhang; dime@ietf.org >> > > > > > > Subject: Re: [Dime] yet another way of achieving >> strict routing >> > > > > > > >> > > > > > > >> > > > > > > RFC 3588 has explicit text that prohibits replacing >> the End-to-End >> > > > > > > Identifier: >> > > > > > > >> > > > > > > "The End-to-End Identifier MUST NOT be modified by >> > > Diameter agents >> > > > > > > of any kind." >> > > > > > > >> > > > > > > Note: if the proxy replaces the End-to-End=20 >Identifier AVP,=20 >> > > > > > > the ultimate receiver of the request message will not >> able to detect a >> > > > > > > duplicate request if the original request is routed >> via the proxy >> > > > > > > while a dup of the original request is not routed via the >> > > proxy. For >> > > > > > > the same reason, Origin-Host AVP should not be modified >> > > by the proxy. >> > > > > > > (RFC 3588 has explicit text that prohibits modification >> > > of Origin-Host >> > > > > > > AVP by relay agents in Section 6.3, but the text should >> > > be revised to >> > > > > > > prohibit modification of Origin-Host AVP by any Diameter >> > > agents of any >> > > > > > > kind.) >> > > > > > > >> > > > > > > Yoshihiro Ohba >> > > > > > > >> > > > > > > >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga=20 >Asveren wrote: >> > > > > > > > One quick note on duplicat detection in the setup we >> > > are discussing: >> > > > > > > > Proxy probably doesn't need to provide duplicate >> detection, as >> > > > > > > long as it >> > > > > > > > generates a new request for each request it is=20 >proxying. >> > > > > the new request >> > > > > > > > would have a new End-to-ed Identifier assigned=20 >by the proxy. >> > > > > > > > >> > > > > > > > Thanks, >> > > > > > > > Tolga >> > > > > > > > >> > > > > > > > > -----Original Message----- >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM >> > > > > > > > > To: Tony Zhang; dime@ietf.org >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving >> > > strict routing >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > Hi Tony, >> > > > > > > > > >> > > > > > > > > > -----Original Message----- >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving >> > > strict routing >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Hi Tolga: >> > > > > > > > > > (1) Some Request in session are sent by >> > > server.so should each >> > > > > > > > > > proxy repalce first request >> > > Origin-Host/Origin-Realm then maybe >> > > > > > > > > > will achieve this. >> > > > > > > > > [TOLGA]That is really a good point. The solution >> is probably >> > > > > > > real proxying >> > > > > > > > > of the requests: Both Origin/Destination AVP=20 >> > > > > > > > > information >> > > > > needs to be >> > > > > > > > > replaced with the identity of the proxy entity. In=20 >> > > > > > > > > that >> > > > > > > model, from client >> > > > > > > > > point of view, it is the proxy which provides the=20 >> > > > > > > > > service, >> > > > > > > and this is my >> > > > > > > > > understanding of a proxy in the generic sense. This >> > > would mean, >> > > > > > > > > proxies need >> > > > > > > > > to provide duplicate detection as well because it >> relies on >> > > > > > > > > Origin-Host AVP >> > > > > > > > > value, but that IMO is logical considering that proxy >> > > > > acts as a node >> > > > > > > > > providing a service. >> > > > > > > > > > (2)if client send request to one realm,but >> > > another realm give >> > > > > > > > > > answer,maybe will confusion. >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol >> > > > > > > mechanics point of >> > > > > > > > > view. >> > > > > > > > > > Thanks >> > > > > > > > > > Tony >> > > > > > > > > > ----- Original Message ----- >> > > > > > > > > > From: "Tolga Asveren" >> > > > > > > > > > To: >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM >> > > > > > > > > > Subject: [Dime] yet another way of achieving >> strict routing >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > While studying the mechanics of achiveing strict >> > > routing in >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following=20 >> > > > > > > > > > > came >> > > > > to my mind: >> > > > > > > > > > > >> > > > > > > > > > > 1) Requests are sent by client regularly >> > > > > > > > > > > 2) Stateless intermediaries just relay=20 >the message >> > > > > > > > > > > 3) If an intermediary wants to stay in the path >> > > for a session, >> > > > > > > > > > it does the >> > > > > > > > > > > following with the messages for that session: >> > > > > > > > > > > i- For the first answer, it saves the >> > > Origin-Host/Origin-Realm >> > > > > > > > > > AVP values >> > > > > > > > > > > in the message and replaces them with its own >> > > > > Host/Realm values. >> > > > > > > > > > > ii- Subsequent requests received by this=20 >> > > > > > > > > > > intermediary >> > > > > > > will have its >> > > > > > > > > > > Host/Realm value in >> > > Destination-Host/Destination-Realm AVPs of >> > > > > > > > > > the request. >> > > > > > > > > > > They are replaced with the values stored in i-. >> > > > > > > > > > > >> > > > > > > > > > > Considering that proxies which want to=20 >stay on the >> > > > > path will be >> > > > > > > > > > stateful, 3) >> > > > > > > > > > > shouldn't be a problem. >> > > > > > > > > > > >> > > > > > > > > > > This is very similar to what is explained in the >> > > draft, except >> > > > > > > > > > the state is >> > > > > > > > > > > kept in proxies rather than in the message. >> > > > > > > > > > > >> > > > > > > > > > > Thanks, >> > > > > > > > > > > Tolga >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > _______________________________________________ >> > > > > > > > > > > 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 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 10 18:32:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04JA-0005wG-De; Mon, 10 Jul 2006 18:32:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G04J9-0005ti-4g for dime@ietf.org; Mon, 10 Jul 2006 18:32:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzwGm-0008Nx-OK for dime@ietf.org; Mon, 10 Jul 2006 09:57:52 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fzw9h-0001E5-Tt for dime@ietf.org; Mon, 10 Jul 2006 09:50:40 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id E29CA785C5; Mon, 10 Jul 2006 09:50:25 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6ADoMtJ019844; Mon, 10 Jul 2006 09:50:23 -0400 (EDT) From: "Tolga Asveren" To: , Subject: RE: [Dime] yet another way of achieving strict routing Date: Mon, 10 Jul 2006 09:26:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: -2.3 (--) X-Scan-Signature: 031b5f42d6d2cd097710e6b68613cb36 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 John, One important point regarding B2BUA (or ALG or whatever we want to name it) is that it does not require any changes to the existing protocol definition, i.e. it is not violating on-the-wire aspects of RFC3588 AFAICS. Basically it is not a protocol issue but an administrative/deployment issue whether one wants to deploy it -and thus IETF can't do anything about it ;-) -. >From security point of view, I guess it won't cause a practical problem for most of the cases. I would think, the application level processing which needs to be performed on such nodes -whether it be ALG or proxy- anyhow will require inspection of AVPs and some preestablished trust relationship. It could be the case that people want certain AVPs to be end-to-end secured, but I don't think this will be majority of the cases and I agree that ALG approach won't provide a satisfactory solution if that is required. I think, it is worthwile to make people aware that this (ALG, B2BCS [Back-to-Back-Client-Server]) is an option, if it suits their needs. If mentioning of such functionality wouldn't be blessed by IETF because it breaks end-to-end security (Actually there are different ways of seeing this as well, from Diameter Base Protocol point of view, ALG is and endpoint, well actually two endpoints and hence does not violate end-to-end security), I hope this thread was informative enough for people (at least for me it was). Thanks, Tolga > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, July 10, 2006 9:15 AM > To: asveren@ulticom.com; yohba@tari.toshiba.com > Cc: dime@ietf.org > Subject: RE: [Dime] yet another way of achieving strict routing > > > Hi all, > > I basically side with Yoshihiro so far. About Diameter "B2BUA" > funtionality, this would be officially frowned upon in the IETF, > as it does cause problems with security. If we would bring back > the end-to-end security for Diameter (CMS work), then this kind > of deployment would be easier to digest. > > John > > >-----Original Message----- > >From: ext Tolga Asveren [mailto:asveren@ulticom.com] > >Sent: 06 July, 2006 15:58 > >To: Yoshihiro Ohba > >Cc: dime@ietf.org > >Subject: RE: [Dime] yet another way of achieving strict routing > > > >Hi Yoshihiro, > > > >Yes, it is analogical to a SIP B2BUA. Actually in my world of > >ideas this is the definition of a proxy in the generic sense > >-I am not speaking of SIP/Diameter proxies-: A proxy is an > >entity, which acts on behalf of another entity. Proxy as > >defined in SIP -or as defined in Diameter- is more a glorified > >relay node, but I agree with you that the node I describe is > >not the "proxy" defined in RFC3588. (Diameter proxy is more > >similar to the concept of proxy in my mind because it has more > >authority in terms of changing the contents of the message, so > >I probably would classify it somewhere between relay and proxy) > > > >IMHO, this is not orthogonal to strict routing issue because > >it is one way of dealing with scenarios presented as the > >reason for strict routing. > >Actually, if one considers the application logic running on > >such nodes, it seems to me a reasonable solution but picking > >one approach over another one is obviously an implementation decision. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> Sent: Thursday, July 06, 2006 4:02 PM > >> To: Tolga Asveren > >> Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> Subject: Re: [Dime] yet another way of achieving strict routing > >> > >> > >> Hi Tolga, > >> > >> Is the sceanario you described is an application layer gateway for > >> (like SIP B2BUA)? If so, we should not mix it up with a proxy and I > >> believe it is orthogonal to the strict routing issue. > >> > >> Yoshihiro Ohba > >> > >> > >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote: > >> > O.K., now I got what you mean. And yes, this will be a problem > >> unless B and > >> > C work in a synchronized way, where they share state. I > >think, this > >> > they need to do anyhow, because they keep some application level > >> state, otherwise > >> > they wouldn't want to stay on the path. Basically, in the model > >> I described, > >> > B and C act as endnodes. If there are intermediaries, which don't > >> > share state, I would expect them to abort the session after a > >> failover -when they > >> > receive messages for an unknown session-, because they can't > >> perform their > >> > application level processing regarding that session. > >> > > >> > Thanks, > >> > Tolga > >> > > >> > > -----Original Message----- > >> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> > > Sent: Thursday, July 06, 2006 1:59 PM > >> > > To: Tolga Asveren > >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> > > Subject: Re: [Dime] yet another way of achieving strict routing > >> > > > >> > > > >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote: > >> > > > If the intermediary node uses the same End-to-End > >identifier for > >> > > > the original and retransmission request, this shouldn't be a > >> problem. Server > >> > > > would receive two requests with the same Origin-Host and > >> > > End-to-End values > >> > > > and could detect the duplicate. > >> > > > >> > > You are assuming that the two requests go through the same > >> > > intermediary, which is not always true. Retransmission can also > >> > > happen at the original sender. > >> > > > >> > > +-----B----+ > >> > > / \ > >> > > A D > >> > > \ / > >> > > +-----C----+ > >> > > > >> > > Assume that the orignial request is forwarded A->B->D. > >> > > > >> > > If failover happens at A, A may retransmit the request to a > >> > > different path, say A->C->D. > >> > > > >> > > If B modifies the Origin-Host and End-to-End values of the > >> > > original request, the original and retransmitted requests will > >> > > have different Origin-Host or End-to-End values. This is the > >> > > problem I was mentioning. > >> > > > >> > > Yoshihiro Ohba > >> > > > >> > > > >> > > > >> > > > > -----Original Message----- > >> > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> > > > > Sent: Thursday, July 06, 2006 12:17 PM > >> > > > > To: Tolga Asveren > >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime@ietf.org > >> > > > > Subject: Re: [Dime] yet another way of achieving strict > >> > > > > routing > >> > > > > > >> > > > > > >> > > > > Allowing a Diameter node to creates a request with modifying > >> > > > > End-to-End Identifier and Origin-Host AVP can break > >> interoperability, > >> > > > > because the server cannot distinguish the original > >request and > >> > > > > the modified request. As a result, the server will process > >> > > > > the two requests differently and generate two different > >> > > > > answers > >> as oppose to > >> > > > > the original requester's expectation that only one > >> request should be > >> > > > > processed by a given server and that no multiple > >> > > > > non-duplicated answers are received for the same request. > >> > > > > > >> > > > > Yoshihiro Ohba > >> > > > > > >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga > >Asveren wrote: > >> > > > > > Hi Yoshihiro, > >> > > > > > > >> > > > > > If the proxy creates a corresponding but new request for a > >> > > request it is > >> > > > > > proxying, I don't see why there should be a problem from > >> > > > > duplicate detection > >> > > > > > point of view. In that case, there are two Diameter > >> > > > > > signaling > >> > > > > relationships, > >> > > > > > one between the client and the proxy and the other one > >> > > > > > between > >> > > > > the proxy and > >> > > > > > the server, i.e. client sees proxy as server and server > >> > > sees proxy as > >> > > > > > client. > >> > > > > > > >> > > > > > OTOH, one could argue whether that type of behavior is > >> > > > > overlapping with the > >> > > > > > definition of proxy in RFC3588, but I believe one can mix > >> > > > > > and > >> > > > > match any type > >> > > > > > of functionality in any node as long as interoperability is > >> > > not broken. > >> > > > > > > >> > > > > > Thanks, > >> > > > > > Tolga > >> > > > > > > >> > > > > > > >> > > > > > > -----Original Message----- > >> > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM > >> > > > > > > To: Tolga Asveren > >> > > > > > > Cc: Tony Zhang; dime@ietf.org > >> > > > > > > Subject: Re: [Dime] yet another way of achieving > >> strict routing > >> > > > > > > > >> > > > > > > > >> > > > > > > RFC 3588 has explicit text that prohibits replacing > >> the End-to-End > >> > > > > > > Identifier: > >> > > > > > > > >> > > > > > > "The End-to-End Identifier MUST NOT be modified by > >> > > Diameter agents > >> > > > > > > of any kind." > >> > > > > > > > >> > > > > > > Note: if the proxy replaces the End-to-End > >Identifier AVP, > >> > > > > > > the ultimate receiver of the request message will not > >> able to detect a > >> > > > > > > duplicate request if the original request is routed > >> via the proxy > >> > > > > > > while a dup of the original request is not routed via the > >> > > proxy. For > >> > > > > > > the same reason, Origin-Host AVP should not be modified > >> > > by the proxy. > >> > > > > > > (RFC 3588 has explicit text that prohibits modification > >> > > of Origin-Host > >> > > > > > > AVP by relay agents in Section 6.3, but the text should > >> > > be revised to > >> > > > > > > prohibit modification of Origin-Host AVP by any Diameter > >> > > agents of any > >> > > > > > > kind.) > >> > > > > > > > >> > > > > > > Yoshihiro Ohba > >> > > > > > > > >> > > > > > > > >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga > >Asveren wrote: > >> > > > > > > > One quick note on duplicat detection in the setup we > >> > > are discussing: > >> > > > > > > > Proxy probably doesn't need to provide duplicate > >> detection, as > >> > > > > > > long as it > >> > > > > > > > generates a new request for each request it is > >proxying. > >> > > > > the new request > >> > > > > > > > would have a new End-to-ed Identifier assigned > >by the proxy. > >> > > > > > > > > >> > > > > > > > Thanks, > >> > > > > > > > Tolga > >> > > > > > > > > >> > > > > > > > > -----Original Message----- > >> > > > > > > > > From: Tolga Asveren [mailto:asveren@ulticom.com] > >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM > >> > > > > > > > > To: Tony Zhang; dime@ietf.org > >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving > >> > > strict routing > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > Hi Tony, > >> > > > > > > > > > >> > > > > > > > > > -----Original Message----- > >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM > >> > > > > > > > > > To: Tolga Asveren; dime@ietf.org > >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving > >> > > strict routing > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > Hi Tolga: > >> > > > > > > > > > (1) Some Request in session are sent by > >> > > server.so should each > >> > > > > > > > > > proxy repalce first request > >> > > Origin-Host/Origin-Realm then maybe > >> > > > > > > > > > will achieve this. > >> > > > > > > > > [TOLGA]That is really a good point. The solution > >> is probably > >> > > > > > > real proxying > >> > > > > > > > > of the requests: Both Origin/Destination AVP > >> > > > > > > > > information > >> > > > > needs to be > >> > > > > > > > > replaced with the identity of the proxy entity. In > >> > > > > > > > > that > >> > > > > > > model, from client > >> > > > > > > > > point of view, it is the proxy which provides the > >> > > > > > > > > service, > >> > > > > > > and this is my > >> > > > > > > > > understanding of a proxy in the generic sense. This > >> > > would mean, > >> > > > > > > > > proxies need > >> > > > > > > > > to provide duplicate detection as well because it > >> relies on > >> > > > > > > > > Origin-Host AVP > >> > > > > > > > > value, but that IMO is logical considering that proxy > >> > > > > acts as a node > >> > > > > > > > > providing a service. > >> > > > > > > > > > (2)if client send request to one realm,but > >> > > another realm give > >> > > > > > > > > > answer,maybe will confusion. > >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol > >> > > > > > > mechanics point of > >> > > > > > > > > view. > >> > > > > > > > > > Thanks > >> > > > > > > > > > Tony > >> > > > > > > > > > ----- Original Message ----- > >> > > > > > > > > > From: "Tolga Asveren" > >> > > > > > > > > > To: > >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM > >> > > > > > > > > > Subject: [Dime] yet another way of achieving > >> strict routing > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > While studying the mechanics of achiveing strict > >> > > routing in > >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following > >> > > > > > > > > > > came > >> > > > > to my mind: > >> > > > > > > > > > > > >> > > > > > > > > > > 1) Requests are sent by client regularly > >> > > > > > > > > > > 2) Stateless intermediaries just relay > >the message > >> > > > > > > > > > > 3) If an intermediary wants to stay in the path > >> > > for a session, > >> > > > > > > > > > it does the > >> > > > > > > > > > > following with the messages for that session: > >> > > > > > > > > > > i- For the first answer, it saves the > >> > > Origin-Host/Origin-Realm > >> > > > > > > > > > AVP values > >> > > > > > > > > > > in the message and replaces them with its own > >> > > > > Host/Realm values. > >> > > > > > > > > > > ii- Subsequent requests received by this > >> > > > > > > > > > > intermediary > >> > > > > > > will have its > >> > > > > > > > > > > Host/Realm value in > >> > > Destination-Host/Destination-Realm AVPs of > >> > > > > > > > > > the request. > >> > > > > > > > > > > They are replaced with the values stored in i-. > >> > > > > > > > > > > > >> > > > > > > > > > > Considering that proxies which want to > >stay on the > >> > > > > path will be > >> > > > > > > > > > stateful, 3) > >> > > > > > > > > > > shouldn't be a problem. > >> > > > > > > > > > > > >> > > > > > > > > > > This is very similar to what is explained in the > >> > > draft, except > >> > > > > > > > > > the state is > >> > > > > > > > > > > kept in proxies rather than in the message. > >> > > > > > > > > > > > >> > > > > > > > > > > Thanks, > >> > > > > > > > > > > Tolga > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > _______________________________________________ > >> > > > > > > > > > > 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 > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 14 13:47:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rl0-0000Bg-9X; Fri, 14 Jul 2006 13:47:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Rky-0000AI-PS for dime@ietf.org; Fri, 14 Jul 2006 13:47:16 -0400 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 1G1Rkw-0002Ti-C0 for dime@ietf.org; Fri, 14 Jul 2006 13:47:16 -0400 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 k6EHkSiB050703 for ; Fri, 14 Jul 2006 13:46:28 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44B7D875.40204@tari.toshiba.com> Date: Fri, 14 Jul 2006 13:46:29 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) 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: -2.4 (--) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Dime] Summary of 3588bis Issues Status 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 Folks, The is a summary of the 3588bis issues discussion during DIME WG meeting in IETF66. If you have comments on any of the existing issues pls don't hesitate to post it on the DIME list so we can facilitate quicker resolution or at least better understanding of the problem. We also need some proposals on the open issues if you believe they are truly issues. Note that the assigned issue numbers are based on the current tracker which is for historical reasons the diameter-interop tracker (http://www.tschofenig.priv.at:8080/diameter-interop). Closed Issues: ------------- Issue 6 : TLS version issue Comments: interop related problem only. Does not affect the base spec Issue 7 : Textual IP address qualify as FQDN Comments: Consensus that FQDN is defined as "internet name" only Issue 11 : Confusion about use of Proxy-Info AVP for Relay Comments: Clarified in Sec 6.2 with the text "Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request." Open Issues with some consensus on proposals: --------------------------------------------- Notes: These issues have some consensus either during the IETF66 meeting and/or in the DIME mailing list. Issue 2 & 5 : App Ids used by common diameter messages Proposals: Use the application id of the current application Issue 3 & 16 : CER/CEA exchange in the open state Proposals: Need more consensus on current proposals posted in issue 16 Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp Proposals: The Vendor-Id ABNF should one and only one instance, i.e. ::= < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Issue 20 : Determining an offending/invalid AVP contained within the group AVP Proposals: Do nothing. The AVP code should be enough. Existing proposals may needlessly extend the length of the Failed-AVP. Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 Proposals: Change diameter-message definition in Sec 3.2 to: diameter-message=header[*fixed][*required][*optional] Open Issues with no consensus on proposals: ------------------------------------------ Issue 21 : URI schemes for AAA Proposals: draft-garcia-dime-aaa-uri-00.txt Issue 4 : Proxy agent stay in the path of the request message of a session Proposals: draft-tsou-dime-routing-ext-00.txt Open Issues that needs proposals: -------------------------------- Notes: These issues did not receive any comments during IETF66 and have no pending proposals. Issue 1 : Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id Issue 15 : Duplicate detection requires server side storage of e2e id and origin-host avp Issue 13 : Clarify usage of application id avp's and how they relate to the app-id in the header Issue 9 & 19 : Error codes defined in wrong category Issue 8 : Setting error flag (e-bit) during CER/CEA exchange Issue 12 : Differing concepts and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue 14 : Explicit text on which error category should have error flag (e-bit) set Issue 18 : Clarify reconnect behavior of peer based on value of Disconnect-Cause AVP Open issues falling into the "New Features" category: ---------------------------------------------------- Note: These features should use the extension procedures defined in 3588. No comments received in IETF66 meeting. Issue 23 : Predictive loop detection Comments: Optimzation techiniques in detecting loops at the succeeding hops Issue 22 : Fetch data request and location update request. Comments: Proposal to include LUR messages into base since its reusable in different applications If you believe there are some in-accurate info below, pls let us know. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 17 17:24:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2aZj-0006Mm-EH; Mon, 17 Jul 2006 17:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2aZi-0006Mc-C1 for dime@ietf.org; Mon, 17 Jul 2006 17:24:22 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2aZf-0004Sd-TO for dime@ietf.org; Mon, 17 Jul 2006 17:24:22 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 0649108510 for ; Mon, 17 Jul 2006 17:24:02 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6HLOI7V017693 for ; Mon, 17 Jul 2006 17:24:18 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Mon, 17 Jul 2006 17:00:47 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44B7D875.40204@tari.toshiba.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 Victor, Thanks a lot for that very useful update. IMHO, a few of the items listed below have a higher importance than the other ones: 1) AppId to be used by common diameter messages 2) Grouping of error codes Especially 1) seem to be a real interop-killer. I hope all people which have any opinion on this issue would post their ideas so that we can reach a conclusion ASAP. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, July 14, 2006 1:46 PM > To: dime@ietf.org > Subject: [Dime] Summary of 3588bis Issues Status > > > Folks, > > The is a summary of the 3588bis issues discussion during DIME WG meeting > in IETF66. If you have comments on any of the existing issues pls don't > hesitate to post it on the DIME list so we can facilitate quicker > resolution or at least better understanding of the problem. We also need > some proposals on the open issues if you believe they are truly issues. > Note that the assigned issue numbers are based on the current tracker > which is for historical reasons the diameter-interop tracker > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > Closed Issues: > ------------- > > Issue 6 : TLS version issue > Comments: interop related problem only. Does not > affect the > base spec > > Issue 7 : Textual IP address qualify as FQDN > Comments: Consensus that FQDN is defined as > "internet name" > only > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > Comments: Clarified in Sec 6.2 with the text > > "Any Proxy-Info AVPs in the request MUST be added to the > answer message, in the same order they were present in > the request." > > Open Issues with some consensus on proposals: > --------------------------------------------- > > Notes: These issues have some consensus either during the IETF66 > meeting and/or in the DIME mailing list. > > Issue 2 & 5 : App Ids used by common diameter messages > Proposals: Use the application id of the current > application > > Issue 3 & 16 : CER/CEA exchange in the open state > Proposals: Need more consensus on current proposals > posted in issue 16 > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > Proposals: The Vendor-Id ABNF should one and only one > instance, i.e. > > ::= < AVP Header: 260 > > < Vendor-Id > > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP. > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > Proposals: Change diameter-message definition in > Sec 3.2 to: > > diameter-message=header[*fixed][*required][*optional] > > Open Issues with no consensus on proposals: > ------------------------------------------ > > Issue 21 : URI schemes for AAA > Proposals: draft-garcia-dime-aaa-uri-00.txt > > Issue 4 : Proxy agent stay in the path of the request message of > a session > Proposals: draft-tsou-dime-routing-ext-00.txt > > Open Issues that needs proposals: > -------------------------------- > > Notes: These issues did not receive any comments during IETF66 and > have no pending proposals. > > Issue 1 : Advertising relay application id (0xffffffff) in > auth-application-id or acct-application-id > > Issue 15 : Duplicate detection requires server side storage of > e2e id and origin-host avp > > Issue 13 : Clarify usage of application id avp's and how they > relate to the app-id in the header > > Issue 9 & 19 : Error codes defined in wrong category > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > Issue 12 : Differing concepts and/or usage of Diameter Identity > (FQDN + port or FQDN only) > > Issue 14 : Explicit text on which error category should have > error flag (e-bit) set > > Issue 18 : Clarify reconnect behavior of peer based on value of > Disconnect-Cause AVP > > Open issues falling into the "New Features" category: > ---------------------------------------------------- > > Note: These features should use the extension procedures defined in 3588. > No comments received in IETF66 meeting. > > Issue 23 : Predictive loop detection > Comments: Optimzation techiniques in detecting loops > at the succeeding hops > > Issue 22 : Fetch data request and location update request. > Comments: Proposal to include LUR messages into > base since its reusable in different > applications > > If you believe there are some in-accurate info below, pls let us know. > > best regards, > victor > > _______________________________________________ > 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 Jul 17 23:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ghw-0006ve-3h; Mon, 17 Jul 2006 23:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ghu-0006vC-OP for dime@ietf.org; Mon, 17 Jul 2006 23:57:14 -0400 Received: from mail5.opentransfer.com ([69.49.238.6]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2ghs-0008R6-0L for dime@ietf.org; Mon, 17 Jul 2006 23:57:14 -0400 Received: (qmail 27683 invoked by uid 399); 18 Jul 2006 03:57:08 -0000 Received: from unknown (HELO webmail3.opentransfer.com) (192.168.66.36) by mail.opentransfer.com with SMTP; 18 Jul 2006 03:57:08 -0000 Received: (from nobody@localhost) by webmail3.opentransfer.com (8.11.6/8.11.6) id k6I3v7611731; Mon, 17 Jul 2006 22:57:07 -0500 X-Authentication-Warning: webmail3.opentransfer.com: nobody set sender to nilanjans@condornetworks.com using -f Received: from 203.145.132.252 ([203.145.132.252]) by mail.opentransfer.com (IMP) with HTTP for ; Mon, 17 Jul 2006 22:57:07 -0500 Message-ID: <1153195027.44bc5c137b4dd@mail.opentransfer.com> Date: Mon, 17 Jul 2006 22:57:07 -0500 From: nilanjans@condornetworks.com To: Tolga Asveren Subject: RE: [Dime] Summary of 3588bis Issues Status References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 203.145.132.252 X-Spam-Score: 1.2 (+) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 Victor, I agree with Tolga. The item (1) is really an interop issue and needs to be added to the list. Thanks Prasad. Quoting Tolga Asveren : > Hi Victor, > > Thanks a lot for that very useful update. > > IMHO, a few of the items listed below have a higher importance than the > other ones: > > 1) AppId to be used by common diameter messages > 2) Grouping of error codes > > Especially 1) seem to be a real interop-killer. I hope all people which have > any opinion on this issue would post their ideas so that we can reach a > conclusion ASAP. > > Thanks, > Tolga > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Friday, July 14, 2006 1:46 PM > > To: dime@ietf.org > > Subject: [Dime] Summary of 3588bis Issues Status > > > > > > Folks, > > > > The is a summary of the 3588bis issues discussion during DIME WG meeting > > in IETF66. If you have comments on any of the existing issues pls don't > > hesitate to post it on the DIME list so we can facilitate quicker > > resolution or at least better understanding of the problem. We also need > > some proposals on the open issues if you believe they are truly issues. > > Note that the assigned issue numbers are based on the current tracker > > which is for historical reasons the diameter-interop tracker > > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > > > > Closed Issues: > > ------------- > > > > Issue 6 : TLS version issue > > Comments: interop related problem only. Does not > > affect the > > base spec > > > > Issue 7 : Textual IP address qualify as FQDN > > Comments: Consensus that FQDN is defined as > > "internet name" > > only > > > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > > Comments: Clarified in Sec 6.2 with the text > > > > "Any Proxy-Info AVPs in the request MUST be added to the > > answer message, in the same order they were present in > > the request." > > > > Open Issues with some consensus on proposals: > > --------------------------------------------- > > > > Notes: These issues have some consensus either during the IETF66 > > meeting and/or in the DIME mailing list. > > > > Issue 2 & 5 : App Ids used by common diameter messages > > Proposals: Use the application id of the current > > application > > > > Issue 3 & 16 : CER/CEA exchange in the open state > > Proposals: Need more consensus on current proposals > > posted in issue 16 > > > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > > Proposals: The Vendor-Id ABNF should one and only one > > instance, i.e. > > > > ::= < AVP Header: 260 > > > < Vendor-Id > > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > Issue 20 : Determining an offending/invalid AVP contained within > > the group AVP > > Proposals: Do nothing. The AVP code should be enough. > > Existing proposals may needlessly extend > > the length of the Failed-AVP. > > > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > > Proposals: Change diameter-message definition in > > Sec 3.2 to: > > > > diameter-message=header[*fixed][*required][*optional] > > > > Open Issues with no consensus on proposals: > > ------------------------------------------ > > > > Issue 21 : URI schemes for AAA > > Proposals: draft-garcia-dime-aaa-uri-00.txt > > > > Issue 4 : Proxy agent stay in the path of the request message of > > a session > > Proposals: draft-tsou-dime-routing-ext-00.txt > > > > Open Issues that needs proposals: > > -------------------------------- > > > > Notes: These issues did not receive any comments during IETF66 and > > have no pending proposals. > > > > Issue 1 : Advertising relay application id (0xffffffff) in > > auth-application-id or acct-application-id > > > > Issue 15 : Duplicate detection requires server side storage of > > e2e id and origin-host avp > > > > Issue 13 : Clarify usage of application id avp's and how they > > relate to the app-id in the header > > > > Issue 9 & 19 : Error codes defined in wrong category > > > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > > > Issue 12 : Differing concepts and/or usage of Diameter Identity > > (FQDN + port or FQDN only) > > > > Issue 14 : Explicit text on which error category should have > > error flag (e-bit) set > > > > Issue 18 : Clarify reconnect behavior of peer based on value of > > Disconnect-Cause AVP > > > > Open issues falling into the "New Features" category: > > ---------------------------------------------------- > > > > Note: These features should use the extension procedures defined in 3588. > > No comments received in IETF66 meeting. > > > > Issue 23 : Predictive loop detection > > Comments: Optimzation techiniques in detecting loops > > at the succeeding hops > > > > Issue 22 : Fetch data request and location update request. > > Comments: Proposal to include LUR messages into > > base since its reusable in different > > applications > > > > If you believe there are some in-accurate info below, pls let us know. > > > > best regards, > > victor > > > > _______________________________________________ > > 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 Jul 18 00:49:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hWV-0005x0-OX; Tue, 18 Jul 2006 00:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hWV-0005wv-5x for dime@ietf.org; Tue, 18 Jul 2006 00:49:31 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2hWM-0003kR-0P for dime@ietf.org; Tue, 18 Jul 2006 00:49:31 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6I4nLN8005194 for ; Mon, 17 Jul 2006 21:49:21 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6I4nJBL002618 for ; Mon, 17 Jul 2006 23:49:20 -0500 (CDT) 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] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 12:49:19 +0800 Message-ID: In-Reply-To: <1153195027.44bc5c137b4dd@mail.opentransfer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqHlAO8Jjp8PMKRlOLKmr0GFWm4AABrifg From: "Ram O V Vishnu-A14676" To: , "Tolga Asveren" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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 comment on (1) is that all messages which are terminated/handled in the base FSM (RFC3588/3539) should carry app-id 0 and any other message should carry the respective other app-ids. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: nilanjans@condornetworks.com [mailto:nilanjans@condornetworks.com] Sent: Tuesday, July 18, 2006 9:27 AM To: Tolga Asveren Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Hi Victor, I agree with Tolga. The item (1) is really an interop issue and needs to be=20 added to the list. Thanks Prasad. Quoting Tolga Asveren : > Hi Victor, >=20 > Thanks a lot for that very useful update. >=20 > IMHO, a few of the items listed below have a higher importance than=20 > the other ones: >=20 > 1) AppId to be used by common diameter messages > 2) Grouping of error codes >=20 > Especially 1) seem to be a real interop-killer. I hope all people=20 > which have any opinion on this issue would post their ideas so that we > can reach a conclusion ASAP. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Friday, July 14, 2006 1:46 PM > > To: dime@ietf.org > > Subject: [Dime] Summary of 3588bis Issues Status > > > > > > Folks, > > > > The is a summary of the 3588bis issues discussion during DIME WG=20 > > meeting in IETF66. If you have comments on any of the existing=20 > > issues pls don't hesitate to post it on the DIME list so we can=20 > > facilitate quicker resolution or at least better understanding of=20 > > the problem. We also need some proposals on the open issues if you=20 > > believe they are truly issues. Note that the assigned issue numbers=20 > > are based on the current tracker which is for historical reasons the > > diameter-interop tracker=20 > > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > > > > Closed Issues: > > ------------- > > > > Issue 6 : TLS version issue > > Comments: interop related problem only. Does not=20 > > affect the > > base spec > > > > Issue 7 : Textual IP address qualify as FQDN > > Comments: Consensus that FQDN is defined as=20 > > "internet name" > > only > > > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > > Comments: Clarified in Sec 6.2 with the text > > > > "Any Proxy-Info AVPs in the request MUST be added to the > > answer message, in the same order they were present in > > the request." > > > > Open Issues with some consensus on proposals: > > --------------------------------------------- > > > > Notes: These issues have some consensus either during the IETF66 > > meeting and/or in the DIME mailing list. > > > > Issue 2 & 5 : App Ids used by common diameter messages > > Proposals: Use the application id of the current > > application > > > > Issue 3 & 16 : CER/CEA exchange in the open state > > Proposals: Need more consensus on current proposals > > posted in issue 16 > > > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > > Proposals: The Vendor-Id ABNF should one and only one > > instance, i.e. > > > > ::=3D < AVP Header: 260 > > > < Vendor-Id > > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > Issue 20 : Determining an offending/invalid AVP contained within > > the group AVP > > Proposals: Do nothing. The AVP code should be enough. > > Existing proposals may needlessly extend > > the length of the Failed-AVP. > > > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > > Proposals: Change diameter-message definition in Sec > > 3.2 to: > > > > = diameter-message=3Dheader[*fixed][*required][*optional] > > > > Open Issues with no consensus on proposals: > > ------------------------------------------ > > > > Issue 21 : URI schemes for AAA > > Proposals: draft-garcia-dime-aaa-uri-00.txt > > > > Issue 4 : Proxy agent stay in the path of the request message of > > a session > > Proposals: draft-tsou-dime-routing-ext-00.txt > > > > Open Issues that needs proposals: > > -------------------------------- > > > > Notes: These issues did not receive any comments during IETF66 and > > have no pending proposals. > > > > Issue 1 : Advertising relay application id (0xffffffff) in > > auth-application-id or acct-application-id > > > > Issue 15 : Duplicate detection requires server side storage of > > e2e id and origin-host avp > > > > Issue 13 : Clarify usage of application id avp's and how they > > relate to the app-id in the header > > > > Issue 9 & 19 : Error codes defined in wrong category > > > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > > > Issue 12 : Differing concepts and/or usage of Diameter Identity > > (FQDN + port or FQDN only) > > > > Issue 14 : Explicit text on which error category should have > > error flag (e-bit) set > > > > Issue 18 : Clarify reconnect behavior of peer based on value of > > Disconnect-Cause AVP > > > > Open issues falling into the "New Features" category: > > ---------------------------------------------------- > > > > Note: These features should use the extension procedures defined in 3588. > > No comments received in IETF66 meeting. > > > > Issue 23 : Predictive loop detection > > Comments: Optimzation techiniques in detecting loops > > at the succeeding hops > > > > Issue 22 : Fetch data request and location update request. > > Comments: Proposal to include LUR messages into > > base since its reusable in different > > applications > > > > If you believe there are some in-accurate info below, pls let us=20 > > know. > > > > best regards, > > victor > > > > _______________________________________________ > > 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 >=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 Tue Jul 18 01:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hjh-0006ck-9P; Tue, 18 Jul 2006 01:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2hjf-0006cf-S7 for dime@ietf.org; Tue, 18 Jul 2006 01:03:07 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2hjc-0005S0-Sy for dime@ietf.org; Tue, 18 Jul 2006 01:03:07 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2L007V32FUP1@szxga03-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 13:11:54 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2L005ED2FT8E@szxga03-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 13:11:54 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2L00J0U2IGG4@szxml04-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 13:13:29 +0800 (CST) Date: Tue, 18 Jul 2006 10:32:07 +0530 From: Rajith R Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: To: 'Ram O V Vishnu-A14676' Message-id: <000601c6aa27$522a2ce0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaqHlAO8Jjp8PMKRlOLKmr0GFWm4AABrifgAACCPaA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: dime@ietf.org 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 By base FSM do you mean only the connection management FSM (which handles CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as well? Regards Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >Sent: Tuesday, July 18, 2006 10:19 AM >To: nilanjans@condornetworks.com; Tolga Asveren >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >Hi, > >My comment on (1) is that all messages which are terminated/handled in >the base FSM (RFC3588/3539) should carry app-id 0 and any other message >should carry the respective other app-ids. > >Regards, >Vishnu. > >Motorola India Electronics Pvt Ltd >+91 9844178052 >[*] Motorola Internal Use Only > > > >-----Original Message----- >From: nilanjans@condornetworks.com [mailto:nilanjans@condornetworks.com] > >Sent: Tuesday, July 18, 2006 9:27 AM >To: Tolga Asveren >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >Hi Victor, > I agree with Tolga. The item (1) is really an interop issue and needs >to be >added to the list. > >Thanks >Prasad. > >Quoting Tolga Asveren : > >> Hi Victor, >> >> Thanks a lot for that very useful update. >> >> IMHO, a few of the items listed below have a higher importance than >> the other ones: >> >> 1) AppId to be used by common diameter messages >> 2) Grouping of error codes >> >> Especially 1) seem to be a real interop-killer. I hope all people >> which have any opinion on this issue would post their ideas so that we > >> can reach a conclusion ASAP. >> >> Thanks, >> Tolga >> >> > -----Original Message----- >> > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> > Sent: Friday, July 14, 2006 1:46 PM >> > To: dime@ietf.org >> > Subject: [Dime] Summary of 3588bis Issues Status >> > >> > >> > Folks, >> > >> > The is a summary of the 3588bis issues discussion during DIME WG >> > meeting in IETF66. If you have comments on any of the existing >> > issues pls don't hesitate to post it on the DIME list so we can >> > facilitate quicker resolution or at least better understanding of >> > the problem. We also need some proposals on the open issues if you >> > believe they are truly issues. Note that the assigned issue numbers >> > are based on the current tracker which is for historical reasons the > >> > diameter-interop tracker >> > (http://www.tschofenig.priv.at:8080/diameter-interop). >> > >> > >> > Closed Issues: >> > ------------- >> > >> > Issue 6 : TLS version issue >> > Comments: interop related problem only. Does not >> > affect the >> > base spec >> > >> > Issue 7 : Textual IP address qualify as FQDN >> > Comments: Consensus that FQDN is defined as >> > "internet name" >> > only >> > >> > Issue 11 : Confusion about use of Proxy-Info AVP for Relay >> > Comments: Clarified in Sec 6.2 with the text >> > >> > "Any Proxy-Info AVPs in the request MUST be added to >the >> > answer message, in the same order they were present >in >> > the request." >> > >> > Open Issues with some consensus on proposals: >> > --------------------------------------------- >> > >> > Notes: These issues have some consensus either during the IETF66 >> > meeting and/or in the DIME mailing list. >> > >> > Issue 2 & 5 : App Ids used by common diameter messages >> > Proposals: Use the application id of the current >> > application >> > >> > Issue 3 & 16 : CER/CEA exchange in the open state >> > Proposals: Need more consensus on current proposals >> > posted in issue 16 >> > >> > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA >avp >> > Proposals: The Vendor-Id ABNF should one and only >one >> > instance, i.e. >> > >> > ::= < AVP Header: 260 > >> > < Vendor-Id > >> > 0*1{ Auth-Application-Id } >> > 0*1{ Acct-Application-Id } >> > >> > Issue 20 : Determining an offending/invalid AVP contained >within >> > the group AVP >> > Proposals: Do nothing. The AVP code should be >enough. >> > Existing proposals may needlessly extend >> > the length of the Failed-AVP. >> > >> > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >> > Proposals: Change diameter-message definition in Sec > >> > 3.2 to: >> > >> > diameter-message=header[*fixed][*required][*optional] >> > >> > Open Issues with no consensus on proposals: >> > ------------------------------------------ >> > >> > Issue 21 : URI schemes for AAA >> > Proposals: draft-garcia-dime-aaa-uri-00.txt >> > >> > Issue 4 : Proxy agent stay in the path of the request message >of >> > a session >> > Proposals: draft-tsou-dime-routing-ext-00.txt >> > >> > Open Issues that needs proposals: >> > -------------------------------- >> > >> > Notes: These issues did not receive any comments during IETF66 and >> > have no pending proposals. >> > >> > Issue 1 : Advertising relay application id (0xffffffff) in >> > auth-application-id or acct-application-id >> > >> > Issue 15 : Duplicate detection requires server side storage of >> > e2e id and origin-host avp >> > >> > Issue 13 : Clarify usage of application id avp's and how they >> > relate to the app-id in the header >> > >> > Issue 9 & 19 : Error codes defined in wrong category >> > >> > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >> > >> > Issue 12 : Differing concepts and/or usage of Diameter Identity >> > (FQDN + port or FQDN only) >> > >> > Issue 14 : Explicit text on which error category should have >> > error flag (e-bit) set >> > >> > Issue 18 : Clarify reconnect behavior of peer based on value of >> > Disconnect-Cause AVP >> > >> > Open issues falling into the "New Features" category: >> > ---------------------------------------------------- >> > >> > Note: These features should use the extension procedures defined in >3588. >> > No comments received in IETF66 meeting. >> > >> > Issue 23 : Predictive loop detection >> > Comments: Optimzation techiniques in detecting loops >> > at the succeeding hops >> > >> > Issue 22 : Fetch data request and location update request. >> > Comments: Proposal to include LUR messages into >> > base since its reusable in different >> > applications >> > >> > If you believe there are some in-accurate info below, pls let us >> > know. >> > >> > best regards, >> > victor >> > >> > _______________________________________________ >> > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 01:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2iMS-00032H-Rg; Tue, 18 Jul 2006 01:43:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2iMQ-000324-Uv for dime@ietf.org; Tue, 18 Jul 2006 01:43:10 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2iMN-0000cp-GI for dime@ietf.org; Tue, 18 Jul 2006 01:43:10 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6I5h7gF011450 for ; Mon, 17 Jul 2006 22:43:07 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6I5h5GX026107 for ; Tue, 18 Jul 2006 00:43:06 -0500 (CDT) 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] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 13:43:04 +0800 Message-ID: In-Reply-To: <000601c6aa27$522a2ce0$a905120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqHlAO8Jjp8PMKRlOLKmr0GFWm4AABrifgAACCPaAAAUFs8A== From: "Ram O V Vishnu-A14676" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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, I meant section 5.6 of RFC 3588. I don't think the auth fsm in section 8.1 can handle messages with appid 0 because it talks about "Service-specific authorization" messages. I think the section 8.2 should handle messages with appid 3 (as per section 2.4). Ofcourse it could be something else too (like a 3GPP accounting appid), but not 0. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Rajith R [mailto:rajithr@huawei.com]=20 Sent: Tuesday, July 18, 2006 10:32 AM To: Ram O V Vishnu-A14676 Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status By base FSM do you mean only the connection management FSM (which handles CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as well? Regards Rajith ************************************************************************ **** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >Sent: Tuesday, July 18, 2006 10:19 AM >To: nilanjans@condornetworks.com; Tolga Asveren >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >Hi, > >My comment on (1) is that all messages which are terminated/handled in=20 >the base FSM (RFC3588/3539) should carry app-id 0 and any other message >should carry the respective other app-ids. > >Regards, >Vishnu. > >Motorola India Electronics Pvt Ltd >+91 9844178052 >[*] Motorola Internal Use Only > > > >-----Original Message----- >From: nilanjans@condornetworks.com=20 >[mailto:nilanjans@condornetworks.com] > >Sent: Tuesday, July 18, 2006 9:27 AM >To: Tolga Asveren >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >Hi Victor, > I agree with Tolga. The item (1) is really an interop issue and needs=20 >to be added to the list. > >Thanks >Prasad. > >Quoting Tolga Asveren : > >> Hi Victor, >> >> Thanks a lot for that very useful update. >> >> IMHO, a few of the items listed below have a higher importance than=20 >> the other ones: >> >> 1) AppId to be used by common diameter messages >> 2) Grouping of error codes >> >> Especially 1) seem to be a real interop-killer. I hope all people=20 >> which have any opinion on this issue would post their ideas so that=20 >> we > >> can reach a conclusion ASAP. >> >> Thanks, >> Tolga >> >> > -----Original Message----- >> > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> > Sent: Friday, July 14, 2006 1:46 PM >> > To: dime@ietf.org >> > Subject: [Dime] Summary of 3588bis Issues Status >> > >> > >> > Folks, >> > >> > The is a summary of the 3588bis issues discussion during DIME WG=20 >> > meeting in IETF66. If you have comments on any of the existing=20 >> > issues pls don't hesitate to post it on the DIME list so we can=20 >> > facilitate quicker resolution or at least better understanding of=20 >> > the problem. We also need some proposals on the open issues if you=20 >> > believe they are truly issues. Note that the assigned issue numbers >> > are based on the current tracker which is for historical reasons=20 >> > the > >> > diameter-interop tracker=20 >> > (http://www.tschofenig.priv.at:8080/diameter-interop). >> > >> > >> > Closed Issues: >> > ------------- >> > >> > Issue 6 : TLS version issue >> > Comments: interop related problem only. Does not=20 >> > affect the >> > base spec >> > >> > Issue 7 : Textual IP address qualify as FQDN >> > Comments: Consensus that FQDN is defined as=20 >> > "internet name" >> > only >> > >> > Issue 11 : Confusion about use of Proxy-Info AVP for Relay >> > Comments: Clarified in Sec 6.2 with the text >> > >> > "Any Proxy-Info AVPs in the request MUST be added=20 >> > to >the >> > answer message, in the same order they were=20 >> > present >in >> > the request." >> > >> > Open Issues with some consensus on proposals: >> > --------------------------------------------- >> > >> > Notes: These issues have some consensus either during the IETF66 >> > meeting and/or in the DIME mailing list. >> > >> > Issue 2 & 5 : App Ids used by common diameter messages >> > Proposals: Use the application id of the current >> > application >> > >> > Issue 3 & 16 : CER/CEA exchange in the open state >> > Proposals: Need more consensus on current proposals >> > posted in issue 16 >> > >> > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA >avp >> > Proposals: The Vendor-Id ABNF should one and only >one >> > instance, i.e. >> > >> > ::=3D < AVP Header: 260 > >> > < Vendor-Id > >> > 0*1{ Auth-Application-Id } >> > 0*1{ Acct-Application-Id } >> > >> > Issue 20 : Determining an offending/invalid AVP contained >within >> > the group AVP >> > Proposals: Do nothing. The AVP code should be >enough. >> > Existing proposals may needlessly extend >> > the length of the Failed-AVP. >> > >> > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >> > Proposals: Change diameter-message definition in=20 >> > Sec > >> > 3.2 to: >> > >> > = diameter-message=3Dheader[*fixed][*required][*optional] >> > >> > Open Issues with no consensus on proposals: >> > ------------------------------------------ >> > >> > Issue 21 : URI schemes for AAA >> > Proposals: draft-garcia-dime-aaa-uri-00.txt >> > >> > Issue 4 : Proxy agent stay in the path of the request message >of >> > a session >> > Proposals: draft-tsou-dime-routing-ext-00.txt >> > >> > Open Issues that needs proposals: >> > -------------------------------- >> > >> > Notes: These issues did not receive any comments during IETF66 and >> > have no pending proposals. >> > >> > Issue 1 : Advertising relay application id (0xffffffff) in >> > auth-application-id or acct-application-id >> > >> > Issue 15 : Duplicate detection requires server side storage of >> > e2e id and origin-host avp >> > >> > Issue 13 : Clarify usage of application id avp's and how they >> > relate to the app-id in the header >> > >> > Issue 9 & 19 : Error codes defined in wrong category >> > >> > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >> > >> > Issue 12 : Differing concepts and/or usage of Diameter Identity >> > (FQDN + port or FQDN only) >> > >> > Issue 14 : Explicit text on which error category should have >> > error flag (e-bit) set >> > >> > Issue 18 : Clarify reconnect behavior of peer based on value of >> > Disconnect-Cause AVP >> > >> > Open issues falling into the "New Features" category: >> > ---------------------------------------------------- >> > >> > Note: These features should use the extension procedures defined in >3588. >> > No comments received in IETF66 meeting. >> > >> > Issue 23 : Predictive loop detection >> > Comments: Optimzation techiniques in detecting loops >> > at the succeeding hops >> > >> > Issue 22 : Fetch data request and location update request. >> > Comments: Proposal to include LUR messages into >> > base since its reusable in different >> > applications >> > >> > If you believe there are some in-accurate info below, pls let us=20 >> > know. >> > >> > best regards, >> > victor >> > >> > _______________________________________________ >> > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 02:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2j4B-0005Ko-9L; Tue, 18 Jul 2006 02:28:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2j49-0005Kj-Lz for dime@ietf.org; Tue, 18 Jul 2006 02:28:21 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2j48-0003yP-5A for dime@ietf.org; Tue, 18 Jul 2006 02:28:21 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2L0075Q5ZJWP@szxga01-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 14:28:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2L008F65ZIUN@szxga01-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 14:28:31 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2L00KFR6EK4V@szxml04-in.huawei.com> for dime@ietf.org; Tue, 18 Jul 2006 14:37:33 +0800 (CST) Date: Tue, 18 Jul 2006 11:56:12 +0530 From: Rajith R Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: To: 'Ram O V Vishnu-A14676' Message-id: <000701c6aa33$10d33910$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaqHlAO8Jjp8PMKRlOLKmr0GFWm4AABrifgAACCPaAAAUFs8AAAdt4g X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: dime@ietf.org 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 Hi I also agree that app Id 0 should be used only for CE, DW & DP commands. However, I could not understand why we have the app Id field in the DIAMETER header? RFC 3588 specifies that all accounting, auth or experimental commands MUST have Acct.,Auth. or Vendor Sp. App Id respectively. So, I assume, the app Id field in the header might be for nodes to quickly identify whether the msg is for the connection management FSM (app Id = 0) or for some session management logic (like NASREQ, Base-Accounting or Vendor specific). But this could be achieved by checking the command code as well. Regards Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >Sent: Tuesday, July 18, 2006 11:13 AM >To: rajithr@huawei.com >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >Rajith, > >I meant section 5.6 of RFC 3588. > >I don't think the auth fsm in section 8.1 can handle messages with appid >0 because it talks about "Service-specific authorization" messages. > >I think the section 8.2 should handle messages with appid 3 (as per >section 2.4). Ofcourse it could be something else too (like a 3GPP >accounting appid), but not 0. > >Regards, >Vishnu. > >Motorola India Electronics Pvt Ltd >+91 9844178052 >[*] Motorola Internal Use Only > > > >-----Original Message----- >From: Rajith R [mailto:rajithr@huawei.com] >Sent: Tuesday, July 18, 2006 10:32 AM >To: Ram O V Vishnu-A14676 >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >By base FSM do you mean only the connection management FSM (which >handles >CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as >well? > > >Regards > >Rajith >************************************************************************ >**** >This e-mail and attachments contain confidential information from >HUAWEI, which is intended only for the person or entity whose address is >listed above. Any use of the information contained herein in any way >(including, but not limited to, total or partial disclosure, >reproduction, or >dissemination) by persons other than the intended recipient's) is >prohibited. If you receive this e-mail in error, please notify the >sender by phone or email immediately and delete it! >>-----Original Message----- >>From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >>Sent: Tuesday, July 18, 2006 10:19 AM >>To: nilanjans@condornetworks.com; Tolga Asveren >>Cc: dime@ietf.org >>Subject: RE: [Dime] Summary of 3588bis Issues Status >> >>Hi, >> >>My comment on (1) is that all messages which are terminated/handled in >>the base FSM (RFC3588/3539) should carry app-id 0 and any other message > >>should carry the respective other app-ids. >> >>Regards, >>Vishnu. >> >>Motorola India Electronics Pvt Ltd >>+91 9844178052 >>[*] Motorola Internal Use Only >> >> >> >>-----Original Message----- >>From: nilanjans@condornetworks.com >>[mailto:nilanjans@condornetworks.com] >> >>Sent: Tuesday, July 18, 2006 9:27 AM >>To: Tolga Asveren >>Cc: dime@ietf.org >>Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> >>Hi Victor, >> I agree with Tolga. The item (1) is really an interop issue and needs >>to be added to the list. >> >>Thanks >>Prasad. >> >>Quoting Tolga Asveren : >> >>> Hi Victor, >>> >>> Thanks a lot for that very useful update. >>> >>> IMHO, a few of the items listed below have a higher importance than >>> the other ones: >>> >>> 1) AppId to be used by common diameter messages >>> 2) Grouping of error codes >>> >>> Especially 1) seem to be a real interop-killer. I hope all people >>> which have any opinion on this issue would post their ideas so that >>> we >> >>> can reach a conclusion ASAP. >>> >>> Thanks, >>> Tolga >>> >>> > -----Original Message----- >>> > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>> > Sent: Friday, July 14, 2006 1:46 PM >>> > To: dime@ietf.org >>> > Subject: [Dime] Summary of 3588bis Issues Status >>> > >>> > >>> > Folks, >>> > >>> > The is a summary of the 3588bis issues discussion during DIME WG >>> > meeting in IETF66. If you have comments on any of the existing >>> > issues pls don't hesitate to post it on the DIME list so we can >>> > facilitate quicker resolution or at least better understanding of >>> > the problem. We also need some proposals on the open issues if you >>> > believe they are truly issues. Note that the assigned issue numbers > >>> > are based on the current tracker which is for historical reasons >>> > the >> >>> > diameter-interop tracker >>> > (http://www.tschofenig.priv.at:8080/diameter-interop). >>> > >>> > >>> > Closed Issues: >>> > ------------- >>> > >>> > Issue 6 : TLS version issue >>> > Comments: interop related problem only. Does not >>> > affect the >>> > base spec >>> > >>> > Issue 7 : Textual IP address qualify as FQDN >>> > Comments: Consensus that FQDN is defined as >>> > "internet name" >>> > only >>> > >>> > Issue 11 : Confusion about use of Proxy-Info AVP for Relay >>> > Comments: Clarified in Sec 6.2 with the text >>> > >>> > "Any Proxy-Info AVPs in the request MUST be added >>> > to >>the >>> > answer message, in the same order they were >>> > present >>in >>> > the request." >>> > >>> > Open Issues with some consensus on proposals: >>> > --------------------------------------------- >>> > >>> > Notes: These issues have some consensus either during the IETF66 >>> > meeting and/or in the DIME mailing list. >>> > >>> > Issue 2 & 5 : App Ids used by common diameter messages >>> > Proposals: Use the application id of the current >>> > application >>> > >>> > Issue 3 & 16 : CER/CEA exchange in the open state >>> > Proposals: Need more consensus on current proposals >>> > posted in issue 16 >>> > >>> > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA >>avp >>> > Proposals: The Vendor-Id ABNF should one and only >>one >>> > instance, i.e. >>> > >>> > ::= < AVP Header: 260 > >>> > < Vendor-Id > >>> > 0*1{ Auth-Application-Id } >>> > 0*1{ Acct-Application-Id } >>> > >>> > Issue 20 : Determining an offending/invalid AVP contained >>within >>> > the group AVP >>> > Proposals: Do nothing. The AVP code should be >>enough. >>> > Existing proposals may needlessly extend >>> > the length of the Failed-AVP. >>> > >>> > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >>> > Proposals: Change diameter-message definition in >>> > Sec >> >>> > 3.2 to: >>> > >>> > diameter-message=header[*fixed][*required][*optional] >>> > >>> > Open Issues with no consensus on proposals: >>> > ------------------------------------------ >>> > >>> > Issue 21 : URI schemes for AAA >>> > Proposals: draft-garcia-dime-aaa-uri-00.txt >>> > >>> > Issue 4 : Proxy agent stay in the path of the request message >>of >>> > a session >>> > Proposals: draft-tsou-dime-routing-ext-00.txt >>> > >>> > Open Issues that needs proposals: >>> > -------------------------------- >>> > >>> > Notes: These issues did not receive any comments during IETF66 and >>> > have no pending proposals. >>> > >>> > Issue 1 : Advertising relay application id (0xffffffff) in >>> > auth-application-id or acct-application-id >>> > >>> > Issue 15 : Duplicate detection requires server side storage of >>> > e2e id and origin-host avp >>> > >>> > Issue 13 : Clarify usage of application id avp's and how they >>> > relate to the app-id in the header >>> > >>> > Issue 9 & 19 : Error codes defined in wrong category >>> > >>> > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >>> > >>> > Issue 12 : Differing concepts and/or usage of Diameter >Identity >>> > (FQDN + port or FQDN only) >>> > >>> > Issue 14 : Explicit text on which error category should have >>> > error flag (e-bit) set >>> > >>> > Issue 18 : Clarify reconnect behavior of peer based on value >of >>> > Disconnect-Cause AVP >>> > >>> > Open issues falling into the "New Features" category: >>> > ---------------------------------------------------- >>> > >>> > Note: These features should use the extension procedures defined in >>3588. >>> > No comments received in IETF66 meeting. >>> > >>> > Issue 23 : Predictive loop detection >>> > Comments: Optimzation techiniques in detecting >loops >>> > at the succeeding hops >>> > >>> > Issue 22 : Fetch data request and location update request. >>> > Comments: Proposal to include LUR messages into >>> > base since its reusable in different >>> > applications >>> > >>> > If you believe there are some in-accurate info below, pls let us >>> > know. >>> > >>> > best regards, >>> > victor >>> > >>> > _______________________________________________ >>> > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 08:15:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2oTw-0000MW-PB; Tue, 18 Jul 2006 08:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2oTv-0000FL-71 for dime@ietf.org; Tue, 18 Jul 2006 08:15:19 -0400 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 1G2oTs-0005Ft-Em for dime@ietf.org; Tue, 18 Jul 2006 08:15:19 -0400 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 k6ICEcNs064993; Tue, 18 Jul 2006 08:14:38 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BCD0B6.1080809@tari.toshiba.com> Date: Tue, 18 Jul 2006 08:14:46 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: nilanjans@condornetworks.com Subject: Re: [Dime] Summary of 3588bis Issues Status References: <1153195027.44bc5c137b4dd@mail.opentransfer.com> In-Reply-To: <1153195027.44bc5c137b4dd@mail.opentransfer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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, > Hi Victor, > I agree with Tolga. The item (1) is really an interop issue and needs to be > added to the list. > It is on the list as issue #2&5. victor > Thanks > Prasad. > > Quoting Tolga Asveren : > > >> Hi Victor, >> >> Thanks a lot for that very useful update. >> >> IMHO, a few of the items listed below have a higher importance than the >> other ones: >> >> 1) AppId to be used by common diameter messages >> 2) Grouping of error codes >> >> Especially 1) seem to be a real interop-killer. I hope all people which have >> any opinion on this issue would post their ideas so that we can reach a >> conclusion ASAP. >> >> Thanks, >> Tolga >> >> >>> -----Original Message----- >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>> Sent: Friday, July 14, 2006 1:46 PM >>> To: dime@ietf.org >>> Subject: [Dime] Summary of 3588bis Issues Status >>> >>> >>> Folks, >>> >>> The is a summary of the 3588bis issues discussion during DIME WG meeting >>> in IETF66. If you have comments on any of the existing issues pls don't >>> hesitate to post it on the DIME list so we can facilitate quicker >>> resolution or at least better understanding of the problem. We also need >>> some proposals on the open issues if you believe they are truly issues. >>> Note that the assigned issue numbers are based on the current tracker >>> which is for historical reasons the diameter-interop tracker >>> (http://www.tschofenig.priv.at:8080/diameter-interop). >>> >>> >>> Closed Issues: >>> ------------- >>> >>> Issue 6 : TLS version issue >>> Comments: interop related problem only. Does not >>> affect the >>> base spec >>> >>> Issue 7 : Textual IP address qualify as FQDN >>> Comments: Consensus that FQDN is defined as >>> "internet name" >>> only >>> >>> Issue 11 : Confusion about use of Proxy-Info AVP for Relay >>> Comments: Clarified in Sec 6.2 with the text >>> >>> "Any Proxy-Info AVPs in the request MUST be added to the >>> answer message, in the same order they were present in >>> the request." >>> >>> Open Issues with some consensus on proposals: >>> --------------------------------------------- >>> >>> Notes: These issues have some consensus either during the IETF66 >>> meeting and/or in the DIME mailing list. >>> >>> Issue 2 & 5 : App Ids used by common diameter messages >>> Proposals: Use the application id of the current >>> application >>> >>> Issue 3 & 16 : CER/CEA exchange in the open state >>> Proposals: Need more consensus on current proposals >>> posted in issue 16 >>> >>> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp >>> Proposals: The Vendor-Id ABNF should one and only one >>> instance, i.e. >>> >>> ::= < AVP Header: 260 > >>> < Vendor-Id > >>> 0*1{ Auth-Application-Id } >>> 0*1{ Acct-Application-Id } >>> >>> Issue 20 : Determining an offending/invalid AVP contained within >>> the group AVP >>> Proposals: Do nothing. The AVP code should be enough. >>> Existing proposals may needlessly extend >>> the length of the Failed-AVP. >>> >>> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >>> Proposals: Change diameter-message definition in >>> Sec 3.2 to: >>> >>> diameter-message=header[*fixed][*required][*optional] >>> >>> Open Issues with no consensus on proposals: >>> ------------------------------------------ >>> >>> Issue 21 : URI schemes for AAA >>> Proposals: draft-garcia-dime-aaa-uri-00.txt >>> >>> Issue 4 : Proxy agent stay in the path of the request message of >>> a session >>> Proposals: draft-tsou-dime-routing-ext-00.txt >>> >>> Open Issues that needs proposals: >>> -------------------------------- >>> >>> Notes: These issues did not receive any comments during IETF66 and >>> have no pending proposals. >>> >>> Issue 1 : Advertising relay application id (0xffffffff) in >>> auth-application-id or acct-application-id >>> >>> Issue 15 : Duplicate detection requires server side storage of >>> e2e id and origin-host avp >>> >>> Issue 13 : Clarify usage of application id avp's and how they >>> relate to the app-id in the header >>> >>> Issue 9 & 19 : Error codes defined in wrong category >>> >>> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >>> >>> Issue 12 : Differing concepts and/or usage of Diameter Identity >>> (FQDN + port or FQDN only) >>> >>> Issue 14 : Explicit text on which error category should have >>> error flag (e-bit) set >>> >>> Issue 18 : Clarify reconnect behavior of peer based on value of >>> Disconnect-Cause AVP >>> >>> Open issues falling into the "New Features" category: >>> ---------------------------------------------------- >>> >>> Note: These features should use the extension procedures defined in 3588. >>> No comments received in IETF66 meeting. >>> >>> Issue 23 : Predictive loop detection >>> Comments: Optimzation techiniques in detecting loops >>> at the succeeding hops >>> >>> Issue 22 : Fetch data request and location update request. >>> Comments: Proposal to include LUR messages into >>> base since its reusable in different >>> applications >>> >>> If you believe there are some in-accurate info below, pls let us know. >>> >>> best regards, >>> victor >>> >>> _______________________________________________ >>> 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 Jul 18 08:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p48-0002i4-7K; Tue, 18 Jul 2006 08:52:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p3h-0002XV-Dn for dime@ietf.org; Tue, 18 Jul 2006 08:52:17 -0400 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 1G2oxX-00067G-Jt for dime@ietf.org; Tue, 18 Jul 2006 08:45:58 -0400 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 k6ICj8rq065090; Tue, 18 Jul 2006 08:45:09 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BCD7D5.2020204@tari.toshiba.com> Date: Tue, 18 Jul 2006 08:45:09 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Summary of 3588bis Issues Status References: <000701c6aa33$10d33910$a905120a@china.huawei.com> In-Reply-To: <000701c6aa33$10d33910$a905120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 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 Folks, Just for the clarity. This topic is issue #2&5 and refers to what app id should "application session level" messages defined in the base protocol (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the meeting and more likely in this list as well is that it MUST carry the app id of the application using it. Messages dealing with peer connectivity (CER/CEA, DWR/DWA, DPR/DPA) will carry an app id of 0. If there are no technical objections to this solution then we can close this issue. Comments below: > Hi > I also agree that app Id 0 should be used only for CE, DW & DP > commands. > > However, I could not understand why we have the app Id field in the > DIAMETER header? > > RFC 3588 specifies that all accounting, auth or experimental > commands MUST have Acct.,Auth. or Vendor Sp. App Id respectively. > So, I assume, the app Id field in the header might be for nodes to > quickly identify whether the msg is for the connection management FSM (app > Id = 0) or for some session management logic (like NASREQ, Base-Accounting > or Vendor specific). But this could be achieved by checking the command code > as well. > > > The app id in the header make's it easier to route messages rather than searching for the app id avp's in the message. Relay's does not really care about command codes. A more important issue that we should discuss is issue#13 (Clarify usage of application id avp's and how they relate to the app-id in the header) and consequently issue #1 (Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id). Pls send your comments. best regards, victor > Regards > > Rajith > **************************************************************************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > > >> -----Original Message----- >> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >> Sent: Tuesday, July 18, 2006 11:13 AM >> To: rajithr@huawei.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> Rajith, >> >> I meant section 5.6 of RFC 3588. >> >> I don't think the auth fsm in section 8.1 can handle messages with appid >> 0 because it talks about "Service-specific authorization" messages. >> >> I think the section 8.2 should handle messages with appid 3 (as per >> section 2.4). Ofcourse it could be something else too (like a 3GPP >> accounting appid), but not 0. >> >> Regards, >> Vishnu. >> >> Motorola India Electronics Pvt Ltd >> +91 9844178052 >> [*] Motorola Internal Use Only >> >> >> >> -----Original Message----- >> From: Rajith R [mailto:rajithr@huawei.com] >> Sent: Tuesday, July 18, 2006 10:32 AM >> To: Ram O V Vishnu-A14676 >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> >> By base FSM do you mean only the connection management FSM (which >> handles >> CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as >> well? >> >> >> Regards >> >> Rajith >> ************************************************************************ >> **** >> This e-mail and attachments contain confidential information from >> HUAWEI, which is intended only for the person or entity whose address is >> listed above. Any use of the information contained herein in any way >> (including, but not limited to, total or partial disclosure, >> reproduction, or >> dissemination) by persons other than the intended recipient's) is >> prohibited. If you receive this e-mail in error, please notify the >> sender by phone or email immediately and delete it! >> >>> -----Original Message----- >>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] >>> Sent: Tuesday, July 18, 2006 10:19 AM >>> To: nilanjans@condornetworks.com; Tolga Asveren >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> Hi, >>> >>> My comment on (1) is that all messages which are terminated/handled in >>> the base FSM (RFC3588/3539) should carry app-id 0 and any other message >>> >>> should carry the respective other app-ids. >>> >>> Regards, >>> Vishnu. >>> >>> Motorola India Electronics Pvt Ltd >>> +91 9844178052 >>> [*] Motorola Internal Use Only >>> >>> >>> >>> -----Original Message----- >>> From: nilanjans@condornetworks.com >>> [mailto:nilanjans@condornetworks.com] >>> >>> Sent: Tuesday, July 18, 2006 9:27 AM >>> To: Tolga Asveren >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> >>> Hi Victor, >>> I agree with Tolga. The item (1) is really an interop issue and needs >>> to be added to the list. >>> >>> Thanks >>> Prasad. >>> >>> Quoting Tolga Asveren : >>> >>> >>>> Hi Victor, >>>> >>>> Thanks a lot for that very useful update. >>>> >>>> IMHO, a few of the items listed below have a higher importance than >>>> the other ones: >>>> >>>> 1) AppId to be used by common diameter messages >>>> 2) Grouping of error codes >>>> >>>> Especially 1) seem to be a real interop-killer. I hope all people >>>> which have any opinion on this issue would post their ideas so that >>>> we >>>> >>>> can reach a conclusion ASAP. >>>> >>>> Thanks, >>>> Tolga >>>> >>>> >>>>> -----Original Message----- >>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>>> Sent: Friday, July 14, 2006 1:46 PM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] Summary of 3588bis Issues Status >>>>> >>>>> >>>>> Folks, >>>>> >>>>> The is a summary of the 3588bis issues discussion during DIME WG >>>>> meeting in IETF66. If you have comments on any of the existing >>>>> issues pls don't hesitate to post it on the DIME list so we can >>>>> facilitate quicker resolution or at least better understanding of >>>>> the problem. We also need some proposals on the open issues if you >>>>> believe they are truly issues. Note that the assigned issue numbers >>>>> >>>>> are based on the current tracker which is for historical reasons >>>>> the >>>>> >>>>> diameter-interop tracker >>>>> (http://www.tschofenig.priv.at:8080/diameter-interop). >>>>> >>>>> >>>>> Closed Issues: >>>>> ------------- >>>>> >>>>> Issue 6 : TLS version issue >>>>> Comments: interop related problem only. Does not >>>>> affect the >>>>> base spec >>>>> >>>>> Issue 7 : Textual IP address qualify as FQDN >>>>> Comments: Consensus that FQDN is defined as >>>>> "internet name" >>>>> only >>>>> >>>>> Issue 11 : Confusion about use of Proxy-Info AVP for Relay >>>>> Comments: Clarified in Sec 6.2 with the text >>>>> >>>>> "Any Proxy-Info AVPs in the request MUST be added >>>>> to >>>>> >>> the >>> >>>>> answer message, in the same order they were >>>>> present >>>>> >>> in >>> >>>>> the request." >>>>> >>>>> Open Issues with some consensus on proposals: >>>>> --------------------------------------------- >>>>> >>>>> Notes: These issues have some consensus either during the IETF66 >>>>> meeting and/or in the DIME mailing list. >>>>> >>>>> Issue 2 & 5 : App Ids used by common diameter messages >>>>> Proposals: Use the application id of the current >>>>> application >>>>> >>>>> Issue 3 & 16 : CER/CEA exchange in the open state >>>>> Proposals: Need more consensus on current proposals >>>>> posted in issue 16 >>>>> >>>>> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA >>>>> >>> avp >>> >>>>> Proposals: The Vendor-Id ABNF should one and only >>>>> >>> one >>> >>>>> instance, i.e. >>>>> >>>>> ::= < AVP Header: 260 > >>>>> < Vendor-Id > >>>>> 0*1{ Auth-Application-Id } >>>>> 0*1{ Acct-Application-Id } >>>>> >>>>> Issue 20 : Determining an offending/invalid AVP contained >>>>> >>> within >>> >>>>> the group AVP >>>>> Proposals: Do nothing. The AVP code should be >>>>> >>> enough. >>> >>>>> Existing proposals may needlessly extend >>>>> the length of the Failed-AVP. >>>>> >>>>> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >>>>> Proposals: Change diameter-message definition in >>>>> Sec >>>>> >>>>> 3.2 to: >>>>> >>>>> diameter-message=header[*fixed][*required][*optional] >>>>> >>>>> Open Issues with no consensus on proposals: >>>>> ------------------------------------------ >>>>> >>>>> Issue 21 : URI schemes for AAA >>>>> Proposals: draft-garcia-dime-aaa-uri-00.txt >>>>> >>>>> Issue 4 : Proxy agent stay in the path of the request message >>>>> >>> of >>> >>>>> a session >>>>> Proposals: draft-tsou-dime-routing-ext-00.txt >>>>> >>>>> Open Issues that needs proposals: >>>>> -------------------------------- >>>>> >>>>> Notes: These issues did not receive any comments during IETF66 and >>>>> have no pending proposals. >>>>> >>>>> Issue 1 : Advertising relay application id (0xffffffff) in >>>>> auth-application-id or acct-application-id >>>>> >>>>> Issue 15 : Duplicate detection requires server side storage of >>>>> e2e id and origin-host avp >>>>> >>>>> Issue 13 : Clarify usage of application id avp's and how they >>>>> relate to the app-id in the header >>>>> >>>>> Issue 9 & 19 : Error codes defined in wrong category >>>>> >>>>> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >>>>> >>>>> Issue 12 : Differing concepts and/or usage of Diameter >>>>> >> Identity >> >>>>> (FQDN + port or FQDN only) >>>>> >>>>> Issue 14 : Explicit text on which error category should have >>>>> error flag (e-bit) set >>>>> >>>>> Issue 18 : Clarify reconnect behavior of peer based on value >>>>> >> of >> >>>>> Disconnect-Cause AVP >>>>> >>>>> Open issues falling into the "New Features" category: >>>>> ---------------------------------------------------- >>>>> >>>>> Note: These features should use the extension procedures defined in >>>>> >>> 3588. >>> >>>>> No comments received in IETF66 meeting. >>>>> >>>>> Issue 23 : Predictive loop detection >>>>> Comments: Optimzation techiniques in detecting >>>>> >> loops >> >>>>> at the succeeding hops >>>>> >>>>> Issue 22 : Fetch data request and location update request. >>>>> Comments: Proposal to include LUR messages into >>>>> base since its reusable in different >>>>> applications >>>>> >>>>> If you believe there are some in-accurate info below, pls let us >>>>> know. >>>>> >>>>> best regards, >>>>> victor >>>>> >>>>> _______________________________________________ >>>>> 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 >>> > > > _______________________________________________ > 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 Jul 18 10:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qIZ-0004us-Qc; Tue, 18 Jul 2006 10:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qIY-0004un-LK for dime@ietf.org; Tue, 18 Jul 2006 10:11:42 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qIV-0002dN-GU for dime@ietf.org; Tue, 18 Jul 2006 10:11:42 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 06E49C584D for ; Tue, 18 Jul 2006 10:11:25 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6IEBZoZ011030 for ; Tue, 18 Jul 2006 10:11:36 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 09:47:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44BCD7D5.2020204@tari.toshiba.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 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 Victor, I agree with this. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, July 18, 2006 8:45 AM > To: rajithr@huawei.com > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > Folks, > > Just for the clarity. This topic is issue #2&5 and refers to what app id > should "application session level" messages defined in the base protocol > (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the > meeting and more likely in this list as well is that it MUST carry the > app id of the application using it. Messages dealing with peer > connectivity (CER/CEA, DWR/DWA, DPR/DPA) will carry an app id of 0. If > there are no technical objections to this solution then we can close > this issue. > > Comments below: > > Hi > > I also agree that app Id 0 should be used only for CE, DW & DP > > commands. > > > > However, I could not understand why we have the app Id field in the > > DIAMETER header? > > > > RFC 3588 specifies that all accounting, auth or experimental > > commands MUST have Acct.,Auth. or Vendor Sp. App Id respectively. > > So, I assume, the app Id field in the header might be for nodes to > > quickly identify whether the msg is for the connection > management FSM (app > > Id = 0) or for some session management logic (like NASREQ, > Base-Accounting > > or Vendor specific). But this could be achieved by checking the > command code > > as well. > > > > > > > The app id in the header make's it easier to route messages rather than > searching for the app id avp's in the message. Relay's does not really > care about command codes. A more important issue that we should discuss > is issue#13 (Clarify usage of application id avp's and how they relate > to the app-id in the header) and consequently issue #1 (Advertising > relay application id (0xffffffff) in auth-application-id or > acct-application-id). Pls send your comments. > > best regards, > victor > > > > Regards > > > > Rajith > > > ****************************************************************** > ********** > > This e-mail and attachments contain confidential information > from HUAWEI, > > which is intended only for the person or entity whose address is listed > > above. Any use of the information contained herein in any way > (including, > > but not limited to, total or partial disclosure, reproduction, or > > dissemination) by persons other than the intended recipient's) is > > prohibited. If you receive this e-mail in error, please notify > the sender by > > phone or email immediately and delete it! > > > > > >> -----Original Message----- > >> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >> Sent: Tuesday, July 18, 2006 11:13 AM > >> To: rajithr@huawei.com > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> Rajith, > >> > >> I meant section 5.6 of RFC 3588. > >> > >> I don't think the auth fsm in section 8.1 can handle messages > with appid > >> 0 because it talks about "Service-specific authorization" messages. > >> > >> I think the section 8.2 should handle messages with appid 3 (as per > >> section 2.4). Ofcourse it could be something else too (like a 3GPP > >> accounting appid), but not 0. > >> > >> Regards, > >> Vishnu. > >> > >> Motorola India Electronics Pvt Ltd > >> +91 9844178052 > >> [*] Motorola Internal Use Only > >> > >> > >> > >> -----Original Message----- > >> From: Rajith R [mailto:rajithr@huawei.com] > >> Sent: Tuesday, July 18, 2006 10:32 AM > >> To: Ram O V Vishnu-A14676 > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> > >> By base FSM do you mean only the connection management FSM (which > >> handles > >> CE/DW/DP) or the Auth./Accounting state machines defined in RFC 3588 as > >> well? > >> > >> > >> Regards > >> > >> Rajith > >> > ************************************************************************ > >> **** > >> This e-mail and attachments contain confidential information from > >> HUAWEI, which is intended only for the person or entity whose > address is > >> listed above. Any use of the information contained herein in any way > >> (including, but not limited to, total or partial disclosure, > >> reproduction, or > >> dissemination) by persons other than the intended recipient's) is > >> prohibited. If you receive this e-mail in error, please notify the > >> sender by phone or email immediately and delete it! > >> > >>> -----Original Message----- > >>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >>> Sent: Tuesday, July 18, 2006 10:19 AM > >>> To: nilanjans@condornetworks.com; Tolga Asveren > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> Hi, > >>> > >>> My comment on (1) is that all messages which are terminated/handled in > >>> the base FSM (RFC3588/3539) should carry app-id 0 and any > other message > >>> > >>> should carry the respective other app-ids. > >>> > >>> Regards, > >>> Vishnu. > >>> > >>> Motorola India Electronics Pvt Ltd > >>> +91 9844178052 > >>> [*] Motorola Internal Use Only > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: nilanjans@condornetworks.com > >>> [mailto:nilanjans@condornetworks.com] > >>> > >>> Sent: Tuesday, July 18, 2006 9:27 AM > >>> To: Tolga Asveren > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> > >>> Hi Victor, > >>> I agree with Tolga. The item (1) is really an interop issue and needs > >>> to be added to the list. > >>> > >>> Thanks > >>> Prasad. > >>> > >>> Quoting Tolga Asveren : > >>> > >>> > >>>> Hi Victor, > >>>> > >>>> Thanks a lot for that very useful update. > >>>> > >>>> IMHO, a few of the items listed below have a higher importance than > >>>> the other ones: > >>>> > >>>> 1) AppId to be used by common diameter messages > >>>> 2) Grouping of error codes > >>>> > >>>> Especially 1) seem to be a real interop-killer. I hope all people > >>>> which have any opinion on this issue would post their ideas so that > >>>> we > >>>> > >>>> can reach a conclusion ASAP. > >>>> > >>>> Thanks, > >>>> Tolga > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>>>> Sent: Friday, July 14, 2006 1:46 PM > >>>>> To: dime@ietf.org > >>>>> Subject: [Dime] Summary of 3588bis Issues Status > >>>>> > >>>>> > >>>>> Folks, > >>>>> > >>>>> The is a summary of the 3588bis issues discussion during DIME WG > >>>>> meeting in IETF66. If you have comments on any of the existing > >>>>> issues pls don't hesitate to post it on the DIME list so we can > >>>>> facilitate quicker resolution or at least better understanding of > >>>>> the problem. We also need some proposals on the open issues if you > >>>>> believe they are truly issues. Note that the assigned issue numbers > >>>>> > >>>>> are based on the current tracker which is for historical reasons > >>>>> the > >>>>> > >>>>> diameter-interop tracker > >>>>> (http://www.tschofenig.priv.at:8080/diameter-interop). > >>>>> > >>>>> > >>>>> Closed Issues: > >>>>> ------------- > >>>>> > >>>>> Issue 6 : TLS version issue > >>>>> Comments: interop related problem only. Does not > >>>>> affect the > >>>>> base spec > >>>>> > >>>>> Issue 7 : Textual IP address qualify as FQDN > >>>>> Comments: Consensus that FQDN is defined as > >>>>> "internet name" > >>>>> only > >>>>> > >>>>> Issue 11 : Confusion about use of Proxy-Info AVP for Relay > >>>>> Comments: Clarified in Sec 6.2 with the text > >>>>> > >>>>> "Any Proxy-Info AVPs in the request MUST be added > >>>>> to > >>>>> > >>> the > >>> > >>>>> answer message, in the same order they were > >>>>> present > >>>>> > >>> in > >>> > >>>>> the request." > >>>>> > >>>>> Open Issues with some consensus on proposals: > >>>>> --------------------------------------------- > >>>>> > >>>>> Notes: These issues have some consensus either during the IETF66 > >>>>> meeting and/or in the DIME mailing list. > >>>>> > >>>>> Issue 2 & 5 : App Ids used by common diameter messages > >>>>> Proposals: Use the application id of the current > >>>>> application > >>>>> > >>>>> Issue 3 & 16 : CER/CEA exchange in the open state > >>>>> Proposals: Need more consensus on current proposals > >>>>> posted in issue 16 > >>>>> > >>>>> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA > >>>>> > >>> avp > >>> > >>>>> Proposals: The Vendor-Id ABNF should one and only > >>>>> > >>> one > >>> > >>>>> instance, i.e. > >>>>> > >>>>> ::= < AVP Header: 260 > > >>>>> < Vendor-Id > > >>>>> 0*1{ Auth-Application-Id } > >>>>> 0*1{ Acct-Application-Id } > >>>>> > >>>>> Issue 20 : Determining an offending/invalid AVP contained > >>>>> > >>> within > >>> > >>>>> the group AVP > >>>>> Proposals: Do nothing. The AVP code should be > >>>>> > >>> enough. > >>> > >>>>> Existing proposals may needlessly extend > >>>>> the length of the Failed-AVP. > >>>>> > >>>>> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > >>>>> Proposals: Change diameter-message definition in > >>>>> Sec > >>>>> > >>>>> 3.2 to: > >>>>> > >>>>> diameter-message=header[*fixed][*required][*optional] > >>>>> > >>>>> Open Issues with no consensus on proposals: > >>>>> ------------------------------------------ > >>>>> > >>>>> Issue 21 : URI schemes for AAA > >>>>> Proposals: draft-garcia-dime-aaa-uri-00.txt > >>>>> > >>>>> Issue 4 : Proxy agent stay in the path of the request message > >>>>> > >>> of > >>> > >>>>> a session > >>>>> Proposals: draft-tsou-dime-routing-ext-00.txt > >>>>> > >>>>> Open Issues that needs proposals: > >>>>> -------------------------------- > >>>>> > >>>>> Notes: These issues did not receive any comments during IETF66 and > >>>>> have no pending proposals. > >>>>> > >>>>> Issue 1 : Advertising relay application id (0xffffffff) in > >>>>> auth-application-id or acct-application-id > >>>>> > >>>>> Issue 15 : Duplicate detection requires server side storage of > >>>>> e2e id and origin-host avp > >>>>> > >>>>> Issue 13 : Clarify usage of application id avp's and how they > >>>>> relate to the app-id in the header > >>>>> > >>>>> Issue 9 & 19 : Error codes defined in wrong category > >>>>> > >>>>> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > >>>>> > >>>>> Issue 12 : Differing concepts and/or usage of Diameter > >>>>> > >> Identity > >> > >>>>> (FQDN + port or FQDN only) > >>>>> > >>>>> Issue 14 : Explicit text on which error category should have > >>>>> error flag (e-bit) set > >>>>> > >>>>> Issue 18 : Clarify reconnect behavior of peer based on value > >>>>> > >> of > >> > >>>>> Disconnect-Cause AVP > >>>>> > >>>>> Open issues falling into the "New Features" category: > >>>>> ---------------------------------------------------- > >>>>> > >>>>> Note: These features should use the extension procedures defined in > >>>>> > >>> 3588. > >>> > >>>>> No comments received in IETF66 meeting. > >>>>> > >>>>> Issue 23 : Predictive loop detection > >>>>> Comments: Optimzation techiniques in detecting > >>>>> > >> loops > >> > >>>>> at the succeeding hops > >>>>> > >>>>> Issue 22 : Fetch data request and location update request. > >>>>> Comments: Proposal to include LUR messages into > >>>>> base since its reusable in different > >>>>> applications > >>>>> > >>>>> If you believe there are some in-accurate info below, pls let us > >>>>> know. > >>>>> > >>>>> best regards, > >>>>> victor > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > > > > > > _______________________________________________ > > 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 Jul 18 10:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qXf-00065E-QR; Tue, 18 Jul 2006 10:27:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qXe-000659-5H for dime@ietf.org; Tue, 18 Jul 2006 10:27:18 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qXb-0003CQ-FJ for dime@ietf.org; Tue, 18 Jul 2006 10:27:18 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6IERFEe006053 for ; Tue, 18 Jul 2006 07:27:15 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6IERDB0016589 for ; Tue, 18 Jul 2006 09:27:14 -0500 (CDT) 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] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 22:27:12 +0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqdCH6eEC0e/fWTvmVNe9pbGtx/gAAehdw From: "Ram O V Vishnu-A14676" To: "Tolga Asveren" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff 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 All, I agree with this too. I guess we can close 2&5. Also, I have added comments to issue 13 and 1. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: Tuesday, July 18, 2006 7:18 PM To: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Hi Victor, I agree with this. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, July 18, 2006 8:45 AM > To: rajithr@huawei.com > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > Folks, > > Just for the clarity. This topic is issue #2&5 and refers to what app=20 > id should "application session level" messages defined in the base=20 > protocol (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current=20 > consensus in the meeting and more likely in this list as well is that=20 > it MUST carry the app id of the application using it. Messages dealing > with peer connectivity (CER/CEA, DWR/DWA, DPR/DPA) will carry an app=20 > id of 0. If there are no technical objections to this solution then we > can close this issue. > > Comments below: > > Hi > > I also agree that app Id 0 should be used only for CE, DW & DP=20 > > commands. > > > > However, I could not understand why we have the app Id field in the=20 > > DIAMETER header? > > > > RFC 3588 specifies that all accounting, auth or experimental=20 > > commands MUST have Acct.,Auth. or Vendor Sp. App Id respectively. > > So, I assume, the app Id field in the header might be for nodes to=20 > > quickly identify whether the msg is for the connection > management FSM (app > > Id =3D 0) or for some session management logic (like NASREQ, > Base-Accounting > > or Vendor specific). But this could be achieved by checking the > command code > > as well. > > > > > > > The app id in the header make's it easier to route messages rather=20 > than searching for the app id avp's in the message. Relay's does not=20 > really care about command codes. A more important issue that we should > discuss is issue#13 (Clarify usage of application id avp's and how=20 > they relate to the app-id in the header) and consequently issue #1=20 > (Advertising relay application id (0xffffffff) in auth-application-id=20 > or acct-application-id). Pls send your comments. > > best regards, > victor > > > > Regards > > > > Rajith > > > ****************************************************************** > ********** > > This e-mail and attachments contain confidential information > from HUAWEI, > > which is intended only for the person or entity whose address is=20 > > listed above. Any use of the information contained herein in any way > (including, > > but not limited to, total or partial disclosure, reproduction, or > > dissemination) by persons other than the intended recipient's) is=20 > > prohibited. If you receive this e-mail in error, please notify > the sender by > > phone or email immediately and delete it! > > > > > >> -----Original Message----- > >> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >> Sent: Tuesday, July 18, 2006 11:13 AM > >> To: rajithr@huawei.com > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> Rajith, > >> > >> I meant section 5.6 of RFC 3588. > >> > >> I don't think the auth fsm in section 8.1 can handle messages > with appid > >> 0 because it talks about "Service-specific authorization" messages. > >> > >> I think the section 8.2 should handle messages with appid 3 (as per > >> section 2.4). Ofcourse it could be something else too (like a 3GPP=20 > >> accounting appid), but not 0. > >> > >> Regards, > >> Vishnu. > >> > >> Motorola India Electronics Pvt Ltd > >> +91 9844178052 > >> [*] Motorola Internal Use Only > >> > >> > >> > >> -----Original Message----- > >> From: Rajith R [mailto:rajithr@huawei.com] > >> Sent: Tuesday, July 18, 2006 10:32 AM > >> To: Ram O V Vishnu-A14676 > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> > >> By base FSM do you mean only the connection management FSM (which=20 > >> handles > >> CE/DW/DP) or the Auth./Accounting state machines defined in RFC=20 > >> 3588 as well? > >> > >> > >> Regards > >> > >> Rajith > >> > ********************************************************************** > ** > >> **** > >> This e-mail and attachments contain confidential information from=20 > >> HUAWEI, which is intended only for the person or entity whose > address is > >> listed above. Any use of the information contained herein in any=20 > >> way (including, but not limited to, total or partial disclosure,=20 > >> reproduction, or > >> dissemination) by persons other than the intended recipient's) is=20 > >> prohibited. If you receive this e-mail in error, please notify the=20 > >> sender by phone or email immediately and delete it! > >> > >>> -----Original Message----- > >>> From: Ram O V Vishnu-A14676 [mailto:vishnu@motorola.com] > >>> Sent: Tuesday, July 18, 2006 10:19 AM > >>> To: nilanjans@condornetworks.com; Tolga Asveren > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> Hi, > >>> > >>> My comment on (1) is that all messages which are=20 > >>> terminated/handled in the base FSM (RFC3588/3539) should carry=20 > >>> app-id 0 and any > other message > >>> > >>> should carry the respective other app-ids. > >>> > >>> Regards, > >>> Vishnu. > >>> > >>> Motorola India Electronics Pvt Ltd > >>> +91 9844178052 > >>> [*] Motorola Internal Use Only > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: nilanjans@condornetworks.com=20 > >>> [mailto:nilanjans@condornetworks.com] > >>> > >>> Sent: Tuesday, July 18, 2006 9:27 AM > >>> To: Tolga Asveren > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> > >>> Hi Victor, > >>> I agree with Tolga. The item (1) is really an interop issue and=20 > >>> needs to be added to the list. > >>> > >>> Thanks > >>> Prasad. > >>> > >>> Quoting Tolga Asveren : > >>> > >>> > >>>> Hi Victor, > >>>> > >>>> Thanks a lot for that very useful update. > >>>> > >>>> IMHO, a few of the items listed below have a higher importance=20 > >>>> than the other ones: > >>>> > >>>> 1) AppId to be used by common diameter messages > >>>> 2) Grouping of error codes > >>>> > >>>> Especially 1) seem to be a real interop-killer. I hope all people > >>>> which have any opinion on this issue would post their ideas so=20 > >>>> that we > >>>> > >>>> can reach a conclusion ASAP. > >>>> > >>>> Thanks, > >>>> Tolga > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>>>> Sent: Friday, July 14, 2006 1:46 PM > >>>>> To: dime@ietf.org > >>>>> Subject: [Dime] Summary of 3588bis Issues Status > >>>>> > >>>>> > >>>>> Folks, > >>>>> > >>>>> The is a summary of the 3588bis issues discussion during DIME WG > >>>>> meeting in IETF66. If you have comments on any of the existing=20 > >>>>> issues pls don't hesitate to post it on the DIME list so we can=20 > >>>>> facilitate quicker resolution or at least better understanding=20 > >>>>> of the problem. We also need some proposals on the open issues=20 > >>>>> if you believe they are truly issues. Note that the assigned=20 > >>>>> issue numbers > >>>>> > >>>>> are based on the current tracker which is for historical reasons > >>>>> the > >>>>> > >>>>> diameter-interop tracker=20 > >>>>> (http://www.tschofenig.priv.at:8080/diameter-interop). > >>>>> > >>>>> > >>>>> Closed Issues: > >>>>> ------------- > >>>>> > >>>>> Issue 6 : TLS version issue > >>>>> Comments: interop related problem only. Does not > >>>>> affect the > >>>>> base spec > >>>>> > >>>>> Issue 7 : Textual IP address qualify as FQDN > >>>>> Comments: Consensus that FQDN is defined as=20 > >>>>> "internet name" > >>>>> only > >>>>> > >>>>> Issue 11 : Confusion about use of Proxy-Info AVP for Relay > >>>>> Comments: Clarified in Sec 6.2 with the text > >>>>> > >>>>> "Any Proxy-Info AVPs in the request MUST be=20 > >>>>> added to > >>>>> > >>> the > >>> > >>>>> answer message, in the same order they were=20 > >>>>> present > >>>>> > >>> in > >>> > >>>>> the request." > >>>>> > >>>>> Open Issues with some consensus on proposals: > >>>>> --------------------------------------------- > >>>>> > >>>>> Notes: These issues have some consensus either during the IETF66 > >>>>> meeting and/or in the DIME mailing list. > >>>>> > >>>>> Issue 2 & 5 : App Ids used by common diameter messages > >>>>> Proposals: Use the application id of the current > >>>>> application > >>>>> > >>>>> Issue 3 & 16 : CER/CEA exchange in the open state > >>>>> Proposals: Need more consensus on current proposals > >>>>> posted in issue 16 > >>>>> > >>>>> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA > >>>>> > >>> avp > >>> > >>>>> Proposals: The Vendor-Id ABNF should one and=20 > >>>>> only > >>>>> > >>> one > >>> > >>>>> instance, i.e. > >>>>> > >>>>> ::=3D < AVP Header: 260 > > >>>>> < Vendor-Id > > >>>>> 0*1{ Auth-Application-Id } > >>>>> 0*1{ Acct-Application-Id } > >>>>> > >>>>> Issue 20 : Determining an offending/invalid AVP contained > >>>>> > >>> within > >>> > >>>>> the group AVP > >>>>> Proposals: Do nothing. The AVP code should be > >>>>> > >>> enough. > >>> > >>>>> Existing proposals may needlessly extend > >>>>> the length of the Failed-AVP. > >>>>> > >>>>> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > >>>>> Proposals: Change diameter-message definition in > >>>>> Sec > >>>>> > >>>>> 3.2 to: > >>>>> > >>>>> =20 > >>>>> diameter-message=3Dheader[*fixed][*required][*optional] > >>>>> > >>>>> Open Issues with no consensus on proposals: > >>>>> ------------------------------------------ > >>>>> > >>>>> Issue 21 : URI schemes for AAA > >>>>> Proposals: draft-garcia-dime-aaa-uri-00.txt > >>>>> > >>>>> Issue 4 : Proxy agent stay in the path of the request message > >>>>> > >>> of > >>> > >>>>> a session > >>>>> Proposals: draft-tsou-dime-routing-ext-00.txt > >>>>> > >>>>> Open Issues that needs proposals: > >>>>> -------------------------------- > >>>>> > >>>>> Notes: These issues did not receive any comments during IETF66 and > >>>>> have no pending proposals. > >>>>> > >>>>> Issue 1 : Advertising relay application id (0xffffffff) in > >>>>> auth-application-id or acct-application-id > >>>>> > >>>>> Issue 15 : Duplicate detection requires server side storage of > >>>>> e2e id and origin-host avp > >>>>> > >>>>> Issue 13 : Clarify usage of application id avp's and how they > >>>>> relate to the app-id in the header > >>>>> > >>>>> Issue 9 & 19 : Error codes defined in wrong category > >>>>> > >>>>> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > >>>>> > >>>>> Issue 12 : Differing concepts and/or usage of Diameter > >>>>> > >> Identity > >> > >>>>> (FQDN + port or FQDN only) > >>>>> > >>>>> Issue 14 : Explicit text on which error category should have > >>>>> error flag (e-bit) set > >>>>> > >>>>> Issue 18 : Clarify reconnect behavior of peer based on value > >>>>> > >> of > >> > >>>>> Disconnect-Cause AVP > >>>>> > >>>>> Open issues falling into the "New Features" category: > >>>>> ---------------------------------------------------- > >>>>> > >>>>> Note: These features should use the extension procedures defined > >>>>> in > >>>>> > >>> 3588. > >>> > >>>>> No comments received in IETF66 meeting. > >>>>> > >>>>> Issue 23 : Predictive loop detection > >>>>> Comments: Optimzation techiniques in detecting > >>>>> > >> loops > >> > >>>>> at the succeeding hops > >>>>> > >>>>> Issue 22 : Fetch data request and location update request. > >>>>> Comments: Proposal to include LUR messages into > >>>>> base since its reusable in different > >>>>> applications > >>>>> > >>>>> If you believe there are some in-accurate info below, pls let us > >>>>> know. > >>>>> > >>>>> best regards, > >>>>> victor > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > > > > > > _______________________________________________ > > 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 Jul 18 10:27:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qXk-00067h-44; Tue, 18 Jul 2006 10:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qXi-000670-EN for dime@ietf.org; Tue, 18 Jul 2006 10:27:22 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qXh-0003CZ-2u for dime@ietf.org; Tue, 18 Jul 2006 10:27:22 -0400 Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6IERII7026391 for ; Tue, 18 Jul 2006 16:27:18 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jul 2006 16:27:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 16:27:14 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqbxzL91F/F3jvRBuuKCATEIOPGwABle2Q From: "STURA, Marco, VF-IT" To: "Victor Fajardo" X-OriginalArrivalTime: 18 Jul 2006 14:27:17.0805 (UTC) FILETIME=[45A6A5D0:01C6AA76] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Victor, >This topic is issue #2&5 and refers to what app id=20 >should "application session level" messages defined in the base protocol=20 >(STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the=20 >meeting and more likely in this list as well is that it MUST carry the=20 >app id of the application using it. Could you bring some light on the reasons behind this consensus? I thought the discussion in the old AAA list was toward a consensus on using Appl ID 0 at least for the ASR/ASA Diameter common messages. Regards Marco _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 10:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qxC-0002ks-PO; Tue, 18 Jul 2006 10:53:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qxB-0002kn-LT for dime@ietf.org; Tue, 18 Jul 2006 10:53:41 -0400 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 1G2qxA-0004q7-BJ for dime@ietf.org; Tue, 18 Jul 2006 10:53:41 -0400 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 k6IEr9RP065526; Tue, 18 Jul 2006 10:53:09 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BCF5D5.2030106@tari.toshiba.com> Date: Tue, 18 Jul 2006 10:53:09 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Marco, The main reason (and people can correct me if i'm wrong) is that these messages belong to the session/application using them and it is better/easier to co-relate these messages to the said application. Since the base protocol really defines two sets of messages, one set is for session/application usage and another for peer connectivity, it is also semantically correct for the the session message to carry the app id of the session. In addition, for implementations, it is more practical to look at the app id in the header to determine the application that a message belongs to ... and rightfully so. In my opinion, ASR belongs to this category even if it is server directed. It maybe a little bit confusing for relays with cannot resolve a route via destination-host to look at an ASR with an app id of 0. hope this helps, victor > Hi Victor, > > >> This topic is issue #2&5 and refers to what app id >> should "application session level" messages defined in the base >> > protocol > >> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the >> meeting and more likely in this list as well is that it MUST carry the >> app id of the application using it. >> > > Could you bring some light on the reasons behind this consensus? I > thought the discussion in the old AAA list was toward a consensus on > using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > Regards > Marco > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 11:26:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rSN-0006zt-4m; Tue, 18 Jul 2006 11:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rSM-0006zo-Jf for dime@ietf.org; Tue, 18 Jul 2006 11:25:54 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rSL-0007Rg-6H for dime@ietf.org; Tue, 18 Jul 2006 11:25:54 -0400 Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6IFPpI7014857 for ; Tue, 18 Jul 2006 17:25:51 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jul 2006 17:25:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 17:25:49 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133AB@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqefp1kttf407jTVmSPE+LUp8NIgAADymg From: "STURA, Marco, VF-IT" To: "Victor Fajardo" X-OriginalArrivalTime: 18 Jul 2006 15:25:50.0664 (UTC) FILETIME=[737A6480:01C6AA7E] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 >It maybe a little bit confusing for relays with cannot resolve a route = via >destination-host to look at an ASR with an app id of 0. Interesting argument I have to say. Routing ASR based on app id doesn't = ensure that the session ASR is supposed to kill is actually running on = the client where the request is routed to. Suppose a relay agent = connected to 10 clients all of which support app id x, the relay routes = based on app id x to client 2 but the session indicated in the = is actually running in client 5. The ASR will not kill the = session as requested by the server, therefore ASR MUST use = Destination-Host based routing. Same argument stands for RAR. In fact the base defines ASR and RAR with Destination-Host AVP as = mandatory in the ABNF of the message. I think in the AAA thread also available in the issue tracker there were = arguments why ASR is really a common message, same would be for RAR if = no mandatory AVPs are defined by the application. Regards Marco -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: marted=EC 18 luglio 2006 16.53 To: STURA, Marco, VF-IT Cc: dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status Hi Marco, The main reason (and people can correct me if i'm wrong) is that these=20 messages belong to the session/application using them and it is=20 better/easier to co-relate these messages to the said application. Since = the base protocol really defines two sets of messages, one set is for=20 session/application usage and another for peer connectivity, it is also=20 semantically correct for the the session message to carry the app id of=20 the session. In addition, for implementations, it is more practical to look at the=20 app id in the header to determine the application that a message belongs = to ... and rightfully so. In my opinion, ASR belongs to this category=20 even if it is server directed. It maybe a little bit confusing for=20 relays with cannot resolve a route via destination-host to look at an=20 ASR with an app id of 0. hope this helps, victor > Hi Victor, > > =20 >> This topic is issue #2&5 and refers to what app id=20 >> should "application session level" messages defined in the base >> =20 > protocol=20 > =20 >> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in = the=20 >> meeting and more likely in this list as well is that it MUST carry = the=20 >> app id of the application using it. >> =20 > > Could you bring some light on the reasons behind this consensus? I > thought the discussion in the old AAA list was toward a consensus on > using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > Regards > Marco > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 12:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2s9B-00088B-RV; Tue, 18 Jul 2006 12:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2s9A-000884-Q3 for dime@ietf.org; Tue, 18 Jul 2006 12:10:08 -0400 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 1G2s9A-0002ZC-Dh for dime@ietf.org; Tue, 18 Jul 2006 12:10:08 -0400 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 k6IG9Xu9065920; Tue, 18 Jul 2006 12:09:34 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD07BD.1090700@tari.toshiba.com> Date: Tue, 18 Jul 2006 12:09:33 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AB@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AB@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k6IG9Xu9065920 X-Spam-Score: -2.4 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Marco, comments inline: >> It maybe a little bit confusing for relays with cannot resolve a route= via >destination-host to look at an ASR with an app id of 0. >> =20 > > Interesting argument I have to say. Routing ASR based on app id doesn't= ensure that the session ASR is supposed to kill is actually running on t= he client where the request is routed to. Suppose a relay agent connected= to 10 clients all of which support app id x, the relay routes based on a= pp id x to client 2 but the session indicated in the is actu= ally running in client 5. The ASR will not kill the session as requested = by the server, therefore ASR MUST use Destination-Host based routing. > =20 I agree with your example above regarding destination-host. It is=20 required in the case of ASR (and perhaps some other message) though I=20 guess I was stating a case which is a little bit different than your=20 example above. I was thinking of the following case: clients[1,2,3...x] <--- relay1 <---- relay2 <---- server in this case relay2 will not be able to route using dest-host. This is=20 where dest-realm and app id becomes important. In this case app id of 0=20 might not work as well ... or maybe I'm wrong. > Same argument stands for RAR. > > In fact the base defines ASR and RAR with Destination-Host AVP as manda= tory in the ABNF of the message. > > I think in the AAA thread also available in the issue tracker there wer= e arguments why ASR is really a common message, same would be for RAR if = no mandatory AVPs are defined by the application. > =20 I've read through some of the comments in the AAA thread regarding this=20 issue and it was not clear to me why an app id of 0 is applicable to ASR=20 and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set=20 to 4 (CC app id). hope this helps, victor > > Regards > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: marted=EC 18 luglio 2006 16.53 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > > The main reason (and people can correct me if i'm wrong) is that these=20 > messages belong to the session/application using them and it is=20 > better/easier to co-relate these messages to the said application. Sinc= e=20 > the base protocol really defines two sets of messages, one set is for=20 > session/application usage and another for peer connectivity, it is also= =20 > semantically correct for the the session message to carry the app id of= =20 > the session. > > In addition, for implementations, it is more practical to look at the=20 > app id in the header to determine the application that a message belong= s=20 > to ... and rightfully so. In my opinion, ASR belongs to this category=20 > even if it is server directed. It maybe a little bit confusing for=20 > relays with cannot resolve a route via destination-host to look at an=20 > ASR with an app id of 0. > > hope this helps, > victor > =20 >> Hi Victor, >> >> =20 >> =20 >>> This topic is issue #2&5 and refers to what app id=20 >>> should "application session level" messages defined in the base >>> =20 >>> =20 >> protocol=20 >> =20 >> =20 >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in th= e=20 >>> meeting and more likely in this list as well is that it MUST carry th= e=20 >>> app id of the application using it. >>> =20 >>> =20 >> Could you bring some light on the reasons behind this consensus? I >> thought the discussion in the old AAA list was toward a consensus on >> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >> >> Regards >> Marco >> >> >> >> >> =20 >> =20 > > > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 12:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sVS-0001mK-Mv; Tue, 18 Jul 2006 12:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sVR-0001mF-Op for dime@ietf.org; Tue, 18 Jul 2006 12:33:09 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sVP-00057T-8U for dime@ietf.org; Tue, 18 Jul 2006 12:33:09 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6IGX5ps020035 for ; Tue, 18 Jul 2006 18:33:05 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Jul 2006 18:33:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 18:32:50 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqhKccdTpwfa8URwmzi0bQs3qSOwAAcHLA From: "STURA, Marco, VF-IT" To: "Victor Fajardo" X-OriginalArrivalTime: 18 Jul 2006 16:33:04.0817 (UTC) FILETIME=[D8054A10:01C6AA87] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 See in line. Br Marco -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: marted=EC 18 luglio 2006 18.10 To: STURA, Marco, VF-IT Cc: dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status Hi Marco, comments inline: >> It maybe a little bit confusing for relays with cannot resolve a = route via >destination-host to look at an ASR with an app id of 0. >> =20 > > Interesting argument I have to say. Routing ASR based on app id = doesn't ensure that the session ASR is supposed to kill is actually = running on the client where the request is routed to. Suppose a relay = agent connected to 10 clients all of which support app id x, the relay = routes based on app id x to client 2 but the session indicated in the = is actually running in client 5. The ASR will not kill the = session as requested by the server, therefore ASR MUST use = Destination-Host based routing. > =20 I agree with your example above regarding destination-host. It is=20 required in the case of ASR (and perhaps some other message) though I=20 guess I was stating a case which is a little bit different than your=20 example above. I was thinking of the following case: clients[1,2,3...x] <--- relay1 <---- relay2 <---- server in this case relay2 will not be able to route using dest-host. This is=20 where dest-realm and app id becomes important. In this case app id of 0=20 might not work as well ... or maybe I'm wrong. [MSt] In this case R1 would advertise it self as a relay (i.e. = 0xffffffff) it won't advertise app id x or y or z. So, any app id would = be routed to R1 by R2. > Same argument stands for RAR. > > In fact the base defines ASR and RAR with Destination-Host AVP as = mandatory in the ABNF of the message. > > I think in the AAA thread also available in the issue tracker there = were arguments why ASR is really a common message, same would be for RAR = if no mandatory AVPs are defined by the application. > =20 I've read through some of the comments in the AAA thread regarding this=20 issue and it was not clear to me why an app id of 0 is applicable to ASR = and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set=20 to 4 (CC app id). [MSt] Because the ASR or RAR requests a specific action to the client = that is to be inferred to the session indicated in the . = Diameter CC sets the app id 4 in RAR because it augments the base = message with mandatory AVPs defined in it with associated behavior. All = ASR does is "kill the session". So, the why not stick on the original = rules when RFC3588 was defined? Base common messages such as ASR and RAR = MUST use app id 0 unless augmented with mandatory AVPs that define a = specific behavior of the client (e.g. DCC application). hope this helps, victor > > Regards > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: marted=EC 18 luglio 2006 16.53 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > > The main reason (and people can correct me if i'm wrong) is that these = > messages belong to the session/application using them and it is=20 > better/easier to co-relate these messages to the said application. = Since=20 > the base protocol really defines two sets of messages, one set is for=20 > session/application usage and another for peer connectivity, it is = also=20 > semantically correct for the the session message to carry the app id = of=20 > the session. > > In addition, for implementations, it is more practical to look at the=20 > app id in the header to determine the application that a message = belongs=20 > to ... and rightfully so. In my opinion, ASR belongs to this category=20 > even if it is server directed. It maybe a little bit confusing for=20 > relays with cannot resolve a route via destination-host to look at an=20 > ASR with an app id of 0. > > hope this helps, > victor > =20 >> Hi Victor, >> >> =20 >> =20 >>> This topic is issue #2&5 and refers to what app id=20 >>> should "application session level" messages defined in the base >>> =20 >>> =20 >> protocol=20 >> =20 >> =20 >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in = the=20 >>> meeting and more likely in this list as well is that it MUST carry = the=20 >>> app id of the application using it. >>> =20 >>> =20 >> Could you bring some light on the reasons behind this consensus? I >> thought the discussion in the old AAA list was toward a consensus on >> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >> >> Regards >> Marco >> >> >> >> >> =20 >> =20 > > > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 12:41:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sd8-0002bu-Ry; Tue, 18 Jul 2006 12:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sd7-0002bp-HZ for dime@ietf.org; Tue, 18 Jul 2006 12:41:05 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sd3-0000B2-O1 for dime@ietf.org; Tue, 18 Jul 2006 12:41:05 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 3F49160D40; Tue, 18 Jul 2006 12:40:50 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6IGf0cS025521; Tue, 18 Jul 2006 12:41:00 -0400 (EDT) From: "Tolga Asveren" To: "STURA, Marco, VF-IT" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 12:17:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 Marco, I think, the reason for different point of views is mainly due to the question who is considered as the owner of a session. IMHO, session is better owned by the application logic, because only it has full knowledge about when a session is supposed to end, hence I believe it is best that any session/application logic related message is handled by the application. For that reason, I think it is a good idea to use the App-Id of the application in message header for the messages under discussion. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Tuesday, July 18, 2006 12:33 PM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > See in line. > > Br > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: martedì 18 luglio 2006 18.10 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > > comments inline: > >> It maybe a little bit confusing for relays with cannot resolve > a route via >destination-host to look at an ASR with an app id of 0. > >> > > > > Interesting argument I have to say. Routing ASR based on app id > doesn't ensure that the session ASR is supposed to kill is > actually running on the client where the request is routed to. > Suppose a relay agent connected to 10 clients all of which > support app id x, the relay routes based on app id x to client 2 > but the session indicated in the is actually running > in client 5. The ASR will not kill the session as requested by > the server, therefore ASR MUST use Destination-Host based routing. > > > > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. > 0xffffffff) it won't advertise app id x or y or z. So, any app id > would be routed to R1 by R2. > > > Same argument stands for RAR. > > > > In fact the base defines ASR and RAR with Destination-Host AVP > as mandatory in the ABNF of the message. > > > > I think in the AAA thread also available in the issue tracker > there were arguments why ASR is really a common message, same > would be for RAR if no mandatory AVPs are defined by the application. > > > I've read through some of the comments in the AAA thread regarding this > issue and it was not clear to me why an app id of 0 is applicable to ASR > and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set > to 4 (CC app id). > > [MSt] Because the ASR or RAR requests a specific action to the > client that is to be inferred to the session indicated in the > . Diameter CC sets the app id 4 in RAR because it > augments the base message with mandatory AVPs defined in it with > associated behavior. All ASR does is "kill the session". So, the > why not stick on the original rules when RFC3588 was defined? > Base common messages such as ASR and RAR MUST use app id 0 unless > augmented with mandatory AVPs that define a specific behavior of > the client (e.g. DCC application). > > hope this helps, > victor > > > > > Regards > > Marco > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: martedì 18 luglio 2006 16.53 > > To: STURA, Marco, VF-IT > > Cc: dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > Hi Marco, > > > > The main reason (and people can correct me if i'm wrong) is that these > > messages belong to the session/application using them and it is > > better/easier to co-relate these messages to the said > application. Since > > the base protocol really defines two sets of messages, one set is for > > session/application usage and another for peer connectivity, it is also > > semantically correct for the the session message to carry the app id of > > the session. > > > > In addition, for implementations, it is more practical to look at the > > app id in the header to determine the application that a > message belongs > > to ... and rightfully so. In my opinion, ASR belongs to this category > > even if it is server directed. It maybe a little bit confusing for > > relays with cannot resolve a route via destination-host to look at an > > ASR with an app id of 0. > > > > hope this helps, > > victor > > > >> Hi Victor, > >> > >> > >> > >>> This topic is issue #2&5 and refers to what app id > >>> should "application session level" messages defined in the base > >>> > >>> > >> protocol > >> > >> > >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > consensus in the > >>> meeting and more likely in this list as well is that it MUST > carry the > >>> app id of the application using it. > >>> > >>> > >> Could you bring some light on the reasons behind this consensus? I > >> thought the discussion in the old AAA list was toward a consensus on > >> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >> > >> Regards > >> Marco > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > 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 Jul 18 13:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tAM-0003e7-Pj; Tue, 18 Jul 2006 13:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2tAL-0003df-C4 for dime@ietf.org; Tue, 18 Jul 2006 13:15:25 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2tAK-0006bB-3f for dime@ietf.org; Tue, 18 Jul 2006 13:15:25 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 538C92D075; Tue, 18 Jul 2006 13:15:08 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6IHFIwS028348; Tue, 18 Jul 2006 13:15:18 -0400 (EDT) From: "Tolga Asveren" To: "STURA, Marco, VF-IT" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 12:51:41 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 [.. snip ..] > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. > 0xffffffff) it won't advertise app id x or y or z. So, any app id > would be routed to R1 by R2. [TOLGA] Let me try to further refine the scenario: ***************************** * Realm A * * * * +---------+ * * +--+C1 App=X | * * +----+ | +---------+ * +----*-+ P1 +-+ +---------+ * +---+ +-+--+ * +----+----+C2 App=Y | * |S1 +--+ R1 | * +---------+ * +---+ +-+--+ * * | * +----+ * +----*-+ P2 +----+---------+ * * +----+ |C3 App=Z | * * +---------+ * * * ***************************** In this case, R1 wouldn't have enough knowledge to route the message properly to the correct proxy just by looking to the App-Id in the message header, if App-Id is populated with "0". _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 14:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2twS-0003fS-2q; Tue, 18 Jul 2006 14:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2twR-0003fN-EU for dime@ietf.org; Tue, 18 Jul 2006 14:05:07 -0400 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 1G2twQ-0002WH-9d for dime@ietf.org; Tue, 18 Jul 2006 14:05:06 -0400 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 k6II4PIY066478; Tue, 18 Jul 2006 14:04:25 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD22AA.4030105@tari.toshiba.com> Date: Tue, 18 Jul 2006 14:04:26 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k6II4PIY066478 X-Spam-Score: -2.4 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 All, > [MSt] Because the ASR or RAR requests a specific action to the client t= hat is to be inferred to the session indicated in the . Diame= ter CC sets the app id 4 in RAR because it augments the base message with= mandatory AVPs defined in it with associated behavior. All ASR does is "= kill the session". So, the why not stick on the original rules when RFC35= 88 was defined?=20 Yes but the session being "killed" belongs to a particular application.=20 Semantically speaking, setting it to 0 seems to imply all applications. > Base common messages such as ASR and RAR MUST use app id 0 unless augme= nted with mandatory AVPs that define a specific behavior of the client (e= .g. DCC application). > =20 I'm still not sure why we 'MUST' use app id of 0 ? I'm also not sure if=20 there is any technical merit/advantage in having to define different=20 rules for setting different app ids for just one or two messages=20 depending on whether they are mandated to use new avp. I think it tends=20 to lead to more confusion which is what we are originally trying to=20 resolve. Unless I have the wrong take on this issue, there is a=20 consensus that we should just use the app id of the application for=20 simplicity and correctness. To that end, I would encourage folks to give their comments if any so we=20 can get a better sense on the pitfalls of the current proposals if there=20 is any. hope this helps, victor > hope this helps, > victor > > =20 >> Regards >> Marco >> >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 >> Sent: marted=EC 18 luglio 2006 16.53 >> To: STURA, Marco, VF-IT >> Cc: dime@ietf.org >> Subject: Re: [Dime] Summary of 3588bis Issues Status >> >> Hi Marco, >> >> The main reason (and people can correct me if i'm wrong) is that these= =20 >> messages belong to the session/application using them and it is=20 >> better/easier to co-relate these messages to the said application. Sin= ce=20 >> the base protocol really defines two sets of messages, one set is for=20 >> session/application usage and another for peer connectivity, it is als= o=20 >> semantically correct for the the session message to carry the app id o= f=20 >> the session. >> >> In addition, for implementations, it is more practical to look at the=20 >> app id in the header to determine the application that a message belon= gs=20 >> to ... and rightfully so. In my opinion, ASR belongs to this category=20 >> even if it is server directed. It maybe a little bit confusing for=20 >> relays with cannot resolve a route via destination-host to look at an=20 >> ASR with an app id of 0. >> >> hope this helps, >> victor >> =20 >> =20 >>> Hi Victor, >>> >>> =20 >>> =20 >>> =20 >>>> This topic is issue #2&5 and refers to what app id=20 >>>> should "application session level" messages defined in the base >>>> =20 >>>> =20 >>>> =20 >>> protocol=20 >>> =20 >>> =20 >>> =20 >>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in t= he=20 >>>> meeting and more likely in this list as well is that it MUST carry t= he=20 >>>> app id of the application using it. >>>> =20 >>>> =20 >>>> =20 >>> Could you bring some light on the reasons behind this consensus? I >>> thought the discussion in the old AAA list was toward a consensus on >>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >>> >>> Regards >>> Marco >>> >>> >>> >>> >>> =20 >>> =20 >>> =20 >> >> >> >> >> =20 >> =20 > > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 15:15:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2v2F-0005Ze-7u; Tue, 18 Jul 2006 15:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2v2E-0005Yr-3e for dime@ietf.org; Tue, 18 Jul 2006 15:15:10 -0400 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 1G2v2D-0001bg-My for dime@ietf.org; Tue, 18 Jul 2006 15:15:10 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6IJEVqj066902; Tue, 18 Jul 2006 15:14:32 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Tue, 18 Jul 2006 15:14:27 -0400 To: Victor Fajardo Subject: Re: [Dime] Summary of 3588bis Issues Status Message-ID: <20060718191426.GB7387@steelhead> References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> <44BCF5D5.2030106@tari.toshiba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <44BCF5D5.2030106@tari.toshiba.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 70 X-Spam-Score: -2.4 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 thought the main issue is how to route Diameter base protocol messages carrying a Session-Id AVP (i.e., messages associated with a particular session) along the same path on which the application-specific messages that were used for establishing that session traversed *when stateful agents are on the path*. If there is no stateful agent on the path, I think using application Id = 0 for all Diameter base protocol messages can work regardless of whether it is better/easier or not. Yoshihiro Ohba On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > Hi Marco, > > The main reason (and people can correct me if i'm wrong) is that these > messages belong to the session/application using them and it is > better/easier to co-relate these messages to the said application. Since > the base protocol really defines two sets of messages, one set is for > session/application usage and another for peer connectivity, it is also > semantically correct for the the session message to carry the app id of > the session. > > In addition, for implementations, it is more practical to look at the > app id in the header to determine the application that a message belongs > to ... and rightfully so. In my opinion, ASR belongs to this category > even if it is server directed. It maybe a little bit confusing for > relays with cannot resolve a route via destination-host to look at an > ASR with an app id of 0. > > hope this helps, > victor > >Hi Victor, > > > > > >>This topic is issue #2&5 and refers to what app id > >>should "application session level" messages defined in the base > >> > >protocol > > > >>(STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the > >>meeting and more likely in this list as well is that it MUST carry the > >>app id of the application using it. > >> > > > >Could you bring some light on the reasons behind this consensus? I > >thought the discussion in the old AAA list was toward a consensus on > >using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > > >Regards > >Marco > > > > > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 15:29:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vGE-0001c5-4A; Tue, 18 Jul 2006 15:29:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vGC-0001c0-Dn for dime@ietf.org; Tue, 18 Jul 2006 15:29:36 -0400 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 1G2vGA-0002rw-Rj for dime@ietf.org; Tue, 18 Jul 2006 15:29:36 -0400 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 k6IJTU18066957; Tue, 18 Jul 2006 15:29:30 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD369A.6070100@tari.toshiba.com> Date: Tue, 18 Jul 2006 15:29:30 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> <44BCF5D5.2030106@tari.toshiba.com> <20060718191426.GB7387@steelhead> In-Reply-To: <20060718191426.GB7387@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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, > I thought the main issue is how to route Diameter base protocol > messages carrying a Session-Id AVP (i.e., messages associated with a > particular session) along the same path on which the > application-specific messages that were used for establishing that > session traversed *when stateful agents are on the path*. > Mmm.. this maybe for issue 4. Though comments for all issues are welcomed as well. The current discussion is for Issue 2&5. It has to do with what app id should be present in common diameter messages. During the meeting as well as in the list, several people commented that it was preferable for session level messages (ASR,STR etc) to use the app id of the application and the rest should use 0. best regards, victor > If there is no stateful agent on the path, I think using application > Id = 0 for all Diameter base protocol messages can work regardless of > whether it is better/easier or not. > > Yoshihiro Ohba > > > On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > >> Hi Marco, >> >> The main reason (and people can correct me if i'm wrong) is that these >> messages belong to the session/application using them and it is >> better/easier to co-relate these messages to the said application. Since >> the base protocol really defines two sets of messages, one set is for >> session/application usage and another for peer connectivity, it is also >> semantically correct for the the session message to carry the app id of >> the session. >> > > >> In addition, for implementations, it is more practical to look at the >> app id in the header to determine the application that a message belongs >> to ... and rightfully so. In my opinion, ASR belongs to this category >> even if it is server directed. It maybe a little bit confusing for >> relays with cannot resolve a route via destination-host to look at an >> ASR with an app id of 0. >> >> hope this helps, >> victor >> >>> Hi Victor, >>> >>> >>> >>>> This topic is issue #2&5 and refers to what app id >>>> should "application session level" messages defined in the base >>>> >>>> >>> protocol >>> >>> >>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the >>>> meeting and more likely in this list as well is that it MUST carry the >>>> app id of the application using it. >>>> >>>> >>> Could you bring some light on the reasons behind this consensus? I >>> thought the discussion in the old AAA list was toward a consensus on >>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >>> >>> Regards >>> Marco >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 16:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wAE-00032A-2n; Tue, 18 Jul 2006 16:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wAD-000325-8p for dime@ietf.org; Tue, 18 Jul 2006 16:27:29 -0400 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 1G2wAB-0003Jv-KW for dime@ietf.org; Tue, 18 Jul 2006 16:27:29 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6IKQodv067264; Tue, 18 Jul 2006 16:26:50 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Tue, 18 Jul 2006 16:26:40 -0400 To: Victor Fajardo Subject: Re: [Dime] Summary of 3588bis Issues Status Message-ID: <20060718202640.GB8661@steelhead> References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> <44BCF5D5.2030106@tari.toshiba.com> <20060718191426.GB7387@steelhead> <44BD369A.6070100@tari.toshiba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <44BD369A.6070100@tari.toshiba.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 105 X-Spam-Score: -2.4 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 On Tue, Jul 18, 2006 at 03:29:30PM -0400, Victor Fajardo wrote: > Hi, > > I thought the main issue is how to route Diameter base protocol > > messages carrying a Session-Id AVP (i.e., messages associated with a > > particular session) along the same path on which the > > application-specific messages that were used for establishing that > > session traversed *when stateful agents are on the path*. > > > > > Mmm.. this maybe for issue 4. Though comments for all issues are > welcomed as well. The current discussion is for Issue 2&5. It has to do > with what app id should be present in common diameter messages. During > the meeting as well as in the list, several people commented that it was > preferable for session level messages (ASR,STR etc) to use the app id of > the application and the rest should use 0. Then I am not much convinced with the use of app id of the application for session level base protocol messages, because existing XML dictionary in Open Diameter is using app id 0 for them. Why should a working implementation need to be changed? Yoshihiro Ohba > > > best regards, > victor > > > If there is no stateful agent on the path, I think using application > > Id = 0 for all Diameter base protocol messages can work regardless of > > whether it is better/easier or not. > > > > Yoshihiro Ohba > > > > > > On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > > > >> Hi Marco, > >> > >> The main reason (and people can correct me if i'm wrong) is that these > >> messages belong to the session/application using them and it is > >> better/easier to co-relate these messages to the said application. Since > >> the base protocol really defines two sets of messages, one set is for > >> session/application usage and another for peer connectivity, it is also > >> semantically correct for the the session message to carry the app id of > >> the session. > >> > > > > > >> In addition, for implementations, it is more practical to look at the > >> app id in the header to determine the application that a message belongs > >> to ... and rightfully so. In my opinion, ASR belongs to this category > >> even if it is server directed. It maybe a little bit confusing for > >> relays with cannot resolve a route via destination-host to look at an > >> ASR with an app id of 0. > >> > >> hope this helps, > >> victor > >> > >>> Hi Victor, > >>> > >>> > >>> > >>>> This topic is issue #2&5 and refers to what app id > >>>> should "application session level" messages defined in the base > >>>> > >>>> > >>> protocol > >>> > >>> > >>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the > >>>> meeting and more likely in this list as well is that it MUST carry the > >>>> app id of the application using it. > >>>> > >>>> > >>> Could you bring some light on the reasons behind this consensus? I > >>> thought the discussion in the old AAA list was toward a consensus on > >>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >>> > >>> Regards > >>> Marco > >>> > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 16:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wNs-0004iH-VP; Tue, 18 Jul 2006 16:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wNr-0004hp-9x for dime@ietf.org; Tue, 18 Jul 2006 16:41:35 -0400 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 1G2wNr-00049l-2h for dime@ietf.org; Tue, 18 Jul 2006 16:41:35 -0400 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 k6IKfSAN067324; Tue, 18 Jul 2006 16:41:28 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD4779.3080208@tari.toshiba.com> Date: Tue, 18 Jul 2006 16:41:29 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> <44BCF5D5.2030106@tari.toshiba.com> <20060718191426.GB7387@steelhead> <44BD369A.6070100@tari.toshiba.com> <20060718202640.GB8661@steelhead> In-Reply-To: <20060718202640.GB8661@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 Ohba, > >> Mmm.. this maybe for issue 4. Though comments for all issues are >> welcomed as well. The current discussion is for Issue 2&5. It has to do >> with what app id should be present in common diameter messages. During >> the meeting as well as in the list, several people commented that it was >> preferable for session level messages (ASR,STR etc) to use the app id of >> the application and the rest should use 0. >> > > Then I am not much convinced with the use of app id of the application > for session level base protocol messages, because existing XML > dictionary in Open Diameter is using app id 0 for them. Why should a > working implementation need to be changed? > I guess this is the main reason why there is a need for clarification. Because existing implementations does have interoperability problems. Some implementations sets the app id to 0 while other don't and this seems to have caused some issue during the last interop. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 17:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wlM-0007a1-RV; Tue, 18 Jul 2006 17:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2wlL-0007Zw-VL for dime@ietf.org; Tue, 18 Jul 2006 17:05:51 -0400 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 1G2wlL-00070l-Kv for dime@ietf.org; Tue, 18 Jul 2006 17:05:51 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6IL5E2q067454; Tue, 18 Jul 2006 17:05:14 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Tue, 18 Jul 2006 17:04:56 -0400 To: Victor Fajardo Subject: Re: [Dime] Summary of 3588bis Issues Status Message-ID: <20060718210456.GD8661@steelhead> References: <5371BE300539E6439919CF97203DDEC2077133AA@OIVMEXO01.omnitel.it> <44BCF5D5.2030106@tari.toshiba.com> <20060718191426.GB7387@steelhead> <44BD369A.6070100@tari.toshiba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <44BD369A.6070100@tari.toshiba.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 104 X-Spam-Score: -2.4 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 On Tue, Jul 18, 2006 at 03:29:30PM -0400, Victor Fajardo wrote: > Hi, > > I thought the main issue is how to route Diameter base protocol > > messages carrying a Session-Id AVP (i.e., messages associated with a > > particular session) along the same path on which the > > application-specific messages that were used for establishing that > > session traversed *when stateful agents are on the path*. > > > > > Mmm.. this maybe for issue 4. Though comments for all issues are > welcomed as well. The current discussion is for Issue 2&5. It has to do > with what app id should be present in common diameter messages. During > the meeting as well as in the list, several people commented that it was > preferable for session level messages (ASR,STR etc) to use the app id of > the application and the rest should use 0. Let me point out that the issue I indicated above is not the same as issue 4, because issue 4 is about explicit routing while the above issue applies to hop-by-hop routing as well. Yoshihiro Ohba > > > best regards, > victor > > > If there is no stateful agent on the path, I think using application > > Id = 0 for all Diameter base protocol messages can work regardless of > > whether it is better/easier or not. > > > > Yoshihiro Ohba > > > > > > On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > > > >> Hi Marco, > >> > >> The main reason (and people can correct me if i'm wrong) is that these > >> messages belong to the session/application using them and it is > >> better/easier to co-relate these messages to the said application. Since > >> the base protocol really defines two sets of messages, one set is for > >> session/application usage and another for peer connectivity, it is also > >> semantically correct for the the session message to carry the app id of > >> the session. > >> > > > > > >> In addition, for implementations, it is more practical to look at the > >> app id in the header to determine the application that a message belongs > >> to ... and rightfully so. In my opinion, ASR belongs to this category > >> even if it is server directed. It maybe a little bit confusing for > >> relays with cannot resolve a route via destination-host to look at an > >> ASR with an app id of 0. > >> > >> hope this helps, > >> victor > >> > >>> Hi Victor, > >>> > >>> > >>> > >>>> This topic is issue #2&5 and refers to what app id > >>>> should "application session level" messages defined in the base > >>>> > >>>> > >>> protocol > >>> > >>> > >>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current consensus in the > >>>> meeting and more likely in this list as well is that it MUST carry the > >>>> app id of the application using it. > >>>> > >>>> > >>> Could you bring some light on the reasons behind this consensus? I > >>> thought the discussion in the old AAA list was toward a consensus on > >>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >>> > >>> Regards > >>> Marco > >>> > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security System. > >> For more information please visit http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 17:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xIU-0003Ei-1Q; Tue, 18 Jul 2006 17:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xIS-0003Ed-WB for dime@ietf.org; Tue, 18 Jul 2006 17:40:05 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xIQ-0002Rp-L4 for dime@ietf.org; Tue, 18 Jul 2006 17:40:04 -0400 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6ILdwut010506 for ; Tue, 18 Jul 2006 16:39:58 -0500 (CDT) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id k6ILduvw028654 for ; Tue, 18 Jul 2006 16:39:57 -0500 (CDT) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id k6ILdtuX013412 for ; Tue, 18 Jul 2006 14:39:56 -0700 (PDT) Message-ID: <44BD5532.2040002@aaa.lucent.com> Date: Tue, 18 Jul 2006 14:40:02 -0700 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Few topics has generated as many messages in this and other groups as the subject regarding (or the confusion surrounding) the fact that there is an AVP-based application id in the message in addition to the message id in the Diameter header. As far as I am concerned, the application-id serves three purposes: 1. Combined with the Command-Code as a message type discriminator to determine what dictionary and processing entry point to apply in order to process the message. 2. Combined with the Destination-Realm to determine message routing. 3. As a special case in the CER/CEA as a means to advertise application id support. I just can't imagine what scenario would require more than one application id in a message to serve the purpose of both case 1 and 2 above, but I may be wrong. Only in case 3, which is an exception, use of the application id AVPs is necessary since they are overloaded to mean "support for" in contrast to identifying the type of message. In this latter case the header application id only serves as a discriminator to indicate "base". For messages that are intended for a specific server, such as ASRs or any other message that are tied to a specific session, the primary means for reaching the correct destination is the Destination-Host AVP. The application id may of course still be used to make coarse routing decisions to reach a host that has connectivity to and knowledge about the given host. Obviously it is the responsibility of the network administrator to configure the network in this case in such a way that messages aren't dropped, i.e. are being relayed or proxied to reach a "knowledgeable" peer. This would also seem as a very likely way to set up routing in practice, i.e. make course decisions far away from the target and make more precise decisions as the message gets closer to its destination. If the header application id is always set to resolve cases 1 and 2 above, i.e. set to identify the application pertaining to the message, the only remaining meaningful use for the AVP based application ids is for CE[AR]s. For existing AVP rules that include application ids as AVPs, the standard could simply state that if one of the Application-Id AVPs appear in a message, it MUST be set to the same value as the header application id and thereby relieve implementers from a lot of confusion. For new definitions, AVP application ids may be defined as optional, or simply handled by the "universal last resort" *AVP rule. IMHO, a clean and simple rule that would make life much easier both for implementers and standards writers that avoids complicated and/or hard to grasp rules regarding when to use one or the other of the application ids. One obvious issue is that the AVP application id can carry 65 bits of information; an optional 32 bits of vendor id and a binary selector between Auth versus Acct. There seems to be some disagreement as to whether the application id numbering space is flat or not, but if it considered flat, which indeed a 32 bit number would be sufficient for, the "optional" AVP information could be disregarded and the header carry the authoritative source of information. As an alternative, if the vendor id and the Auth/Acct distinction is deemed necessary, the header application id could be disregarded and the AVP be treated as the only authoritative piece of information instead. Just my five cents, Jan Nordqvist _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 18:13:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xoW-000123-QL; Tue, 18 Jul 2006 18:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xoV-00011y-Mk for dime@ietf.org; Tue, 18 Jul 2006 18:13:11 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xoT-0005Ze-9N for dime@ietf.org; Tue, 18 Jul 2006 18:13:11 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 9B25D36BFC; Tue, 18 Jul 2006 18:12:59 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6IMD8mR022503; Tue, 18 Jul 2006 18:13:08 -0400 (EDT) From: "Tolga Asveren" To: "Yoshihiro Ohba" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Tue, 18 Jul 2006 17:49:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <20060718191426.GB7387@steelhead> X-STA-Metric: 0 (engine=021) X-STA-NotSpam: wrote: from:addr:ulticom.co url:mailman -0400, url:listinfo X-STA-Spam: directed charset:windows-1252 url:www1 appid traversed X-BTI-AntiSpam: sta:false/0/021,dcc:off,rbl:off,spf:off,wlbl:trust/4 Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: "STURA, Marco, VF-IT" , 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 Yoshihiro, AFAICS, the toplogoy I posted today (one relay and two proxies) won't work properly if App-Id = 0 is used. Thanks, Tolga > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Tuesday, July 18, 2006 3:14 PM > To: Victor Fajardo > Cc: dime@ietf.org; STURA, Marco, VF-IT > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > I thought the main issue is how to route Diameter base protocol > messages carrying a Session-Id AVP (i.e., messages associated with a > particular session) along the same path on which the > application-specific messages that were used for establishing that > session traversed *when stateful agents are on the path*. > > If there is no stateful agent on the path, I think using application > Id = 0 for all Diameter base protocol messages can work regardless of > whether it is better/easier or not. > > Yoshihiro Ohba > > > On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > > Hi Marco, > > > > The main reason (and people can correct me if i'm wrong) is that these > > messages belong to the session/application using them and it is > > better/easier to co-relate these messages to the said > application. Since > > the base protocol really defines two sets of messages, one set is for > > session/application usage and another for peer connectivity, it is also > > semantically correct for the the session message to carry the app id of > > the session. > > > > > In addition, for implementations, it is more practical to look at the > > app id in the header to determine the application that a > message belongs > > to ... and rightfully so. In my opinion, ASR belongs to this category > > even if it is server directed. It maybe a little bit confusing for > > relays with cannot resolve a route via destination-host to look at an > > ASR with an app id of 0. > > > > hope this helps, > > victor > > >Hi Victor, > > > > > > > > >>This topic is issue #2&5 and refers to what app id > > >>should "application session level" messages defined in the base > > >> > > >protocol > > > > > >>(STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > consensus in the > > >>meeting and more likely in this list as well is that it MUST > carry the > > >>app id of the application using it. > > >> > > > > > >Could you bring some light on the reasons behind this consensus? I > > >thought the discussion in the old AAA list was toward a consensus on > > >using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > > > > >Regards > > >Marco > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > _______________________________________________ > 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 Jul 18 19:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yce-0007Tv-JR; Tue, 18 Jul 2006 19:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ycd-0007Tj-6N for dime@ietf.org; Tue, 18 Jul 2006 19:04:59 -0400 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 1G2ycc-0007Jg-Pb for dime@ietf.org; Tue, 18 Jul 2006 19:04:59 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6IN4GmK067959; Tue, 18 Jul 2006 19:04:17 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Tue, 18 Jul 2006 19:04:00 -0400 To: Tolga Asveren Subject: Re: [Dime] Summary of 3588bis Issues Status Message-ID: <20060718230400.GJ8661@steelhead> References: <20060718191426.GB7387@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 109 X-Spam-Score: -2.4 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: "STURA, Marco, VF-IT" , 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 On Tue, Jul 18, 2006 at 05:49:29PM -0400, Tolga Asveren wrote: > Hi Yoshihiro, > > AFAICS, the toplogoy I posted today (one relay and two proxies) won't work > properly if App-Id = 0 is used. If the proxies in the topology are stateful agents, then you are right. If the proxies are stateless agents, then routing based on Destination-Host AVP will just work fine for routing common messages used for *established sessions*, even with app-id=0, because only the end nodes mantains the session states in this case. Yoshihiro Ohba > > Thanks, > Tolga > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Tuesday, July 18, 2006 3:14 PM > > To: Victor Fajardo > > Cc: dime@ietf.org; STURA, Marco, VF-IT > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > I thought the main issue is how to route Diameter base protocol > > messages carrying a Session-Id AVP (i.e., messages associated with a > > particular session) along the same path on which the > > application-specific messages that were used for establishing that > > session traversed *when stateful agents are on the path*. > > > > If there is no stateful agent on the path, I think using application > > Id = 0 for all Diameter base protocol messages can work regardless of > > whether it is better/easier or not. > > > > Yoshihiro Ohba > > > > > > On Tue, Jul 18, 2006 at 10:53:09AM -0400, Victor Fajardo wrote: > > > Hi Marco, > > > > > > The main reason (and people can correct me if i'm wrong) is that these > > > messages belong to the session/application using them and it is > > > better/easier to co-relate these messages to the said > > application. Since > > > the base protocol really defines two sets of messages, one set is for > > > session/application usage and another for peer connectivity, it is also > > > semantically correct for the the session message to carry the app id of > > > the session. > > > > > > > > In addition, for implementations, it is more practical to look at the > > > app id in the header to determine the application that a > > message belongs > > > to ... and rightfully so. In my opinion, ASR belongs to this category > > > even if it is server directed. It maybe a little bit confusing for > > > relays with cannot resolve a route via destination-host to look at an > > > ASR with an app id of 0. > > > > > > hope this helps, > > > victor > > > >Hi Victor, > > > > > > > > > > > >>This topic is issue #2&5 and refers to what app id > > > >>should "application session level" messages defined in the base > > > >> > > > >protocol > > > > > > > >>(STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > > consensus in the > > > >>meeting and more likely in this list as well is that it MUST > > carry the > > > >>app id of the application using it. > > > >> > > > > > > > >Could you bring some light on the reasons behind this consensus? I > > > >thought the discussion in the old AAA list was toward a consensus on > > > >using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > > > > > > >Regards > > > >Marco > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email Security System. > > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > _______________________________________________ > > 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 Jul 18 19:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yht-0007kh-MZ; Tue, 18 Jul 2006 19:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2yhs-0007kb-PK for dime@ietf.org; Tue, 18 Jul 2006 19:10:24 -0400 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 1G2yhr-0007RK-H7 for dime@ietf.org; Tue, 18 Jul 2006 19:10:24 -0400 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 k6INAIcK067992; Tue, 18 Jul 2006 19:10:19 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD5B49.2070004@tari.toshiba.com> Date: Tue, 18 Jul 2006 18:06:01 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AC@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Yoshi/Marco, > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. 0xffffffff) it won't advertise app id x or y or z. So, any app id would be routed to R1 by R2. > Yes your right. Apologize for that. However, I think based on Yoshi and Tolga's comments if relay2 is actually a stateful proxy then app id becomes important to properly route the ASR s. In such a case, an app id of 0 may not work. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 18 20:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zlu-0007s5-7e; Tue, 18 Jul 2006 20:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zls-0007ry-Jl for dime@ietf.org; Tue, 18 Jul 2006 20:18:36 -0400 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 1G2zls-0003O9-61 for dime@ietf.org; Tue, 18 Jul 2006 20:18:36 -0400 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 k6J0HwTa068206; Tue, 18 Jul 2006 20:17:59 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BD6B2C.8090403@tari.toshiba.com> Date: Tue, 18 Jul 2006 19:13:48 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Jan Nordqvist Subject: Re: [Dime] Summary of 3588bis Issues Status References: <44BD5532.2040002@aaa.lucent.com> In-Reply-To: <44BD5532.2040002@aaa.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Jan, Thanks for bringing up this topic. Just to clarify, this is a new discussion for issue 13 of the tracker. Comments inline: > Few topics has generated as many messages in this and other groups as > the subject regarding (or the confusion surrounding) the fact that > there is an AVP-based application id in the message in addition to the > message id in the Diameter header. > > As far as I am concerned, the application-id serves three purposes: > > 1. Combined with the Command-Code as a message type discriminator to > determine what dictionary and processing entry point to apply in > order to process the message. > 2. Combined with the Destination-Realm to determine message routing. > 3. As a special case in the CER/CEA as a means to advertise > application id support. > > I just can't imagine what scenario would require more than one > application id in a message to serve the purpose of both case 1 and 2 > above, but I may be wrong. > Only in case 3, which is an exception, use of the application id AVPs > is necessary since they are overloaded to mean "support for" in > contrast to identifying the type of message. In this latter case the > header application id only serves as a discriminator to indicate "base". > > For messages that are intended for a specific server, such as ASRs or > any other message that are tied to a specific session, the primary > means for reaching the correct destination is the Destination-Host > AVP. The application id may of course still be used to make coarse > routing decisions to reach a host that has connectivity to and > knowledge about the given host. Obviously it is the responsibility of > the network administrator to configure the network in this case in > such a way that messages aren't dropped, i.e. are being relayed or > proxied to reach a "knowledgeable" peer. This would also seem as a > very likely way to set up routing in practice, i.e. make course > decisions far away from the target and make more precise decisions as > the message gets closer to its destination. > > If the header application id is always set to resolve cases 1 and 2 > above, i.e. set to identify the application pertaining to the message, > the only remaining meaningful use for the AVP based application ids is > for CE[AR]s. For existing AVP rules that include application ids as > AVPs, the standard could simply state that if one of the > Application-Id AVPs appear in a message, it MUST be set to the same > value as the header application id and thereby relieve implementers > from a lot of confusion. For new definitions, AVP application ids may > be defined as optional, or simply handled by the "universal last > resort" *AVP rule. I generally agree. In terms of backward compatibility, the base protocol already mandates that Application-Id AVPs MUST match the app id in the header (Sec 3) though I think the text should be a little bit more clear. In that sense, I'm guessing the above scheme should work even for existing implementations. > > IMHO, a clean and simple rule that would make life much easier both > for implementers and standards writers that avoids complicated and/or > hard to grasp rules regarding when to use one or the other of the > application ids. > > One obvious issue is that the AVP application id can carry 65 bits of > information; an optional 32 bits of vendor id and a binary selector > between Auth versus Acct. There seems to be some disagreement as to > whether the application id numbering space is flat or not, but if it > considered flat, which indeed a 32 bit number would be sufficient for, > the "optional" AVP information could be disregarded and the header > carry the authoritative source of information. As an alternative, if > the vendor id and the Auth/Acct distinction is deemed necessary, the > header application id could be disregarded and the AVP be treated as > the only authoritative piece of information instead. I think this last paragraph is a separate issue but related to issue 13. Regarding the last sentence, if vendor id + auth/acct distinction is applied then the vendor id will now have to be reflected in the routing table. This may have some implications with existing implementations which will not recognize this scheme. I guess this would be an issue with any app in general since they now has to be concerned with vendor id + auth/acct id space. So I think we need to have some resolution with regards to address space first. I'm more in favor of a flat 32 bit space and a strict allocation of app id's as currently mandated by the base. In this case, vendor id has no co-relation with app id. The question then arises on how this affects existing implementations and VSA's. best regards, victor best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 03:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G363m-0000HS-6C; Wed, 19 Jul 2006 03:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G363l-0000HN-1J for dime@ietf.org; Wed, 19 Jul 2006 03:01:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G363i-0006W6-33 for dime@ietf.org; Wed, 19 Jul 2006 03:01:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2N002KW2GJB6@szxga03-in.huawei.com> for dime@ietf.org; Wed, 19 Jul 2006 15:07:31 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2N001AK2GIJP@szxga03-in.huawei.com> for dime@ietf.org; Wed, 19 Jul 2006 15:07:30 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2N00G7W24IAS@szxml03-in.huawei.com> for dime@ietf.org; Wed, 19 Jul 2006 15:00:19 +0800 (CST) Date: Wed, 19 Jul 2006 12:27:42 +0530 From: Rajith R Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: <44BD6B2C.8090403@tari.toshiba.com> To: 'Victor Fajardo' , 'Jan Nordqvist' Message-id: <001c01c6ab00$a261dcb0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaqyOsIehQWfsk9TpKJto/8yF0iFgAN459w X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: dime@ietf.org 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 Hi Victor What you suggest would render the vendor specific application Id AVP useless, I think. Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, July 19, 2006 4:44 AM >To: Jan Nordqvist >Cc: dime@ietf.org >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi Jan, > >Thanks for bringing up this topic. Just to clarify, this is a new >discussion for issue 13 of the tracker. > >Comments inline: >> Few topics has generated as many messages in this and other groups as >> the subject regarding (or the confusion surrounding) the fact that >> there is an AVP-based application id in the message in addition to the >> message id in the Diameter header. >> >> As far as I am concerned, the application-id serves three purposes: >> >> 1. Combined with the Command-Code as a message type discriminator to >> determine what dictionary and processing entry point to apply in >> order to process the message. >> 2. Combined with the Destination-Realm to determine message routing. >> 3. As a special case in the CER/CEA as a means to advertise >> application id support. >> >> I just can't imagine what scenario would require more than one >> application id in a message to serve the purpose of both case 1 and 2 >> above, but I may be wrong. >> Only in case 3, which is an exception, use of the application id AVPs >> is necessary since they are overloaded to mean "support for" in >> contrast to identifying the type of message. In this latter case the >> header application id only serves as a discriminator to indicate "base". >> >> For messages that are intended for a specific server, such as ASRs or >> any other message that are tied to a specific session, the primary >> means for reaching the correct destination is the Destination-Host >> AVP. The application id may of course still be used to make coarse >> routing decisions to reach a host that has connectivity to and >> knowledge about the given host. Obviously it is the responsibility of >> the network administrator to configure the network in this case in >> such a way that messages aren't dropped, i.e. are being relayed or >> proxied to reach a "knowledgeable" peer. This would also seem as a >> very likely way to set up routing in practice, i.e. make course >> decisions far away from the target and make more precise decisions as >> the message gets closer to its destination. >> >> If the header application id is always set to resolve cases 1 and 2 >> above, i.e. set to identify the application pertaining to the message, >> the only remaining meaningful use for the AVP based application ids is >> for CE[AR]s. For existing AVP rules that include application ids as >> AVPs, the standard could simply state that if one of the >> Application-Id AVPs appear in a message, it MUST be set to the same >> value as the header application id and thereby relieve implementers >> from a lot of confusion. For new definitions, AVP application ids may >> be defined as optional, or simply handled by the "universal last >> resort" *AVP rule. > >I generally agree. In terms of backward compatibility, the base protocol >already mandates that Application-Id AVPs MUST match the app id in the >header (Sec 3) though I think the text should be a little bit more >clear. In that sense, I'm guessing the above scheme should work even for >existing implementations. > >> >> IMHO, a clean and simple rule that would make life much easier both >> for implementers and standards writers that avoids complicated and/or >> hard to grasp rules regarding when to use one or the other of the >> application ids. >> >> One obvious issue is that the AVP application id can carry 65 bits of >> information; an optional 32 bits of vendor id and a binary selector >> between Auth versus Acct. There seems to be some disagreement as to >> whether the application id numbering space is flat or not, but if it >> considered flat, which indeed a 32 bit number would be sufficient for, >> the "optional" AVP information could be disregarded and the header >> carry the authoritative source of information. As an alternative, if >> the vendor id and the Auth/Acct distinction is deemed necessary, the >> header application id could be disregarded and the AVP be treated as >> the only authoritative piece of information instead. > >I think this last paragraph is a separate issue but related to issue 13. >Regarding the last sentence, if vendor id + auth/acct distinction is >applied then the vendor id will now have to be reflected in the routing >table. This may have some implications with existing implementations >which will not recognize this scheme. I guess this would be an issue >with any app in general since they now has to be concerned with vendor >id + auth/acct id space. So I think we need to have some resolution with >regards to address space first. I'm more in favor of a flat 32 bit space >and a strict allocation of app id's as currently mandated by the base. >In this case, vendor id has no co-relation with app id. The question >then arises on how this affects existing implementations and VSA's. > >best regards, >victor > > >best regards, >victor > >_______________________________________________ >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 Jul 19 04:05:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G373B-0007Q9-HQ; Wed, 19 Jul 2006 04:04:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3739-0007Px-W9 for dime@ietf.org; Wed, 19 Jul 2006 04:04:56 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3737-0001K8-5q for dime@ietf.org; Wed, 19 Jul 2006 04:04:55 -0400 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6J84ops023714 for ; Wed, 19 Jul 2006 10:04:50 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 10:04:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 10:04:45 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133AD@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqiO9kdeIQi9GySE2BeLHSfCtoQAAf2igg From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 08:04:48.0715 (UTC) FILETIME=[015729B0:01C6AB0A] X-Spam-Score: 0.1 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 Tolga, Diameter was defined as a framework with a set of base common messages = and procedures on top of which we could build additional service = specific application logic. This additional service specific application = logic is supposed to use 'utilities' from the base framework such as = transport and routing, session handling, capability negotiation and = common messages handling. What you're saying is changing the paradigm and philosophy of the base = framework; essentially you're saying that we don't have common messages = and common mechanisms anymore. All what RFC 3588 defines as session = based common messages according to your comments is shifted to the = service specific application, hence jeopardizing the entire framework. = To me your proposal calls for re-building the same handling for those = common messages in each of the service specific applications rather than = applications re-using the common handling offered by the base framework. = Not a good idea IMHO. Regards Marco=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: marted=EC 18 luglio 2006 18.17 To: STURA, Marco, VF-IT; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Marco, I think, the reason for different point of views is mainly due to the question who is considered as the owner of a session. IMHO, session is better owned by the application logic, because only it has full = knowledge about when a session is supposed to end, hence I believe it is best that = any session/application logic related message is handled by the application. = For that reason, I think it is a good idea to use the App-Id of the = application in message header for the messages under discussion. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Tuesday, July 18, 2006 12:33 PM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > See in line. > > Br > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: marted=EC 18 luglio 2006 18.10 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > > comments inline: > >> It maybe a little bit confusing for relays with cannot resolve > a route via >destination-host to look at an ASR with an app id of 0. > >> > > > > Interesting argument I have to say. Routing ASR based on app id > doesn't ensure that the session ASR is supposed to kill is > actually running on the client where the request is routed to. > Suppose a relay agent connected to 10 clients all of which > support app id x, the relay routes based on app id x to client 2 > but the session indicated in the is actually running > in client 5. The ASR will not kill the session as requested by > the server, therefore ASR MUST use Destination-Host based routing. > > > > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of = 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. > 0xffffffff) it won't advertise app id x or y or z. So, any app id > would be routed to R1 by R2. > > > Same argument stands for RAR. > > > > In fact the base defines ASR and RAR with Destination-Host AVP > as mandatory in the ABNF of the message. > > > > I think in the AAA thread also available in the issue tracker > there were arguments why ASR is really a common message, same > would be for RAR if no mandatory AVPs are defined by the application. > > > I've read through some of the comments in the AAA thread regarding = this > issue and it was not clear to me why an app id of 0 is applicable to = ASR > and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set > to 4 (CC app id). > > [MSt] Because the ASR or RAR requests a specific action to the > client that is to be inferred to the session indicated in the > . Diameter CC sets the app id 4 in RAR because it > augments the base message with mandatory AVPs defined in it with > associated behavior. All ASR does is "kill the session". So, the > why not stick on the original rules when RFC3588 was defined? > Base common messages such as ASR and RAR MUST use app id 0 unless > augmented with mandatory AVPs that define a specific behavior of > the client (e.g. DCC application). > > hope this helps, > victor > > > > > Regards > > Marco > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: marted=EC 18 luglio 2006 16.53 > > To: STURA, Marco, VF-IT > > Cc: dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > Hi Marco, > > > > The main reason (and people can correct me if i'm wrong) is that = these > > messages belong to the session/application using them and it is > > better/easier to co-relate these messages to the said > application. Since > > the base protocol really defines two sets of messages, one set is = for > > session/application usage and another for peer connectivity, it is = also > > semantically correct for the the session message to carry the app id = of > > the session. > > > > In addition, for implementations, it is more practical to look at = the > > app id in the header to determine the application that a > message belongs > > to ... and rightfully so. In my opinion, ASR belongs to this = category > > even if it is server directed. It maybe a little bit confusing for > > relays with cannot resolve a route via destination-host to look at = an > > ASR with an app id of 0. > > > > hope this helps, > > victor > > > >> Hi Victor, > >> > >> > >> > >>> This topic is issue #2&5 and refers to what app id > >>> should "application session level" messages defined in the base > >>> > >>> > >> protocol > >> > >> > >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > consensus in the > >>> meeting and more likely in this list as well is that it MUST > carry the > >>> app id of the application using it. > >>> > >>> > >> Could you bring some light on the reasons behind this consensus? I > >> thought the discussion in the old AAA list was toward a consensus = on > >> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >> > >> Regards > >> Marco > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > 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 Jul 19 05:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G385y-0005Hk-Hd; Wed, 19 Jul 2006 05:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G385w-0005Hc-Kl for dime@ietf.org; Wed, 19 Jul 2006 05:11:52 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G385u-0006K1-MD for dime@ietf.org; Wed, 19 Jul 2006 05:11:52 -0400 Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6J9BmI7002490 for ; Wed, 19 Jul 2006 11:11:48 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 11:11:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 11:11:41 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133AE@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcaqjcOfQpGRFXkNRgig9uqha6eAnwAfES+Q From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 09:11:46.0374 (UTC) FILETIME=[5C0D4660:01C6AB13] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 See in line. Regards Marco -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: marted=EC 18 luglio 2006 18.52 To: STURA, Marco, VF-IT; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status [.. snip ..] > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of = 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. > 0xffffffff) it won't advertise app id x or y or z. So, any app id > would be routed to R1 by R2. [TOLGA] Let me try to further refine the scenario: ***************************** * Realm A * * * * +---------+ * * +--+C1 App=3DX | * * +----+ | +---------+ * +----*-+ P1 +-+ +---------+ * +---+ +-+--+ * +----+----+C2 App=3DY | * |S1 +--+ R1 | * +---------+ * +---+ +-+--+ * * | * +----+ * +----*-+ P2 +----+---------+ * * +----+ |C3 App=3DZ | * * +---------+ * * * ***************************** In this case, R1 wouldn't have enough knowledge to route the message properly to the correct proxy just by looking to the App-Id in the = message header, if App-Id is populated with "0". [MSt] I think you assume P1 and P2 advertise supports for App x/y and = App z respectively but I would rather consider this configuration an = academic use case since typically you have only one logical Proxy as a = interconnect point for a given realm in real deployments as a central = point for policy enforcement. However, let see whether a server = initiated message using Destination-Host and app id 0 based routing = works. S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id = 0. In the realm-based routing table R1 will certainly find a match for = realm A and app id 0, say for instance the match is for P1. ASR is = routed to P1, which doesn't have C3 in its peer table and then answers = with DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message = via the alternative entry for Realm A, hence P2. P2 now deliver the = message to C3. So, app-id 0 works at the end if Destination-Host based = routing is used and, actually, is to be used for certain server = initiated messages as also defined in RFC 3588 in section 6.1.=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 05:45:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G38c9-00017L-Ms; Wed, 19 Jul 2006 05:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G38c0-00011i-46 for dime@ietf.org; Wed, 19 Jul 2006 05:45:00 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G38W6-00018v-JM for dime@ietf.org; Wed, 19 Jul 2006 05:38:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6J9cpEq003593; Wed, 19 Jul 2006 12:38:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:38:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 12:38:51 +0300 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] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 12:38:49 +0300 Message-ID: In-Reply-To: <44BD22AA.4030105@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3Wrw From: To: , X-OriginalArrivalTime: 19 Jul 2006 09:38:51.0015 (UTC) FILETIME=[2469D170:01C6AB17] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Fajardo wrote: > I'm still not sure why we 'MUST' use app id of 0 ?=20 In the case of RFC 4005 and 4072: because the spec says so? RFC 4005, Section 1.3: "All other messages are defined by [BASE] and use the Base application id value." RFC 4072, Section 3, last paragraph: "the others [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." This should not lead to interoperability problems unless the implementors can't read the specs. And in that case, producing more specs is unlikely to be of help. > Unless I have the wrong take on this issue, there is a consensus > that we should just use the app id of the application for simplicity > and correctness. The last time this was discussed, there was consensus that using 0 is the right answer, and this lead to adding the above-quoted text to RFC 4005 and 4072. So unless the approach in 4005/4072 leads to significant problems, even when correctly implemented, I'd suggest not changing it. Changing it could also lead to interoperability problems with those implementations that correctly implement 4005/4072. Best regards, Pasi _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 05:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G38cH-0001DB-Tn; Wed, 19 Jul 2006 05:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G38cF-0001C3-Ci for dime@ietf.org; Wed, 19 Jul 2006 05:45:15 -0400 Received: from mail2.ptinovacao.pt ([194.65.138.21] helo=inoavrex07.ptin.corpPT.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G38Oi-0008IP-E0 for dime@ietf.org; Wed, 19 Jul 2006 05:31:18 -0400 Received: from INOAVREX05.ptin.corpPT.com ([10.112.15.67]) by inoavrex07.ptin.corpPT.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 10:29:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [Dime] diameter redirect X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Jul 2006 10:31:08 +0100 Message-ID: <75D349FBF7C131408F5061B7168072C303329DC6@INOAVREX06.ptin.corpPT.com> In-Reply-To: <20060531154024.65174.qmail@web38215.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] diameter redirect Thread-Index: AcaEyK7DmCF+uXF2T3CNdeBpvkDrcgmR6R0Q From: "Paulo Rolo" To: X-OriginalArrivalTime: 19 Jul 2006 09:29:42.0968 (UTC) FILETIME=[DDC07B80:01C6AB15] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Hello, We are currently developing a set of Diameter interfaces and some doubts = have arise, concerning SLF usage. On ETSI TS 123 228 (IP Multimedia Subsystem (IMS)) at section 5.8.1 = (User identity to HSS resolution) it is suggested that a Public User = Identity should be selected and used as input to SLF_QUERY, in order to = resolve to the correct HSS name.=20 Also at section 6.1.2 (S-CSCF registration/deregistration notification) = of TS 129 228 (IP Multimedia (IM) Subsystem Cx and Dx Interfaces), it is = suggested that if Routing Information is not available for SAR (S-CSCF = registration/deregistration), it should be routed to next diameter node, = for example SLF. =20 The issue is that on TS 129 229 (Cx and Dx interfaces based on the = Diameter protocol) at section 6.1.3 (Server-Assignment-Request (SAR) = Command) the Public-Identity is presented as an optional attribute. If = it is not present how should be SLF_QUERY performed? All the other = messages (UAR, LIR, MAR) have Public-Identity as mandatory. Thanks in advance, Paulo Rolo Network and Protocols Unit Intelligent Networks Department Portugal Telecom Inova=E7=E3o, S.A =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 06:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G39BH-0004xz-E8; Wed, 19 Jul 2006 06:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G39BG-0004x6-3S for dime@ietf.org; Wed, 19 Jul 2006 06:21:26 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G39BD-0002Mr-LK for dime@ietf.org; Wed, 19 Jul 2006 06:21:26 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6JALLps009693 for ; Wed, 19 Jul 2006 12:21:22 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 12:21:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 12:21:18 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133B0@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAACOQcA= From: "STURA, Marco, VF-IT" To: , X-OriginalArrivalTime: 19 Jul 2006 10:21:20.0160 (UTC) FILETIME=[13D27A00:01C6AB1D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Fully agree with Pasi. And, as far as I know, there are implementations out there that comply = with the specs refereed by Pasi and surprisingly inter-work = successfully. There are also implementations that comply with RFC 4006, = where application specific behavior is defined as a result of the RAR = message if certain mandatory AVPs were present (e.g. credit pool = re-authorization vs full session re-authorization). So, I think the rule should be " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter Common = Messages) unless a service specific application augments those messages = with mandatory AVPs ('M' bit set) that define application specific = behavior (one example can be found in RFC 4006 for the RAR message)." Regards Marco -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: mercoled=EC 19 luglio 2006 11.39 To: vfajardo@tari.toshiba.com; STURA, Marco, VF-IT Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Victor Fajardo wrote: > I'm still not sure why we 'MUST' use app id of 0 ?=20 In the case of RFC 4005 and 4072: because the spec says so? RFC 4005, Section 1.3: "All other messages are defined by [BASE] and use the Base application id value." RFC 4072, Section 3, last paragraph: "the others [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." This should not lead to interoperability problems unless the implementors can't read the specs. And in that case, producing more specs is unlikely to be of help. > Unless I have the wrong take on this issue, there is a consensus > that we should just use the app id of the application for simplicity > and correctness. The last time this was discussed, there was consensus that using 0 is the right answer, and this lead to adding the above-quoted text to RFC 4005 and 4072. So unless the approach in 4005/4072 leads to significant problems, even when correctly implemented, I'd suggest not changing it. Changing it could also lead to interoperability problems with those implementations that correctly implement 4005/4072. Best regards, Pasi _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 07:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3AY8-00071W-Lw; Wed, 19 Jul 2006 07:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3AY7-00071Q-MJ for dime@ietf.org; Wed, 19 Jul 2006 07:49:07 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3AY3-0004D6-Jz for dime@ietf.org; Wed, 19 Jul 2006 07:49:07 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDFEFF69; Wed, 19 Jul 2006 13:49:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 13:49:02 +0200 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 13:49:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summary of 3588bis Issues Status X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Jul 2006 13:49:00 +0200 Message-ID: <7457D12699374F40BD026D2B1EFFBEC6028430D2@eesmdmw020.eemea.ericsson.se> In-Reply-To: <44B7D875.40204@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summary of 3588bis Issues Status Thread-Index: AcanbZNuxoYtCmTURp6FNA2v4L2sxwDuu97w From: "German Blanco \(MI/EEM\)" To: "Victor Fajardo" , X-OriginalArrivalTime: 19 Jul 2006 11:49:01.0663 (UTC) FILETIME=[53EC1EF0:01C6AB29] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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 Victor,=20 Thanks for the summary! When you say: > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP.=20 Is the proposal to indicate in the answer only the code of the missing AVP inside the Grouped AVP? If that is the case, I would suggest this text additions for RFC 3558bis (between ">>"s and "<<"s): " DIAMETER_MISSING_AVP 5005 The request did not contain an AVP that is required by the Command Code >>or Grouped AVP <> If the AVP is missing in a Grouped AVP, only the missing AVP and not the Grouped-AVP will be included in=20 the Failed-AVP. <> If the AVP is present inside a Grouped AVP, only the offending AVP and not the Grouped-AVP will be included=20 in the Failed-AVP. << " "Do nothing" doesn't seem a good idea to me. I would prefer that this is clarified, whatever the conclusion is. The long list of error codes will not make sense, if we end up not knowing what happened. Regards, German.=20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: viernes, 14 de julio de 2006 19:46 To: dime@ietf.org Subject: [Dime] Summary of 3588bis Issues Status Folks, The is a summary of the 3588bis issues discussion during DIME WG meeting in IETF66. If you have comments on any of the existing issues pls don't hesitate to post it on the DIME list so we can facilitate quicker resolution or at least better understanding of the problem. We also need some proposals on the open issues if you believe they are truly issues.=20 Note that the assigned issue numbers are based on the current tracker which is for historical reasons the diameter-interop tracker (http://www.tschofenig.priv.at:8080/diameter-interop). Closed Issues: ------------- Issue 6 : TLS version issue Comments: interop related problem only. Does not affect the base spec Issue 7 : Textual IP address qualify as FQDN Comments: Consensus that FQDN is defined as "internet name" only Issue 11 : Confusion about use of Proxy-Info AVP for Relay Comments: Clarified in Sec 6.2 with the text "Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request." Open Issues with some consensus on proposals: --------------------------------------------- Notes: These issues have some consensus either during the IETF66 meeting and/or in the DIME mailing list. Issue 2 & 5 : App Ids used by common diameter messages Proposals: Use the application id of the current application Issue 3 & 16 : CER/CEA exchange in the open state Proposals: Need more consensus on current proposals posted in issue 16 Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp Proposals: The Vendor-Id ABNF should one and only one instance, i.e. ::=3D < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Issue 20 : Determining an offending/invalid AVP contained within the group AVP Proposals: Do nothing. The AVP code should be enough. Existing proposals may needlessly extend the length of the Failed-AVP. Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 Proposals: Change diameter-message definition in Sec 3.2 to: diameter-message=3Dheader[*fixed][*required][*optional] Open Issues with no consensus on proposals: ------------------------------------------ Issue 21 : URI schemes for AAA Proposals: draft-garcia-dime-aaa-uri-00.txt Issue 4 : Proxy agent stay in the path of the request message of a session Proposals: draft-tsou-dime-routing-ext-00.txt Open Issues that needs proposals: -------------------------------- Notes: These issues did not receive any comments during IETF66 and have no pending proposals. Issue 1 : Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id Issue 15 : Duplicate detection requires server side storage of e2e id and origin-host avp Issue 13 : Clarify usage of application id avp's and how they relate to the app-id in the header Issue 9 & 19 : Error codes defined in wrong category Issue 8 : Setting error flag (e-bit) during CER/CEA exchange Issue 12 : Differing concepts and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue 14 : Explicit text on which error category should have error flag (e-bit) set Issue 18 : Clarify reconnect behavior of peer based on value of Disconnect-Cause AVP Open issues falling into the "New Features" category: ---------------------------------------------------- Note: These features should use the extension procedures defined in 3588. No comments received in IETF66 meeting. Issue 23 : Predictive loop detection Comments: Optimzation techiniques in detecting loops at the succeeding hops Issue 22 : Fetch data request and location update request. Comments: Proposal to include LUR messages into base since its reusable in different applications If you believe there are some in-accurate info below, pls let us know. best regards, victor _______________________________________________ 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 Jul 19 08:18:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3B0q-0004Yj-0T; Wed, 19 Jul 2006 08:18:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3B0o-0004Yb-Pj for dime@ietf.org; Wed, 19 Jul 2006 08:18:46 -0400 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 1G3B0n-0006UG-6y for dime@ietf.org; Wed, 19 Jul 2006 08:18:46 -0400 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 k6JCG64F069959; Wed, 19 Jul 2006 08:16:10 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE1389.4080006@tari.toshiba.com> Date: Wed, 19 Jul 2006 07:12:09 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: rajithr@huawei.com Subject: Re: [Dime] Summary of 3588bis Issues Status References: <001c01c6ab00$a261dcb0$a905120a@china.huawei.com> In-Reply-To: <001c01c6ab00$a261dcb0$a905120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: dime@ietf.org, 'Jan Nordqvist' 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 Rajith, > Hi Victor > > What you suggest would render the vendor specific application Id AVP > useless, I think. > Probably. I don't have a strong opinion on this so maybe someone else can shed light on what a good course of action would be. regards, victor > Rajith > **************************************************************************** > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Wednesday, July 19, 2006 4:44 AM >> To: Jan Nordqvist >> Cc: dime@ietf.org >> Subject: Re: [Dime] Summary of 3588bis Issues Status >> >> Hi Jan, >> >> Thanks for bringing up this topic. Just to clarify, this is a new >> discussion for issue 13 of the tracker. >> >> Comments inline: >> >>> Few topics has generated as many messages in this and other groups as >>> the subject regarding (or the confusion surrounding) the fact that >>> there is an AVP-based application id in the message in addition to the >>> message id in the Diameter header. >>> >>> As far as I am concerned, the application-id serves three purposes: >>> >>> 1. Combined with the Command-Code as a message type discriminator to >>> determine what dictionary and processing entry point to apply in >>> order to process the message. >>> 2. Combined with the Destination-Realm to determine message routing. >>> 3. As a special case in the CER/CEA as a means to advertise >>> application id support. >>> >>> I just can't imagine what scenario would require more than one >>> application id in a message to serve the purpose of both case 1 and 2 >>> above, but I may be wrong. >>> Only in case 3, which is an exception, use of the application id AVPs >>> is necessary since they are overloaded to mean "support for" in >>> contrast to identifying the type of message. In this latter case the >>> header application id only serves as a discriminator to indicate "base". >>> >>> For messages that are intended for a specific server, such as ASRs or >>> any other message that are tied to a specific session, the primary >>> means for reaching the correct destination is the Destination-Host >>> AVP. The application id may of course still be used to make coarse >>> routing decisions to reach a host that has connectivity to and >>> knowledge about the given host. Obviously it is the responsibility of >>> the network administrator to configure the network in this case in >>> such a way that messages aren't dropped, i.e. are being relayed or >>> proxied to reach a "knowledgeable" peer. This would also seem as a >>> very likely way to set up routing in practice, i.e. make course >>> decisions far away from the target and make more precise decisions as >>> the message gets closer to its destination. >>> >>> If the header application id is always set to resolve cases 1 and 2 >>> above, i.e. set to identify the application pertaining to the message, >>> the only remaining meaningful use for the AVP based application ids is >>> for CE[AR]s. For existing AVP rules that include application ids as >>> AVPs, the standard could simply state that if one of the >>> Application-Id AVPs appear in a message, it MUST be set to the same >>> value as the header application id and thereby relieve implementers >>> from a lot of confusion. For new definitions, AVP application ids may >>> be defined as optional, or simply handled by the "universal last >>> resort" *AVP rule. >>> >> I generally agree. In terms of backward compatibility, the base protocol >> already mandates that Application-Id AVPs MUST match the app id in the >> header (Sec 3) though I think the text should be a little bit more >> clear. In that sense, I'm guessing the above scheme should work even for >> existing implementations. >> >> >>> IMHO, a clean and simple rule that would make life much easier both >>> for implementers and standards writers that avoids complicated and/or >>> hard to grasp rules regarding when to use one or the other of the >>> application ids. >>> >>> One obvious issue is that the AVP application id can carry 65 bits of >>> information; an optional 32 bits of vendor id and a binary selector >>> between Auth versus Acct. There seems to be some disagreement as to >>> whether the application id numbering space is flat or not, but if it >>> considered flat, which indeed a 32 bit number would be sufficient for, >>> the "optional" AVP information could be disregarded and the header >>> carry the authoritative source of information. As an alternative, if >>> the vendor id and the Auth/Acct distinction is deemed necessary, the >>> header application id could be disregarded and the AVP be treated as >>> the only authoritative piece of information instead. >>> >> I think this last paragraph is a separate issue but related to issue 13. >> Regarding the last sentence, if vendor id + auth/acct distinction is >> applied then the vendor id will now have to be reflected in the routing >> table. This may have some implications with existing implementations >> which will not recognize this scheme. I guess this would be an issue >> with any app in general since they now has to be concerned with vendor >> id + auth/acct id space. So I think we need to have some resolution with >> regards to address space first. I'm more in favor of a flat 32 bit space >> and a strict allocation of app id's as currently mandated by the base. >> In this case, vendor id has no co-relation with app id. The question >> then arises on how this affects existing implementations and VSA's. >> >> best regards, >> victor >> >> >> best regards, >> victor >> >> _______________________________________________ >> 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 Jul 19 08:38:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BJV-0007Ra-JJ; Wed, 19 Jul 2006 08:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BJU-0007Pq-73 for dime@ietf.org; Wed, 19 Jul 2006 08:38:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BJU-0007Px-5H for dime@ietf.org; Wed, 19 Jul 2006 08:38:04 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3B9m-0002mc-P8 for dime@ietf.org; Wed, 19 Jul 2006 08:28:05 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id ECA16A5838; Wed, 19 Jul 2006 08:27:53 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JCRdCJ003827; Wed, 19 Jul 2006 08:27:48 -0400 (EDT) From: "Tolga Asveren" To: "STURA, Marco, VF-IT" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 08:03:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AD@OIVMEXO01.omnitel.it> Received-SPF: none X-Spam-Score: -2.1 (--) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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 Marco, I understand your point. OTOH, to me it sounds strange to leave decisions related with session life cycle to anything else than the application logic, because it usually is dependent on the type of application and the context of the scenario. The way I see it is as follows: a) We have hop-to-hop messages, to be consumed by base diameter. b) We have messages defined by base protocol, which are related with session life-cycle, are generic in nature -hence defined in base diameter rather than replicated in every new application specification-, and are consumed by application. c) Messages which are defined by applications. I don't see this as a drastic paradigm shift. Actually the reason for this thread is that the text in RFC3588 can be interpreted in different ways, so whether there is a shift or not depends of ones understanding of the current specifications -where obviously people have different interpretations-. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 4:05 AM > To: Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Tolga, > > Diameter was defined as a framework with a set of base common > messages and procedures on top of which we could build additional > service specific application logic. This additional service > specific application logic is supposed to use 'utilities' from > the base framework such as transport and routing, session > handling, capability negotiation and common messages handling. > > What you're saying is changing the paradigm and philosophy of the > base framework; essentially you're saying that we don't have > common messages and common mechanisms anymore. All what RFC 3588 > defines as session based common messages according to your > comments is shifted to the service specific application, hence > jeopardizing the entire framework. To me your proposal calls for > re-building the same handling for those common messages in each > of the service specific applications rather than applications > re-using the common handling offered by the base framework. Not a > good idea IMHO. > > Regards > Marco > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: martedì 18 luglio 2006 18.17 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > Marco, > > I think, the reason for different point of views is mainly due to the > question who is considered as the owner of a session. IMHO, session is > better owned by the application logic, because only it has full knowledge > about when a session is supposed to end, hence I believe it is > best that any > session/application logic related message is handled by the > application. For > that reason, I think it is a good idea to use the App-Id of the > application > in message header for the messages under discussion. > > Thanks, > Tolga > > > -----Original Message----- > > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > > Sent: Tuesday, July 18, 2006 12:33 PM > > To: Victor Fajardo > > Cc: dime@ietf.org > > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > > > > See in line. > > > > Br > > Marco > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: martedì 18 luglio 2006 18.10 > > To: STURA, Marco, VF-IT > > Cc: dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > Hi Marco, > > > > comments inline: > > >> It maybe a little bit confusing for relays with cannot resolve > > a route via >destination-host to look at an ASR with an app id of 0. > > >> > > > > > > Interesting argument I have to say. Routing ASR based on app id > > doesn't ensure that the session ASR is supposed to kill is > > actually running on the client where the request is routed to. > > Suppose a relay agent connected to 10 clients all of which > > support app id x, the relay routes based on app id x to client 2 > > but the session indicated in the is actually running > > in client 5. The ASR will not kill the session as requested by > > the server, therefore ASR MUST use Destination-Host based routing. > > > > > > > I agree with your example above regarding destination-host. It is > > required in the case of ASR (and perhaps some other message) though I > > guess I was stating a case which is a little bit different than your > > example above. I was thinking of the following case: > > > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > > > in this case relay2 will not be able to route using dest-host. This is > > where dest-realm and app id becomes important. In this case app id of 0 > > might not work as well ... or maybe I'm wrong. > > > > [MSt] In this case R1 would advertise it self as a relay (i.e. > > 0xffffffff) it won't advertise app id x or y or z. So, any app id > > would be routed to R1 by R2. > > > > > Same argument stands for RAR. > > > > > > In fact the base defines ASR and RAR with Destination-Host AVP > > as mandatory in the ABNF of the message. > > > > > > I think in the AAA thread also available in the issue tracker > > there were arguments why ASR is really a common message, same > > would be for RAR if no mandatory AVPs are defined by the application. > > > > > I've read through some of the comments in the AAA thread regarding this > > issue and it was not clear to me why an app id of 0 is applicable to ASR > > and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set > > to 4 (CC app id). > > > > [MSt] Because the ASR or RAR requests a specific action to the > > client that is to be inferred to the session indicated in the > > . Diameter CC sets the app id 4 in RAR because it > > augments the base message with mandatory AVPs defined in it with > > associated behavior. All ASR does is "kill the session". So, the > > why not stick on the original rules when RFC3588 was defined? > > Base common messages such as ASR and RAR MUST use app id 0 unless > > augmented with mandatory AVPs that define a specific behavior of > > the client (e.g. DCC application). > > > > hope this helps, > > victor > > > > > > > > Regards > > > Marco > > > > > > -----Original Message----- > > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > Sent: martedì 18 luglio 2006 16.53 > > > To: STURA, Marco, VF-IT > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > Hi Marco, > > > > > > The main reason (and people can correct me if i'm wrong) is that these > > > messages belong to the session/application using them and it is > > > better/easier to co-relate these messages to the said > > application. Since > > > the base protocol really defines two sets of messages, one set is for > > > session/application usage and another for peer connectivity, > it is also > > > semantically correct for the the session message to carry the > app id of > > > the session. > > > > > > In addition, for implementations, it is more practical to look at the > > > app id in the header to determine the application that a > > message belongs > > > to ... and rightfully so. In my opinion, ASR belongs to this category > > > even if it is server directed. It maybe a little bit confusing for > > > relays with cannot resolve a route via destination-host to look at an > > > ASR with an app id of 0. > > > > > > hope this helps, > > > victor > > > > > >> Hi Victor, > > >> > > >> > > >> > > >>> This topic is issue #2&5 and refers to what app id > > >>> should "application session level" messages defined in the base > > >>> > > >>> > > >> protocol > > >> > > >> > > >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > > consensus in the > > >>> meeting and more likely in this list as well is that it MUST > > carry the > > >>> app id of the application using it. > > >>> > > >>> > > >> Could you bring some light on the reasons behind this consensus? I > > >> thought the discussion in the old AAA list was toward a consensus on > > >> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > > >> > > >> Regards > > >> Marco > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 Jul 19 08:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BNB-0007Zv-Pz; Wed, 19 Jul 2006 08:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3BN9-0007Zq-Pm for dime@ietf.org; Wed, 19 Jul 2006 08:41:51 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3BN8-0007q0-76 for dime@ietf.org; Wed, 19 Jul 2006 08:41:51 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 7A28C36B71; Wed, 19 Jul 2006 08:41:44 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JCfmtW004781; Wed, 19 Jul 2006 08:41:48 -0400 (EDT) From: "Tolga Asveren" To: "STURA, Marco, VF-IT" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 08:18:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133AE@OIVMEXO01.omnitel.it> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Marco, Please see below for comments. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 5:12 AM > To: Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > See in line. > > Regards > Marco > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: martedì 18 luglio 2006 18.52 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > [.. snip ..] > > I agree with your example above regarding destination-host. It is > > required in the case of ASR (and perhaps some other message) though I > > guess I was stating a case which is a little bit different than your > > example above. I was thinking of the following case: > > > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > > > in this case relay2 will not be able to route using dest-host. This is > > where dest-realm and app id becomes important. In this case app id of 0 > > might not work as well ... or maybe I'm wrong. > > > > [MSt] In this case R1 would advertise it self as a relay (i.e. > > 0xffffffff) it won't advertise app id x or y or z. So, any app id > > would be routed to R1 by R2. > [TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=X | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * > +---+ +-+--+ * +----+----+C2 App=Y | * > |S1 +--+ R1 | * +---------+ * > +---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=Z | * > * +---------+ * > * * > ***************************** > In this case, R1 wouldn't have enough knowledge to route the message > properly to the correct proxy just by looking to the App-Id in the message > header, if App-Id is populated with "0". > > [MSt] I think you assume P1 and P2 advertise supports for App x/y > and App z respectively but I would rather consider this > configuration an academic use case since typically you have only > one logical Proxy as a interconnect point for a given realm in > real deployments as a central point for policy enforcement. > However, let see whether a server initiated message using > Destination-Host and app id 0 based routing works. [TOLGA]To me this configuration is not unrealistic, because Realm-A is supporting multiple applications and that may require different policy enforcement processing per application. Maybe a better configuration would be to have a gateway relay in Realm-A to provide a single point of enterance but that wouldn't change anything in the context of current discussion. > > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) > app id 0. In the realm-based routing table R1 will certainly find > a match for realm A and app id 0, say for instance the match is > for P1. ASR is routed to P1, which doesn't have C3 in its peer > table and then answers with DIAMETER_UNABLE_TO_DELIVER. R1 > attempts then to deliver the message via the alternative entry > for Realm A, hence P2. P2 now deliver the message to C3. So, > app-id 0 works at the end if Destination-Host based routing is > used and, actually, is to be used for certain server initiated > messages as also defined in RFC 3588 in section 6.1. [TOLGA]Probably this is not the optimum way to achieve routing, especially considering that it would happen statistically for half of the session life-cycle related messages, if App-Id=0 is used. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 09:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Bim-0000kz-2P; Wed, 19 Jul 2006 09:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Bik-0000i1-8O for dime@ietf.org; Wed, 19 Jul 2006 09:04:10 -0400 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 1G3Bii-0000jb-W8 for dime@ietf.org; Wed, 19 Jul 2006 09:04:10 -0400 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 k6JD3WPc070075; Wed, 19 Jul 2006 09:03:32 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE2DA6.40606@tari.toshiba.com> Date: Wed, 19 Jul 2006 09:03:34 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Dime] Summary of 3588bis Issues Status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org, Marco.STURA@vodafone.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 Pasi, > Victor Fajardo wrote: > >> I'm still not sure why we 'MUST' use app id of 0 ? >> > > In the case of RFC 4005 and 4072: because the spec says so? > > RFC 4005, Section 1.3: "All other messages are defined by [BASE] and > use the Base application id value." > > RFC 4072, Section 3, last paragraph: "the others > [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." > I can understand how the issue can affect 4005/4072. > This should not lead to interoperability problems unless the > implementors can't read the specs. And in that case, producing more > specs is unlikely to be of help. > Not sure if this is the case ... it was several implementors who requested clarification on this issue during an interop so it maybe best to hear out their concerns beyond 4005 or 4072. Some of such concerns have been posted in this list. > > > >> Unless I have the wrong take on this issue, there is a consensus >> that we should just use the app id of the application for simplicity >> and correctness. >> > > The last time this was discussed, there was consensus that using 0 is > the right answer, and this lead to adding the above-quoted text to RFC > 4005 and 4072. > I guess if there was a previous consensus ... then maybe all we need is a clarification on the reasoning behind the previous consensus and see if it that reasoning still hold true with regards to current concerns. hope this helps, victor > So unless the approach in 4005/4072 leads to significant problems, > even when correctly implemented, I'd suggest not changing it. > Changing it could also lead to interoperability problems with > those implementations that correctly implement 4005/4072. > > Best regards, > Pasi > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 09:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Buu-0000Of-4s; Wed, 19 Jul 2006 09:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Bus-0000Oa-VV for dime@ietf.org; Wed, 19 Jul 2006 09:16:42 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Buq-0001hB-EP for dime@ietf.org; Wed, 19 Jul 2006 09:16:42 -0400 Received: from omini95.omnitel.it (omini95.omnitel.it [10.21.18.147]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6JDGcps000412 for ; Wed, 19 Jul 2006 15:16:38 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 15:16:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 15:16:33 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133B3@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarMLbSXogAMDatSoaeFK8U27XIEgABBNDA From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 13:16:36.0722 (UTC) FILETIME=[902E7D20:01C6AB35] X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 [TOLGA]Probably this is not the optimum way to achieve routing, = especially considering that it would happen statistically for half of the session life-cycle related messages, if App-Id=3D0 is used. Only for server initiated messages and as I said a more realistic = deployment is one logical proxy that enforces policies for all = applications of the Real A. Marco -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: mercoled=EC 19 luglio 2006 14.18 To: STURA, Marco, VF-IT; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Marco, Please see below for comments. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 5:12 AM > To: Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > See in line. > > Regards > Marco > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: marted=EC 18 luglio 2006 18.52 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > [.. snip ..] > > I agree with your example above regarding destination-host. It is > > required in the case of ASR (and perhaps some other message) though = I > > guess I was stating a case which is a little bit different than your > > example above. I was thinking of the following case: > > > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > > > in this case relay2 will not be able to route using dest-host. This = is > > where dest-realm and app id becomes important. In this case app id = of 0 > > might not work as well ... or maybe I'm wrong. > > > > [MSt] In this case R1 would advertise it self as a relay (i.e. > > 0xffffffff) it won't advertise app id x or y or z. So, any app id > > would be routed to R1 by R2. > [TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=3DX | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * > +---+ +-+--+ * +----+----+C2 App=3DY | * > |S1 +--+ R1 | * +---------+ * > +---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=3DZ | * > * +---------+ * > * * > ***************************** > In this case, R1 wouldn't have enough knowledge to route the message > properly to the correct proxy just by looking to the App-Id in the = message > header, if App-Id is populated with "0". > > [MSt] I think you assume P1 and P2 advertise supports for App x/y > and App z respectively but I would rather consider this > configuration an academic use case since typically you have only > one logical Proxy as a interconnect point for a given realm in > real deployments as a central point for policy enforcement. > However, let see whether a server initiated message using > Destination-Host and app id 0 based routing works. [TOLGA]To me this configuration is not unrealistic, because Realm-A is supporting multiple applications and that may require different policy enforcement processing per application. Maybe a better configuration = would be to have a gateway relay in Realm-A to provide a single point of = enterance but that wouldn't change anything in the context of current discussion. > > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) > app id 0. In the realm-based routing table R1 will certainly find > a match for realm A and app id 0, say for instance the match is > for P1. ASR is routed to P1, which doesn't have C3 in its peer > table and then answers with DIAMETER_UNABLE_TO_DELIVER. R1 > attempts then to deliver the message via the alternative entry > for Realm A, hence P2. P2 now deliver the message to C3. So, > app-id 0 works at the end if Destination-Host based routing is > used and, actually, is to be used for certain server initiated > messages as also defined in RFC 3588 in section 6.1. [TOLGA]Probably this is not the optimum way to achieve routing, = especially considering that it would happen statistically for half of the session life-cycle related messages, if App-Id=3D0 is used. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 09:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C7L-0004p8-LS; Wed, 19 Jul 2006 09:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3C7K-0004p3-N2 for dime@ietf.org; Wed, 19 Jul 2006 09:29:34 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C7K-0002Nd-2W for dime@ietf.org; Wed, 19 Jul 2006 09:29:34 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6JDTWps004183 for ; Wed, 19 Jul 2006 15:29:32 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 15:29:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 15:29:13 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133B4@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarLsxVEjVO53UXT+S58o3GW35zdgAB/1JA From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 13:29:28.0425 (UTC) FILETIME=[5C270590:01C6AB37] X-Spam-Score: 0.1 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca 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 don't see this as a drastic paradigm shift. Actually the reason for = this >thread is that the text in RFC3588 can be interpreted in different = ways, so >whether there is a shift or not depends of ones understanding of the = >current >specifications -where obviously people have different interpretations-. I still don't see how there could be different interpretations of = implementers of standard applications given the clear text written = there, as pointed out by Pasi too (see below). >RFC 4005, Section 1.3: "All other messages are defined by [BASE] and = use >the Base application id value." >RFC 4072, Section 3, last paragraph: "the others = [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)." >This should not lead to interoperability problems unless the = implementors >can't read the specs. And in that case, producing more = specs is unlikely to >be of help. -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: mercoled=EC 19 luglio 2006 14.04 To: STURA, Marco, VF-IT; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Marco, I understand your point. OTOH, to me it sounds strange to leave = decisions related with session life cycle to anything else than the application = logic, because it usually is dependent on the type of application and the = context of the scenario. The way I see it is as follows: a) We have hop-to-hop messages, to be consumed by base diameter. b) We have messages defined by base protocol, which are related with = session life-cycle, are generic in nature -hence defined in base diameter rather than replicated in every new application specification-, and are = consumed by application. c) Messages which are defined by applications. I don't see this as a drastic paradigm shift. Actually the reason for = this thread is that the text in RFC3588 can be interpreted in different ways, = so whether there is a shift or not depends of ones understanding of the = current specifications -where obviously people have different interpretations-. Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 4:05 AM > To: Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Tolga, > > Diameter was defined as a framework with a set of base common > messages and procedures on top of which we could build additional > service specific application logic. This additional service > specific application logic is supposed to use 'utilities' from > the base framework such as transport and routing, session > handling, capability negotiation and common messages handling. > > What you're saying is changing the paradigm and philosophy of the > base framework; essentially you're saying that we don't have > common messages and common mechanisms anymore. All what RFC 3588 > defines as session based common messages according to your > comments is shifted to the service specific application, hence > jeopardizing the entire framework. To me your proposal calls for > re-building the same handling for those common messages in each > of the service specific applications rather than applications > re-using the common handling offered by the base framework. Not a > good idea IMHO. > > Regards > Marco > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: marted=EC 18 luglio 2006 18.17 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > Marco, > > I think, the reason for different point of views is mainly due to the > question who is considered as the owner of a session. IMHO, session is > better owned by the application logic, because only it has full = knowledge > about when a session is supposed to end, hence I believe it is > best that any > session/application logic related message is handled by the > application. For > that reason, I think it is a good idea to use the App-Id of the > application > in message header for the messages under discussion. > > Thanks, > Tolga > > > -----Original Message----- > > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > > Sent: Tuesday, July 18, 2006 12:33 PM > > To: Victor Fajardo > > Cc: dime@ietf.org > > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > > > > See in line. > > > > Br > > Marco > > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: marted=EC 18 luglio 2006 18.10 > > To: STURA, Marco, VF-IT > > Cc: dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > Hi Marco, > > > > comments inline: > > >> It maybe a little bit confusing for relays with cannot resolve > > a route via >destination-host to look at an ASR with an app id of 0. > > >> > > > > > > Interesting argument I have to say. Routing ASR based on app id > > doesn't ensure that the session ASR is supposed to kill is > > actually running on the client where the request is routed to. > > Suppose a relay agent connected to 10 clients all of which > > support app id x, the relay routes based on app id x to client 2 > > but the session indicated in the is actually running > > in client 5. The ASR will not kill the session as requested by > > the server, therefore ASR MUST use Destination-Host based routing. > > > > > > > I agree with your example above regarding destination-host. It is > > required in the case of ASR (and perhaps some other message) though = I > > guess I was stating a case which is a little bit different than your > > example above. I was thinking of the following case: > > > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > > > in this case relay2 will not be able to route using dest-host. This = is > > where dest-realm and app id becomes important. In this case app id = of 0 > > might not work as well ... or maybe I'm wrong. > > > > [MSt] In this case R1 would advertise it self as a relay (i.e. > > 0xffffffff) it won't advertise app id x or y or z. So, any app id > > would be routed to R1 by R2. > > > > > Same argument stands for RAR. > > > > > > In fact the base defines ASR and RAR with Destination-Host AVP > > as mandatory in the ABNF of the message. > > > > > > I think in the AAA thread also available in the issue tracker > > there were arguments why ASR is really a common message, same > > would be for RAR if no mandatory AVPs are defined by the = application. > > > > > I've read through some of the comments in the AAA thread regarding = this > > issue and it was not clear to me why an app id of 0 is applicable to = ASR > > and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is = set > > to 4 (CC app id). > > > > [MSt] Because the ASR or RAR requests a specific action to the > > client that is to be inferred to the session indicated in the > > . Diameter CC sets the app id 4 in RAR because it > > augments the base message with mandatory AVPs defined in it with > > associated behavior. All ASR does is "kill the session". So, the > > why not stick on the original rules when RFC3588 was defined? > > Base common messages such as ASR and RAR MUST use app id 0 unless > > augmented with mandatory AVPs that define a specific behavior of > > the client (e.g. DCC application). > > > > hope this helps, > > victor > > > > > > > > Regards > > > Marco > > > > > > -----Original Message----- > > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > > Sent: marted=EC 18 luglio 2006 16.53 > > > To: STURA, Marco, VF-IT > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > Hi Marco, > > > > > > The main reason (and people can correct me if i'm wrong) is that = these > > > messages belong to the session/application using them and it is > > > better/easier to co-relate these messages to the said > > application. Since > > > the base protocol really defines two sets of messages, one set is = for > > > session/application usage and another for peer connectivity, > it is also > > > semantically correct for the the session message to carry the > app id of > > > the session. > > > > > > In addition, for implementations, it is more practical to look at = the > > > app id in the header to determine the application that a > > message belongs > > > to ... and rightfully so. In my opinion, ASR belongs to this = category > > > even if it is server directed. It maybe a little bit confusing for > > > relays with cannot resolve a route via destination-host to look at = an > > > ASR with an app id of 0. > > > > > > hope this helps, > > > victor > > > > > >> Hi Victor, > > >> > > >> > > >> > > >>> This topic is issue #2&5 and refers to what app id > > >>> should "application session level" messages defined in the base > > >>> > > >>> > > >> protocol > > >> > > >> > > >>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > > consensus in the > > >>> meeting and more likely in this list as well is that it MUST > > carry the > > >>> app id of the application using it. > > >>> > > >>> > > >> Could you bring some light on the reasons behind this consensus? = I > > >> thought the discussion in the old AAA list was toward a consensus = on > > >> using Appl ID 0 at least for the ASR/ASA Diameter common = messages. > > >> > > >> Regards > > >> Marco > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 Jul 19 09:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CD4-0005Vt-RZ; Wed, 19 Jul 2006 09:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CD3-0005Vo-K9 for dime@ietf.org; Wed, 19 Jul 2006 09:35:29 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CD2-0002co-8e for dime@ietf.org; Wed, 19 Jul 2006 09:35:29 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 5622F46B3B for ; Wed, 19 Jul 2006 09:35:23 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JDZQBC009775 for ; Wed, 19 Jul 2006 09:35:26 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 09:11:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 [... resending...] Pasi, OTOH we also have the following text from RFC3588: 3. Diameter Header Application-ID The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. If one is building a diameter base stack following RFC3588, this sentence probably would make them think that all messages intended for a specific application will use applications identifier in App-Id filed of the message header. Thanks, Tolga > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Wednesday, July 19, 2006 5:39 AM > To: vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Victor Fajardo wrote: > > I'm still not sure why we 'MUST' use app id of 0 ? > > In the case of RFC 4005 and 4072: because the spec says so? > > RFC 4005, Section 1.3: "All other messages are defined by [BASE] and > use the Base application id value." > > RFC 4072, Section 3, last paragraph: "the others > [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." > > This should not lead to interoperability problems unless the > implementors can't read the specs. And in that case, producing more > specs is unlikely to be of help. > > > > > Unless I have the wrong take on this issue, there is a consensus > > that we should just use the app id of the application for simplicity > > and correctness. > > The last time this was discussed, there was consensus that using 0 is > the right answer, and this lead to adding the above-quoted text to RFC > 4005 and 4072. > > So unless the approach in 4005/4072 leads to significant problems, > even when correctly implemented, I'd suggest not changing it. > Changing it could also lead to interoperability problems with > those implementations that correctly implement 4005/4072. > > Best regards, > Pasi > > _______________________________________________ > 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 Jul 19 09:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CNU-0007o0-Oh; Wed, 19 Jul 2006 09:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CNT-0007lu-CD for dime@ietf.org; Wed, 19 Jul 2006 09:46:15 -0400 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 1G3CNS-0002zA-MA for dime@ietf.org; Wed, 19 Jul 2006 09:46:15 -0400 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 k6JDjdfa070223; Wed, 19 Jul 2006 09:45:39 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE3784.9060106@tari.toshiba.com> Date: Wed, 19 Jul 2006 09:45:40 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133B4@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133B4@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k6JDjdfa070223 X-Spam-Score: -2.4 (--) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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 Marco, >> I don't see this as a drastic paradigm shift. Actually the reason for = this >> thread is that the text in RFC3588 can be interpreted in different way= s, so >> whether there is a shift or not depends of ones understanding of the >= current >> specifications -where obviously people have different interpretations-. >> =20 > > I still don't see how there could be different interpretations of imple= menters of standard applications given the clear text written there, as p= ointed out by Pasi too (see below). > =20 These text applies to 4005 and 4072 as they reference the base ....=20 there are other diameter implementations beyond this. my two cents, victor > =20 >> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and u= se >the Base application id value." >> =20 > > =20 >> RFC 4072, Section 3, last paragraph: "the others [RAR,RAA,STR,STA,ASR,= ASA] >use 0 (Diameter Common Messages)." >> =20 > > =20 >> This should not lead to interoperability problems unless the implement= ors >can't read the specs. And in that case, producing more specs is unli= kely to >be of help. >> =20 > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: mercoled=EC 19 luglio 2006 14.04 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > Marco, > > I understand your point. OTOH, to me it sounds strange to leave decisio= ns > related with session life cycle to anything else than the application l= ogic, > because it usually is dependent on the type of application and the cont= ext > of the scenario. > > The way I see it is as follows: > a) We have hop-to-hop messages, to be consumed by base diameter. > b) We have messages defined by base protocol, which are related with se= ssion > life-cycle, are generic in nature -hence defined in base diameter rathe= r > than replicated in every new application specification-, and are consum= ed by > application. > c) Messages which are defined by applications. > > I don't see this as a drastic paradigm shift. Actually the reason for t= his > thread is that the text in RFC3588 can be interpreted in different ways= , so > whether there is a shift or not depends of ones understanding of the cu= rrent > specifications -where obviously people have different interpretations-. > > Thanks, > Tolga > =20 >> -----Original Message----- >> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >> Sent: Wednesday, July 19, 2006 4:05 AM >> To: Tolga Asveren; Victor Fajardo >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> >> Tolga, >> >> Diameter was defined as a framework with a set of base common >> messages and procedures on top of which we could build additional >> service specific application logic. This additional service >> specific application logic is supposed to use 'utilities' from >> the base framework such as transport and routing, session >> handling, capability negotiation and common messages handling. >> >> What you're saying is changing the paradigm and philosophy of the >> base framework; essentially you're saying that we don't have >> common messages and common mechanisms anymore. All what RFC 3588 >> defines as session based common messages according to your >> comments is shifted to the service specific application, hence >> jeopardizing the entire framework. To me your proposal calls for >> re-building the same handling for those common messages in each >> of the service specific applications rather than applications >> re-using the common handling offered by the base framework. Not a >> good idea IMHO. >> >> Regards >> Marco >> >> -----Original Message----- >> From: Tolga Asveren [mailto:asveren@ulticom.com] >> Sent: marted=EC 18 luglio 2006 18.17 >> To: STURA, Marco, VF-IT; Victor Fajardo >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> Marco, >> >> I think, the reason for different point of views is mainly due to the >> question who is considered as the owner of a session. IMHO, session is >> better owned by the application logic, because only it has full knowle= dge >> about when a session is supposed to end, hence I believe it is >> best that any >> session/application logic related message is handled by the >> application. For >> that reason, I think it is a good idea to use the App-Id of the >> application >> in message header for the messages under discussion. >> >> Thanks, >> Tolga >> >> =20 >>> -----Original Message----- >>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >>> Sent: Tuesday, July 18, 2006 12:33 PM >>> To: Victor Fajardo >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> >>> See in line. >>> >>> Br >>> Marco >>> >>> -----Original Message----- >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>> Sent: marted=EC 18 luglio 2006 18.10 >>> To: STURA, Marco, VF-IT >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>> >>> Hi Marco, >>> >>> comments inline: >>> =20 >>>>> It maybe a little bit confusing for relays with cannot resolve >>>>> =20 >>> a route via >destination-host to look at an ASR with an app id of 0. >>> =20 >>>> Interesting argument I have to say. Routing ASR based on app id >>>> =20 >>> doesn't ensure that the session ASR is supposed to kill is >>> actually running on the client where the request is routed to. >>> Suppose a relay agent connected to 10 clients all of which >>> support app id x, the relay routes based on app id x to client 2 >>> but the session indicated in the is actually running >>> in client 5. The ASR will not kill the session as requested by >>> the server, therefore ASR MUST use Destination-Host based routing. >>> =20 >>> I agree with your example above regarding destination-host. It is >>> required in the case of ASR (and perhaps some other message) though I >>> guess I was stating a case which is a little bit different than your >>> example above. I was thinking of the following case: >>> >>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >>> >>> in this case relay2 will not be able to route using dest-host. This i= s >>> where dest-realm and app id becomes important. In this case app id of= 0 >>> might not work as well ... or maybe I'm wrong. >>> >>> [MSt] In this case R1 would advertise it self as a relay (i.e. >>> 0xffffffff) it won't advertise app id x or y or z. So, any app id >>> would be routed to R1 by R2. >>> >>> =20 >>>> Same argument stands for RAR. >>>> >>>> In fact the base defines ASR and RAR with Destination-Host AVP >>>> =20 >>> as mandatory in the ABNF of the message. >>> =20 >>>> I think in the AAA thread also available in the issue tracker >>>> =20 >>> there were arguments why ASR is really a common message, same >>> would be for RAR if no mandatory AVPs are defined by the application. >>> =20 >>> I've read through some of the comments in the AAA thread regarding th= is >>> issue and it was not clear to me why an app id of 0 is applicable to = ASR >>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is se= t >>> to 4 (CC app id). >>> >>> [MSt] Because the ASR or RAR requests a specific action to the >>> client that is to be inferred to the session indicated in the >>> . Diameter CC sets the app id 4 in RAR because it >>> augments the base message with mandatory AVPs defined in it with >>> associated behavior. All ASR does is "kill the session". So, the >>> why not stick on the original rules when RFC3588 was defined? >>> Base common messages such as ASR and RAR MUST use app id 0 unless >>> augmented with mandatory AVPs that define a specific behavior of >>> the client (e.g. DCC application). >>> >>> hope this helps, >>> victor >>> >>> =20 >>>> Regards >>>> Marco >>>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: marted=EC 18 luglio 2006 16.53 >>>> To: STURA, Marco, VF-IT >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>>> >>>> Hi Marco, >>>> >>>> The main reason (and people can correct me if i'm wrong) is that the= se >>>> messages belong to the session/application using them and it is >>>> better/easier to co-relate these messages to the said >>>> =20 >>> application. Since >>> =20 >>>> the base protocol really defines two sets of messages, one set is fo= r >>>> session/application usage and another for peer connectivity, >>>> =20 >> it is also >> =20 >>>> semantically correct for the the session message to carry the >>>> =20 >> app id of >> =20 >>>> the session. >>>> >>>> In addition, for implementations, it is more practical to look at th= e >>>> app id in the header to determine the application that a >>>> =20 >>> message belongs >>> =20 >>>> to ... and rightfully so. In my opinion, ASR belongs to this categor= y >>>> even if it is server directed. It maybe a little bit confusing for >>>> relays with cannot resolve a route via destination-host to look at a= n >>>> ASR with an app id of 0. >>>> >>>> hope this helps, >>>> victor >>>> >>>> =20 >>>>> Hi Victor, >>>>> >>>>> >>>>> >>>>> =20 >>>>>> This topic is issue #2&5 and refers to what app id >>>>>> should "application session level" messages defined in the base >>>>>> >>>>>> >>>>>> =20 >>>>> protocol >>>>> >>>>> >>>>> =20 >>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current >>>>>> =20 >>> consensus in the >>> =20 >>>>>> meeting and more likely in this list as well is that it MUST >>>>>> =20 >>> carry the >>> =20 >>>>>> app id of the application using it. >>>>>> >>>>>> >>>>>> =20 >>>>> Could you bring some light on the reasons behind this consensus? I >>>>> thought the discussion in the old AAA list was toward a consensus o= n >>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >>>>> >>>>> Regards >>>>> Marco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> =20 >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> =20 >> =20 > > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 09:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CUO-0006H0-KQ; Wed, 19 Jul 2006 09:53:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CUN-0006Gv-PA for dime@ietf.org; Wed, 19 Jul 2006 09:53:23 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CUN-0003Yh-2h for dime@ietf.org; Wed, 19 Jul 2006 09:53:23 -0400 Received: from omini95.omnitel.it (omini95.omnitel.it [10.21.18.147]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6JDrLps011853 for ; Wed, 19 Jul 2006 15:53:22 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 15:53:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 15:53:19 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133B5@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarObhoCzOcDUvcR6ylElTT3xLRuQAAEdAA From: "STURA, Marco, VF-IT" To: "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 13:53:20.0253 (UTC) FILETIME=[B196A2D0:01C6AB3A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 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, >These text applies to 4005 and 4072 as they reference the base ....=20 >there are other diameter implementations beyond this. Unless you are talking of some proprietary application I think what we = have to date are, in addition to 4005 and 4072, RFC 4004 and RFC 4006. RFC 4004 section 4 The value of zero (0) SHOULD be used as the Application-Id in all STR/STA and ASR/ASA commands, as these are defined in the Diameter base protocol and no additional mandatory AVPs for those commands are defined in this document. Given the nature of Mobile IPv4, re-authentication can only be initiated by a mobile node, which does not participate in the Diameter message exchanges. Therefore, Diameter server initiated re-auth does not apply to this application, and RAR/RAA commands MUST NOT be sent for Diameter Mobile IPv4 sessions. RFC 4006 I think was extensively discussed in the list. So, what is beyond that? Please explain. If you now write a text in RFC 3588bis as the one I proposed (below) I = don't see any issue beyond those standard applications that already use = app id 0 (as defined in RFCs). " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter Common = Messages) unless a service specific application augments those messages = with mandatory AVPs ('M' bit set) that define application specific = behavior (one example can be found in RFC 4006 for the RAR message)." Regards Marco -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: mercoled=EC 19 luglio 2006 15.46 To: STURA, Marco, VF-IT Cc: dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status Hi Marco, >> I don't see this as a drastic paradigm shift. Actually the reason for = this >> thread is that the text in RFC3588 can be interpreted in different = ways, so >> whether there is a shift or not depends of ones understanding of the = >current >> specifications -where obviously people have different = interpretations-. >> =20 > > I still don't see how there could be different interpretations of = implementers of standard applications given the clear text written = there, as pointed out by Pasi too (see below). > =20 These text applies to 4005 and 4072 as they reference the base ....=20 there are other diameter implementations beyond this. my two cents, victor > =20 >> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and = use >the Base application id value." >> =20 > > =20 >> RFC 4072, Section 3, last paragraph: "the others = [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)." >> =20 > > =20 >> This should not lead to interoperability problems unless the = implementors >can't read the specs. And in that case, producing more = specs is unlikely to >be of help. >> =20 > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: mercoled=EC 19 luglio 2006 14.04 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > Marco, > > I understand your point. OTOH, to me it sounds strange to leave = decisions > related with session life cycle to anything else than the application = logic, > because it usually is dependent on the type of application and the = context > of the scenario. > > The way I see it is as follows: > a) We have hop-to-hop messages, to be consumed by base diameter. > b) We have messages defined by base protocol, which are related with = session > life-cycle, are generic in nature -hence defined in base diameter = rather > than replicated in every new application specification-, and are = consumed by > application. > c) Messages which are defined by applications. > > I don't see this as a drastic paradigm shift. Actually the reason for = this > thread is that the text in RFC3588 can be interpreted in different = ways, so > whether there is a shift or not depends of ones understanding of the = current > specifications -where obviously people have different = interpretations-. > > Thanks, > Tolga > =20 >> -----Original Message----- >> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >> Sent: Wednesday, July 19, 2006 4:05 AM >> To: Tolga Asveren; Victor Fajardo >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> >> Tolga, >> >> Diameter was defined as a framework with a set of base common >> messages and procedures on top of which we could build additional >> service specific application logic. This additional service >> specific application logic is supposed to use 'utilities' from >> the base framework such as transport and routing, session >> handling, capability negotiation and common messages handling. >> >> What you're saying is changing the paradigm and philosophy of the >> base framework; essentially you're saying that we don't have >> common messages and common mechanisms anymore. All what RFC 3588 >> defines as session based common messages according to your >> comments is shifted to the service specific application, hence >> jeopardizing the entire framework. To me your proposal calls for >> re-building the same handling for those common messages in each >> of the service specific applications rather than applications >> re-using the common handling offered by the base framework. Not a >> good idea IMHO. >> >> Regards >> Marco >> >> -----Original Message----- >> From: Tolga Asveren [mailto:asveren@ulticom.com] >> Sent: marted=EC 18 luglio 2006 18.17 >> To: STURA, Marco, VF-IT; Victor Fajardo >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> Marco, >> >> I think, the reason for different point of views is mainly due to the >> question who is considered as the owner of a session. IMHO, session = is >> better owned by the application logic, because only it has full = knowledge >> about when a session is supposed to end, hence I believe it is >> best that any >> session/application logic related message is handled by the >> application. For >> that reason, I think it is a good idea to use the App-Id of the >> application >> in message header for the messages under discussion. >> >> Thanks, >> Tolga >> >> =20 >>> -----Original Message----- >>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >>> Sent: Tuesday, July 18, 2006 12:33 PM >>> To: Victor Fajardo >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> >>> See in line. >>> >>> Br >>> Marco >>> >>> -----Original Message----- >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>> Sent: marted=EC 18 luglio 2006 18.10 >>> To: STURA, Marco, VF-IT >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>> >>> Hi Marco, >>> >>> comments inline: >>> =20 >>>>> It maybe a little bit confusing for relays with cannot resolve >>>>> =20 >>> a route via >destination-host to look at an ASR with an app id of 0. >>> =20 >>>> Interesting argument I have to say. Routing ASR based on app id >>>> =20 >>> doesn't ensure that the session ASR is supposed to kill is >>> actually running on the client where the request is routed to. >>> Suppose a relay agent connected to 10 clients all of which >>> support app id x, the relay routes based on app id x to client 2 >>> but the session indicated in the is actually running >>> in client 5. The ASR will not kill the session as requested by >>> the server, therefore ASR MUST use Destination-Host based routing. >>> =20 >>> I agree with your example above regarding destination-host. It is >>> required in the case of ASR (and perhaps some other message) though = I >>> guess I was stating a case which is a little bit different than your >>> example above. I was thinking of the following case: >>> >>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >>> >>> in this case relay2 will not be able to route using dest-host. This = is >>> where dest-realm and app id becomes important. In this case app id = of 0 >>> might not work as well ... or maybe I'm wrong. >>> >>> [MSt] In this case R1 would advertise it self as a relay (i.e. >>> 0xffffffff) it won't advertise app id x or y or z. So, any app id >>> would be routed to R1 by R2. >>> >>> =20 >>>> Same argument stands for RAR. >>>> >>>> In fact the base defines ASR and RAR with Destination-Host AVP >>>> =20 >>> as mandatory in the ABNF of the message. >>> =20 >>>> I think in the AAA thread also available in the issue tracker >>>> =20 >>> there were arguments why ASR is really a common message, same >>> would be for RAR if no mandatory AVPs are defined by the = application. >>> =20 >>> I've read through some of the comments in the AAA thread regarding = this >>> issue and it was not clear to me why an app id of 0 is applicable to = ASR >>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is = set >>> to 4 (CC app id). >>> >>> [MSt] Because the ASR or RAR requests a specific action to the >>> client that is to be inferred to the session indicated in the >>> . Diameter CC sets the app id 4 in RAR because it >>> augments the base message with mandatory AVPs defined in it with >>> associated behavior. All ASR does is "kill the session". So, the >>> why not stick on the original rules when RFC3588 was defined? >>> Base common messages such as ASR and RAR MUST use app id 0 unless >>> augmented with mandatory AVPs that define a specific behavior of >>> the client (e.g. DCC application). >>> >>> hope this helps, >>> victor >>> >>> =20 >>>> Regards >>>> Marco >>>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: marted=EC 18 luglio 2006 16.53 >>>> To: STURA, Marco, VF-IT >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>>> >>>> Hi Marco, >>>> >>>> The main reason (and people can correct me if i'm wrong) is that = these >>>> messages belong to the session/application using them and it is >>>> better/easier to co-relate these messages to the said >>>> =20 >>> application. Since >>> =20 >>>> the base protocol really defines two sets of messages, one set is = for >>>> session/application usage and another for peer connectivity, >>>> =20 >> it is also >> =20 >>>> semantically correct for the the session message to carry the >>>> =20 >> app id of >> =20 >>>> the session. >>>> >>>> In addition, for implementations, it is more practical to look at = the >>>> app id in the header to determine the application that a >>>> =20 >>> message belongs >>> =20 >>>> to ... and rightfully so. In my opinion, ASR belongs to this = category >>>> even if it is server directed. It maybe a little bit confusing for >>>> relays with cannot resolve a route via destination-host to look at = an >>>> ASR with an app id of 0. >>>> >>>> hope this helps, >>>> victor >>>> >>>> =20 >>>>> Hi Victor, >>>>> >>>>> >>>>> >>>>> =20 >>>>>> This topic is issue #2&5 and refers to what app id >>>>>> should "application session level" messages defined in the base >>>>>> >>>>>> >>>>>> =20 >>>>> protocol >>>>> >>>>> >>>>> =20 >>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current >>>>>> =20 >>> consensus in the >>> =20 >>>>>> meeting and more likely in this list as well is that it MUST >>>>>> =20 >>> carry the >>> =20 >>>>>> app id of the application using it. >>>>>> >>>>>> >>>>>> =20 >>>>> Could you bring some light on the reasons behind this consensus? I >>>>> thought the discussion in the old AAA list was toward a consensus = on >>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >>>>> >>>>> Regards >>>>> Marco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =20 >>>> >>>> >>>> >>>> >>>> >>>> =20 >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> =20 >> =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 Jul 19 10:17:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Crs-00017T-KY; Wed, 19 Jul 2006 10:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Crq-00017N-KL for dime@ietf.org; Wed, 19 Jul 2006 10:17:38 -0400 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 1G3Crp-0005Il-V3 for dime@ietf.org; Wed, 19 Jul 2006 10:17:38 -0400 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 k6JEH1eL070396; Wed, 19 Jul 2006 10:17:01 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE3EDD.6050405@tari.toshiba.com> Date: Wed, 19 Jul 2006 10:17:01 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133B5@OIVMEXO01.omnitel.it> In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133B5@OIVMEXO01.omnitel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k6JEH1eL070396 X-Spam-Score: -2.4 (--) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f 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 Marco, > If you now write a text in RFC 3588bis as the one I proposed (below) I = don't see any issue beyond those standard applications that already use a= pp id 0 (as defined in RFCs). > > " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter Common Mess= ages) unless a service specific application augments those messages with = mandatory AVPs ('M' bit set) that define application specific behavior (o= ne example can be found in RFC 4006 for the RAR message)." > =20 I appreciate the discussion and the proposed text. Seeing as how there=20 are contending opinions that will never coalesce I think I will leave it=20 up to the chairs to arbitrate on the matter. I would not want to decide=20 immediately on what text should be added to 3588bis. my two cents, victor > Regards > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: mercoled=EC 19 luglio 2006 15.46 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > =20 >>> I don't see this as a drastic paradigm shift. Actually the reason for= this >>> thread is that the text in RFC3588 can be interpreted in different wa= ys, so >>> whether there is a shift or not depends of ones understanding of the = >current >>> specifications -where obviously people have different interpretations= -. >>> =20 >>> =20 >> I still don't see how there could be different interpretations of impl= ementers of standard applications given the clear text written there, as = pointed out by Pasi too (see below). >> =20 >> =20 > > > These text applies to 4005 and 4072 as they reference the base ....=20 > there are other diameter implementations beyond this. > > my two cents, > victor > > > > =20 >> =20 >> =20 >>> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and = use >the Base application id value." >>> =20 >>> =20 >> =20 >> =20 >>> RFC 4072, Section 3, last paragraph: "the others [RAR,RAA,STR,STA,ASR= ,ASA] >use 0 (Diameter Common Messages)." >>> =20 >>> =20 >> =20 >> =20 >>> This should not lead to interoperability problems unless the implemen= tors >can't read the specs. And in that case, producing more specs is unl= ikely to >be of help. >>> =20 >>> =20 >> -----Original Message----- >> From: Tolga Asveren [mailto:asveren@ulticom.com]=20 >> Sent: mercoled=EC 19 luglio 2006 14.04 >> To: STURA, Marco, VF-IT; Victor Fajardo >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> Marco, >> >> I understand your point. OTOH, to me it sounds strange to leave decisi= ons >> related with session life cycle to anything else than the application = logic, >> because it usually is dependent on the type of application and the con= text >> of the scenario. >> >> The way I see it is as follows: >> a) We have hop-to-hop messages, to be consumed by base diameter. >> b) We have messages defined by base protocol, which are related with s= ession >> life-cycle, are generic in nature -hence defined in base diameter rath= er >> than replicated in every new application specification-, and are consu= med by >> application. >> c) Messages which are defined by applications. >> >> I don't see this as a drastic paradigm shift. Actually the reason for = this >> thread is that the text in RFC3588 can be interpreted in different way= s, so >> whether there is a shift or not depends of ones understanding of the c= urrent >> specifications -where obviously people have different interpretations-. >> >> Thanks, >> Tolga >> =20 >> =20 >>> -----Original Message----- >>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >>> Sent: Wednesday, July 19, 2006 4:05 AM >>> To: Tolga Asveren; Victor Fajardo >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> >>> Tolga, >>> >>> Diameter was defined as a framework with a set of base common >>> messages and procedures on top of which we could build additional >>> service specific application logic. This additional service >>> specific application logic is supposed to use 'utilities' from >>> the base framework such as transport and routing, session >>> handling, capability negotiation and common messages handling. >>> >>> What you're saying is changing the paradigm and philosophy of the >>> base framework; essentially you're saying that we don't have >>> common messages and common mechanisms anymore. All what RFC 3588 >>> defines as session based common messages according to your >>> comments is shifted to the service specific application, hence >>> jeopardizing the entire framework. To me your proposal calls for >>> re-building the same handling for those common messages in each >>> of the service specific applications rather than applications >>> re-using the common handling offered by the base framework. Not a >>> good idea IMHO. >>> >>> Regards >>> Marco >>> >>> -----Original Message----- >>> From: Tolga Asveren [mailto:asveren@ulticom.com] >>> Sent: marted=EC 18 luglio 2006 18.17 >>> To: STURA, Marco, VF-IT; Victor Fajardo >>> Cc: dime@ietf.org >>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>> >>> Marco, >>> >>> I think, the reason for different point of views is mainly due to the >>> question who is considered as the owner of a session. IMHO, session i= s >>> better owned by the application logic, because only it has full knowl= edge >>> about when a session is supposed to end, hence I believe it is >>> best that any >>> session/application logic related message is handled by the >>> application. For >>> that reason, I think it is a good idea to use the App-Id of the >>> application >>> in message header for the messages under discussion. >>> >>> Thanks, >>> Tolga >>> >>> =20 >>> =20 >>>> -----Original Message----- >>>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] >>>> Sent: Tuesday, July 18, 2006 12:33 PM >>>> To: Victor Fajardo >>>> Cc: dime@ietf.org >>>> Subject: RE: [Dime] Summary of 3588bis Issues Status >>>> >>>> >>>> See in line. >>>> >>>> Br >>>> Marco >>>> >>>> -----Original Message----- >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>> Sent: marted=EC 18 luglio 2006 18.10 >>>> To: STURA, Marco, VF-IT >>>> Cc: dime@ietf.org >>>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>>> >>>> Hi Marco, >>>> >>>> comments inline: >>>> =20 >>>> =20 >>>>>> It maybe a little bit confusing for relays with cannot resolve >>>>>> =20 >>>>>> =20 >>>> a route via >destination-host to look at an ASR with an app id of 0. >>>> =20 >>>> =20 >>>>> Interesting argument I have to say. Routing ASR based on app id >>>>> =20 >>>>> =20 >>>> doesn't ensure that the session ASR is supposed to kill is >>>> actually running on the client where the request is routed to. >>>> Suppose a relay agent connected to 10 clients all of which >>>> support app id x, the relay routes based on app id x to client 2 >>>> but the session indicated in the is actually running >>>> in client 5. The ASR will not kill the session as requested by >>>> the server, therefore ASR MUST use Destination-Host based routing. >>>> =20 >>>> I agree with your example above regarding destination-host. It is >>>> required in the case of ASR (and perhaps some other message) though = I >>>> guess I was stating a case which is a little bit different than your >>>> example above. I was thinking of the following case: >>>> >>>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >>>> >>>> in this case relay2 will not be able to route using dest-host. This = is >>>> where dest-realm and app id becomes important. In this case app id o= f 0 >>>> might not work as well ... or maybe I'm wrong. >>>> >>>> [MSt] In this case R1 would advertise it self as a relay (i.e. >>>> 0xffffffff) it won't advertise app id x or y or z. So, any app id >>>> would be routed to R1 by R2. >>>> >>>> =20 >>>> =20 >>>>> Same argument stands for RAR. >>>>> >>>>> In fact the base defines ASR and RAR with Destination-Host AVP >>>>> =20 >>>>> =20 >>>> as mandatory in the ABNF of the message. >>>> =20 >>>> =20 >>>>> I think in the AAA thread also available in the issue tracker >>>>> =20 >>>>> =20 >>>> there were arguments why ASR is really a common message, same >>>> would be for RAR if no mandatory AVPs are defined by the application. >>>> =20 >>>> I've read through some of the comments in the AAA thread regarding t= his >>>> issue and it was not clear to me why an app id of 0 is applicable to= ASR >>>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is s= et >>>> to 4 (CC app id). >>>> >>>> [MSt] Because the ASR or RAR requests a specific action to the >>>> client that is to be inferred to the session indicated in the >>>> . Diameter CC sets the app id 4 in RAR because it >>>> augments the base message with mandatory AVPs defined in it with >>>> associated behavior. All ASR does is "kill the session". So, the >>>> why not stick on the original rules when RFC3588 was defined? >>>> Base common messages such as ASR and RAR MUST use app id 0 unless >>>> augmented with mandatory AVPs that define a specific behavior of >>>> the client (e.g. DCC application). >>>> >>>> hope this helps, >>>> victor >>>> >>>> =20 >>>> =20 >>>>> Regards >>>>> Marco >>>>> >>>>> -----Original Message----- >>>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>>>> Sent: marted=EC 18 luglio 2006 16.53 >>>>> To: STURA, Marco, VF-IT >>>>> Cc: dime@ietf.org >>>>> Subject: Re: [Dime] Summary of 3588bis Issues Status >>>>> >>>>> Hi Marco, >>>>> >>>>> The main reason (and people can correct me if i'm wrong) is that th= ese >>>>> messages belong to the session/application using them and it is >>>>> better/easier to co-relate these messages to the said >>>>> =20 >>>>> =20 >>>> application. Since >>>> =20 >>>> =20 >>>>> the base protocol really defines two sets of messages, one set is f= or >>>>> session/application usage and another for peer connectivity, >>>>> =20 >>>>> =20 >>> it is also >>> =20 >>> =20 >>>>> semantically correct for the the session message to carry the >>>>> =20 >>>>> =20 >>> app id of >>> =20 >>> =20 >>>>> the session. >>>>> >>>>> In addition, for implementations, it is more practical to look at t= he >>>>> app id in the header to determine the application that a >>>>> =20 >>>>> =20 >>>> message belongs >>>> =20 >>>> =20 >>>>> to ... and rightfully so. In my opinion, ASR belongs to this catego= ry >>>>> even if it is server directed. It maybe a little bit confusing for >>>>> relays with cannot resolve a route via destination-host to look at = an >>>>> ASR with an app id of 0. >>>>> >>>>> hope this helps, >>>>> victor >>>>> >>>>> =20 >>>>> =20 >>>>>> Hi Victor, >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>> This topic is issue #2&5 and refers to what app id >>>>>>> should "application session level" messages defined in the base >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>> protocol >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current >>>>>>> =20 >>>>>>> =20 >>>> consensus in the >>>> =20 >>>> =20 >>>>>>> meeting and more likely in this list as well is that it MUST >>>>>>> =20 >>>>>>> =20 >>>> carry the >>>> =20 >>>> =20 >>>>>>> app id of the application using it. >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>> Could you bring some light on the reasons behind this consensus? I >>>>>> thought the discussion in the old AAA list was toward a consensus = on >>>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. >>>>>> >>>>>> Regards >>>>>> Marco >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>> >>>>> >>>>> >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> =20 >>>> =20 >>> =20 >>> =20 >> >> >> >> =20 >> =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 Wed Jul 19 10:22:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CwB-0001T1-Uz; Wed, 19 Jul 2006 10:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3CwA-0001St-Rg for dime@ietf.org; Wed, 19 Jul 2006 10:22:06 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3CwA-0005np-5e for dime@ietf.org; Wed, 19 Jul 2006 10:22:06 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 66E480495D; Wed, 19 Jul 2006 10:22:01 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JEM2OC014528; Wed, 19 Jul 2006 10:22:03 -0400 (EDT) From: "Tolga Asveren" To: "STURA, Marco, VF-IT" , "Victor Fajardo" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 09:58:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133B5@OIVMEXO01.omnitel.it> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f 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 Marco, I believe the point is whether it is RFC3588 or the RFCs you quoted needs to be fixed. I am puzzled how those RFcs had such statements, which IMO clearly violate what is said about Application-ID in RFC3588 3. Diameter Header section. Another point is that considering existing few applications you mentioned is not really enough. There are also diameter base stack implementations, which conform to RFC3588 and provide generic capability for any type of application. (Just read now Victor just posted in terms of how to proceed in this issue and I agree with him. Probably the arguments are clear and somehow a decision needs to be made, so that everybody can interoperate) Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 9:53 AM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Victor, > > >These text applies to 4005 and 4072 as they reference the base .... > >there are other diameter implementations beyond this. > > Unless you are talking of some proprietary application I think > what we have to date are, in addition to 4005 and 4072, RFC 4004 > and RFC 4006. > > RFC 4004 section 4 > > The value of zero (0) SHOULD be used as the > Application-Id in all STR/STA and ASR/ASA commands, as these are > defined in the Diameter base protocol and no additional mandatory > AVPs for those commands are defined in this document. > > Given the nature of Mobile IPv4, re-authentication can only be > initiated by a mobile node, which does not participate in the > Diameter message exchanges. Therefore, Diameter server initiated > re-auth does not apply to this application, and RAR/RAA commands MUST > NOT be sent for Diameter Mobile IPv4 sessions. > > RFC 4006 I think was extensively discussed in the list. > > So, what is beyond that? Please explain. > > If you now write a text in RFC 3588bis as the one I proposed > (below) I don't see any issue beyond those standard applications > that already use app id 0 (as defined in RFCs). > > " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter > Common Messages) unless a service specific application augments > those messages with mandatory AVPs ('M' bit set) that define > application specific behavior (one example can be found in RFC > 4006 for the RAR message)." > > Regards > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: mercoledì 19 luglio 2006 15.46 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > >> I don't see this as a drastic paradigm shift. Actually the > reason for this > >> thread is that the text in RFC3588 can be interpreted in > different ways, so > >> whether there is a shift or not depends of ones understanding > of the >current > >> specifications -where obviously people have different interpretations-. > >> > > > > I still don't see how there could be different interpretations > of implementers of standard applications given the clear text > written there, as pointed out by Pasi too (see below). > > > > > These text applies to 4005 and 4072 as they reference the base .... > there are other diameter implementations beyond this. > > my two cents, > victor > > > > > > >> RFC 4005, Section 1.3: "All other messages are defined by > [BASE] and use >the Base application id value." > >> > > > > > >> RFC 4072, Section 3, last paragraph: "the others > [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)." > >> > > > > > >> This should not lead to interoperability problems unless the > implementors >can't read the specs. And in that case, producing > more specs is unlikely to >be of help. > >> > > > > -----Original Message----- > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > Sent: mercoledì 19 luglio 2006 14.04 > > To: STURA, Marco, VF-IT; Victor Fajardo > > Cc: dime@ietf.org > > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > > Marco, > > > > I understand your point. OTOH, to me it sounds strange to leave > decisions > > related with session life cycle to anything else than the > application logic, > > because it usually is dependent on the type of application and > the context > > of the scenario. > > > > The way I see it is as follows: > > a) We have hop-to-hop messages, to be consumed by base diameter. > > b) We have messages defined by base protocol, which are related > with session > > life-cycle, are generic in nature -hence defined in base diameter rather > > than replicated in every new application specification-, and > are consumed by > > application. > > c) Messages which are defined by applications. > > > > I don't see this as a drastic paradigm shift. Actually the > reason for this > > thread is that the text in RFC3588 can be interpreted in > different ways, so > > whether there is a shift or not depends of ones understanding > of the current > > specifications -where obviously people have different interpretations-. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > >> Sent: Wednesday, July 19, 2006 4:05 AM > >> To: Tolga Asveren; Victor Fajardo > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> > >> Tolga, > >> > >> Diameter was defined as a framework with a set of base common > >> messages and procedures on top of which we could build additional > >> service specific application logic. This additional service > >> specific application logic is supposed to use 'utilities' from > >> the base framework such as transport and routing, session > >> handling, capability negotiation and common messages handling. > >> > >> What you're saying is changing the paradigm and philosophy of the > >> base framework; essentially you're saying that we don't have > >> common messages and common mechanisms anymore. All what RFC 3588 > >> defines as session based common messages according to your > >> comments is shifted to the service specific application, hence > >> jeopardizing the entire framework. To me your proposal calls for > >> re-building the same handling for those common messages in each > >> of the service specific applications rather than applications > >> re-using the common handling offered by the base framework. Not a > >> good idea IMHO. > >> > >> Regards > >> Marco > >> > >> -----Original Message----- > >> From: Tolga Asveren [mailto:asveren@ulticom.com] > >> Sent: martedì 18 luglio 2006 18.17 > >> To: STURA, Marco, VF-IT; Victor Fajardo > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> Marco, > >> > >> I think, the reason for different point of views is mainly due to the > >> question who is considered as the owner of a session. IMHO, session is > >> better owned by the application logic, because only it has > full knowledge > >> about when a session is supposed to end, hence I believe it is > >> best that any > >> session/application logic related message is handled by the > >> application. For > >> that reason, I think it is a good idea to use the App-Id of the > >> application > >> in message header for the messages under discussion. > >> > >> Thanks, > >> Tolga > >> > >> > >>> -----Original Message----- > >>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > >>> Sent: Tuesday, July 18, 2006 12:33 PM > >>> To: Victor Fajardo > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> > >>> See in line. > >>> > >>> Br > >>> Marco > >>> > >>> -----Original Message----- > >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>> Sent: martedì 18 luglio 2006 18.10 > >>> To: STURA, Marco, VF-IT > >>> Cc: dime@ietf.org > >>> Subject: Re: [Dime] Summary of 3588bis Issues Status > >>> > >>> Hi Marco, > >>> > >>> comments inline: > >>> > >>>>> It maybe a little bit confusing for relays with cannot resolve > >>>>> > >>> a route via >destination-host to look at an ASR with an app id of 0. > >>> > >>>> Interesting argument I have to say. Routing ASR based on app id > >>>> > >>> doesn't ensure that the session ASR is supposed to kill is > >>> actually running on the client where the request is routed to. > >>> Suppose a relay agent connected to 10 clients all of which > >>> support app id x, the relay routes based on app id x to client 2 > >>> but the session indicated in the is actually running > >>> in client 5. The ASR will not kill the session as requested by > >>> the server, therefore ASR MUST use Destination-Host based routing. > >>> > >>> I agree with your example above regarding destination-host. It is > >>> required in the case of ASR (and perhaps some other message) though I > >>> guess I was stating a case which is a little bit different than your > >>> example above. I was thinking of the following case: > >>> > >>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > >>> > >>> in this case relay2 will not be able to route using dest-host. This is > >>> where dest-realm and app id becomes important. In this case > app id of 0 > >>> might not work as well ... or maybe I'm wrong. > >>> > >>> [MSt] In this case R1 would advertise it self as a relay (i.e. > >>> 0xffffffff) it won't advertise app id x or y or z. So, any app id > >>> would be routed to R1 by R2. > >>> > >>> > >>>> Same argument stands for RAR. > >>>> > >>>> In fact the base defines ASR and RAR with Destination-Host AVP > >>>> > >>> as mandatory in the ABNF of the message. > >>> > >>>> I think in the AAA thread also available in the issue tracker > >>>> > >>> there were arguments why ASR is really a common message, same > >>> would be for RAR if no mandatory AVPs are defined by the application. > >>> > >>> I've read through some of the comments in the AAA thread > regarding this > >>> issue and it was not clear to me why an app id of 0 is > applicable to ASR > >>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set > >>> to 4 (CC app id). > >>> > >>> [MSt] Because the ASR or RAR requests a specific action to the > >>> client that is to be inferred to the session indicated in the > >>> . Diameter CC sets the app id 4 in RAR because it > >>> augments the base message with mandatory AVPs defined in it with > >>> associated behavior. All ASR does is "kill the session". So, the > >>> why not stick on the original rules when RFC3588 was defined? > >>> Base common messages such as ASR and RAR MUST use app id 0 unless > >>> augmented with mandatory AVPs that define a specific behavior of > >>> the client (e.g. DCC application). > >>> > >>> hope this helps, > >>> victor > >>> > >>> > >>>> Regards > >>>> Marco > >>>> > >>>> -----Original Message----- > >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>>> Sent: martedì 18 luglio 2006 16.53 > >>>> To: STURA, Marco, VF-IT > >>>> Cc: dime@ietf.org > >>>> Subject: Re: [Dime] Summary of 3588bis Issues Status > >>>> > >>>> Hi Marco, > >>>> > >>>> The main reason (and people can correct me if i'm wrong) is > that these > >>>> messages belong to the session/application using them and it is > >>>> better/easier to co-relate these messages to the said > >>>> > >>> application. Since > >>> > >>>> the base protocol really defines two sets of messages, one set is for > >>>> session/application usage and another for peer connectivity, > >>>> > >> it is also > >> > >>>> semantically correct for the the session message to carry the > >>>> > >> app id of > >> > >>>> the session. > >>>> > >>>> In addition, for implementations, it is more practical to look at the > >>>> app id in the header to determine the application that a > >>>> > >>> message belongs > >>> > >>>> to ... and rightfully so. In my opinion, ASR belongs to this category > >>>> even if it is server directed. It maybe a little bit confusing for > >>>> relays with cannot resolve a route via destination-host to look at an > >>>> ASR with an app id of 0. > >>>> > >>>> hope this helps, > >>>> victor > >>>> > >>>> > >>>>> Hi Victor, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> This topic is issue #2&5 and refers to what app id > >>>>>> should "application session level" messages defined in the base > >>>>>> > >>>>>> > >>>>>> > >>>>> protocol > >>>>> > >>>>> > >>>>> > >>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > >>>>>> > >>> consensus in the > >>> > >>>>>> meeting and more likely in this list as well is that it MUST > >>>>>> > >>> carry the > >>> > >>>>>> app id of the application using it. > >>>>>> > >>>>>> > >>>>>> > >>>>> Could you bring some light on the reasons behind this consensus? I > >>>>> thought the discussion in the old AAA list was toward a consensus on > >>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >>>>> > >>>>> Regards > >>>>> Marco > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> 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 Wed Jul 19 10:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DCd-0005Gz-Rp; Wed, 19 Jul 2006 10:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DCc-0005Gu-Nv for dime@ietf.org; Wed, 19 Jul 2006 10:39:06 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DCZ-0007Vh-Gu for dime@ietf.org; Wed, 19 Jul 2006 10:39:06 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F263F3D02A for ; Wed, 19 Jul 2006 10:38:56 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JEcx44016343 for ; Wed, 19 Jul 2006 10:39:00 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 10:15:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 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 [.. resending ..] Marco, I believe the point is whether it is RFC3588 or the RFCs you quoted needs to be fixed. I am puzzled how those RFcs had such statements, which IMO clearly violate what is said about Application-ID in RFC3588 3. Diameter Header section. Another point is that considering existing few applications you mentioned is not really enough. There are also diameter base stack implementations, which conform to RFC3588 and provide generic capability for any type of application. (Just read now what Victor just posted in terms of how to proceed in this issue and I agree with him. Probably the arguments are clear and somehow a decision needs to be made, so that everybody can interoperate) Thanks, Tolga > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > Sent: Wednesday, July 19, 2006 9:53 AM > To: Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Victor, > > >These text applies to 4005 and 4072 as they reference the base .... > >there are other diameter implementations beyond this. > > Unless you are talking of some proprietary application I think > what we have to date are, in addition to 4005 and 4072, RFC 4004 > and RFC 4006. > > RFC 4004 section 4 > > The value of zero (0) SHOULD be used as the > Application-Id in all STR/STA and ASR/ASA commands, as these are > defined in the Diameter base protocol and no additional mandatory > AVPs for those commands are defined in this document. > > Given the nature of Mobile IPv4, re-authentication can only be > initiated by a mobile node, which does not participate in the > Diameter message exchanges. Therefore, Diameter server initiated > re-auth does not apply to this application, and RAR/RAA commands MUST > NOT be sent for Diameter Mobile IPv4 sessions. > > RFC 4006 I think was extensively discussed in the list. > > So, what is beyond that? Please explain. > > If you now write a text in RFC 3588bis as the one I proposed > (below) I don't see any issue beyond those standard applications > that already use app id 0 (as defined in RFCs). > > " RAR,RAA,STR,STA,ASR,ASA use application id of 0 (Diameter > Common Messages) unless a service specific application augments > those messages with mandatory AVPs ('M' bit set) that define > application specific behavior (one example can be found in RFC > 4006 for the RAR message)." > > Regards > Marco > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: mercoledì 19 luglio 2006 15.46 > To: STURA, Marco, VF-IT > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Marco, > >> I don't see this as a drastic paradigm shift. Actually the > reason for this > >> thread is that the text in RFC3588 can be interpreted in > different ways, so > >> whether there is a shift or not depends of ones understanding > of the >current > >> specifications -where obviously people have different interpretations-. > >> > > > > I still don't see how there could be different interpretations > of implementers of standard applications given the clear text > written there, as pointed out by Pasi too (see below). > > > > > These text applies to 4005 and 4072 as they reference the base .... > there are other diameter implementations beyond this. > > my two cents, > victor > > > > > > >> RFC 4005, Section 1.3: "All other messages are defined by > [BASE] and use >the Base application id value." > >> > > > > > >> RFC 4072, Section 3, last paragraph: "the others > [RAR,RAA,STR,STA,ASR,ASA] >use 0 (Diameter Common Messages)." > >> > > > > > >> This should not lead to interoperability problems unless the > implementors >can't read the specs. And in that case, producing > more specs is unlikely to >be of help. > >> > > > > -----Original Message----- > > From: Tolga Asveren [mailto:asveren@ulticom.com] > > Sent: mercoledì 19 luglio 2006 14.04 > > To: STURA, Marco, VF-IT; Victor Fajardo > > Cc: dime@ietf.org > > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > > Marco, > > > > I understand your point. OTOH, to me it sounds strange to leave > decisions > > related with session life cycle to anything else than the > application logic, > > because it usually is dependent on the type of application and > the context > > of the scenario. > > > > The way I see it is as follows: > > a) We have hop-to-hop messages, to be consumed by base diameter. > > b) We have messages defined by base protocol, which are related > with session > > life-cycle, are generic in nature -hence defined in base diameter rather > > than replicated in every new application specification-, and > are consumed by > > application. > > c) Messages which are defined by applications. > > > > I don't see this as a drastic paradigm shift. Actually the > reason for this > > thread is that the text in RFC3588 can be interpreted in > different ways, so > > whether there is a shift or not depends of ones understanding > of the current > > specifications -where obviously people have different interpretations-. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > >> Sent: Wednesday, July 19, 2006 4:05 AM > >> To: Tolga Asveren; Victor Fajardo > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> > >> Tolga, > >> > >> Diameter was defined as a framework with a set of base common > >> messages and procedures on top of which we could build additional > >> service specific application logic. This additional service > >> specific application logic is supposed to use 'utilities' from > >> the base framework such as transport and routing, session > >> handling, capability negotiation and common messages handling. > >> > >> What you're saying is changing the paradigm and philosophy of the > >> base framework; essentially you're saying that we don't have > >> common messages and common mechanisms anymore. All what RFC 3588 > >> defines as session based common messages according to your > >> comments is shifted to the service specific application, hence > >> jeopardizing the entire framework. To me your proposal calls for > >> re-building the same handling for those common messages in each > >> of the service specific applications rather than applications > >> re-using the common handling offered by the base framework. Not a > >> good idea IMHO. > >> > >> Regards > >> Marco > >> > >> -----Original Message----- > >> From: Tolga Asveren [mailto:asveren@ulticom.com] > >> Sent: martedì 18 luglio 2006 18.17 > >> To: STURA, Marco, VF-IT; Victor Fajardo > >> Cc: dime@ietf.org > >> Subject: RE: [Dime] Summary of 3588bis Issues Status > >> > >> Marco, > >> > >> I think, the reason for different point of views is mainly due to the > >> question who is considered as the owner of a session. IMHO, session is > >> better owned by the application logic, because only it has > full knowledge > >> about when a session is supposed to end, hence I believe it is > >> best that any > >> session/application logic related message is handled by the > >> application. For > >> that reason, I think it is a good idea to use the App-Id of the > >> application > >> in message header for the messages under discussion. > >> > >> Thanks, > >> Tolga > >> > >> > >>> -----Original Message----- > >>> From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com] > >>> Sent: Tuesday, July 18, 2006 12:33 PM > >>> To: Victor Fajardo > >>> Cc: dime@ietf.org > >>> Subject: RE: [Dime] Summary of 3588bis Issues Status > >>> > >>> > >>> See in line. > >>> > >>> Br > >>> Marco > >>> > >>> -----Original Message----- > >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>> Sent: martedì 18 luglio 2006 18.10 > >>> To: STURA, Marco, VF-IT > >>> Cc: dime@ietf.org > >>> Subject: Re: [Dime] Summary of 3588bis Issues Status > >>> > >>> Hi Marco, > >>> > >>> comments inline: > >>> > >>>>> It maybe a little bit confusing for relays with cannot resolve > >>>>> > >>> a route via >destination-host to look at an ASR with an app id of 0. > >>> > >>>> Interesting argument I have to say. Routing ASR based on app id > >>>> > >>> doesn't ensure that the session ASR is supposed to kill is > >>> actually running on the client where the request is routed to. > >>> Suppose a relay agent connected to 10 clients all of which > >>> support app id x, the relay routes based on app id x to client 2 > >>> but the session indicated in the is actually running > >>> in client 5. The ASR will not kill the session as requested by > >>> the server, therefore ASR MUST use Destination-Host based routing. > >>> > >>> I agree with your example above regarding destination-host. It is > >>> required in the case of ASR (and perhaps some other message) though I > >>> guess I was stating a case which is a little bit different than your > >>> example above. I was thinking of the following case: > >>> > >>> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > >>> > >>> in this case relay2 will not be able to route using dest-host. This is > >>> where dest-realm and app id becomes important. In this case > app id of 0 > >>> might not work as well ... or maybe I'm wrong. > >>> > >>> [MSt] In this case R1 would advertise it self as a relay (i.e. > >>> 0xffffffff) it won't advertise app id x or y or z. So, any app id > >>> would be routed to R1 by R2. > >>> > >>> > >>>> Same argument stands for RAR. > >>>> > >>>> In fact the base defines ASR and RAR with Destination-Host AVP > >>>> > >>> as mandatory in the ABNF of the message. > >>> > >>>> I think in the AAA thread also available in the issue tracker > >>>> > >>> there were arguments why ASR is really a common message, same > >>> would be for RAR if no mandatory AVPs are defined by the application. > >>> > >>> I've read through some of the comments in the AAA thread > regarding this > >>> issue and it was not clear to me why an app id of 0 is > applicable to ASR > >>> and/or RAR. In fact, in diameter CC (rfc4006) the app id of RAR is set > >>> to 4 (CC app id). > >>> > >>> [MSt] Because the ASR or RAR requests a specific action to the > >>> client that is to be inferred to the session indicated in the > >>> . Diameter CC sets the app id 4 in RAR because it > >>> augments the base message with mandatory AVPs defined in it with > >>> associated behavior. All ASR does is "kill the session". So, the > >>> why not stick on the original rules when RFC3588 was defined? > >>> Base common messages such as ASR and RAR MUST use app id 0 unless > >>> augmented with mandatory AVPs that define a specific behavior of > >>> the client (e.g. DCC application). > >>> > >>> hope this helps, > >>> victor > >>> > >>> > >>>> Regards > >>>> Marco > >>>> > >>>> -----Original Message----- > >>>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >>>> Sent: martedì 18 luglio 2006 16.53 > >>>> To: STURA, Marco, VF-IT > >>>> Cc: dime@ietf.org > >>>> Subject: Re: [Dime] Summary of 3588bis Issues Status > >>>> > >>>> Hi Marco, > >>>> > >>>> The main reason (and people can correct me if i'm wrong) is > that these > >>>> messages belong to the session/application using them and it is > >>>> better/easier to co-relate these messages to the said > >>>> > >>> application. Since > >>> > >>>> the base protocol really defines two sets of messages, one set is for > >>>> session/application usage and another for peer connectivity, > >>>> > >> it is also > >> > >>>> semantically correct for the the session message to carry the > >>>> > >> app id of > >> > >>>> the session. > >>>> > >>>> In addition, for implementations, it is more practical to look at the > >>>> app id in the header to determine the application that a > >>>> > >>> message belongs > >>> > >>>> to ... and rightfully so. In my opinion, ASR belongs to this category > >>>> even if it is server directed. It maybe a little bit confusing for > >>>> relays with cannot resolve a route via destination-host to look at an > >>>> ASR with an app id of 0. > >>>> > >>>> hope this helps, > >>>> victor > >>>> > >>>> > >>>>> Hi Victor, > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> This topic is issue #2&5 and refers to what app id > >>>>>> should "application session level" messages defined in the base > >>>>>> > >>>>>> > >>>>>> > >>>>> protocol > >>>>> > >>>>> > >>>>> > >>>>>> (STR/STA, ASR/ASA, RAR/RAA, ACR/ACA) use. The current > >>>>>> > >>> consensus in the > >>> > >>>>>> meeting and more likely in this list as well is that it MUST > >>>>>> > >>> carry the > >>> > >>>>>> app id of the application using it. > >>>>>> > >>>>>> > >>>>>> > >>>>> Could you bring some light on the reasons behind this consensus? I > >>>>> thought the discussion in the old AAA list was toward a consensus on > >>>>> using Appl ID 0 at least for the ASR/ASA Diameter common messages. > >>>>> > >>>>> Regards > >>>>> Marco > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 10:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DSs-0003ar-RQ; Wed, 19 Jul 2006 10:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DSr-0003Xs-Rt for dime@ietf.org; Wed, 19 Jul 2006 10:55:53 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3DSq-0008Le-DY for dime@ietf.org; Wed, 19 Jul 2006 10:55:53 -0400 Received: (qmail invoked by alias); 19 Jul 2006 14:55:51 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 19 Jul 2006 16:55:51 +0200 X-Authenticated: #29516787 Message-ID: <44BE47E7.5040900@gmx.net> Date: Wed, 19 Jul 2006 16:55:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en 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.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Dime] IETF#66 Meeting Minutes 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, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/06jul/minutes/dime.txt Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 11:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DYq-0000Qo-3r; Wed, 19 Jul 2006 11:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3DYo-0000Qj-S8 for dime@ietf.org; Wed, 19 Jul 2006 11:02:02 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3DYn-0000hc-Dr for dime@ietf.org; Wed, 19 Jul 2006 11:02:02 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6JE1xAp018679; Wed, 19 Jul 2006 17:01:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:01:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 18:01:59 +0300 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] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 18:01:58 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarMc/ruoEqnY7hT+CFO3e8sPpRYQAEPR/A From: To: , , X-OriginalArrivalTime: 19 Jul 2006 15:01:59.0329 (UTC) FILETIME=[48BFC110:01C6AB44] X-Spam-Score: 0.2 (/) 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 Tolga, This is not the first time this issue has been discussed (see e.g.=20 AAA archives around July 2004). What it really boils down to is what exactly an "application" is. Quoting myself from two years ago: > This brings us back to the topic what an "application" actually > is. It could mean e.g. a software module in a Diameter > implementation, or a (set of) specifications that document how > Diameter is extended for some particular purpose (such as SIP or > Mobile IPv4). > > My reading of RFC3588 supports the latter interpretation (but I > guess there is some room for disagreement and other interpretations > as well...). With this interpretation, it does not make sense to say that you send a message _to_ an application, or that a message is intended _for_ an application. Instead, you send a message defined _in_ some application. Back then, several others seemed to agree that RFC 3588 supports=20 this interpretation.=20 (How a Diameter server implementation is organized to modules and=20 how the modules communicate is beyond the scope of RFC 3588.) Best regards, Pasi > -----Original Message----- > From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: 19 July, 2006 15:25 > To: Eronen Pasi (Nokia-NRC/Helsinki);=20 > vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status >=20 > Pasi, >=20 > OTOH we also have the following text from RFC3588: > 3. Diameter Header >=20 > Application-ID >=20 > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. >=20 > If one is building a diameter base stack following RFC3588, this > sentence probably would make them think that all messages intended > for a specific application will use applications identifier in > App-Id filed of the message header. >=20 > Thanks, > Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 11:03:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Dah-0000yo-H1; Wed, 19 Jul 2006 11:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Daf-0000yi-Ns for dime@ietf.org; Wed, 19 Jul 2006 11:03:57 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Dae-0000oF-0X for dime@ietf.org; Wed, 19 Jul 2006 11:03:57 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6JF3oI7023175 for ; Wed, 19 Jul 2006 17:03:51 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc74.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Jul 2006 17:03:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 17:03:42 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133B6@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarPr4UIpnHXaMKTWumSWwM+EpGRwAAUYCA From: "STURA, Marco, VF-IT" To: "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 19 Jul 2006 15:03:49.0331 (UTC) FILETIME=[8A50BA30:01C6AB44] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: John.loughney@nokia.com, 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 Tolga, I agree of course with the Victor's proposed approach on how to proceed. That said I would still comment on some of your statements below and feed in some more arguments into this thread. Regards Marco >I believe the point is whether it is RFC3588 or the RFCs you quoted needs >to >be fixed. I am puzzled how those RFcs had such statements, which IMO >clearly >violate what is said about Application-ID in RFC3588 3. Diameter Header >section. [MSt] I think you refer to this text below Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section 11.3 for the possible values that the application-id may use. The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. [MSt] If you look in to section 11.3 you find Diameter Common Messages with app id 0. Obviously the Diameter Common Messages are those defined in the base protocol. The above text, simply means that both Application-Id in the message header and the Auth-Application-Id AVP have to be set to the same value that is 0 (zero) for common messages. So I really don't think that all the existing RFCs violate the base protocol since all of them are consistent, rather I think that some implementation of RFC 3588 may not be compliant and I don't see why we should change all the existing RFCs and application implementations that may be deployed out there (on top of clean base protocol) as opposed to someone fixing their bogus RFC 3588 implementations. >Another point is that considering existing few applications you mentioned >is >not really enough. There are also diameter base stack implementations, >which >conform to RFC3588 and provide generic capability for any type of >application. [MSt] See my comment above. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 11:12:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Dic-0001ua-Pk; Wed, 19 Jul 2006 11:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Dic-0001uU-7r for dime@ietf.org; Wed, 19 Jul 2006 11:12:10 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Dia-0001XO-UI for dime@ietf.org; Wed, 19 Jul 2006 11:12:10 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id D193F994AA; Wed, 19 Jul 2006 11:12:04 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JFC6pA020118; Wed, 19 Jul 2006 11:12:06 -0400 (EDT) From: "Tolga Asveren" To: , , Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 10:48:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Pasi, Thanks for the pointer, which clarifies your point. I think I tend to think more similar to the first interpretation. I consider base diameter protocol as transport-routing/encoding-decoding services, which can be used by applications, which actually perform application level processing. Thanks, Tolga > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Wednesday, July 19, 2006 11:02 AM > To: asveren@ulticom.com; vfajardo@tari.toshiba.com; > Marco.STURA@vodafone.com > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Tolga, > > This is not the first time this issue has been discussed (see e.g. > AAA archives around July 2004). What it really boils down to > is what exactly an "application" is. Quoting myself from two > years ago: > > > This brings us back to the topic what an "application" actually > > is. It could mean e.g. a software module in a Diameter > > implementation, or a (set of) specifications that document how > > Diameter is extended for some particular purpose (such as SIP or > > Mobile IPv4). > > > > My reading of RFC3588 supports the latter interpretation (but I > > guess there is some room for disagreement and other interpretations > > as well...). > > With this interpretation, it does not make sense to say that you send > a message _to_ an application, or that a message is intended _for_ an > application. Instead, you send a message defined _in_ some > application. > > Back then, several others seemed to agree that RFC 3588 supports > this interpretation. > > (How a Diameter server implementation is organized to modules and > how the modules communicate is beyond the scope of RFC 3588.) > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Tolga Asveren [mailto:asveren@ulticom.com] > > Sent: 19 July, 2006 15:25 > > To: Eronen Pasi (Nokia-NRC/Helsinki); > > vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com > > Cc: dime@ietf.org > > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > > Pasi, > > > > OTOH we also have the following text from RFC3588: > > 3. Diameter Header > > > > Application-ID > > > > The application-id in the header MUST be the same as what is > > contained in any relevant AVPs contained in the message. > > > > If one is building a diameter base stack following RFC3588, this > > sentence probably would make them think that all messages intended > > for a specific application will use applications identifier in > > App-Id filed of the message header. > > > > Thanks, > > Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 19 11:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EBV-00025S-U2; Wed, 19 Jul 2006 11:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EBU-00025K-CR for dime@ietf.org; Wed, 19 Jul 2006 11:42:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Bin-0000km-Gl for dime@ietf.org; Wed, 19 Jul 2006 09:04:13 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3BTz-00036L-Gw for dime@ietf.org; Wed, 19 Jul 2006 08:48:57 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id FE1EB58597; Wed, 19 Jul 2006 08:48:50 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JCmrLR005300; Wed, 19 Jul 2006 08:48:54 -0400 (EDT) From: "Tolga Asveren" To: , , Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 08:25:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: Received-SPF: none X-Spam-Score: -2.4 (--) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Pasi, OTOH we also have the following text from RFC3588: 3. Diameter Header Application-ID The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. If one is building a diameter base stack following RFC3588, this sentence probably would make them think that all messages intended for a specific application will use applications identifier in App-Id filed of the message header. Thanks, Tolga > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Wednesday, July 19, 2006 5:39 AM > To: vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Victor Fajardo wrote: > > I'm still not sure why we 'MUST' use app id of 0 ? > > In the case of RFC 4005 and 4072: because the spec says so? > > RFC 4005, Section 1.3: "All other messages are defined by [BASE] and > use the Base application id value." > > RFC 4072, Section 3, last paragraph: "the others > [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." > > This should not lead to interoperability problems unless the > implementors can't read the specs. And in that case, producing more > specs is unlikely to be of help. > > > > > Unless I have the wrong take on this issue, there is a consensus > > that we should just use the app id of the application for simplicity > > and correctness. > > The last time this was discussed, there was consensus that using 0 is > the right answer, and this lead to adding the above-quoted text to RFC > 4005 and 4072. > > So unless the approach in 4005/4072 leads to significant problems, > even when correctly implemented, I'd suggest not changing it. > Changing it could also lead to interoperability problems with > those implementations that correctly implement 4005/4072. > > Best regards, > Pasi > > _______________________________________________ > 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 Jul 19 11:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EOy-0007aN-8u; Wed, 19 Jul 2006 11:55:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3EOx-0007aI-NF for dime@ietf.org; Wed, 19 Jul 2006 11:55:55 -0400 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 1G3EOw-0005I3-VR for dime@ietf.org; Wed, 19 Jul 2006 11:55:55 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k6JFtDC1070908; Wed, 19 Jul 2006 11:55:14 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Wed, 19 Jul 2006 11:54:58 -0400 To: "STURA, Marco, VF-IT" Subject: Re: [Dime] Summary of 3588bis Issues Status Message-ID: <20060719155458.GA12694@steelhead> References: <5371BE300539E6439919CF97203DDEC2077133B6@OIVMEXO01.omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <5371BE300539E6439919CF97203DDEC2077133B6@OIVMEXO01.omnitel.it> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 73 X-Spam-Score: -2.4 (--) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: John.loughney@nokia.com, 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 fully aggree with Marco's statement below as well as Pasi's opinion based on the discussion happened in the past. We should use application identifier 0 for Diameter common messages. On the other hand, the routing issue for established sessions with stateful agents needs to be resolved (this issue is different from Issue 4). I'd suggest creating a separate issue on this, which probably needs explicit routing functionality like Issue 4. Yoshihiro Ohba On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: > Tolga, > > I agree of course with the Victor's proposed approach on how to proceed. > > That said I would still comment on some of your statements below and > feed in some more arguments into this thread. > > Regards > Marco > > > >I believe the point is whether it is RFC3588 or the RFCs you quoted > needs >to > >be fixed. I am puzzled how those RFcs had such statements, which IMO > >clearly > >violate what is said about Application-ID in RFC3588 3. Diameter Header > >section. > > [MSt] I think you refer to this text below > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > [MSt] If you look in to section 11.3 you find Diameter Common Messages > with app id 0. Obviously the Diameter Common Messages are those defined > in the base protocol. The above text, simply means that both > Application-Id in the message header and the Auth-Application-Id AVP > have to be set to the same value that is 0 (zero) for common messages. > So I really don't think that all the existing RFCs violate the base > protocol since all of them are consistent, rather I think that some > implementation of RFC 3588 may not be compliant and I don't see why we > should change all the existing RFCs and application implementations that > may be deployed out there (on top of clean base protocol) as opposed to > someone fixing their bogus RFC 3588 implementations. > > >Another point is that considering existing few applications you > mentioned >is > >not really enough. There are also diameter base stack implementations, > >which > >conform to RFC3588 and provide generic capability for any type of > >application. > > [MSt] See my comment above. > > > > _______________________________________________ > 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 Jul 19 11:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ER6-0007oi-Hs; Wed, 19 Jul 2006 11:58:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ER4-0007oX-TI for dime@ietf.org; Wed, 19 Jul 2006 11:58:06 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ER2-0005jh-Cj for dime@ietf.org; Wed, 19 Jul 2006 11:58:06 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 17:58:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jul 2006 17:58:00 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603A9E161@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 20 (offending AVP inside a Grouped AVP) Thread-Index: AcanbZNuxoYtCmTURp6FNA2v4L2sxwDuu97wAAEO+XA= From: "MORAND Lionel RD-CORE-ISS" To: "German Blanco \(MI/EEM\)" , "Victor Fajardo" , X-OriginalArrivalTime: 19 Jul 2006 15:58:03.0121 (UTC) FILETIME=[1DB9AE10:01C6AB4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: Subject: [Dime] RE: Issue 20 (offending AVP inside a Grouped AVP) 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 don't see what is the problem with Grouped AVP and Failed-AVP AVP. A Grouped AVP is just a logical set of individual AVPs. The Failed-AVP = AVP will contain information about missing/offending AVPs, whatever the = AVP location in a command, (in a Grouped AVP or not). Therefore the existing text on the Failed-AVP AVP definition and its use = seems to be clear enough. Execpet if I missed something... BR, Lionel -----Message d'origine----- De : German Blanco (MI/EEM) [mailto:german.blanco@ericsson.com]=20 Envoy=E9 : mercredi 19 juillet 2006 13:49 =C0 : Victor Fajardo; dime@ietf.org Objet : Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] = Summaryof 3588bis Issues Status Victor,=20 Thanks for the summary! When you say: > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP.=20 Is the proposal to indicate in the answer only the code of the missing = AVP inside the Grouped AVP? If that is the case, I would suggest this text additions for RFC 3558bis = (between ">>"s and "<<"s): " DIAMETER_MISSING_AVP 5005 The request did not contain an AVP that is required by the Command Code >>or Grouped AVP <> If the AVP is missing in a = Grouped AVP, only the missing AVP and not the Grouped-AVP will be included = in=20 the Failed-AVP. <> If the AVP is present inside a Grouped AVP, only the offending AVP and not the Grouped-AVP will be = included=20 in the Failed-AVP. << " "Do nothing" doesn't seem a good idea to me. I would prefer that this = is clarified, whatever the conclusion is. The long list of error codes = will not make sense, if we end up not knowing what happened. Regards, German.=20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: viernes, 14 de julio de 2006 19:46 To: dime@ietf.org Subject: [Dime] Summary of 3588bis Issues Status Folks, The is a summary of the 3588bis issues discussion during DIME WG meeting = in IETF66. If you have comments on any of the existing issues pls don't = hesitate to post it on the DIME list so we can facilitate quicker = resolution or at least better understanding of the problem. We also need = some proposals on the open issues if you believe they are truly issues.=20 Note that the assigned issue numbers are based on the current tracker = which is for historical reasons the diameter-interop tracker = (http://www.tschofenig.priv.at:8080/diameter-interop). Closed Issues: ------------- Issue 6 : TLS version issue Comments: interop related problem only. Does not affect = the base spec Issue 7 : Textual IP address qualify as FQDN Comments: Consensus that FQDN is defined as "internet = name" only Issue 11 : Confusion about use of Proxy-Info AVP for Relay Comments: Clarified in Sec 6.2 with the text "Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request." Open Issues with some consensus on proposals: --------------------------------------------- Notes: These issues have some consensus either during the IETF66 meeting and/or in the DIME mailing list. Issue 2 & 5 : App Ids used by common diameter messages Proposals: Use the application id of the current application Issue 3 & 16 : CER/CEA exchange in the open state Proposals: Need more consensus on current proposals posted in issue 16 Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp Proposals: The Vendor-Id ABNF should one and only one instance, i.e. ::=3D < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Issue 20 : Determining an offending/invalid AVP contained within the group AVP Proposals: Do nothing. The AVP code should be enough. Existing proposals may needlessly extend the length of the Failed-AVP. Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 Proposals: Change diameter-message definition in Sec 3.2 to: diameter-message=3Dheader[*fixed][*required][*optional] Open Issues with no consensus on proposals: ------------------------------------------ Issue 21 : URI schemes for AAA Proposals: draft-garcia-dime-aaa-uri-00.txt Issue 4 : Proxy agent stay in the path of the request message of a session Proposals: draft-tsou-dime-routing-ext-00.txt Open Issues that needs proposals: -------------------------------- Notes: These issues did not receive any comments during IETF66 and have no pending proposals. Issue 1 : Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id Issue 15 : Duplicate detection requires server side storage of e2e id and origin-host avp Issue 13 : Clarify usage of application id avp's and how they relate to the app-id in the header Issue 9 & 19 : Error codes defined in wrong category Issue 8 : Setting error flag (e-bit) during CER/CEA exchange Issue 12 : Differing concepts and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue 14 : Explicit text on which error category should have error flag (e-bit) set Issue 18 : Clarify reconnect behavior of peer based on value of Disconnect-Cause AVP Open issues falling into the "New Features" category: ---------------------------------------------------- Note: These features should use the extension procedures defined in = 3588. No comments received in IETF66 meeting. Issue 23 : Predictive loop detection Comments: Optimzation techiniques in detecting loops at the succeeding hops Issue 22 : Fetch data request and location update request. Comments: Proposal to include LUR messages into base since its reusable in different applications If you believe there are some in-accurate info below, pls let us know. best regards, victor _______________________________________________ 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 Wed Jul 19 12:33:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ez7-0002rA-9S; Wed, 19 Jul 2006 12:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ez5-0002qf-Kz for dime@ietf.org; Wed, 19 Jul 2006 12:33:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3D5H-0006mP-TY for dime@ietf.org; Wed, 19 Jul 2006 10:31:31 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Cyu-0004dH-DK for dime@ietf.org; Wed, 19 Jul 2006 10:25:01 -0400 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 k6JEOgTV070455; Wed, 19 Jul 2006 10:24:42 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE40AA.8050902@tari.toshiba.com> Date: Wed, 19 Jul 2006 10:24:42 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: "German Blanco (MI/EEM)" Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summary of 3588bis Issues Status References: <7457D12699374F40BD026D2B1EFFBEC6028430D2@eesmdmw020.eemea.ericsson.se> In-Reply-To: <7457D12699374F40BD026D2B1EFFBEC6028430D2@eesmdmw020.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.2 (-) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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, Comments inline: > Victor, > > Thanks for the summary! > > When you say: > >> Issue 20 : Determining an offending/invalid AVP contained within >> the group AVP >> Proposals: Do nothing. The AVP code should be enough. >> Existing proposals may needlessly extend >> the length of the Failed-AVP. >> > > Is the proposal to indicate in the answer only the code of the missing > AVP inside the Grouped AVP? > > If that is the case, I would suggest this text additions for RFC 3558bis > (between ">>"s and "<<"s): > " > DIAMETER_MISSING_AVP 5005 > The request did not contain an AVP that is required by the Command > Code >>or Grouped AVP < Result-Code AVP, a Failed-AVP AVP SHOULD be included in the > message. > The Failed-AVP AVP MUST contain an example of the missing AVP > complete > with the Vendor-Id if applicable.>> If the AVP is missing in a > Grouped > AVP, only the missing AVP and not the Grouped-AVP will be included > in > the Failed-AVP. < correct > minimum length and contain zeroes. > " > " > DIAMETER_AVP_NOT_ALLOWED 5008 > A message was received with an AVP that MUST NOT be present. The > Failed-AVP AVP MUST be included and contain a copy of the > offending AVP.>> If the AVP is present inside a Grouped > AVP, only the offending AVP and not the Grouped-AVP will be > included > in the Failed-AVP. << > " > > "Do nothing" doesn't seem a good idea to me. I would prefer that this > is clarified, whatever the conclusion is. The long list of error codes > will not make sense, if we end up not knowing what happened. > I don't have any opinion on this topic but I hope some folks will comment on your proposal. regards, victor > Regards, > German. > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: viernes, 14 de julio de 2006 19:46 > To: dime@ietf.org > Subject: [Dime] Summary of 3588bis Issues Status > > Folks, > > The is a summary of the 3588bis issues discussion during DIME WG meeting > in IETF66. If you have comments on any of the existing issues pls don't > hesitate to post it on the DIME list so we can facilitate quicker > resolution or at least better understanding of the problem. We also need > some proposals on the open issues if you believe they are truly issues. > Note that the assigned issue numbers are based on the current tracker > which is for historical reasons the diameter-interop tracker > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > Closed Issues: > ------------- > > Issue 6 : TLS version issue > Comments: interop related problem only. Does not affect > the > base spec > > Issue 7 : Textual IP address qualify as FQDN > Comments: Consensus that FQDN is defined as "internet > name" > only > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > Comments: Clarified in Sec 6.2 with the text > > "Any Proxy-Info AVPs in the request MUST be added to the > answer message, in the same order they were present in > the request." > > Open Issues with some consensus on proposals: > --------------------------------------------- > > Notes: These issues have some consensus either during the IETF66 > meeting and/or in the DIME mailing list. > > Issue 2 & 5 : App Ids used by common diameter messages > Proposals: Use the application id of the current > application > > Issue 3 & 16 : CER/CEA exchange in the open state > Proposals: Need more consensus on current proposals > posted in issue 16 > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > Proposals: The Vendor-Id ABNF should one and only one > instance, i.e. > > ::= < AVP Header: 260 > > < Vendor-Id > > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP. > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > Proposals: Change diameter-message definition in Sec 3.2 > to: > > diameter-message=header[*fixed][*required][*optional] > > Open Issues with no consensus on proposals: > ------------------------------------------ > > Issue 21 : URI schemes for AAA > Proposals: draft-garcia-dime-aaa-uri-00.txt > > Issue 4 : Proxy agent stay in the path of the request message of > a session > Proposals: draft-tsou-dime-routing-ext-00.txt > > Open Issues that needs proposals: > -------------------------------- > > Notes: These issues did not receive any comments during IETF66 and > have no pending proposals. > > Issue 1 : Advertising relay application id (0xffffffff) in > auth-application-id or acct-application-id > > Issue 15 : Duplicate detection requires server side storage of > e2e id and origin-host avp > > Issue 13 : Clarify usage of application id avp's and how they > relate to the app-id in the header > > Issue 9 & 19 : Error codes defined in wrong category > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > Issue 12 : Differing concepts and/or usage of Diameter Identity > (FQDN + port or FQDN only) > > Issue 14 : Explicit text on which error category should have > error flag (e-bit) set > > Issue 18 : Clarify reconnect behavior of peer based on value of > Disconnect-Cause AVP > > Open issues falling into the "New Features" category: > ---------------------------------------------------- > > Note: These features should use the extension procedures defined in > 3588. > No comments received in IETF66 meeting. > > Issue 23 : Predictive loop detection > Comments: Optimzation techiniques in detecting loops > at the succeeding hops > > Issue 22 : Fetch data request and location update request. > Comments: Proposal to include LUR messages into > base since its reusable in different > applications > > If you believe there are some in-accurate info below, pls let us know. > > best regards, > victor > > _______________________________________________ > 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 Jul 19 13:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FPi-0000UU-KQ; Wed, 19 Jul 2006 13:00:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FPi-0000UP-67 for dime@ietf.org; Wed, 19 Jul 2006 13:00:46 -0400 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 1G3FPh-0006uB-PL for dime@ietf.org; Wed, 19 Jul 2006 13:00:46 -0400 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 k6JH08fm071233; Wed, 19 Jul 2006 13:00:08 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE651A.2050205@tari.toshiba.com> Date: Wed, 19 Jul 2006 13:00:10 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133B6@OIVMEXO01.omnitel.it> <20060719155458.GA12694@steelhead> In-Reply-To: <20060719155458.GA12694@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: John.loughney@nokia.com, dime@ietf.org, "STURA, Marco, VF-IT" 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, Comments inline: > I fully aggree with Marco's statement below as well as Pasi's opinion > based on the discussion happened in the past. We should use > application identifier 0 for Diameter common messages. > > On the other hand, the routing issue for established sessions with > stateful agents needs to be resolved (this issue is different from > Issue 4). I'd suggest creating a separate issue on this, which > probably needs explicit routing functionality like Issue 4. > Based on Pasi's historical quotation, I think we can compromise on the app id of 0 since it seems like such "interpretation" is already heavily entrenched. Though I agree with Yoshi that we still need to fix the routing issue as a side effect of this interpretation. In this way, we can agree on something without endangering existing standards and move forward with other issues. Would this proposal be sufficient for all interested parties ? best regards, victor > Yoshihiro Ohba > > > > On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: > >> Tolga, >> >> I agree of course with the Victor's proposed approach on how to proceed. >> >> That said I would still comment on some of your statements below and >> feed in some more arguments into this thread. >> >> Regards >> Marco >> >> >> >>> I believe the point is whether it is RFC3588 or the RFCs you quoted >>> >> needs >to >> >>> be fixed. I am puzzled how those RFcs had such statements, which IMO >>> clearly >>> violate what is said about Application-ID in RFC3588 3. Diameter Header >>> section. >>> >> [MSt] I think you refer to this text below >> >> Application-ID >> Application-ID is four octets and is used to identify to which >> application the message is applicable for. The application can be >> an authentication application, an accounting application or a >> vendor specific application. See Section 11.3 for the possible >> values that the application-id may use. >> >> The application-id in the header MUST be the same as what is >> contained in any relevant AVPs contained in the message. >> >> [MSt] If you look in to section 11.3 you find Diameter Common Messages >> with app id 0. Obviously the Diameter Common Messages are those defined >> in the base protocol. The above text, simply means that both >> Application-Id in the message header and the Auth-Application-Id AVP >> have to be set to the same value that is 0 (zero) for common messages. >> So I really don't think that all the existing RFCs violate the base >> protocol since all of them are consistent, rather I think that some >> implementation of RFC 3588 may not be compliant and I don't see why we >> should change all the existing RFCs and application implementations that >> may be deployed out there (on top of clean base protocol) as opposed to >> someone fixing their bogus RFC 3588 implementations. >> >> >>> Another point is that considering existing few applications you >>> >> mentioned >is >> >>> not really enough. There are also diameter base stack implementations, >>> which >>> conform to RFC3588 and provide generic capability for any type of >>> application. >>> >> [MSt] See my comment above. >> >> >> >> _______________________________________________ >> 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 Jul 19 13:24:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Fmt-0000SL-LD; Wed, 19 Jul 2006 13:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Fms-0000SG-3d for dime@ietf.org; Wed, 19 Jul 2006 13:24:42 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Fmr-0000Bg-Js for dime@ietf.org; Wed, 19 Jul 2006 13:24:42 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1F5CC50DC5; Wed, 19 Jul 2006 13:24:37 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6JHOZX1003559; Wed, 19 Jul 2006 13:24:35 -0400 (EDT) From: "Tolga Asveren" To: "Victor Fajardo" , "Yoshihiro Ohba" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 19 Jul 2006 13:00:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <44BE651A.2050205@tari.toshiba.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: John.loughney@nokia.com, dime@ietf.org, "STURA, Marco, VF-IT" 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 Victor, To me it is fine (not preferrable but just fine ;-) ). I just hope that this can be rephrased in the bis document so that we don't have interoprability issues in the future with people which did not follow this discussion. I don't know whether there is already an issue open related with it, but it could be an idea to clarify the rules for command code namespace as well. My reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it seems not everybody agrees with this and I think this is somehow related with the issue we are discussing. If the answer to this question is answered in the bis document in a clear way, I would feel better. About routing issue, I think it can be deducted to the generic problem of "How can a proxy stay on the path during a session", so I believe this is the question to answer (which we already discussed to some extent in the context of strict-routing draft review) Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, July 19, 2006 1:00 PM > To: Yoshihiro Ohba > Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; > dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > Hi, > > Comments inline: > > > I fully aggree with Marco's statement below as well as Pasi's opinion > > based on the discussion happened in the past. We should use > > application identifier 0 for Diameter common messages. > > > > On the other hand, the routing issue for established sessions with > > stateful agents needs to be resolved (this issue is different from > > Issue 4). I'd suggest creating a separate issue on this, which > > probably needs explicit routing functionality like Issue 4. > > > > Based on Pasi's historical quotation, I think we can compromise on the > app id of 0 since it seems like such "interpretation" is already heavily > entrenched. Though I agree with Yoshi that we still need to fix the > routing issue as a side effect of this interpretation. In this way, we > can agree on something without endangering existing standards and move > forward with other issues. Would this proposal be sufficient for all > interested parties ? > > best regards, > victor > > > Yoshihiro Ohba > > > > > > > > On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: > > > >> Tolga, > >> > >> I agree of course with the Victor's proposed approach on how > to proceed. > >> > >> That said I would still comment on some of your statements below and > >> feed in some more arguments into this thread. > >> > >> Regards > >> Marco > >> > >> > >> > >>> I believe the point is whether it is RFC3588 or the RFCs you quoted > >>> > >> needs >to > >> > >>> be fixed. I am puzzled how those RFcs had such statements, which IMO > >>> clearly > >>> violate what is said about Application-ID in RFC3588 3. > Diameter Header > >>> section. > >>> > >> [MSt] I think you refer to this text below > >> > >> Application-ID > >> Application-ID is four octets and is used to identify to which > >> application the message is applicable for. The > application can be > >> an authentication application, an accounting application or a > >> vendor specific application. See Section 11.3 for the possible > >> values that the application-id may use. > >> > >> The application-id in the header MUST be the same as what is > >> contained in any relevant AVPs contained in the message. > >> > >> [MSt] If you look in to section 11.3 you find Diameter Common Messages > >> with app id 0. Obviously the Diameter Common Messages are those defined > >> in the base protocol. The above text, simply means that both > >> Application-Id in the message header and the Auth-Application-Id AVP > >> have to be set to the same value that is 0 (zero) for common messages. > >> So I really don't think that all the existing RFCs violate the base > >> protocol since all of them are consistent, rather I think that some > >> implementation of RFC 3588 may not be compliant and I don't see why we > >> should change all the existing RFCs and application > implementations that > >> may be deployed out there (on top of clean base protocol) as opposed to > >> someone fixing their bogus RFC 3588 implementations. > >> > >> > >>> Another point is that considering existing few applications you > >>> > >> mentioned >is > >> > >>> not really enough. There are also diameter base stack implementations, > >>> which > >>> conform to RFC3588 and provide generic capability for any type of > >>> application. > >>> > >> [MSt] See my comment above. > >> > >> > >> > >> _______________________________________________ > >> 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 Jul 19 13:57:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GIr-0005Ma-VB; Wed, 19 Jul 2006 13:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3GIq-0005MS-Kn for dime@ietf.org; Wed, 19 Jul 2006 13:57:44 -0400 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 1G3GIq-00027G-8R for dime@ietf.org; Wed, 19 Jul 2006 13:57:44 -0400 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 k6JHv4Tt071561; Wed, 19 Jul 2006 13:57:06 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BE7271.8090503@tari.toshiba.com> Date: Wed, 19 Jul 2006 13:57:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Summary of 3588bis Issues Status References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: John.loughney@nokia.com, dime@ietf.org, "STURA, Marco, VF-IT" 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, > To me it is fine (not preferrable but just fine ;-) ). I just hope that this > can be rephrased in the bis document so that we don't have interoprability > issues in the future with people which did not follow this discussion. > I agree :). > I don't know whether there is already an issue open related with it, but it > could be an idea to clarify the rules for command code namespace as well. My > reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it seems > not everybody agrees with this and I think this is somehow related with the > issue we are discussing. If the answer to this question is answered in the > bis document in a clear way, I would feel better. > My reading on the command code is that it is flat as well because of the strict allocation process. > About routing issue, I think it can be deducted to the generic problem of > "How can a proxy stay on the path during a session", so I believe this is > the question to answer (which we already discussed to some extent in the > context of strict-routing draft review) > I agree. BR, victor > Thanks, > Tolga > > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Wednesday, July 19, 2006 1:00 PM >> To: Yoshihiro Ohba >> Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; >> dime@ietf.org >> Subject: Re: [Dime] Summary of 3588bis Issues Status >> >> >> Hi, >> >> Comments inline: >> >> >>> I fully aggree with Marco's statement below as well as Pasi's opinion >>> based on the discussion happened in the past. We should use >>> application identifier 0 for Diameter common messages. >>> >>> On the other hand, the routing issue for established sessions with >>> stateful agents needs to be resolved (this issue is different from >>> Issue 4). I'd suggest creating a separate issue on this, which >>> probably needs explicit routing functionality like Issue 4. >>> >>> >> Based on Pasi's historical quotation, I think we can compromise on the >> app id of 0 since it seems like such "interpretation" is already heavily >> entrenched. Though I agree with Yoshi that we still need to fix the >> routing issue as a side effect of this interpretation. In this way, we >> can agree on something without endangering existing standards and move >> forward with other issues. Would this proposal be sufficient for all >> interested parties ? >> >> best regards, >> victor >> >> >>> Yoshihiro Ohba >>> >>> >>> >>> On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: >>> >>> >>>> Tolga, >>>> >>>> I agree of course with the Victor's proposed approach on how >>>> >> to proceed. >> >>>> That said I would still comment on some of your statements below and >>>> feed in some more arguments into this thread. >>>> >>>> Regards >>>> Marco >>>> >>>> >>>> >>>> >>>>> I believe the point is whether it is RFC3588 or the RFCs you quoted >>>>> >>>>> >>>> needs >to >>>> >>>> >>>>> be fixed. I am puzzled how those RFcs had such statements, which IMO >>>>> clearly >>>>> violate what is said about Application-ID in RFC3588 3. >>>>> >> Diameter Header >> >>>>> section. >>>>> >>>>> >>>> [MSt] I think you refer to this text below >>>> >>>> Application-ID >>>> Application-ID is four octets and is used to identify to which >>>> application the message is applicable for. The >>>> >> application can be >> >>>> an authentication application, an accounting application or a >>>> vendor specific application. See Section 11.3 for the possible >>>> values that the application-id may use. >>>> >>>> The application-id in the header MUST be the same as what is >>>> contained in any relevant AVPs contained in the message. >>>> >>>> [MSt] If you look in to section 11.3 you find Diameter Common Messages >>>> with app id 0. Obviously the Diameter Common Messages are those defined >>>> in the base protocol. The above text, simply means that both >>>> Application-Id in the message header and the Auth-Application-Id AVP >>>> have to be set to the same value that is 0 (zero) for common messages. >>>> So I really don't think that all the existing RFCs violate the base >>>> protocol since all of them are consistent, rather I think that some >>>> implementation of RFC 3588 may not be compliant and I don't see why we >>>> should change all the existing RFCs and application >>>> >> implementations that >> >>>> may be deployed out there (on top of clean base protocol) as opposed to >>>> someone fixing their bogus RFC 3588 implementations. >>>> >>>> >>>> >>>>> Another point is that considering existing few applications you >>>>> >>>>> >>>> mentioned >is >>>> >>>> >>>>> not really enough. There are also diameter base stack implementations, >>>>> which >>>>> conform to RFC3588 and provide generic capability for any type of >>>>> application. >>>>> >>>>> >>>> [MSt] See my comment above. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Jul 20 03:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3T0U-0001kb-V7; Thu, 20 Jul 2006 03:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3T0T-0001kI-55 for dime@ietf.org; Thu, 20 Jul 2006 03:31:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3T0T-0008B4-2e for dime@ietf.org; Thu, 20 Jul 2006 03:31:37 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Sn1-00048g-3c for dime@ietf.org; Thu, 20 Jul 2006 03:17:46 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5874D6E0001; Thu, 20 Jul 2006 09:17:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 09:17:34 +0200 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 09:17:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jul 2006 09:17:31 +0200 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60286C06D@eesmdmw020.eemea.ericsson.se> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02603A9E161@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 20 (offending AVP inside a Grouped AVP) Thread-Index: AcanbZNuxoYtCmTURp6FNA2v4L2sxwDuu97wAAEO+XAAJ8cd0A== From: "German Blanco \(MI/EEM\)" To: "MORAND Lionel RD-CORE-ISS" , "Victor Fajardo" , X-OriginalArrivalTime: 20 Jul 2006 07:17:33.0831 (UTC) FILETIME=[9207F170:01C6ABCC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -2.6 (--) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: Subject: [Dime] RE: Issue 20 (offending AVP inside a Grouped AVP) 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 Lionel, I also like that way of working better, but it is probably not that = clear when there were several people in this list giving the opinion = that the Failed-AVP should contain the grouped AVP ("top level AVP") = reporting an invalid value. It is in a thread with the subject "[Dime] Invalid AVP within a Grouped = AVP". Cheers, German. -----Original Message----- From: MORAND Lionel RD-CORE-ISS [mailto:lionel.morand@orange-ft.com]=20 Sent: mi=E9rcoles, 19 de julio de 2006 17:58 To: German Blanco (MI/EEM); Victor Fajardo; dime@ietf.org Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) Hi all, I don't see what is the problem with Grouped AVP and Failed-AVP AVP. A Grouped AVP is just a logical set of individual AVPs. The Failed-AVP = AVP will contain information about missing/offending AVPs, whatever the = AVP location in a command, (in a Grouped AVP or not). Therefore the existing text on the Failed-AVP AVP definition and its use = seems to be clear enough. Execpet if I missed something... BR, Lionel -----Message d'origine----- De : German Blanco (MI/EEM) [mailto:german.blanco@ericsson.com] Envoy=E9 : mercredi 19 juillet 2006 13:49 =C0 : Victor Fajardo; dime@ietf.org Objet : Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] = Summaryof 3588bis Issues Status Victor,=20 Thanks for the summary! When you say: > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP.=20 Is the proposal to indicate in the answer only the code of the missing = AVP inside the Grouped AVP? If that is the case, I would suggest this text additions for RFC 3558bis = (between ">>"s and "<<"s): " DIAMETER_MISSING_AVP 5005 The request did not contain an AVP that is required by the Command Code >>or Grouped AVP <> If the AVP is missing in a = Grouped AVP, only the missing AVP and not the Grouped-AVP will be included = in=20 the Failed-AVP. <> If the AVP is present inside a Grouped AVP, only the offending AVP and not the Grouped-AVP will be = included=20 in the Failed-AVP. << " "Do nothing" doesn't seem a good idea to me. I would prefer that this = is clarified, whatever the conclusion is. The long list of error codes = will not make sense, if we end up not knowing what happened. Regards, German.=20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: viernes, 14 de julio de 2006 19:46 To: dime@ietf.org Subject: [Dime] Summary of 3588bis Issues Status Folks, The is a summary of the 3588bis issues discussion during DIME WG meeting = in IETF66. If you have comments on any of the existing issues pls don't = hesitate to post it on the DIME list so we can facilitate quicker = resolution or at least better understanding of the problem. We also need = some proposals on the open issues if you believe they are truly issues.=20 Note that the assigned issue numbers are based on the current tracker = which is for historical reasons the diameter-interop tracker = (http://www.tschofenig.priv.at:8080/diameter-interop). Closed Issues: ------------- Issue 6 : TLS version issue Comments: interop related problem only. Does not affect = the base spec Issue 7 : Textual IP address qualify as FQDN Comments: Consensus that FQDN is defined as "internet = name" only Issue 11 : Confusion about use of Proxy-Info AVP for Relay Comments: Clarified in Sec 6.2 with the text "Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request." Open Issues with some consensus on proposals: --------------------------------------------- Notes: These issues have some consensus either during the IETF66 meeting and/or in the DIME mailing list. Issue 2 & 5 : App Ids used by common diameter messages Proposals: Use the application id of the current application Issue 3 & 16 : CER/CEA exchange in the open state Proposals: Need more consensus on current proposals posted in issue 16 Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp Proposals: The Vendor-Id ABNF should one and only one instance, i.e. ::=3D < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Issue 20 : Determining an offending/invalid AVP contained within the group AVP Proposals: Do nothing. The AVP code should be enough. Existing proposals may needlessly extend the length of the Failed-AVP. Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 Proposals: Change diameter-message definition in Sec 3.2 to: diameter-message=3Dheader[*fixed][*required][*optional] Open Issues with no consensus on proposals: ------------------------------------------ Issue 21 : URI schemes for AAA Proposals: draft-garcia-dime-aaa-uri-00.txt Issue 4 : Proxy agent stay in the path of the request message of a session Proposals: draft-tsou-dime-routing-ext-00.txt Open Issues that needs proposals: -------------------------------- Notes: These issues did not receive any comments during IETF66 and have no pending proposals. Issue 1 : Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id Issue 15 : Duplicate detection requires server side storage of e2e id and origin-host avp Issue 13 : Clarify usage of application id avp's and how they relate to the app-id in the header Issue 9 & 19 : Error codes defined in wrong category Issue 8 : Setting error flag (e-bit) during CER/CEA exchange Issue 12 : Differing concepts and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue 14 : Explicit text on which error category should have error flag (e-bit) set Issue 18 : Clarify reconnect behavior of peer based on value of Disconnect-Cause AVP Open issues falling into the "New Features" category: ---------------------------------------------------- Note: These features should use the extension procedures defined in = 3588. No comments received in IETF66 meeting. Issue 23 : Predictive loop detection Comments: Optimzation techiniques in detecting loops at the succeeding hops Issue 22 : Fetch data request and location update request. Comments: Proposal to include LUR messages into base since its reusable in different applications If you believe there are some in-accurate info below, pls let us know. best regards, victor _______________________________________________ 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 Jul 20 04:37:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3U2a-0002bi-OU; Thu, 20 Jul 2006 04:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3U2Z-0002VS-9c for dime@ietf.org; Thu, 20 Jul 2006 04:37:51 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3U2Y-0007m3-O0 for dime@ietf.org; Thu, 20 Jul 2006 04:37:51 -0400 Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6K8bnI7008945 for ; Thu, 20 Jul 2006 10:37:49 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jul 2006 10:37:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 20 Jul 2006 10:37:43 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133BA@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: AcarXN62zCXmA3gcTh+opl+aQHqbCAAebVug From: "STURA, Marco, VF-IT" To: "Victor Fajardo" , "Tolga Asveren" X-OriginalArrivalTime: 20 Jul 2006 08:37:48.0042 (UTC) FILETIME=[C7863EA0:01C6ABD7] X-Spam-Score: 0.1 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: John.loughney@nokia.com, 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 >Based on Pasi's historical quotation, I think we can compromise on the = app >id of 0 since it seems like such "interpretation" is already = heavily >entrenched. Though I agree with Yoshi that we still need to fix = the routing >issue as a side effect of this interpretation. In this way, = we can agree on >something without endangering existing standards and = move forward with >other issues. Would this proposal be sufficient for = all interested parties ? [MSt] I agree. I also agree with Yoshi to fix this routing issue when = Destination-Host + app id 0 based routing is used in order to achieve = optimal routing of the request (e.g. in the Tolga's configuration = example). > To me it is fine (not preferrable but just fine ;-) ). I just hope = that this > can be rephrased in the bis document so that we don't have = interoprability > issues in the future with people which did not follow this discussion. > =20 [MSt] I proposed some text in this thread. You may want to consider and = elaborate on it. > About routing issue, I think it can be deducted to the generic problem = of > "How can a proxy stay on the path during a session", so I believe this = is > the question to answer (which we already discussed to some extent in = the > context of strict-routing draft review) [MSt] I agree with this too. -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: mercoled=EC 19 luglio 2006 19.57 To: Tolga Asveren Cc: Yoshihiro Ohba; STURA, Marco, VF-IT; John.loughney@nokia.com; = dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status Hi Tolga, > To me it is fine (not preferrable but just fine ;-) ). I just hope = that this > can be rephrased in the bis document so that we don't have = interoprability > issues in the future with people which did not follow this discussion. > =20 I agree :). > I don't know whether there is already an issue open related with it, = but it > could be an idea to clarify the rules for command code namespace as = well. My > reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it = seems > not everybody agrees with this and I think this is somehow related = with the > issue we are discussing. If the answer to this question is answered in = the > bis document in a clear way, I would feel better. > =20 My reading on the command code is that it is flat as well because of the = strict allocation process. > About routing issue, I think it can be deducted to the generic problem = of > "How can a proxy stay on the path during a session", so I believe this = is > the question to answer (which we already discussed to some extent in = the > context of strict-routing draft review) > =20 I agree. BR, victor > Thanks, > Tolga > > =20 >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Wednesday, July 19, 2006 1:00 PM >> To: Yoshihiro Ohba >> Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; >> dime@ietf.org >> Subject: Re: [Dime] Summary of 3588bis Issues Status >> >> >> Hi, >> >> Comments inline: >> >> =20 >>> I fully aggree with Marco's statement below as well as Pasi's = opinion >>> based on the discussion happened in the past. We should use >>> application identifier 0 for Diameter common messages. >>> >>> On the other hand, the routing issue for established sessions with >>> stateful agents needs to be resolved (this issue is different from >>> Issue 4). I'd suggest creating a separate issue on this, which >>> probably needs explicit routing functionality like Issue 4. >>> >>> =20 >> Based on Pasi's historical quotation, I think we can compromise on = the >> app id of 0 since it seems like such "interpretation" is already = heavily >> entrenched. Though I agree with Yoshi that we still need to fix the >> routing issue as a side effect of this interpretation. In this way, = we >> can agree on something without endangering existing standards and = move >> forward with other issues. Would this proposal be sufficient for all >> interested parties ? >> >> best regards, >> victor >> >> =20 >>> Yoshihiro Ohba >>> >>> >>> >>> On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: >>> >>> =20 >>>> Tolga, >>>> >>>> I agree of course with the Victor's proposed approach on how >>>> =20 >> to proceed. >> =20 >>>> That said I would still comment on some of your statements below = and >>>> feed in some more arguments into this thread. >>>> >>>> Regards >>>> Marco >>>> >>>> >>>> >>>> =20 >>>>> I believe the point is whether it is RFC3588 or the RFCs you = quoted >>>>> >>>>> =20 >>>> needs >to >>>> >>>> =20 >>>>> be fixed. I am puzzled how those RFcs had such statements, which = IMO >>>>> clearly >>>>> violate what is said about Application-ID in RFC3588 3. >>>>> =20 >> Diameter Header >> =20 >>>>> section. >>>>> >>>>> =20 >>>> [MSt] I think you refer to this text below >>>> >>>> Application-ID >>>> Application-ID is four octets and is used to identify to = which >>>> application the message is applicable for. The >>>> =20 >> application can be >> =20 >>>> an authentication application, an accounting application or a >>>> vendor specific application. See Section 11.3 for the = possible >>>> values that the application-id may use. >>>> >>>> The application-id in the header MUST be the same as what is >>>> contained in any relevant AVPs contained in the message. >>>> >>>> [MSt] If you look in to section 11.3 you find Diameter Common = Messages >>>> with app id 0. Obviously the Diameter Common Messages are those = defined >>>> in the base protocol. The above text, simply means that both >>>> Application-Id in the message header and the Auth-Application-Id = AVP >>>> have to be set to the same value that is 0 (zero) for common = messages. >>>> So I really don't think that all the existing RFCs violate the base >>>> protocol since all of them are consistent, rather I think that some >>>> implementation of RFC 3588 may not be compliant and I don't see why = we >>>> should change all the existing RFCs and application >>>> =20 >> implementations that >> =20 >>>> may be deployed out there (on top of clean base protocol) as = opposed to >>>> someone fixing their bogus RFC 3588 implementations. >>>> >>>> >>>> =20 >>>>> Another point is that considering existing few applications you >>>>> >>>>> =20 >>>> mentioned >is >>>> >>>> =20 >>>>> not really enough. There are also diameter base stack = implementations, >>>>> which >>>>> conform to RFC3588 and provide generic capability for any type of >>>>> application. >>>>> >>>>> =20 >>>> [MSt] See my comment above. >>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >>>> >>>> >>>> =20 >>> >>> =20 > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 20 05:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3VGz-0007zf-8r; Thu, 20 Jul 2006 05:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3VGv-0007rJ-4Q for dime@ietf.org; Thu, 20 Jul 2006 05:56:45 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3V2p-0005Ta-0M for dime@ietf.org; Thu, 20 Jul 2006 05:42:14 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P00BCG40K95@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 17:36:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P0028340I3C@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 17:36:20 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2P004Y2410ZE@szxml03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 17:36:37 +0800 (CST) Date: Thu, 20 Jul 2006 15:03:57 +0530 From: Rajith R Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: <44BE651A.2050205@tari.toshiba.com> To: 'Victor Fajardo' , 'Yoshihiro Ohba' Message-id: <000601c6abdf$a1067710$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcarVQWHlUSFlqf5RRSjsF2Z7IhxDQAh0T+A X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: John.loughney@nokia.com, "'STURA, Marco, VF-IT'" , dime@ietf.org 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 Hi When you say we should use app Id 0 for Diameter common messages (say ASR/ASA/RAR/RAA etc.), it is in the context of NASREQ application (RFC 4005), right? Say, another application, like Gq in IMS, use these messages (i.e. same command code, may add app. Sp. AVPs), it is not mandatory to use app id 0, right? Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, July 19, 2006 10:30 PM >To: Yoshihiro Ohba >Cc: John.loughney@nokia.com; dime@ietf.org; STURA, Marco, VF-IT >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi, > >Comments inline: > >> I fully aggree with Marco's statement below as well as Pasi's opinion >> based on the discussion happened in the past. We should use >> application identifier 0 for Diameter common messages. >> >> On the other hand, the routing issue for established sessions with >> stateful agents needs to be resolved (this issue is different from >> Issue 4). I'd suggest creating a separate issue on this, which >> probably needs explicit routing functionality like Issue 4. >> > >Based on Pasi's historical quotation, I think we can compromise on the >app id of 0 since it seems like such "interpretation" is already heavily >entrenched. Though I agree with Yoshi that we still need to fix the >routing issue as a side effect of this interpretation. In this way, we >can agree on something without endangering existing standards and move >forward with other issues. Would this proposal be sufficient for all >interested parties ? > >best regards, >victor > >> Yoshihiro Ohba >> >> >> >> On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: >> >>> Tolga, >>> >>> I agree of course with the Victor's proposed approach on how to proceed. >>> >>> That said I would still comment on some of your statements below and >>> feed in some more arguments into this thread. >>> >>> Regards >>> Marco >>> >>> >>> >>>> I believe the point is whether it is RFC3588 or the RFCs you quoted >>>> >>> needs >to >>> >>>> be fixed. I am puzzled how those RFcs had such statements, which IMO >>>> clearly >>>> violate what is said about Application-ID in RFC3588 3. Diameter Header >>>> section. >>>> >>> [MSt] I think you refer to this text below >>> >>> Application-ID >>> Application-ID is four octets and is used to identify to which >>> application the message is applicable for. The application can be >>> an authentication application, an accounting application or a >>> vendor specific application. See Section 11.3 for the possible >>> values that the application-id may use. >>> >>> The application-id in the header MUST be the same as what is >>> contained in any relevant AVPs contained in the message. >>> >>> [MSt] If you look in to section 11.3 you find Diameter Common Messages >>> with app id 0. Obviously the Diameter Common Messages are those defined >>> in the base protocol. The above text, simply means that both >>> Application-Id in the message header and the Auth-Application-Id AVP >>> have to be set to the same value that is 0 (zero) for common messages. >>> So I really don't think that all the existing RFCs violate the base >>> protocol since all of them are consistent, rather I think that some >>> implementation of RFC 3588 may not be compliant and I don't see why we >>> should change all the existing RFCs and application implementations that >>> may be deployed out there (on top of clean base protocol) as opposed to >>> someone fixing their bogus RFC 3588 implementations. >>> >>> >>>> Another point is that considering existing few applications you >>>> >>> mentioned >is >>> >>>> not really enough. There are also diameter base stack implementations, >>>> which >>>> conform to RFC3588 and provide generic capability for any type of >>>> application. >>>> >>> [MSt] See my comment above. >>> >>> >>> >>> _______________________________________________ >>> 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 Jul 20 06:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WC6-0004j3-88; Thu, 20 Jul 2006 06:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WC5-0004en-9o for dime@ietf.org; Thu, 20 Jul 2006 06:55:49 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3VnG-0001J6-VS for dime@ietf.org; Thu, 20 Jul 2006 06:30:14 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P00B4V6C495@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 18:26:29 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P0078K6C3AX@szxga01-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 18:26:28 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2P007BE6CLER@szxml03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 18:26:46 +0800 (CST) Date: Thu, 20 Jul 2006 15:54:07 +0530 From: Rajith R Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summary of 3588bis Issues Status In-reply-to: <44BE40AA.8050902@tari.toshiba.com> To: 'Victor Fajardo' , "'German Blanco (MI/EEM)'" Message-id: <001201c6abe6$a2527ae0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcarURPUCmHOhoFtSa2rIXtswv+QEwAlSgKg X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: dime@ietf.org 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 Hi For unsupported AVP, adding the offending (sub) AVP contents to the Failed AVP is ok. A first-occurrence content match will tell you where the error is. However for missing AVP, if you put an example of the (sub) AVP in Failed AVP, how would you know/indicate whether it is missing in the command or in a particular group AVP? Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, July 19, 2006 7:55 PM >To: German Blanco (MI/EEM) >Cc: dime@ietf.org >Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: >[Dime]Summary of 3588bis Issues Status > >Hi German, > >Comments inline: > >> Victor, >> >> Thanks for the summary! >> >> When you say: >> >>> Issue 20 : Determining an offending/invalid AVP contained within >>> the group AVP >>> Proposals: Do nothing. The AVP code should be enough. >>> Existing proposals may needlessly extend >>> the length of the Failed-AVP. >>> >> >> Is the proposal to indicate in the answer only the code of the missing >> AVP inside the Grouped AVP? >> >> If that is the case, I would suggest this text additions for RFC 3558bis >> (between ">>"s and "<<"s): >> " >> DIAMETER_MISSING_AVP 5005 >> The request did not contain an AVP that is required by the Command >> Code >>or Grouped AVP <> Result-Code AVP, a Failed-AVP AVP SHOULD be included in the >> message. >> The Failed-AVP AVP MUST contain an example of the missing AVP >> complete >> with the Vendor-Id if applicable.>> If the AVP is missing in a >> Grouped >> AVP, only the missing AVP and not the Grouped-AVP will be included >> in >> the Failed-AVP. <> correct >> minimum length and contain zeroes. >> " >> " >> DIAMETER_AVP_NOT_ALLOWED 5008 >> A message was received with an AVP that MUST NOT be present. The >> Failed-AVP AVP MUST be included and contain a copy of the >> offending AVP.>> If the AVP is present inside a Grouped >> AVP, only the offending AVP and not the Grouped-AVP will be >> included >> in the Failed-AVP. << >> " >> >> "Do nothing" doesn't seem a good idea to me. I would prefer that this >> is clarified, whatever the conclusion is. The long list of error codes >> will not make sense, if we end up not knowing what happened. >> > >I don't have any opinion on this topic but I hope some folks will >comment on your proposal. > >regards, >victor > >> Regards, >> German. >> >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: viernes, 14 de julio de 2006 19:46 >> To: dime@ietf.org >> Subject: [Dime] Summary of 3588bis Issues Status >> >> Folks, >> >> The is a summary of the 3588bis issues discussion during DIME WG meeting >> in IETF66. If you have comments on any of the existing issues pls don't >> hesitate to post it on the DIME list so we can facilitate quicker >> resolution or at least better understanding of the problem. We also need >> some proposals on the open issues if you believe they are truly issues. >> Note that the assigned issue numbers are based on the current tracker >> which is for historical reasons the diameter-interop tracker >> (http://www.tschofenig.priv.at:8080/diameter-interop). >> >> >> Closed Issues: >> ------------- >> >> Issue 6 : TLS version issue >> Comments: interop related problem only. Does not affect >> the >> base spec >> >> Issue 7 : Textual IP address qualify as FQDN >> Comments: Consensus that FQDN is defined as "internet >> name" >> only >> >> Issue 11 : Confusion about use of Proxy-Info AVP for Relay >> Comments: Clarified in Sec 6.2 with the text >> >> "Any Proxy-Info AVPs in the request MUST be added to the >> answer message, in the same order they were present in >> the request." >> >> Open Issues with some consensus on proposals: >> --------------------------------------------- >> >> Notes: These issues have some consensus either during the IETF66 >> meeting and/or in the DIME mailing list. >> >> Issue 2 & 5 : App Ids used by common diameter messages >> Proposals: Use the application id of the current >> application >> >> Issue 3 & 16 : CER/CEA exchange in the open state >> Proposals: Need more consensus on current proposals >> posted in issue 16 >> >> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp >> Proposals: The Vendor-Id ABNF should one and only one >> instance, i.e. >> >> ::= < AVP Header: 260 > >> < Vendor-Id > >> 0*1{ Auth-Application-Id } >> 0*1{ Acct-Application-Id } >> >> Issue 20 : Determining an offending/invalid AVP contained within >> the group AVP >> Proposals: Do nothing. The AVP code should be enough. >> Existing proposals may needlessly extend >> the length of the Failed-AVP. >> >> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >> Proposals: Change diameter-message definition in Sec 3.2 >> to: >> >> diameter-message=header[*fixed][*required][*optional] >> >> Open Issues with no consensus on proposals: >> ------------------------------------------ >> >> Issue 21 : URI schemes for AAA >> Proposals: draft-garcia-dime-aaa-uri-00.txt >> >> Issue 4 : Proxy agent stay in the path of the request message of >> a session >> Proposals: draft-tsou-dime-routing-ext-00.txt >> >> Open Issues that needs proposals: >> -------------------------------- >> >> Notes: These issues did not receive any comments during IETF66 and >> have no pending proposals. >> >> Issue 1 : Advertising relay application id (0xffffffff) in >> auth-application-id or acct-application-id >> >> Issue 15 : Duplicate detection requires server side storage of >> e2e id and origin-host avp >> >> Issue 13 : Clarify usage of application id avp's and how they >> relate to the app-id in the header >> >> Issue 9 & 19 : Error codes defined in wrong category >> >> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >> >> Issue 12 : Differing concepts and/or usage of Diameter Identity >> (FQDN + port or FQDN only) >> >> Issue 14 : Explicit text on which error category should have >> error flag (e-bit) set >> >> Issue 18 : Clarify reconnect behavior of peer based on value of >> Disconnect-Cause AVP >> >> Open issues falling into the "New Features" category: >> ---------------------------------------------------- >> >> Note: These features should use the extension procedures defined in >> 3588. >> No comments received in IETF66 meeting. >> >> Issue 23 : Predictive loop detection >> Comments: Optimzation techiniques in detecting loops >> at the succeeding hops >> >> Issue 22 : Fetch data request and location update request. >> Comments: Proposal to include LUR messages into >> base since its reusable in different >> applications >> >> If you believe there are some in-accurate info below, pls let us know. >> >> best regards, >> victor >> >> _______________________________________________ >> 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 Jul 20 07:15:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WVQ-0008PO-8S; Thu, 20 Jul 2006 07:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3WVO-0008KA-V6 for dime@ietf.org; Thu, 20 Jul 2006 07:15:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3WHa-0007Ri-4O for dime@ietf.org; Thu, 20 Jul 2006 07:01:32 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 54F576E0001; Thu, 20 Jul 2006 13:01:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 13:01:29 +0200 Received: from eesmdmw020.eemea.ericsson.se ([159.107.3.34]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 13:01:28 +0200 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: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summary of 3588bis Issues Status Date: Thu, 20 Jul 2006 13:01:27 +0200 Message-ID: <7457D12699374F40BD026D2B1EFFBEC60286C676@eesmdmw020.eemea.ericsson.se> In-Reply-To: <001201c6abe6$a2527ae0$a905120a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summary of 3588bis Issues Status Thread-Index: AcarURPUCmHOhoFtSa2rIXtswv+QEwAlSgKgAADMsAA= From: "German Blanco \(MI/EEM\)" To: , "Victor Fajardo" X-OriginalArrivalTime: 20 Jul 2006 11:01:28.0807 (UTC) FILETIME=[D9E69770:01C6ABEB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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 Hello, it is not possible. In the same way, if you report the error with the top level grouped AVP and the DIAMETER_INVALID_AVP_VALUE, it is not possible to know what happened exactly inside the grouped AVP. So it is a trade off between the two ways to report the error, unless we add something in the Failed-AVP to give more information. The proposed methods seem to "needlessly extend the length of the Failed-AVP". To me this sounds a bit strange, given that reporting the error with the grouped AVP and DIAMETER_INVALID_AVP_VALUE means sending the entire grouped AVP. German. -----Original Message----- From: Rajith R [mailto:rajithr@huawei.com]=20 Sent: jueves, 20 de julio de 2006 12:24 To: 'Victor Fajardo'; German Blanco (MI/EEM) Cc: dime@ietf.org Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summary of 3588bis Issues Status Hi For unsupported AVP, adding the offending (sub) AVP contents to the Failed AVP is ok. A first-occurrence content match will tell you where the error is. However for missing AVP, if you put an example of the (sub) AVP in Failed AVP, how would you know/indicate whether it is missing in the command or in a particular group AVP? Rajith ************************************************************************ **** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, July 19, 2006 7:55 PM >To: German Blanco (MI/EEM) >Cc: dime@ietf.org >Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: >[Dime]Summary of 3588bis Issues Status > >Hi German, > >Comments inline: > >> Victor, >> >> Thanks for the summary! >> >> When you say: >> >>> Issue 20 : Determining an offending/invalid AVP contained within >>> the group AVP >>> Proposals: Do nothing. The AVP code should be enough. >>> Existing proposals may needlessly extend >>> the length of the Failed-AVP. >>> >> >> Is the proposal to indicate in the answer only the code of the=20 >> missing AVP inside the Grouped AVP? >> >> If that is the case, I would suggest this text additions for RFC=20 >> 3558bis (between ">>"s and "<<"s): >> " >> DIAMETER_MISSING_AVP 5005 >> The request did not contain an AVP that is required by the Command >> Code >>or Grouped AVP <> Result-Code AVP, a Failed-AVP AVP SHOULD be included in the=20 >> message. >> The Failed-AVP AVP MUST contain an example of the missing AVP=20 >> complete >> with the Vendor-Id if applicable.>> If the AVP is missing in a >> Grouped >> AVP, only the missing AVP and not the Grouped-AVP will be=20 >> included in >> the Failed-AVP. <> of correct >> minimum length and contain zeroes. >> " >> " >> DIAMETER_AVP_NOT_ALLOWED 5008 >> A message was received with an AVP that MUST NOT be present. The >> Failed-AVP AVP MUST be included and contain a copy of the >> offending AVP.>> If the AVP is present inside a Grouped >> AVP, only the offending AVP and not the Grouped-AVP will be=20 >> included >> in the Failed-AVP. << >> " >> >> "Do nothing" doesn't seem a good idea to me. I would prefer that=20 >> this is clarified, whatever the conclusion is. The long list of=20 >> error codes will not make sense, if we end up not knowing what happened. >> > >I don't have any opinion on this topic but I hope some folks will=20 >comment on your proposal. > >regards, >victor > >> Regards, >> German. >> >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: viernes, 14 de julio de 2006 19:46 >> To: dime@ietf.org >> Subject: [Dime] Summary of 3588bis Issues Status >> >> Folks, >> >> The is a summary of the 3588bis issues discussion during DIME WG=20 >> meeting in IETF66. If you have comments on any of the existing issues >> pls don't hesitate to post it on the DIME list so we can facilitate=20 >> quicker resolution or at least better understanding of the problem.=20 >> We also need some proposals on the open issues if you believe they are truly issues. >> Note that the assigned issue numbers are based on the current tracker >> which is for historical reasons the diameter-interop tracker=20 >> (http://www.tschofenig.priv.at:8080/diameter-interop). >> >> >> Closed Issues: >> ------------- >> >> Issue 6 : TLS version issue >> Comments: interop related problem only. Does not=20 >> affect the >> base spec >> >> Issue 7 : Textual IP address qualify as FQDN >> Comments: Consensus that FQDN is defined as "internet >> name" >> only >> >> Issue 11 : Confusion about use of Proxy-Info AVP for Relay >> Comments: Clarified in Sec 6.2 with the text >> >> "Any Proxy-Info AVPs in the request MUST be added to the >> answer message, in the same order they were present in >> the request." >> >> Open Issues with some consensus on proposals: >> --------------------------------------------- >> >> Notes: These issues have some consensus either during the IETF66 >> meeting and/or in the DIME mailing list. >> >> Issue 2 & 5 : App Ids used by common diameter messages >> Proposals: Use the application id of the current >> application >> >> Issue 3 & 16 : CER/CEA exchange in the open state >> Proposals: Need more consensus on current proposals >> posted in issue 16 >> >> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp >> Proposals: The Vendor-Id ABNF should one and only one >> instance, i.e. >> >> ::=3D < AVP Header: 260 > >> < Vendor-Id > >> 0*1{ Auth-Application-Id } >> 0*1{ Acct-Application-Id } >> >> Issue 20 : Determining an offending/invalid AVP contained within >> the group AVP >> Proposals: Do nothing. The AVP code should be enough. >> Existing proposals may needlessly extend >> the length of the Failed-AVP. >> >> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >> Proposals: Change diameter-message definition in Sec=20 >> 3.2 >> to: >> >> diameter-message=3Dheader[*fixed][*required][*optional] >> >> Open Issues with no consensus on proposals: >> ------------------------------------------ >> >> Issue 21 : URI schemes for AAA >> Proposals: draft-garcia-dime-aaa-uri-00.txt >> >> Issue 4 : Proxy agent stay in the path of the request message of >> a session >> Proposals: draft-tsou-dime-routing-ext-00.txt >> >> Open Issues that needs proposals: >> -------------------------------- >> >> Notes: These issues did not receive any comments during IETF66 and >> have no pending proposals. >> >> Issue 1 : Advertising relay application id (0xffffffff) in >> auth-application-id or acct-application-id >> >> Issue 15 : Duplicate detection requires server side storage of >> e2e id and origin-host avp >> >> Issue 13 : Clarify usage of application id avp's and how they >> relate to the app-id in the header >> >> Issue 9 & 19 : Error codes defined in wrong category >> >> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >> >> Issue 12 : Differing concepts and/or usage of Diameter Identity >> (FQDN + port or FQDN only) >> >> Issue 14 : Explicit text on which error category should have >> error flag (e-bit) set >> >> Issue 18 : Clarify reconnect behavior of peer based on value of >> Disconnect-Cause AVP >> >> Open issues falling into the "New Features" category: >> ---------------------------------------------------- >> >> Note: These features should use the extension procedures defined in=20 >> 3588. >> No comments received in IETF66 meeting. >> >> Issue 23 : Predictive loop detection >> Comments: Optimzation techiniques in detecting loops >> at the succeeding hops >> >> Issue 22 : Fetch data request and location update request. >> Comments: Proposal to include LUR messages into >> base since its reusable in different >> applications >> >> If you believe there are some in-accurate info below, pls let us know. >> >> best regards, >> victor >> >> _______________________________________________ >> 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 Jul 20 08:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XLq-0008LH-5s; Thu, 20 Jul 2006 08:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3XLn-0008Kp-Uo for dime@ietf.org; Thu, 20 Jul 2006 08:09:55 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3WKf-0007Xa-PJ for dime@ietf.org; Thu, 20 Jul 2006 07:04:41 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3W6x-0008If-H4 for dime@ietf.org; Thu, 20 Jul 2006 06:50:37 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P008TR86J90@szxga02-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 19:06:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P002IB86JUZ@szxga02-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 19:06:19 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2P0079S7IVER@szxml03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 18:52:08 +0800 (CST) Date: Thu, 20 Jul 2006 16:19:28 +0530 From: Rajith R To: dime@ietf.org Message-id: <001301c6abea$2d452140$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acar6izBQ7AEXeUDRjSPJcVa45L87Q== X-Spam-Score: -2.6 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Dime] Diameter Error Handling: Violating the rule 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 Hi In most commands, session Id AVP has the rule, i.e. if it is present, it should be present as the first AVP. If this AVP is present, but else where in the msg, what error code would be apt? Rajith **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 20 09:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YPT-00048V-5p; Thu, 20 Jul 2006 09:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3YPH-0003wy-BI for dime@ietf.org; Thu, 20 Jul 2006 09:17:36 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3YHl-0005kc-LX for dime@ietf.org; Thu, 20 Jul 2006 09:09:53 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P00I09EBGME@szxga03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 21:18:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2P00EN7EBF5L@szxga03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 21:18:52 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2P007NYDZHER@szxml03-in.huawei.com> for dime@ietf.org; Thu, 20 Jul 2006 21:11:41 +0800 (CST) Date: Thu, 20 Jul 2006 21:09:02 +0800 From: Tony Zhang Subject: Re: [Dime] Summary of 3588bis Issues Status To: Tolga Asveren , Victor Fajardo , Yoshihiro Ohba Message-id: <004901c6abfd$ac1b6570$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: John.loughney@nokia.com, "STURA, Marco, VF-IT" , 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 All, I suggest ASR,ASA,RAR,RAA use specific application not application 0. now if these command use application 0,it is likely for address command dictionary,not for identifer application. also the application id use for routing,if any message use same,how to assure routing is correct.why should use application id for routing?also when one node support many applications,it is diffcult to address which module process the message. actual the base protocol should define,the application id should how to use. each application document should define which command use which application id,in my opinion is not so good.if i just add one new avp(maybe vendor avp),then should change the application Id,the rule is so complex. Base on this discuss,i think nobody think this is good choice,only donnot want change the code or exist RFC.but i am assure if have rfc3588-bis,we will change our code ,why not use this chance,do a better choice. rfc3588-bis likely one implement guideline,each appliation should follow it,then in future it is easy to extened application. Thanks Tony ----- Original Message ----- From: "Tolga Asveren" To: "Victor Fajardo" ; "Yoshihiro Ohba" Cc: ; ; "STURA, Marco, VF-IT" Sent: Thursday, July 20, 2006 1:00 AM Subject: RE: [Dime] Summary of 3588bis Issues Status > Hi Victor, > > To me it is fine (not preferrable but just fine ;-) ). I just hope that this > can be rephrased in the bis document so that we don't have interoprability > issues in the future with people which did not follow this discussion. > > I don't know whether there is already an issue open related with it, but it > could be an idea to clarify the rules for command code namespace as well. My > reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it seems > not everybody agrees with this and I think this is somehow related with the > issue we are discussing. If the answer to this question is answered in the > bis document in a clear way, I would feel better. > > About routing issue, I think it can be deducted to the generic problem of > "How can a proxy stay on the path during a session", so I believe this is > the question to answer (which we already discussed to some extent in the > context of strict-routing draft review) > > Thanks, > Tolga > > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, July 19, 2006 1:00 PM > > To: Yoshihiro Ohba > > Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; > > dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > Hi, > > > > Comments inline: > > > > > I fully aggree with Marco's statement below as well as Pasi's opinion > > > based on the discussion happened in the past. We should use > > > application identifier 0 for Diameter common messages. > > > > > > On the other hand, the routing issue for established sessions with > > > stateful agents needs to be resolved (this issue is different from > > > Issue 4). I'd suggest creating a separate issue on this, which > > > probably needs explicit routing functionality like Issue 4. > > > > > > > Based on Pasi's historical quotation, I think we can compromise on the > > app id of 0 since it seems like such "interpretation" is already heavily > > entrenched. Though I agree with Yoshi that we still need to fix the > > routing issue as a side effect of this interpretation. In this way, we > > can agree on something without endangering existing standards and move > > forward with other issues. Would this proposal be sufficient for all > > interested parties ? > > > > best regards, > > victor > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT wrote: > > > > > >> Tolga, > > >> > > >> I agree of course with the Victor's proposed approach on how > > to proceed. > > >> > > >> That said I would still comment on some of your statements below and > > >> feed in some more arguments into this thread. > > >> > > >> Regards > > >> Marco > > >> > > >> > > >> > > >>> I believe the point is whether it is RFC3588 or the RFCs you quoted > > >>> > > >> needs >to > > >> > > >>> be fixed. I am puzzled how those RFcs had such statements, which IMO > > >>> clearly > > >>> violate what is said about Application-ID in RFC3588 3. > > Diameter Header > > >>> section. > > >>> > > >> [MSt] I think you refer to this text below > > >> > > >> Application-ID > > >> Application-ID is four octets and is used to identify to which > > >> application the message is applicable for. The > > application can be > > >> an authentication application, an accounting application or a > > >> vendor specific application. See Section 11.3 for the possible > > >> values that the application-id may use. > > >> > > >> The application-id in the header MUST be the same as what is > > >> contained in any relevant AVPs contained in the message. > > >> > > >> [MSt] If you look in to section 11.3 you find Diameter Common Messages > > >> with app id 0. Obviously the Diameter Common Messages are those defined > > >> in the base protocol. The above text, simply means that both > > >> Application-Id in the message header and the Auth-Application-Id AVP > > >> have to be set to the same value that is 0 (zero) for common messages. > > >> So I really don't think that all the existing RFCs violate the base > > >> protocol since all of them are consistent, rather I think that some > > >> implementation of RFC 3588 may not be compliant and I don't see why we > > >> should change all the existing RFCs and application > > implementations that > > >> may be deployed out there (on top of clean base protocol) as opposed to > > >> someone fixing their bogus RFC 3588 implementations. > > >> > > >> > > >>> Another point is that considering existing few applications you > > >>> > > >> mentioned >is > > >> > > >>> not really enough. There are also diameter base stack implementations, > > >>> which > > >>> conform to RFC3588 and provide generic capability for any type of > > >>> application. > > >>> > > >> [MSt] See my comment above. > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 Jul 20 11:17:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aGv-0001qw-FT; Thu, 20 Jul 2006 11:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3aGs-0001kf-7i for dime@ietf.org; Thu, 20 Jul 2006 11:17:02 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3a2B-0007qY-JY for dime@ietf.org; Thu, 20 Jul 2006 11:01:52 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 17:01:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE:[Dime]Summary of 3588bis Issues Status Date: Thu, 20 Jul 2006 17:01:45 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603A9E427@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 20 (offending AVP inside a Grouped AVP) was:RE:[Dime]Summary of 3588bis Issues Status Thread-Index: AcarURPUCmHOhoFtSa2rIXtswv+QEwAlSgKgAADMsAAAB1BcYA== From: "MORAND Lionel RD-CORE-ISS" To: "German Blanco \(MI/EEM\)" , , "Victor Fajardo" X-OriginalArrivalTime: 20 Jul 2006 15:01:49.0746 (UTC) FILETIME=[6D734120:01C6AC0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 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 The Failed-AVP AVP is used to provide information about = missing/offending AVPs. Nothing else. As it is described What would be the added-value to distinguish problems due to stand-alone = AVPs from (sub)AVPs of Grouped AVP? All the AVPs required to support the base diameter and specific = applications are published in a library. The ABNF description of each supported command is given in base diameter = and specific diameter applications specs. What is missing to handle error report? About the given examples: For DIAMETER_INVALID_AVP_VALUE, the Failed-AVP AVP will carry a copy of = the offending AVP (stand-alone AVP or (sub)AVP). It is here possible to check in the library the value allowed for this = AVP. For DIAMETER_MISSING_AVP, the Failed-AVP AVP will carry an example of = the missing AVP (stand-alone AVP or (sub) AVP), whit the expected AVP = code. It is here possible to refer to the command ABNF description to discover = the problem (e.g. wrong implementation of the command). =20 BR, Lionel -----Message d'origine----- De : German Blanco (MI/EEM) [mailto:german.blanco@ericsson.com]=20 Envoy=E9 : jeudi 20 juillet 2006 13:01 =C0 : rajithr@huawei.com; Victor Fajardo Cc : dime@ietf.org Objet : RE: Issue 20 (offending AVP inside a Grouped AVP) = was:RE:[Dime]Summary of 3588bis Issues Status Hello, it is not possible. In the same way, if you report the error with the top level grouped AVP = and the DIAMETER_INVALID_AVP_VALUE, it is not possible to know what = happened exactly inside the grouped AVP. So it is a trade off between the two ways to report the error, unless we = add something in the Failed-AVP to give more information. The proposed = methods seem to "needlessly extend the length of the Failed-AVP". To me = this sounds a bit strange, given that reporting the error with the = grouped AVP and DIAMETER_INVALID_AVP_VALUE means sending the entire = grouped AVP. German. -----Original Message----- From: Rajith R [mailto:rajithr@huawei.com] Sent: jueves, 20 de julio de 2006 12:24 To: 'Victor Fajardo'; German Blanco (MI/EEM) Cc: dime@ietf.org Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summary of 3588bis Issues Status Hi For unsupported AVP, adding the offending (sub) AVP contents to the = Failed AVP is ok. A first-occurrence content match will tell you where = the error is. However for missing AVP, if you put an example of the (sub) AVP in = Failed AVP, how would you know/indicate whether it is missing in the = command or in a particular group AVP? Rajith ************************************************************************ **** This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended recipient's) is = prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it! >-----Original Message----- >From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >Sent: Wednesday, July 19, 2006 7:55 PM >To: German Blanco (MI/EEM) >Cc: dime@ietf.org >Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: >[Dime]Summary of 3588bis Issues Status > >Hi German, > >Comments inline: > >> Victor, >> >> Thanks for the summary! >> >> When you say: >> >>> Issue 20 : Determining an offending/invalid AVP contained within >>> the group AVP >>> Proposals: Do nothing. The AVP code should be enough. >>> Existing proposals may needlessly extend >>> the length of the Failed-AVP. >>> >> >> Is the proposal to indicate in the answer only the code of the=20 >> missing AVP inside the Grouped AVP? >> >> If that is the case, I would suggest this text additions for RFC=20 >> 3558bis (between ">>"s and "<<"s): >> " >> DIAMETER_MISSING_AVP 5005 >> The request did not contain an AVP that is required by the Command >> Code >>or Grouped AVP <> Result-Code AVP, a Failed-AVP AVP SHOULD be included in the=20 >> message. >> The Failed-AVP AVP MUST contain an example of the missing AVP=20 >> complete >> with the Vendor-Id if applicable.>> If the AVP is missing in a >> Grouped >> AVP, only the missing AVP and not the Grouped-AVP will be=20 >> included in >> the Failed-AVP. <> of correct >> minimum length and contain zeroes. >> " >> " >> DIAMETER_AVP_NOT_ALLOWED 5008 >> A message was received with an AVP that MUST NOT be present. The >> Failed-AVP AVP MUST be included and contain a copy of the >> offending AVP.>> If the AVP is present inside a Grouped >> AVP, only the offending AVP and not the Grouped-AVP will be=20 >> included >> in the Failed-AVP. << >> " >> >> "Do nothing" doesn't seem a good idea to me. I would prefer that=20 >> this is clarified, whatever the conclusion is. The long list of=20 >> error codes will not make sense, if we end up not knowing what happened. >> > >I don't have any opinion on this topic but I hope some folks will=20 >comment on your proposal. > >regards, >victor > >> Regards, >> German. >> >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: viernes, 14 de julio de 2006 19:46 >> To: dime@ietf.org >> Subject: [Dime] Summary of 3588bis Issues Status >> >> Folks, >> >> The is a summary of the 3588bis issues discussion during DIME WG=20 >> meeting in IETF66. If you have comments on any of the existing issues >> pls don't hesitate to post it on the DIME list so we can facilitate=20 >> quicker resolution or at least better understanding of the problem. >> We also need some proposals on the open issues if you believe they are truly issues. >> Note that the assigned issue numbers are based on the current tracker >> which is for historical reasons the diameter-interop tracker=20 >> (http://www.tschofenig.priv.at:8080/diameter-interop). >> >> >> Closed Issues: >> ------------- >> >> Issue 6 : TLS version issue >> Comments: interop related problem only. Does not=20 >> affect the >> base spec >> >> Issue 7 : Textual IP address qualify as FQDN >> Comments: Consensus that FQDN is defined as "internet >> name" >> only >> >> Issue 11 : Confusion about use of Proxy-Info AVP for Relay >> Comments: Clarified in Sec 6.2 with the text >> >> "Any Proxy-Info AVPs in the request MUST be added to the >> answer message, in the same order they were present in >> the request." >> >> Open Issues with some consensus on proposals: >> --------------------------------------------- >> >> Notes: These issues have some consensus either during the IETF66 >> meeting and/or in the DIME mailing list. >> >> Issue 2 & 5 : App Ids used by common diameter messages >> Proposals: Use the application id of the current >> application >> >> Issue 3 & 16 : CER/CEA exchange in the open state >> Proposals: Need more consensus on current proposals >> posted in issue 16 >> >> Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp >> Proposals: The Vendor-Id ABNF should one and only one >> instance, i.e. >> >> ::=3D < AVP Header: 260 > >> < Vendor-Id > >> 0*1{ Auth-Application-Id } >> 0*1{ Acct-Application-Id } >> >> Issue 20 : Determining an offending/invalid AVP contained within >> the group AVP >> Proposals: Do nothing. The AVP code should be enough. >> Existing proposals may needlessly extend >> the length of the Failed-AVP. >> >> Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 >> Proposals: Change diameter-message definition in Sec >> 3.2 >> to: >> >> diameter-message=3Dheader[*fixed][*required][*optional] >> >> Open Issues with no consensus on proposals: >> ------------------------------------------ >> >> Issue 21 : URI schemes for AAA >> Proposals: draft-garcia-dime-aaa-uri-00.txt >> >> Issue 4 : Proxy agent stay in the path of the request message of >> a session >> Proposals: draft-tsou-dime-routing-ext-00.txt >> >> Open Issues that needs proposals: >> -------------------------------- >> >> Notes: These issues did not receive any comments during IETF66 and >> have no pending proposals. >> >> Issue 1 : Advertising relay application id (0xffffffff) in >> auth-application-id or acct-application-id >> >> Issue 15 : Duplicate detection requires server side storage of >> e2e id and origin-host avp >> >> Issue 13 : Clarify usage of application id avp's and how they >> relate to the app-id in the header >> >> Issue 9 & 19 : Error codes defined in wrong category >> >> Issue 8 : Setting error flag (e-bit) during CER/CEA exchange >> >> Issue 12 : Differing concepts and/or usage of Diameter Identity >> (FQDN + port or FQDN only) >> >> Issue 14 : Explicit text on which error category should have >> error flag (e-bit) set >> >> Issue 18 : Clarify reconnect behavior of peer based on value of >> Disconnect-Cause AVP >> >> Open issues falling into the "New Features" category: >> ---------------------------------------------------- >> >> Note: These features should use the extension procedures defined in=20 >> 3588. >> No comments received in IETF66 meeting. >> >> Issue 23 : Predictive loop detection >> Comments: Optimzation techiniques in detecting loops >> at the succeeding hops >> >> Issue 22 : Fetch data request and location update request. >> Comments: Proposal to include LUR messages into >> base since its reusable in different >> applications >> >> If you believe there are some in-accurate info below, pls let us know. >> >> best regards, >> victor >> >> _______________________________________________ >> 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 Jul 20 11:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3asd-0004wk-IW; Thu, 20 Jul 2006 11:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3asb-0004uf-Oi for dime@ietf.org; Thu, 20 Jul 2006 11:56:01 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3asU-0001RI-Vq for dime@ietf.org; Thu, 20 Jul 2006 11:56:01 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6KFtsI7022132 for ; Thu, 20 Jul 2006 17:55:54 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jul 2006 17:55:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 20 Jul 2006 17:55:51 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC207B93054@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acar/reE+VIYSRZ7Te+25XHQYJ7CjQADrxbAAAHTtXA= From: "STURA, Marco, VF-IT" To: "Tony Zhang" X-OriginalArrivalTime: 20 Jul 2006 15:55:51.0993 (UTC) FILETIME=[F9FAE290:01C6AC14] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: John.loughney@nokia.com, 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 ----- Re-sending ----- Hi Tony, I thought there was agreement now on this list for app id 0 for several = reasons one being that those are common messages. All your arguments have been discussed already. Thank you Marco -----Original Message----- From: STURA, Marco, VF-IT=20 Sent: gioved=EC 20 luglio 2006 17.05 To: 'Tony Zhang'; Tolga Asveren; Victor Fajardo; Yoshihiro Ohba Cc: John.loughney@nokia.com; dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Hi Tony, I thought there was agreement now on this list for app id 0 for several = reasons one being that those are common messages. All your arguments has been discussed already. Thank you Marco -----Original Message----- From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 Sent: gioved=EC 20 luglio 2006 15.09 To: Tolga Asveren; Victor Fajardo; Yoshihiro Ohba Cc: John.loughney@nokia.com; dime@ietf.org; STURA, Marco, VF-IT Subject: Re: [Dime] Summary of 3588bis Issues Status HI All, I suggest ASR,ASA,RAR,RAA use specific application not application = 0. now if these command use application 0,it is likely for address = command dictionary,not for identifer application. also the application id use for routing,if any message use same,how = to assure routing is correct.why should use application id for = routing?also when one node support many applications,it is diffcult to = address which module process the message. actual the base protocol should define,the application id should = how to use.=20 each application document should define which command use which = application id,in my opinion is not so good.if i just add one new = avp(maybe vendor avp),then should change the application Id,the rule is = so complex. Base on this discuss,i think nobody think this is good choice,only = donnot want change the code or exist RFC.but i am assure if have = rfc3588-bis,we will change our code ,why not use this chance,do a better = choice. rfc3588-bis likely one implement guideline,each appliation should = follow it,then in future it is easy to extened application. Thanks=20 Tony ----- Original Message -----=20 From: "Tolga Asveren" To: "Victor Fajardo" ; "Yoshihiro Ohba" = Cc: ; ; "STURA, Marco, VF-IT" = Sent: Thursday, July 20, 2006 1:00 AM Subject: RE: [Dime] Summary of 3588bis Issues Status > Hi Victor, >=20 > To me it is fine (not preferrable but just fine ;-) ). I just hope = that this > can be rephrased in the bis document so that we don't have = interoprability > issues in the future with people which did not follow this discussion. >=20 > I don't know whether there is already an issue open related with it, = but it > could be an idea to clarify the rules for command code namespace as = well. My > reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it = seems > not everybody agrees with this and I think this is somehow related = with the > issue we are discussing. If the answer to this question is answered in = the > bis document in a clear way, I would feel better. >=20 > About routing issue, I think it can be deducted to the generic problem = of > "How can a proxy stay on the path during a session", so I believe this = is > the question to answer (which we already discussed to some extent in = the > context of strict-routing draft review) >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, July 19, 2006 1:00 PM > > To: Yoshihiro Ohba > > Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; > > dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > Hi, > > > > Comments inline: > > > > > I fully aggree with Marco's statement below as well as Pasi's = opinion > > > based on the discussion happened in the past. We should use > > > application identifier 0 for Diameter common messages. > > > > > > On the other hand, the routing issue for established sessions with > > > stateful agents needs to be resolved (this issue is different from > > > Issue 4). I'd suggest creating a separate issue on this, which > > > probably needs explicit routing functionality like Issue 4. > > > > > > > Based on Pasi's historical quotation, I think we can compromise on = the > > app id of 0 since it seems like such "interpretation" is already = heavily > > entrenched. Though I agree with Yoshi that we still need to fix the > > routing issue as a side effect of this interpretation. In this way, = we > > can agree on something without endangering existing standards and = move > > forward with other issues. Would this proposal be sufficient for all > > interested parties ? > > > > best regards, > > victor > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT = wrote: > > > > > >> Tolga, > > >> > > >> I agree of course with the Victor's proposed approach on how > > to proceed. > > >> > > >> That said I would still comment on some of your statements below = and > > >> feed in some more arguments into this thread. > > >> > > >> Regards > > >> Marco > > >> > > >> > > >> > > >>> I believe the point is whether it is RFC3588 or the RFCs you = quoted > > >>> > > >> needs >to > > >> > > >>> be fixed. I am puzzled how those RFcs had such statements, which = IMO > > >>> clearly > > >>> violate what is said about Application-ID in RFC3588 3. > > Diameter Header > > >>> section. > > >>> > > >> [MSt] I think you refer to this text below > > >> > > >> Application-ID > > >> Application-ID is four octets and is used to identify to = which > > >> application the message is applicable for. The > > application can be > > >> an authentication application, an accounting application or = a > > >> vendor specific application. See Section 11.3 for the = possible > > >> values that the application-id may use. > > >> > > >> The application-id in the header MUST be the same as what = is > > >> contained in any relevant AVPs contained in the message. > > >> > > >> [MSt] If you look in to section 11.3 you find Diameter Common = Messages > > >> with app id 0. Obviously the Diameter Common Messages are those = defined > > >> in the base protocol. The above text, simply means that both > > >> Application-Id in the message header and the Auth-Application-Id = AVP > > >> have to be set to the same value that is 0 (zero) for common = messages. > > >> So I really don't think that all the existing RFCs violate the = base > > >> protocol since all of them are consistent, rather I think that = some > > >> implementation of RFC 3588 may not be compliant and I don't see = why we > > >> should change all the existing RFCs and application > > implementations that > > >> may be deployed out there (on top of clean base protocol) as = opposed to > > >> someone fixing their bogus RFC 3588 implementations. > > >> > > >> > > >>> Another point is that considering existing few applications you > > >>> > > >> mentioned >is > > >> > > >>> not really enough. There are also diameter base stack = implementations, > > >>> which > > >>> conform to RFC3588 and provide generic capability for any type = of > > >>> application. > > >>> > > >> [MSt] See my comment above. > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 Thu Jul 20 11:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3auJ-00063F-EM; Thu, 20 Jul 2006 11:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ast-0004yg-F8 for dime@ietf.org; Thu, 20 Jul 2006 11:56:19 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3a5Q-0008FI-0s for dime@ietf.org; Thu, 20 Jul 2006 11:05:12 -0400 Received: from omini94.omnitel.it (omini94.omnitel.it [10.21.18.146]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6KF59I7007809 for ; Thu, 20 Jul 2006 17:05:09 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Jul 2006 17:05:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 20 Jul 2006 17:04:52 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133BE@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acar/reE+VIYSRZ7Te+25XHQYJ7CjQADrxbA From: "STURA, Marco, VF-IT" To: "Tony Zhang" , "Tolga Asveren" , "Victor Fajardo" , "Yoshihiro Ohba" X-OriginalArrivalTime: 20 Jul 2006 15:05:05.0993 (UTC) FILETIME=[E26C2B90:01C6AC0D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: John.loughney@nokia.com, 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 Tony, I thought there was agreement now on this list for app id 0 for several = reasons one being that those are common messages. All your arguments has been discussed already. Thank you Marco -----Original Message----- From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 Sent: gioved=EC 20 luglio 2006 15.09 To: Tolga Asveren; Victor Fajardo; Yoshihiro Ohba Cc: John.loughney@nokia.com; dime@ietf.org; STURA, Marco, VF-IT Subject: Re: [Dime] Summary of 3588bis Issues Status HI All, I suggest ASR,ASA,RAR,RAA use specific application not application = 0. now if these command use application 0,it is likely for address = command dictionary,not for identifer application. also the application id use for routing,if any message use same,how = to assure routing is correct.why should use application id for = routing?also when one node support many applications,it is diffcult to = address which module process the message. actual the base protocol should define,the application id should = how to use.=20 each application document should define which command use which = application id,in my opinion is not so good.if i just add one new = avp(maybe vendor avp),then should change the application Id,the rule is = so complex. Base on this discuss,i think nobody think this is good choice,only = donnot want change the code or exist RFC.but i am assure if have = rfc3588-bis,we will change our code ,why not use this chance,do a better = choice. rfc3588-bis likely one implement guideline,each appliation should = follow it,then in future it is easy to extened application. Thanks=20 Tony ----- Original Message -----=20 From: "Tolga Asveren" To: "Victor Fajardo" ; "Yoshihiro Ohba" = Cc: ; ; "STURA, Marco, VF-IT" = Sent: Thursday, July 20, 2006 1:00 AM Subject: RE: [Dime] Summary of 3588bis Issues Status > Hi Victor, >=20 > To me it is fine (not preferrable but just fine ;-) ). I just hope = that this > can be rephrased in the bis document so that we don't have = interoprability > issues in the future with people which did not follow this discussion. >=20 > I don't know whether there is already an issue open related with it, = but it > could be an idea to clarify the rules for command code namespace as = well. My > reading of RFC3588 "11.2.1 Command Codes" is that it is flat but it = seems > not everybody agrees with this and I think this is somehow related = with the > issue we are discussing. If the answer to this question is answered in = the > bis document in a clear way, I would feel better. >=20 > About routing issue, I think it can be deducted to the generic problem = of > "How can a proxy stay on the path during a session", so I believe this = is > the question to answer (which we already discussed to some extent in = the > context of strict-routing draft review) >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: Wednesday, July 19, 2006 1:00 PM > > To: Yoshihiro Ohba > > Cc: STURA, Marco, VF-IT; Tolga Asveren; John.loughney@nokia.com; > > dime@ietf.org > > Subject: Re: [Dime] Summary of 3588bis Issues Status > > > > > > Hi, > > > > Comments inline: > > > > > I fully aggree with Marco's statement below as well as Pasi's = opinion > > > based on the discussion happened in the past. We should use > > > application identifier 0 for Diameter common messages. > > > > > > On the other hand, the routing issue for established sessions with > > > stateful agents needs to be resolved (this issue is different from > > > Issue 4). I'd suggest creating a separate issue on this, which > > > probably needs explicit routing functionality like Issue 4. > > > > > > > Based on Pasi's historical quotation, I think we can compromise on = the > > app id of 0 since it seems like such "interpretation" is already = heavily > > entrenched. Though I agree with Yoshi that we still need to fix the > > routing issue as a side effect of this interpretation. In this way, = we > > can agree on something without endangering existing standards and = move > > forward with other issues. Would this proposal be sufficient for all > > interested parties ? > > > > best regards, > > victor > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Wed, Jul 19, 2006 at 05:03:42PM +0200, STURA, Marco, VF-IT = wrote: > > > > > >> Tolga, > > >> > > >> I agree of course with the Victor's proposed approach on how > > to proceed. > > >> > > >> That said I would still comment on some of your statements below = and > > >> feed in some more arguments into this thread. > > >> > > >> Regards > > >> Marco > > >> > > >> > > >> > > >>> I believe the point is whether it is RFC3588 or the RFCs you = quoted > > >>> > > >> needs >to > > >> > > >>> be fixed. I am puzzled how those RFcs had such statements, which = IMO > > >>> clearly > > >>> violate what is said about Application-ID in RFC3588 3. > > Diameter Header > > >>> section. > > >>> > > >> [MSt] I think you refer to this text below > > >> > > >> Application-ID > > >> Application-ID is four octets and is used to identify to = which > > >> application the message is applicable for. The > > application can be > > >> an authentication application, an accounting application or = a > > >> vendor specific application. See Section 11.3 for the = possible > > >> values that the application-id may use. > > >> > > >> The application-id in the header MUST be the same as what = is > > >> contained in any relevant AVPs contained in the message. > > >> > > >> [MSt] If you look in to section 11.3 you find Diameter Common = Messages > > >> with app id 0. Obviously the Diameter Common Messages are those = defined > > >> in the base protocol. The above text, simply means that both > > >> Application-Id in the message header and the Auth-Application-Id = AVP > > >> have to be set to the same value that is 0 (zero) for common = messages. > > >> So I really don't think that all the existing RFCs violate the = base > > >> protocol since all of them are consistent, rather I think that = some > > >> implementation of RFC 3588 may not be compliant and I don't see = why we > > >> should change all the existing RFCs and application > > implementations that > > >> may be deployed out there (on top of clean base protocol) as = opposed to > > >> someone fixing their bogus RFC 3588 implementations. > > >> > > >> > > >>> Another point is that considering existing few applications you > > >>> > > >> mentioned >is > > >> > > >>> not really enough. There are also diameter base stack = implementations, > > >>> which > > >>> conform to RFC3588 and provide generic capability for any type = of > > >>> application. > > >>> > > >> [MSt] See my comment above. > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 Thu Jul 20 16:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3exV-00072C-LE; Thu, 20 Jul 2006 16:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ewr-0006WB-1m for dime@ietf.org; Thu, 20 Jul 2006 16:16:41 -0400 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 1G3emI-0002uR-9E for dime@ietf.org; Thu, 20 Jul 2006 16:05:47 -0400 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 k6KK4v5g078499; Thu, 20 Jul 2006 16:04:57 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44BFE1EA.40305@tari.toshiba.com> Date: Thu, 20 Jul 2006 16:04:58 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] IETF#66 Meeting Minutes References: <44BE47E7.5040900@gmx.net> <003201c6abf6$2bf1cfd0$51e06a9c@IBM4307EA0CEF3> In-Reply-To: <003201c6abf6$2bf1cfd0$51e06a9c@IBM4307EA0CEF3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 all, I apologize for the meeting minutes since it is a bit terse. The status of certain discussion was not captured well. I'll attempt to do some follow up and hopefully recuperate pertinent information. I can start with "Diameter Routing Extensions" draft, the summary is: * Diameter Routing Extensions http://www.ietf.org/internet-drafts/draft-tsou-dime-base-routing-ext Presented by Tina Tsou Slides can be found here: http://www3.ietf.org/proceedings/06jul/slides/dime-11.ppt Discussion: -------------- - John: Ongoing discussion in the mailing list - Glen: Would this extension be optional ? - Tina: Yes - John, voting by Hum: Showed no consensus and further discussion can be brought to the mailing list. Work needs to continue. BR, victor > Hi all, > I think conclusion of * Diameter Routing Extensions could be that it > needs to be improved with the next IETF meeting. > > B. R. > Tina > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: > Sent: Wednesday, July 19, 2006 10:55 PM > Subject: [Dime] IETF#66 Meeting Minutes > > >> Hi all, >> >> please take a look at the meeting minutes: >> http://www3.ietf.org/proceedings/06jul/minutes/dime.txt >> >> 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 Jul 20 23:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3lwe-0002mK-K8; Thu, 20 Jul 2006 23:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3lwd-0002mF-Rp for dime@ietf.org; Thu, 20 Jul 2006 23:44:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3lwb-0000VI-UX for dime@ietf.org; Thu, 20 Jul 2006 23:44:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q007W7ISAA4@szxga03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 11:52:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q00MYOIS9ZW@szxga03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 11:52:58 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Q0075DIGBIE@szxml03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 11:45:48 +0800 (CST) Date: Fri, 21 Jul 2006 11:43:07 +0800 From: Tony Zhang Subject: Re: [Dime] Summary of 3588bis Issues Status To: "STURA, Marco, VF-IT" , Tolga Asveren , Victor Fajardo Message-id: <01a701c6ac77$c7e70690$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <5371BE300539E6439919CF97203DDEC2077133AE@OIVMEXO01.omnitel.it> X-Spam-Score: 0.9 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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="===============0302659203==" Errors-To: dime-bounces@ietf.org --===============0302659203== Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgTWFjcm86DQoNCltNU3RdIEkgdGhpbmsgeW91IGFzc3VtZSBQMSBhbmQgUDIgYWR2ZXJ0aXNl IHN1cHBvcnRzIGZvciBBcHAgeC95IGFuZCBBcHAgeiByZXNwZWN0aXZlbHkgYnV0IEkgd291bGQg cmF0aGVyIGNvbnNpZGVyIHRoaXMgY29uZmlndXJhdGlvbiBhbiBhY2FkZW1pYyB1c2UgY2FzZSBz aW5jZSB0eXBpY2FsbHkgeW91IGhhdmUgb25seSBvbmUgbG9naWNhbCBQcm94eSBhcyBhIGludGVy Y29ubmVjdCBwb2ludCBmb3IgYSBnaXZlbiByZWFsbSBpbiByZWFsIGRlcGxveW1lbnRzIGFzIGEg Y2VudHJhbCBwb2ludCBmb3IgcG9saWN5IGVuZm9yY2VtZW50LiBIb3dldmVyLCBsZXQgc2VlIHdo ZXRoZXIgYSBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2UgdXNpbmcgRGVzdGluYXRpb24tSG9zdCBh bmQgYXBwIGlkIDAgYmFzZWQgcm91dGluZyB3b3Jrcy4NCg0KUzEgc2VuZHMgQVNSIHRvIEMzIChD MyBkaWFtZXRlciBpZGVudGl0eSBpbiBEZXN0aW5hdGlvbi1Ib3N0IEFWUCkgYXBwIGlkIDAuIElu IHRoZSByZWFsbS1iYXNlZCByb3V0aW5nIHRhYmxlIFIxIHdpbGwgY2VydGFpbmx5IGZpbmQgYSBt YXRjaCBmb3IgcmVhbG0gQSBhbmQgYXBwIGlkIDAsIHNheSBmb3IgaW5zdGFuY2UgdGhlIG1hdGNo IGlzIGZvciBQMS4gQVNSIGlzIHJvdXRlZCB0byBQMSwgd2hpY2ggZG9lc24ndCBoYXZlIEMzIGlu IGl0cyBwZWVyIHRhYmxlIGFuZCB0aGVuIGFuc3dlcnMgd2l0aCBESUFNRVRFUl9VTkFCTEVfVE9f REVMSVZFUi4gUjEgYXR0ZW1wdHMgdGhlbiB0byBkZWxpdmVyIHRoZSBtZXNzYWdlIHZpYSB0aGUg YWx0ZXJuYXRpdmUgZW50cnkgZm9yIFJlYWxtIEEsIGhlbmNlIFAyLiBQMiBub3cgZGVsaXZlciB0 aGUgbWVzc2FnZSB0byBDMy4gU28sIGFwcC1pZCAwIHdvcmtzIGF0IHRoZSBlbmQgaWYgRGVzdGlu YXRpb24tSG9zdCBiYXNlZCByb3V0aW5nIGlzIHVzZWQgYW5kLCBhY3R1YWxseSwgaXMgdG8gYmUg dXNlZCBmb3IgY2VydGFpbiBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIGFzIGFsc28gZGVmaW5l ZCBpbiBSRkMgMzU4OCBpbiBzZWN0aW9uIDYuMS4gDQoNCltUb255XUJlY2F1c2UgdGhlIEFwcGxp Y2F0aW9uIElkIDAsbm90IGFkdmVydGlzZW1lbnQgaW4gQ0VSL0NFQSxzbyBpdCBtZWFucyBlYWNo IHJlYWxtIHdpbGwgdXNlIHRoZSBwZWV0IHRhYmxlIHNlbGVjdCBuZXh0IGhvcCxhbG1vc3QgcGVl ciB0YWJsZSBoYXZlIG1hbnkgcGVlciBjYW4gc2VsZWN0LGFsc28gaW5jbHVkZSBwZWVyIG9mIHJl Y2VpdmUgdGhlIHJlcXVlc3QuIHNvIGl0IGNhbiBoYXBwZW4gbG9vcCByb3V0aW5nLihtYXliZSBj YW4gYWRkIG9uZSBwcm9jZXNzIGF2b2lkIHRoaXMsd2hlbiByb3V0aW5nIHNob3VsZCBpbnB1dCBw ZWVyIG5hbWUgb2YgcmVjZWl2ZSB0aGUgcmVxdWVzdC4pLnRoZSBvdGhlciBwcm9ibGVtLGFmdGVy IHJldHJ5IG1hbnkgcGVlciAsdGhlbiB3ZSBmaW5kIGNvcnJlY3Qgcm91dGUsaXQgY29uc3VtZSBs b25nIHRpbWUsbWF5YmUgdGhlIGNsaWVudCBhbHJlYWR5IHRpbWVyIGV4cGlyZS5hbHNvIGFwcGxp Y2F0aW9uIGlkIHVzZSBmb3IgZWZmZWN0aXZlbHkgcm91dGluZyxidXQgZm9yIGFib3ZlIHRoZSBj YXNlICxpdCBpcyBub3QgbGlrZSB0aGlzLg0KDQpzb3JyeSBhYm91dCBpIGRpc2N1c3MgdGhpcyBh Z2FpbixhZnRlciAyMDA0J3MgZGljdXNzLGl0IGlzIGxpa2VseSBtYW55IHBlb3BsZSBjb25mdXNp b24uaWYgdGhpcyB0aW1lIGhhdmUgc2FtZSBjb25sdXNpb24gbWF5YmUgc3RpbGwgaGF2ZSBzYW1l IHByb2JsZW0uDQoNClRoYW5rcyENClRvbnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJTVFVSQSwgTWFyY28sIFZGLUlUIiA8TWFyY28uU1RVUkFAdm9kYWZvbmUuY29t Pg0KVG86ICJUb2xnYSBBc3ZlcmVuIiA8YXN2ZXJlbkB1bHRpY29tLmNvbT47ICJWaWN0b3IgRmFq YXJkbyIgPHZmYWphcmRvQHRhcmkudG9zaGliYS5jb20+DQpDYzogPGRpbWVAaWV0Zi5vcmc+DQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMDYgNToxMSBQTQ0KU3ViamVjdDogUkU6IFtEaW1l XSBTdW1tYXJ5IG9mIDM1ODhiaXMgSXNzdWVzIFN0YXR1cw0KDQoNClNlZSBpbiBsaW5lLg0KDQpS ZWdhcmRzDQpNYXJjbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9sZ2Eg QXN2ZXJlbiBbbWFpbHRvOmFzdmVyZW5AdWx0aWNvbS5jb21dIA0KU2VudDogbWFydGVk7CAxOCBs dWdsaW8gMjAwNiAxOC41Mg0KVG86IFNUVVJBLCBNYXJjbywgVkYtSVQ7IFZpY3RvciBGYWphcmRv DQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBTdW1tYXJ5IG9mIDM1ODhi aXMgSXNzdWVzIFN0YXR1cw0KDQpbLi4gc25pcCAuLl0NCj4gSSBhZ3JlZSB3aXRoIHlvdXIgZXhh bXBsZSBhYm92ZSByZWdhcmRpbmcgZGVzdGluYXRpb24taG9zdC4gSXQgaXMNCj4gcmVxdWlyZWQg aW4gdGhlIGNhc2Ugb2YgQVNSIChhbmQgcGVyaGFwcyBzb21lIG90aGVyIG1lc3NhZ2UpIHRob3Vn aCBJDQo+IGd1ZXNzIEkgd2FzIHN0YXRpbmcgYSBjYXNlIHdoaWNoIGlzIGEgbGl0dGxlIGJpdCBk aWZmZXJlbnQgdGhhbiB5b3VyDQo+IGV4YW1wbGUgYWJvdmUuIEkgd2FzIHRoaW5raW5nIG9mIHRo ZSBmb2xsb3dpbmcgY2FzZToNCj4NCj4gY2xpZW50c1sxLDIsMy4uLnhdIDwtLS0gcmVsYXkxIDwt LS0tIHJlbGF5MiA8LS0tLSBzZXJ2ZXINCj4NCj4gaW4gdGhpcyBjYXNlIHJlbGF5MiB3aWxsIG5v dCBiZSBhYmxlIHRvIHJvdXRlIHVzaW5nIGRlc3QtaG9zdC4gVGhpcyBpcw0KPiB3aGVyZSBkZXN0 LXJlYWxtIGFuZCBhcHAgaWQgYmVjb21lcyBpbXBvcnRhbnQuIEluIHRoaXMgY2FzZSBhcHAgaWQg b2YgMA0KPiBtaWdodCBub3Qgd29yayBhcyB3ZWxsIC4uLiBvciBtYXliZSBJJ20gd3JvbmcuDQo+ DQo+IFtNU3RdIEluIHRoaXMgY2FzZSBSMSB3b3VsZCBhZHZlcnRpc2UgaXQgc2VsZiBhcyBhIHJl bGF5IChpLmUuDQo+IDB4ZmZmZmZmZmYpIGl0IHdvbid0IGFkdmVydGlzZSBhcHAgaWQgeCBvciB5 IG9yIHouIFNvLCBhbnkgYXBwIGlkDQo+IHdvdWxkIGJlIHJvdXRlZCB0byBSMSBieSBSMi4NCltU T0xHQV0gTGV0IG1lIHRyeSB0byBmdXJ0aGVyIHJlZmluZSB0aGUgc2NlbmFyaW86DQogICAgICAg ICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICogIFJl YWxtIEEgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICAgICAg ICAgICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAq DQogICAgICAgICAgICAgICogICAgICAgICstLStDMSBBcHA9WCB8ICAgICAqDQogICAgICAgICAg ICAgICogKy0tLS0rIHwgICstLS0tLS0tLS0rICAgICAqDQogICAgICAgICArLS0tLSotKyBQMSAr LSsgICstLS0tLS0tLS0rICAgICAqDQorLS0tKyAgKy0rLS0rICogKy0tLS0rLS0tLStDMiBBcHA9 WSB8ICAgICAqDQp8UzEgKy0tKyBSMSB8ICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQor LS0tKyAgKy0rLS0rICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICB8ICAg ICogKy0tLS0rICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICArLS0tLSotKyBQMiArLS0t LSstLS0tLS0tLS0rICAgICAqDQogICAgICAgICAgICAgICogKy0tLS0rICAgIHxDMyBBcHA9WiB8 ICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQogICAg ICAgICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQpJbiB0aGlzIGNhc2UsIFIxIHdvdWxkbid0IGhh dmUgZW5vdWdoIGtub3dsZWRnZSB0byByb3V0ZSB0aGUgbWVzc2FnZQ0KcHJvcGVybHkgdG8gdGhl IGNvcnJlY3QgcHJveHkganVzdCBieSBsb29raW5nIHRvIHRoZSBBcHAtSWQgaW4gdGhlIG1lc3Nh Z2UNCmhlYWRlciwgaWYgQXBwLUlkIGlzIHBvcHVsYXRlZCB3aXRoICIwIi4NCg0KW01TdF0gSSB0 aGluayB5b3UgYXNzdW1lIFAxIGFuZCBQMiBhZHZlcnRpc2Ugc3VwcG9ydHMgZm9yIEFwcCB4L3kg YW5kIEFwcCB6IHJlc3BlY3RpdmVseSBidXQgSSB3b3VsZCByYXRoZXIgY29uc2lkZXIgdGhpcyBj b25maWd1cmF0aW9uIGFuIGFjYWRlbWljIHVzZSBjYXNlIHNpbmNlIHR5cGljYWxseSB5b3UgaGF2 ZSBvbmx5IG9uZSBsb2dpY2FsIFByb3h5IGFzIGEgaW50ZXJjb25uZWN0IHBvaW50IGZvciBhIGdp dmVuIHJlYWxtIGluIHJlYWwgZGVwbG95bWVudHMgYXMgYSBjZW50cmFsIHBvaW50IGZvciBwb2xp Y3kgZW5mb3JjZW1lbnQuIEhvd2V2ZXIsIGxldCBzZWUgd2hldGhlciBhIHNlcnZlciBpbml0aWF0 ZWQgbWVzc2FnZSB1c2luZyBEZXN0aW5hdGlvbi1Ib3N0IGFuZCBhcHAgaWQgMCBiYXNlZCByb3V0 aW5nIHdvcmtzLg0KDQpTMSBzZW5kcyBBU1IgdG8gQzMgKEMzIGRpYW1ldGVyIGlkZW50aXR5IGlu IERlc3RpbmF0aW9uLUhvc3QgQVZQKSBhcHAgaWQgMC4gSW4gdGhlIHJlYWxtLWJhc2VkIHJvdXRp bmcgdGFibGUgUjEgd2lsbCBjZXJ0YWlubHkgZmluZCBhIG1hdGNoIGZvciByZWFsbSBBIGFuZCBh cHAgaWQgMCwgc2F5IGZvciBpbnN0YW5jZSB0aGUgbWF0Y2ggaXMgZm9yIFAxLiBBU1IgaXMgcm91 dGVkIHRvIFAxLCB3aGljaCBkb2Vzbid0IGhhdmUgQzMgaW4gaXRzIHBlZXIgdGFibGUgYW5kIHRo ZW4gYW5zd2VycyB3aXRoIERJQU1FVEVSX1VOQUJMRV9UT19ERUxJVkVSLiBSMSBhdHRlbXB0cyB0 aGVuIHRvIGRlbGl2ZXIgdGhlIG1lc3NhZ2UgdmlhIHRoZSBhbHRlcm5hdGl2ZSBlbnRyeSBmb3Ig UmVhbG0gQSwgaGVuY2UgUDIuIFAyIG5vdyBkZWxpdmVyIHRoZSBtZXNzYWdlIHRvIEMzLiBTbywg YXBwLWlkIDAgd29ya3MgYXQgdGhlIGVuZCBpZiBEZXN0aW5hdGlvbi1Ib3N0IGJhc2VkIHJvdXRp bmcgaXMgdXNlZCBhbmQsIGFjdHVhbGx5LCBpcyB0byBiZSB1c2VkIGZvciBjZXJ0YWluIHNlcnZl ciBpbml0aWF0ZWQgbWVzc2FnZXMgYXMgYWxzbyBkZWZpbmVkIGluIFJGQyAzNTg4IGluIHNlY3Rp b24gNi4xLiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== --===============0302659203== 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 --===============0302659203==-- From dime-bounces@ietf.org Fri Jul 21 00:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mcC-0006Cm-2p; Fri, 21 Jul 2006 00:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mcA-00063j-Eg for dime@ietf.org; Fri, 21 Jul 2006 00:27:50 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3mSG-0003IY-Di for dime@ietf.org; Fri, 21 Jul 2006 00:17:37 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q007MUKCKA4@szxga03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 12:26:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2Q000AVKCJGI@szxga03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 12:26:44 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2Q006AXK0LLF@szxml03-in.huawei.com> for dime@ietf.org; Fri, 21 Jul 2006 12:19:34 +0800 (CST) Date: Fri, 21 Jul 2006 12:16:54 +0800 From: Tony Zhang Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summaryof 3588bis Issues Status To: "German Blanco (MI/EEM)" , Victor Fajardo , dime@ietf.org Message-id: <022201c6ac7c$7f8f7cb0$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7457D12699374F40BD026D2B1EFFBEC6028430D2@eesmdmw020.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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 all: i give one Issue for Failed AVP also,for invalid AVP length,it is not easy implement in Failed avp should give the error avp copy back. consider below situation : (1) the AVP length more than message Length, (2)the AVP length less than AVP head length, i suggest only copy the AVP head is enough. Thanks! Tony one problem is ----- Original Message ----- From: "German Blanco (MI/EEM)" To: "Victor Fajardo" ; Sent: Wednesday, July 19, 2006 7:49 PM Subject: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summaryof 3588bis Issues Status Victor, Thanks for the summary! When you say: > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP. Is the proposal to indicate in the answer only the code of the missing AVP inside the Grouped AVP? If that is the case, I would suggest this text additions for RFC 3558bis (between ">>"s and "<<"s): " DIAMETER_MISSING_AVP 5005 The request did not contain an AVP that is required by the Command Code >>or Grouped AVP <> If the AVP is missing in a Grouped AVP, only the missing AVP and not the Grouped-AVP will be included in the Failed-AVP. <> If the AVP is present inside a Grouped AVP, only the offending AVP and not the Grouped-AVP will be included in the Failed-AVP. << " "Do nothing" doesn't seem a good idea to me. I would prefer that this is clarified, whatever the conclusion is. The long list of error codes will not make sense, if we end up not knowing what happened. Regards, German. -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: viernes, 14 de julio de 2006 19:46 To: dime@ietf.org Subject: [Dime] Summary of 3588bis Issues Status Folks, The is a summary of the 3588bis issues discussion during DIME WG meeting in IETF66. If you have comments on any of the existing issues pls don't hesitate to post it on the DIME list so we can facilitate quicker resolution or at least better understanding of the problem. We also need some proposals on the open issues if you believe they are truly issues. Note that the assigned issue numbers are based on the current tracker which is for historical reasons the diameter-interop tracker (http://www.tschofenig.priv.at:8080/diameter-interop). Closed Issues: ------------- Issue 6 : TLS version issue Comments: interop related problem only. Does not affect the base spec Issue 7 : Textual IP address qualify as FQDN Comments: Consensus that FQDN is defined as "internet name" only Issue 11 : Confusion about use of Proxy-Info AVP for Relay Comments: Clarified in Sec 6.2 with the text "Any Proxy-Info AVPs in the request MUST be added to the answer message, in the same order they were present in the request." Open Issues with some consensus on proposals: --------------------------------------------- Notes: These issues have some consensus either during the IETF66 meeting and/or in the DIME mailing list. Issue 2 & 5 : App Ids used by common diameter messages Proposals: Use the application id of the current application Issue 3 & 16 : CER/CEA exchange in the open state Proposals: Need more consensus on current proposals posted in issue 16 Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp Proposals: The Vendor-Id ABNF should one and only one instance, i.e. ::= < AVP Header: 260 > < Vendor-Id > 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } Issue 20 : Determining an offending/invalid AVP contained within the group AVP Proposals: Do nothing. The AVP code should be enough. Existing proposals may needlessly extend the length of the Failed-AVP. Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 Proposals: Change diameter-message definition in Sec 3.2 to: diameter-message=header[*fixed][*required][*optional] Open Issues with no consensus on proposals: ------------------------------------------ Issue 21 : URI schemes for AAA Proposals: draft-garcia-dime-aaa-uri-00.txt Issue 4 : Proxy agent stay in the path of the request message of a session Proposals: draft-tsou-dime-routing-ext-00.txt Open Issues that needs proposals: -------------------------------- Notes: These issues did not receive any comments during IETF66 and have no pending proposals. Issue 1 : Advertising relay application id (0xffffffff) in auth-application-id or acct-application-id Issue 15 : Duplicate detection requires server side storage of e2e id and origin-host avp Issue 13 : Clarify usage of application id avp's and how they relate to the app-id in the header Issue 9 & 19 : Error codes defined in wrong category Issue 8 : Setting error flag (e-bit) during CER/CEA exchange Issue 12 : Differing concepts and/or usage of Diameter Identity (FQDN + port or FQDN only) Issue 14 : Explicit text on which error category should have error flag (e-bit) set Issue 18 : Clarify reconnect behavior of peer based on value of Disconnect-Cause AVP Open issues falling into the "New Features" category: ---------------------------------------------------- Note: These features should use the extension procedures defined in 3588. No comments received in IETF66 meeting. Issue 23 : Predictive loop detection Comments: Optimzation techiniques in detecting loops at the succeeding hops Issue 22 : Fetch data request and location update request. Comments: Proposal to include LUR messages into base since its reusable in different applications If you believe there are some in-accurate info below, pls let us know. best regards, victor _______________________________________________ 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 Fri Jul 21 03:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3pHI-0007md-5m; Fri, 21 Jul 2006 03:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3pHG-0007iM-9Q for dime@ietf.org; Fri, 21 Jul 2006 03:18:26 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3pHF-0004cu-OE for dime@ietf.org; Fri, 21 Jul 2006 03:18:26 -0400 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6L7INps016359 for ; Fri, 21 Jul 2006 09:18:23 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jul 2006 09:18:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Fri, 21 Jul 2006 09:18:13 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133C0@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acasd8WFmPeNtDtPTCeNZhZlcH5kNgAHDEjA From: "STURA, Marco, VF-IT" To: "Tony Zhang" , "Tolga Asveren" , "Victor Fajardo" X-OriginalArrivalTime: 21 Jul 2006 07:18:21.0278 (UTC) FILETIME=[D8B987E0:01C6AC95] X-Spam-Score: 0.1 (/) 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 Tony, Server initiated requests can only be sent in the context of existing = sessions and routing must be done on the basis of Destination-Host to = ensure that the request hits the correct client, so app id is not = enough. The routing problem you are discussing has to do with how a proxy can = stay on the path during a session so that a server can send a request, = say ASR or RAR, to Destination-Host via P1 to C1. As also suggested by = Tolga >I think it can be deducted to the generic problem of "How can a proxy = stay >on the path during a session", so I believe this is the question = to answer >(which we already discussed to some extent in the context of = strict-routing >draft review) So I think your issue can be discussed in that context, app id 0 for = common messages I think is fine. Regards Marco -----Original Message----- From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 Sent: venerd=EC 21 luglio 2006 5.43 To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo Cc: dime@ietf.org Subject: Re: [Dime] Summary of 3588bis Issues Status Hi Macro: [MSt] I think you assume P1 and P2 advertise supports for App x/y and = App z respectively but I would rather consider this configuration an = academic use case since typically you have only one logical Proxy as a = interconnect point for a given realm in real deployments as a central = point for policy enforcement. However, let see whether a server = initiated message using Destination-Host and app id 0 based routing = works. S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id = 0. In the realm-based routing table R1 will certainly find a match for = realm A and app id 0, say for instance the match is for P1. ASR is = routed to P1, which doesn't have C3 in its peer table and then answers = with DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message = via the alternative entry for Realm A, hence P2. P2 now deliver the = message to C3. So, app-id 0 works at the end if Destination-Host based = routing is used and, actually, is to be used for certain server = initiated messages as also defined in RFC 3588 in section 6.1.=20 [Tony]Because the Application Id 0,not advertisement in CER/CEA,so it = means each realm will use the peet table select next hop,almost peer = table have many peer can select,also include peer of receive the = request. so it can happen loop routing.(maybe can add one process avoid = this,when routing should input peer name of receive the request.).the = other problem,after retry many peer ,then we find correct route,it = consume long time,maybe the client already timer expire.also application = id use for effectively routing,but for above the case ,it is not like = this. sorry about i discuss this again,after 2004's dicuss,it is likely many = people confusion.if this time have same conlusion maybe still have same = problem. Thanks! Tony ----- Original Message -----=20 From: "STURA, Marco, VF-IT" To: "Tolga Asveren" ; "Victor Fajardo" = Cc: Sent: Wednesday, July 19, 2006 5:11 PM Subject: RE: [Dime] Summary of 3588bis Issues Status See in line. Regards Marco -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: marted=EC 18 luglio 2006 18.52 To: STURA, Marco, VF-IT; Victor Fajardo Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status [.. snip ..] > I agree with your example above regarding destination-host. It is > required in the case of ASR (and perhaps some other message) though I > guess I was stating a case which is a little bit different than your > example above. I was thinking of the following case: > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > in this case relay2 will not be able to route using dest-host. This is > where dest-realm and app id becomes important. In this case app id of = 0 > might not work as well ... or maybe I'm wrong. > > [MSt] In this case R1 would advertise it self as a relay (i.e. > 0xffffffff) it won't advertise app id x or y or z. So, any app id > would be routed to R1 by R2. [TOLGA] Let me try to further refine the scenario: ***************************** * Realm A * * * * +---------+ * * +--+C1 App=3DX | * * +----+ | +---------+ * +----*-+ P1 +-+ +---------+ * +---+ +-+--+ * +----+----+C2 App=3DY | * |S1 +--+ R1 | * +---------+ * +---+ +-+--+ * * | * +----+ * +----*-+ P2 +----+---------+ * * +----+ |C3 App=3DZ | * * +---------+ * * * ***************************** In this case, R1 wouldn't have enough knowledge to route the message properly to the correct proxy just by looking to the App-Id in the = message header, if App-Id is populated with "0". [MSt] I think you assume P1 and P2 advertise supports for App x/y and = App z respectively but I would rather consider this configuration an = academic use case since typically you have only one logical Proxy as a = interconnect point for a given realm in real deployments as a central = point for policy enforcement. However, let see whether a server = initiated message using Destination-Host and app id 0 based routing = works. S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id = 0. In the realm-based routing table R1 will certainly find a match for = realm A and app id 0, say for instance the match is for P1. ASR is = routed to P1, which doesn't have C3 in its peer table and then answers = with DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message = via the alternative entry for Realm A, hence P2. P2 now deliver the = message to C3. So, app-id 0 works at the end if Destination-Host based = routing is used and, actually, is to be used for certain server = initiated messages as also defined in RFC 3588 in section 6.1.=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 Fri Jul 21 08:22:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u1s-00031E-Dg; Fri, 21 Jul 2006 08:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u1q-000313-LH for dime@ietf.org; Fri, 21 Jul 2006 08:22:50 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3u1N-0007rC-68 for dime@ietf.org; Fri, 21 Jul 2006 08:22:22 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id BD2F2B6B56; Fri, 21 Jul 2006 08:22:30 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k6LCMGkM027097; Fri, 21 Jul 2006 08:22:17 -0400 (EDT) From: "Tolga Asveren" To: "Tony Zhang" , "German Blanco (MI/EEM)" , "Victor Fajardo" , Subject: RE: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime]Summaryof 3588bis Issues Status Date: Fri, 21 Jul 2006 07:58:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <022201c6ac7c$7f8f7cb0$6291460a@china.huawei.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 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 Tony, I also think so. Thanks, Tolga > -----Original Message----- > From: Tony Zhang [mailto:zhangtao_hw@huawei.com] > Sent: Friday, July 21, 2006 12:17 AM > To: German Blanco (MI/EEM); Victor Fajardo; dime@ietf.org > Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: > [Dime]Summaryof 3588bis Issues Status > > > HI all: > i give one Issue for Failed AVP also,for invalid AVP length,it > is not easy implement in Failed avp should give the error avp copy back. > consider below situation : > (1) the AVP length more than message Length, > (2)the AVP length less than AVP head length, > > i suggest only copy the AVP head is enough. > > Thanks! > Tony > > one problem is > ----- Original Message ----- > From: "German Blanco (MI/EEM)" > To: "Victor Fajardo" ; > Sent: Wednesday, July 19, 2006 7:49 PM > Subject: Issue 20 (offending AVP inside a Grouped AVP) was:RE: > [Dime] Summaryof 3588bis Issues Status > > > Victor, > > Thanks for the summary! > > When you say: > > Issue 20 : Determining an offending/invalid AVP contained within > > the group AVP > > Proposals: Do nothing. The AVP code should be enough. > > Existing proposals may needlessly extend > > the length of the Failed-AVP. > > Is the proposal to indicate in the answer only the code of the missing > AVP inside the Grouped AVP? > > If that is the case, I would suggest this text additions for RFC 3558bis > (between ">>"s and "<<"s): > " > DIAMETER_MISSING_AVP 5005 > The request did not contain an AVP that is required by the Command > Code >>or Grouped AVP < Result-Code AVP, a Failed-AVP AVP SHOULD be included in the > message. > The Failed-AVP AVP MUST contain an example of the missing AVP > complete > with the Vendor-Id if applicable.>> If the AVP is missing in a > Grouped > AVP, only the missing AVP and not the Grouped-AVP will be included > in > the Failed-AVP. < correct > minimum length and contain zeroes. > " > " > DIAMETER_AVP_NOT_ALLOWED 5008 > A message was received with an AVP that MUST NOT be present. The > Failed-AVP AVP MUST be included and contain a copy of the > offending AVP.>> If the AVP is present inside a Grouped > AVP, only the offending AVP and not the Grouped-AVP will be > included > in the Failed-AVP. << > " > > "Do nothing" doesn't seem a good idea to me. I would prefer that this > is clarified, whatever the conclusion is. The long list of error codes > will not make sense, if we end up not knowing what happened. > > Regards, > German. > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: viernes, 14 de julio de 2006 19:46 > To: dime@ietf.org > Subject: [Dime] Summary of 3588bis Issues Status > > Folks, > > The is a summary of the 3588bis issues discussion during DIME WG meeting > in IETF66. If you have comments on any of the existing issues pls don't > hesitate to post it on the DIME list so we can facilitate quicker > resolution or at least better understanding of the problem. We also need > some proposals on the open issues if you believe they are truly issues. > Note that the assigned issue numbers are based on the current tracker > which is for historical reasons the diameter-interop tracker > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > Closed Issues: > ------------- > > Issue 6 : TLS version issue > Comments: interop related problem only. Does not affect > the > base spec > > Issue 7 : Textual IP address qualify as FQDN > Comments: Consensus that FQDN is defined as "internet > name" > only > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > Comments: Clarified in Sec 6.2 with the text > > "Any Proxy-Info AVPs in the request MUST be added to the > answer message, in the same order they were present in > the request." > > Open Issues with some consensus on proposals: > --------------------------------------------- > > Notes: These issues have some consensus either during the IETF66 > meeting and/or in the DIME mailing list. > > Issue 2 & 5 : App Ids used by common diameter messages > Proposals: Use the application id of the current > application > > Issue 3 & 16 : CER/CEA exchange in the open state > Proposals: Need more consensus on current proposals > posted in issue 16 > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > Proposals: The Vendor-Id ABNF should one and only one > instance, i.e. > > ::= < AVP Header: 260 > > < Vendor-Id > > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > Issue 20 : Determining an offending/invalid AVP contained within > > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP. > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > Proposals: Change diameter-message definition in Sec 3.2 > to: > > diameter-message=header[*fixed][*required][*optional] > > Open Issues with no consensus on proposals: > ------------------------------------------ > > Issue 21 : URI schemes for AAA > Proposals: draft-garcia-dime-aaa-uri-00.txt > > Issue 4 : Proxy agent stay in the path of the request message of > a session > Proposals: draft-tsou-dime-routing-ext-00.txt > > Open Issues that needs proposals: > -------------------------------- > > Notes: These issues did not receive any comments during IETF66 and > have no pending proposals. > > Issue 1 : Advertising relay application id (0xffffffff) in > auth-application-id or acct-application-id > > Issue 15 : Duplicate detection requires server side storage of > e2e id and origin-host avp > > Issue 13 : Clarify usage of application id avp's and how they > relate to the app-id in the header > > Issue 9 & 19 : Error codes defined in wrong category > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > Issue 12 : Differing concepts and/or usage of Diameter Identity > (FQDN + port or FQDN only) > > Issue 14 : Explicit text on which error category should have > error flag (e-bit) set > > Issue 18 : Clarify reconnect behavior of peer based on value of > Disconnect-Cause AVP > > Open issues falling into the "New Features" category: > ---------------------------------------------------- > > Note: These features should use the extension procedures defined in > 3588. > No comments received in IETF66 meeting. > > Issue 23 : Predictive loop detection > Comments: Optimzation techiniques in detecting loops > at the succeeding hops > > Issue 22 : Fetch data request and location update request. > Comments: Proposal to include LUR messages into > base since its reusable in different > applications > > If you believe there are some in-accurate info below, pls let us know. > > best regards, > victor > > _______________________________________________ > 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 Fri Jul 21 08:40:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3uJA-0006JY-RN; Fri, 21 Jul 2006 08:40:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3uJA-0006In-Do for dime@ietf.org; Fri, 21 Jul 2006 08:40:44 -0400 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 1G3u9K-0000GQ-VA for dime@ietf.org; Fri, 21 Jul 2006 08:30:35 -0400 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 k6LCTmv1081440; Fri, 21 Jul 2006 08:29:48 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44C0C8BC.7090802@tari.toshiba.com> Date: Fri, 21 Jul 2006 08:29:48 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tony Zhang Subject: Re: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summaryof 3588bis Issues Status References: <7457D12699374F40BD026D2B1EFFBEC6028430D2@eesmdmw020.eemea.ericsson.se> <022201c6ac7c$7f8f7cb0$6291460a@china.huawei.com> In-Reply-To: <022201c6ac7c$7f8f7cb0$6291460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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've created issue #24 for this. BR, victor > HI all: > i give one Issue for Failed AVP also,for invalid AVP length,it is not easy implement in Failed avp should give the error avp copy back. > consider below situation : > (1) the AVP length more than message Length, > (2)the AVP length less than AVP head length, > > i suggest only copy the AVP head is enough. > > Thanks! > Tony > > one problem is > ----- Original Message ----- > From: "German Blanco (MI/EEM)" > To: "Victor Fajardo" ; > Sent: Wednesday, July 19, 2006 7:49 PM > Subject: Issue 20 (offending AVP inside a Grouped AVP) was:RE: [Dime] Summaryof 3588bis Issues Status > > > Victor, > > Thanks for the summary! > > When you say: > >> Issue 20 : Determining an offending/invalid AVP contained within >> the group AVP >> Proposals: Do nothing. The AVP code should be enough. >> Existing proposals may needlessly extend >> the length of the Failed-AVP. >> > > Is the proposal to indicate in the answer only the code of the missing > AVP inside the Grouped AVP? > > If that is the case, I would suggest this text additions for RFC 3558bis > (between ">>"s and "<<"s): > " > DIAMETER_MISSING_AVP 5005 > The request did not contain an AVP that is required by the Command > Code >>or Grouped AVP < Result-Code AVP, a Failed-AVP AVP SHOULD be included in the > message. > The Failed-AVP AVP MUST contain an example of the missing AVP > complete > with the Vendor-Id if applicable.>> If the AVP is missing in a > Grouped > AVP, only the missing AVP and not the Grouped-AVP will be included > in > the Failed-AVP. < correct > minimum length and contain zeroes. > " > " > DIAMETER_AVP_NOT_ALLOWED 5008 > A message was received with an AVP that MUST NOT be present. The > Failed-AVP AVP MUST be included and contain a copy of the > offending AVP.>> If the AVP is present inside a Grouped > AVP, only the offending AVP and not the Grouped-AVP will be > included > in the Failed-AVP. << > " > > "Do nothing" doesn't seem a good idea to me. I would prefer that this > is clarified, whatever the conclusion is. The long list of error codes > will not make sense, if we end up not knowing what happened. > > Regards, > German. > > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: viernes, 14 de julio de 2006 19:46 > To: dime@ietf.org > Subject: [Dime] Summary of 3588bis Issues Status > > Folks, > > The is a summary of the 3588bis issues discussion during DIME WG meeting > in IETF66. If you have comments on any of the existing issues pls don't > hesitate to post it on the DIME list so we can facilitate quicker > resolution or at least better understanding of the problem. We also need > some proposals on the open issues if you believe they are truly issues. > Note that the assigned issue numbers are based on the current tracker > which is for historical reasons the diameter-interop tracker > (http://www.tschofenig.priv.at:8080/diameter-interop). > > > Closed Issues: > ------------- > > Issue 6 : TLS version issue > Comments: interop related problem only. Does not affect > the > base spec > > Issue 7 : Textual IP address qualify as FQDN > Comments: Consensus that FQDN is defined as "internet > name" > only > > Issue 11 : Confusion about use of Proxy-Info AVP for Relay > Comments: Clarified in Sec 6.2 with the text > > "Any Proxy-Info AVPs in the request MUST be added to the > answer message, in the same order they were present in > the request." > > Open Issues with some consensus on proposals: > --------------------------------------------- > > Notes: These issues have some consensus either during the IETF66 > meeting and/or in the DIME mailing list. > > Issue 2 & 5 : App Ids used by common diameter messages > Proposals: Use the application id of the current > application > > Issue 3 & 16 : CER/CEA exchange in the open state > Proposals: Need more consensus on current proposals > posted in issue 16 > > Issue 10 : Unclear semantics on multiple vendor-id avp in VSA avp > Proposals: The Vendor-Id ABNF should one and only one > instance, i.e. > > ::= < AVP Header: 260 > > < Vendor-Id > > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } > > Issue 20 : Determining an offending/invalid AVP contained within > the group AVP > Proposals: Do nothing. The AVP code should be enough. > Existing proposals may needlessly extend > the length of the Failed-AVP. > > Issue 17 : Removal of trailing [*fixed] avp in Sec 3.2 > Proposals: Change diameter-message definition in Sec 3.2 > to: > > diameter-message=header[*fixed][*required][*optional] > > Open Issues with no consensus on proposals: > ------------------------------------------ > > Issue 21 : URI schemes for AAA > Proposals: draft-garcia-dime-aaa-uri-00.txt > > Issue 4 : Proxy agent stay in the path of the request message of > a session > Proposals: draft-tsou-dime-routing-ext-00.txt > > Open Issues that needs proposals: > -------------------------------- > > Notes: These issues did not receive any comments during IETF66 and > have no pending proposals. > > Issue 1 : Advertising relay application id (0xffffffff) in > auth-application-id or acct-application-id > > Issue 15 : Duplicate detection requires server side storage of > e2e id and origin-host avp > > Issue 13 : Clarify usage of application id avp's and how they > relate to the app-id in the header > > Issue 9 & 19 : Error codes defined in wrong category > > Issue 8 : Setting error flag (e-bit) during CER/CEA exchange > > Issue 12 : Differing concepts and/or usage of Diameter Identity > (FQDN + port or FQDN only) > > Issue 14 : Explicit text on which error category should have > error flag (e-bit) set > > Issue 18 : Clarify reconnect behavior of peer based on value of > Disconnect-Cause AVP > > Open issues falling into the "New Features" category: > ---------------------------------------------------- > > Note: These features should use the extension procedures defined in > 3588. > No comments received in IETF66 meeting. > > Issue 23 : Predictive loop detection > Comments: Optimzation techiniques in detecting loops > at the succeeding hops > > Issue 22 : Fetch data request and location update request. > Comments: Proposal to include LUR messages into > base since its reusable in different > applications > > If you believe there are some in-accurate info below, pls let us know. > > best regards, > victor > > _______________________________________________ > 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 Sun Jul 23 23:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4qmk-0003pE-VP; Sun, 23 Jul 2006 23:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4qmj-0003p2-8E for dime@ietf.org; Sun, 23 Jul 2006 23:07:09 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4qmh-0002fY-RK for dime@ietf.org; Sun, 23 Jul 2006 23:07:09 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 4E6AF205E1 for ; Mon, 24 Jul 2006 08:34:05 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3579F205DD for ; Mon, 24 Jul 2006 08:34:05 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 08:37:04 +0530 Received: from [10.116.3.25] ([10.116.3.25]) by blr-m2-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 08:37:04 +0530 Subject: RE: [Dime] Summary of 3588bis Issues Status From: venkatesh devalapura nagabhushana To: Ram O V Vishnu-A14676 In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Mon, 24 Jul 2006 08:38:32 +0530 Message-Id: <1153710512.3273.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 24 Jul 2006 03:07:04.0371 (UTC) FILETIME=[3D6D5830:01C6AECE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 inline: On Sat, 2006-07-22 at 01:13 +0800, Ram O V Vishnu-A14676 wrote: > Hi All, >=20 > Its *not* a good idea to use application id 0 for RAR, RAA, ASR, ASA, STR= , STA.=20 >=20 > My reasons are:=20 >=20 > 1. My definition (in the absence of one in the RFC 3588) of "Diameter Com= mon Message" is that - only the ones used in FSM in section 5.6 of RFC 3588= should be treated as common messages. >=20 [Venkatatesh] FSM defined in 5.6 is at connection level rather than at session level. Hence the concept of "application id" should not be applied here....... is my interpretation correct or am i missing something here ? > 2. In the place where Sessions are defined (in section 1.3) RFC 3588, it = is mentioned that "Each application SHOULD provide guidelines as to when a= session begins and ends." So sessions are application level entities and h= ence session related messages (like ASR/STR) with app-id 0 does not make se= nse. They should be with specific application ids which maintain those sess= ions. >=20 > 3. I agree with Tony that this will break existing implementations of the= base protocol. About the past discussions- RFC 3588 still stayed, it was n= ot corrected, implementations have gone ahead - I guess we should take a fr= esh look. >=20 > About other RFCs using other interpretations, I think those should be cor= rected. >=20 > Regards, > Vishnu. >=20 > Motorola India Electronics Pvt Ltd > +91 9844178052 > [*] Motorola Internal Use Only >=20 >=20 >=20 > -----Original Message----- > From: STURA, Marco, VF-IT [mailto:Marco.STURA@vodafone.com]=20 > Sent: Friday, July 21, 2006 12:48 PM > To: Tony Zhang; Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status >=20 >=20 > Hi Tony, >=20 > Server initiated requests can only be sent in the context of existing ses= sions and routing must be done on the basis of Destination-Host to ensure t= hat the request hits the correct client, so app id is not enough. >=20 > The routing problem you are discussing has to do with how a proxy can sta= y on the path during a session so that a server can send a request, say ASR= or RAR, to Destination-Host via P1 to C1. As also suggested by Tolga >=20 > >I think it can be deducted to the generic problem of "How can a proxy=20 > >stay >on the path during a session", so I believe this is the question=20 > >to answer >(which we already discussed to some extent in the context of=20 > >strict-routing >draft review) >=20 > So I think your issue can be discussed in that context, app id 0 for comm= on messages I think is fine. >=20 > Regards > Marco >=20 > -----Original Message----- > From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 > Sent: venerd=C3=AC 21 luglio 2006 5.43 > To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status >=20 > Hi Macro: >=20 > [MSt] I think you assume P1 and P2 advertise supports for App x/y and App= z respectively but I would rather consider this configuration an academic = use case since typically you have only one logical Proxy as a interconnect = point for a given realm in real deployments as a central point for policy e= nforcement. However, let see whether a server initiated message using Desti= nation-Host and app id 0 based routing works. >=20 > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id = 0. In the realm-based routing table R1 will certainly find a match for real= m A and app id 0, say for instance the match is for P1. ASR is routed to P1= , which doesn't have C3 in its peer table and then answers with DIAMETER_UN= ABLE_TO_DELIVER. R1 attempts then to deliver the message via the alternativ= e entry for Realm A, hence P2. P2 now deliver the message to C3. So, app-id= 0 works at the end if Destination-Host based routing is used and, actually= , is to be used for certain server initiated messages as also defined in RF= C 3588 in section 6.1.=20 >=20 > [Tony]Because the Application Id 0,not advertisement in CER/CEA,so it mea= ns each realm will use the peet table select next hop,almost peer table hav= e many peer can select,also include peer of receive the request. so it can = happen loop routing.(maybe can add one process avoid this,when routing shou= ld input peer name of receive the request.).the other problem,after retry m= any peer ,then we find correct route,it consume long time,maybe the client = already timer expire.also application id use for effectively routing,but fo= r above the case ,it is not like this. >=20 > sorry about i discuss this again,after 2004's dicuss,it is likely many pe= ople confusion.if this time have same conlusion maybe still have same probl= em. >=20 > Thanks! > Tony >=20 > ----- Original Message -----=20 > From: "STURA, Marco, VF-IT" > To: "Tolga Asveren" ; "Victor Fajardo" > Cc: > Sent: Wednesday, July 19, 2006 5:11 PM > Subject: RE: [Dime] Summary of 3588bis Issues Status >=20 >=20 > See in line. >=20 > Regards > Marco >=20 > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: marted=C3=AC 18 luglio 2006 18.52 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status >=20 > [.. snip ..] > > I agree with your example above regarding destination-host. It is=20 > > required in the case of ASR (and perhaps some other message) though I=20 > > guess I was stating a case which is a little bit different than your=20 > > example above. I was thinking of the following case: > > > > clients[1,2,3...x] <--- relay1 <---- relay2 <---- server > > > > in this case relay2 will not be able to route using dest-host. This is=20 > > where dest-realm and app id becomes important. In this case app id of=20 > > 0 might not work as well ... or maybe I'm wrong. > > > > [MSt] In this case R1 would advertise it self as a relay (i.e. > > 0xffffffff) it won't advertise app id x or y or z. So, any app id=20 > > would be routed to R1 by R2. > [TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=3DX | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * > +---+ +-+--+ * +----+----+C2 App=3DY | * > |S1 +--+ R1 | * +---------+ * > +---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=3DZ | * > * +---------+ * > * * > ***************************** > In this case, R1 wouldn't have enough knowledge to route the message prop= erly to the correct proxy just by looking to the App-Id in the message head= er, if App-Id is populated with "0". >=20 > [MSt] I think you assume P1 and P2 advertise supports for App x/y and App= z respectively but I would rather consider this configuration an academic = use case since typically you have only one logical Proxy as a interconnect = point for a given realm in real deployments as a central point for policy e= nforcement. However, let see whether a server initiated message using Desti= nation-Host and app id 0 based routing works. >=20 > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app id = 0. In the realm-based routing table R1 will certainly find a match for real= m A and app id 0, say for instance the match is for P1. ASR is routed to P1= , which doesn't have C3 in its peer table and then answers with DIAMETER_UN= ABLE_TO_DELIVER. R1 attempts then to deliver the message via the alternativ= e entry for Realm A, hence P2. P2 now deliver the message to C3. So, app-id= 0 works at the end if Destination-Host based routing is used and, actually= , is to be used for certain server initiated messages as also defined in RF= C 3588 in section 6.1.=20 >=20 >=20 > _______________________________________________ > 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 >=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 Jul 24 02:00:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4tUN-0000ZR-UQ; Mon, 24 Jul 2006 02:00:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4tUN-0000ZM-AB for dime@ietf.org; Mon, 24 Jul 2006 02:00:23 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4tUK-0005a3-CO for dime@ietf.org; Mon, 24 Jul 2006 02:00:23 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00A5U8R9ZQ@szxga01-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 14:01:58 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W002CV8R9RS@szxga01-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 14:01:57 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W0055U96B72@szxml04-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 14:11:00 +0800 (CST) Date: Mon, 24 Jul 2006 13:59:31 +0800 From: Tony Zhang Subject: Re: [Dime] Summary of 3588bis Issues Status To: "STURA, Marco, VF-IT" , Tolga Asveren , Victor Fajardo Message-id: <007901c6aee6$55006c40$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: <5371BE300539E6439919CF97203DDEC2077133C0@OIVMEXO01.omnitel.it> X-Spam-Score: 0.9 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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="===============0990674632==" Errors-To: dime-bounces@ietf.org --===============0990674632== Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgTWFyY286DQoNCiAgICBJIGFsc28gYWdyZWUgdGhlIGdlbmVyaWMgcHJvYmxlbSBvZiAiSG93 IGNhbiBhIHByb3h5IHN0YXkgPm9uIHRoZSBwYXRoIGR1cmluZyBhIHNlc3Npb24iLCBidXQgaSB0 aGluayB0aGlzIHByb2JsZW0gaXMgYWRkcmVzcyB0aGUgc3RhdGVmdWwgcHJveHkgYWdlbnQsYWN1 dGFsIG1heWJlIHN0aWxsIGhhdmUgc3RhdGVsZXNzIHByb3h5IGFnZW50LnNvIHRoZSByb3V0aW5n IHByb2JsZW0gc3RpbGwgaW4gaGVyZS4NCiAgICBJIHN0aWxsIHRoaW5rIHRoZSByb3V0aW5nIGlz IGNvbW1vbiBwYXJ0LGluZGVwZW5kZW50IG9uIHN0YXJ0ICxlbmQgLGludGVyaW0gc2Vzc2lvbiBt ZXNzYWdlLg0KDQpSZWdhcmRzDQpUb255DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0K RnJvbTogIlNUVVJBLCBNYXJjbywgVkYtSVQiIDxNYXJjby5TVFVSQUB2b2RhZm9uZS5jb20+DQpU bzogIlRvbnkgWmhhbmciIDx6aGFuZ3Rhb19od0BodWF3ZWkuY29tPjsgIlRvbGdhIEFzdmVyZW4i IDxhc3ZlcmVuQHVsdGljb20uY29tPjsgIlZpY3RvciBGYWphcmRvIiA8dmZhamFyZG9AdGFyaS50 b3NoaWJhLmNvbT4NCkNjOiA8ZGltZUBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwgSnVseSAyMSwg MjAwNiAzOjE4IFBNDQpTdWJqZWN0OiBSRTogW0RpbWVdIFN1bW1hcnkgb2YgMzU4OGJpcyBJc3N1 ZXMgU3RhdHVzDQoNCg0KSGkgVG9ueSwNCg0KU2VydmVyIGluaXRpYXRlZCByZXF1ZXN0cyBjYW4g b25seSBiZSBzZW50IGluIHRoZSBjb250ZXh0IG9mIGV4aXN0aW5nIHNlc3Npb25zIGFuZCByb3V0 aW5nIG11c3QgYmUgZG9uZSBvbiB0aGUgYmFzaXMgb2YgRGVzdGluYXRpb24tSG9zdCB0byBlbnN1 cmUgdGhhdCB0aGUgcmVxdWVzdCBoaXRzIHRoZSBjb3JyZWN0IGNsaWVudCwgc28gYXBwIGlkIGlz IG5vdCBlbm91Z2guDQoNClRoZSByb3V0aW5nIHByb2JsZW0geW91IGFyZSBkaXNjdXNzaW5nIGhh cyB0byBkbyB3aXRoIGhvdyBhIHByb3h5IGNhbiBzdGF5IG9uIHRoZSBwYXRoIGR1cmluZyBhIHNl c3Npb24gc28gdGhhdCBhIHNlcnZlciBjYW4gc2VuZCBhIHJlcXVlc3QsIHNheSBBU1Igb3IgUkFS LCB0byBEZXN0aW5hdGlvbi1Ib3N0IHZpYSBQMSB0byBDMS4gQXMgYWxzbyBzdWdnZXN0ZWQgYnkg VG9sZ2ENCg0KPkkgdGhpbmsgaXQgY2FuIGJlIGRlZHVjdGVkIHRvIHRoZSBnZW5lcmljIHByb2Js ZW0gb2YgIkhvdyBjYW4gYSBwcm94eSBzdGF5ID5vbiB0aGUgcGF0aCBkdXJpbmcgYSBzZXNzaW9u Iiwgc28gSSBiZWxpZXZlIHRoaXMgaXMgdGhlIHF1ZXN0aW9uIHRvIGFuc3dlciA+KHdoaWNoIHdl IGFscmVhZHkgZGlzY3Vzc2VkIHRvIHNvbWUgZXh0ZW50IGluIHRoZSBjb250ZXh0IG9mIHN0cmlj dC1yb3V0aW5nID5kcmFmdCByZXZpZXcpDQoNClNvIEkgdGhpbmsgeW91ciBpc3N1ZSBjYW4gYmUg ZGlzY3Vzc2VkIGluIHRoYXQgY29udGV4dCwgYXBwIGlkIDAgZm9yIGNvbW1vbiBtZXNzYWdlcyBJ IHRoaW5rIGlzIGZpbmUuDQoNClJlZ2FyZHMNCk1hcmNvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBUb255IFpoYW5nIFttYWlsdG86emhhbmd0YW9faHdAaHVhd2VpLmNvbV0g DQpTZW50OiB2ZW5lcmTsIDIxIGx1Z2xpbyAyMDA2IDUuNDMNClRvOiBTVFVSQSwgTWFyY28sIFZG LUlUOyBUb2xnYSBBc3ZlcmVuOyBWaWN0b3IgRmFqYXJkbw0KQ2M6IGRpbWVAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbRGltZV0gU3VtbWFyeSBvZiAzNTg4YmlzIElzc3VlcyBTdGF0dXMNCg0KSGkg TWFjcm86DQoNCltNU3RdIEkgdGhpbmsgeW91IGFzc3VtZSBQMSBhbmQgUDIgYWR2ZXJ0aXNlIHN1 cHBvcnRzIGZvciBBcHAgeC95IGFuZCBBcHAgeiByZXNwZWN0aXZlbHkgYnV0IEkgd291bGQgcmF0 aGVyIGNvbnNpZGVyIHRoaXMgY29uZmlndXJhdGlvbiBhbiBhY2FkZW1pYyB1c2UgY2FzZSBzaW5j ZSB0eXBpY2FsbHkgeW91IGhhdmUgb25seSBvbmUgbG9naWNhbCBQcm94eSBhcyBhIGludGVyY29u bmVjdCBwb2ludCBmb3IgYSBnaXZlbiByZWFsbSBpbiByZWFsIGRlcGxveW1lbnRzIGFzIGEgY2Vu dHJhbCBwb2ludCBmb3IgcG9saWN5IGVuZm9yY2VtZW50LiBIb3dldmVyLCBsZXQgc2VlIHdoZXRo ZXIgYSBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2UgdXNpbmcgRGVzdGluYXRpb24tSG9zdCBhbmQg YXBwIGlkIDAgYmFzZWQgcm91dGluZyB3b3Jrcy4NCg0KUzEgc2VuZHMgQVNSIHRvIEMzIChDMyBk aWFtZXRlciBpZGVudGl0eSBpbiBEZXN0aW5hdGlvbi1Ib3N0IEFWUCkgYXBwIGlkIDAuIEluIHRo ZSByZWFsbS1iYXNlZCByb3V0aW5nIHRhYmxlIFIxIHdpbGwgY2VydGFpbmx5IGZpbmQgYSBtYXRj aCBmb3IgcmVhbG0gQSBhbmQgYXBwIGlkIDAsIHNheSBmb3IgaW5zdGFuY2UgdGhlIG1hdGNoIGlz IGZvciBQMS4gQVNSIGlzIHJvdXRlZCB0byBQMSwgd2hpY2ggZG9lc24ndCBoYXZlIEMzIGluIGl0 cyBwZWVyIHRhYmxlIGFuZCB0aGVuIGFuc3dlcnMgd2l0aCBESUFNRVRFUl9VTkFCTEVfVE9fREVM SVZFUi4gUjEgYXR0ZW1wdHMgdGhlbiB0byBkZWxpdmVyIHRoZSBtZXNzYWdlIHZpYSB0aGUgYWx0 ZXJuYXRpdmUgZW50cnkgZm9yIFJlYWxtIEEsIGhlbmNlIFAyLiBQMiBub3cgZGVsaXZlciB0aGUg bWVzc2FnZSB0byBDMy4gU28sIGFwcC1pZCAwIHdvcmtzIGF0IHRoZSBlbmQgaWYgRGVzdGluYXRp b24tSG9zdCBiYXNlZCByb3V0aW5nIGlzIHVzZWQgYW5kLCBhY3R1YWxseSwgaXMgdG8gYmUgdXNl ZCBmb3IgY2VydGFpbiBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIGFzIGFsc28gZGVmaW5lZCBp biBSRkMgMzU4OCBpbiBzZWN0aW9uIDYuMS4gDQoNCltUb255XUJlY2F1c2UgdGhlIEFwcGxpY2F0 aW9uIElkIDAsbm90IGFkdmVydGlzZW1lbnQgaW4gQ0VSL0NFQSxzbyBpdCBtZWFucyBlYWNoIHJl YWxtIHdpbGwgdXNlIHRoZSBwZWV0IHRhYmxlIHNlbGVjdCBuZXh0IGhvcCxhbG1vc3QgcGVlciB0 YWJsZSBoYXZlIG1hbnkgcGVlciBjYW4gc2VsZWN0LGFsc28gaW5jbHVkZSBwZWVyIG9mIHJlY2Vp dmUgdGhlIHJlcXVlc3QuIHNvIGl0IGNhbiBoYXBwZW4gbG9vcCByb3V0aW5nLihtYXliZSBjYW4g YWRkIG9uZSBwcm9jZXNzIGF2b2lkIHRoaXMsd2hlbiByb3V0aW5nIHNob3VsZCBpbnB1dCBwZWVy IG5hbWUgb2YgcmVjZWl2ZSB0aGUgcmVxdWVzdC4pLnRoZSBvdGhlciBwcm9ibGVtLGFmdGVyIHJl dHJ5IG1hbnkgcGVlciAsdGhlbiB3ZSBmaW5kIGNvcnJlY3Qgcm91dGUsaXQgY29uc3VtZSBsb25n IHRpbWUsbWF5YmUgdGhlIGNsaWVudCBhbHJlYWR5IHRpbWVyIGV4cGlyZS5hbHNvIGFwcGxpY2F0 aW9uIGlkIHVzZSBmb3IgZWZmZWN0aXZlbHkgcm91dGluZyxidXQgZm9yIGFib3ZlIHRoZSBjYXNl ICxpdCBpcyBub3QgbGlrZSB0aGlzLg0KDQpzb3JyeSBhYm91dCBpIGRpc2N1c3MgdGhpcyBhZ2Fp bixhZnRlciAyMDA0J3MgZGljdXNzLGl0IGlzIGxpa2VseSBtYW55IHBlb3BsZSBjb25mdXNpb24u aWYgdGhpcyB0aW1lIGhhdmUgc2FtZSBjb25sdXNpb24gbWF5YmUgc3RpbGwgaGF2ZSBzYW1lIHBy b2JsZW0uDQoNClRoYW5rcyENClRvbnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJTVFVSQSwgTWFyY28sIFZGLUlUIiA8TWFyY28uU1RVUkFAdm9kYWZvbmUuY29tPg0K VG86ICJUb2xnYSBBc3ZlcmVuIiA8YXN2ZXJlbkB1bHRpY29tLmNvbT47ICJWaWN0b3IgRmFqYXJk byIgPHZmYWphcmRvQHRhcmkudG9zaGliYS5jb20+DQpDYzogPGRpbWVAaWV0Zi5vcmc+DQpTZW50 OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMDYgNToxMSBQTQ0KU3ViamVjdDogUkU6IFtEaW1lXSBT dW1tYXJ5IG9mIDM1ODhiaXMgSXNzdWVzIFN0YXR1cw0KDQoNClNlZSBpbiBsaW5lLg0KDQpSZWdh cmRzDQpNYXJjbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9sZ2EgQXN2 ZXJlbiBbbWFpbHRvOmFzdmVyZW5AdWx0aWNvbS5jb21dIA0KU2VudDogbWFydGVk7CAxOCBsdWds aW8gMjAwNiAxOC41Mg0KVG86IFNUVVJBLCBNYXJjbywgVkYtSVQ7IFZpY3RvciBGYWphcmRvDQpD YzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBTdW1tYXJ5IG9mIDM1ODhiaXMg SXNzdWVzIFN0YXR1cw0KDQpbLi4gc25pcCAuLl0NCj4gSSBhZ3JlZSB3aXRoIHlvdXIgZXhhbXBs ZSBhYm92ZSByZWdhcmRpbmcgZGVzdGluYXRpb24taG9zdC4gSXQgaXMNCj4gcmVxdWlyZWQgaW4g dGhlIGNhc2Ugb2YgQVNSIChhbmQgcGVyaGFwcyBzb21lIG90aGVyIG1lc3NhZ2UpIHRob3VnaCBJ DQo+IGd1ZXNzIEkgd2FzIHN0YXRpbmcgYSBjYXNlIHdoaWNoIGlzIGEgbGl0dGxlIGJpdCBkaWZm ZXJlbnQgdGhhbiB5b3VyDQo+IGV4YW1wbGUgYWJvdmUuIEkgd2FzIHRoaW5raW5nIG9mIHRoZSBm b2xsb3dpbmcgY2FzZToNCj4NCj4gY2xpZW50c1sxLDIsMy4uLnhdIDwtLS0gcmVsYXkxIDwtLS0t IHJlbGF5MiA8LS0tLSBzZXJ2ZXINCj4NCj4gaW4gdGhpcyBjYXNlIHJlbGF5MiB3aWxsIG5vdCBi ZSBhYmxlIHRvIHJvdXRlIHVzaW5nIGRlc3QtaG9zdC4gVGhpcyBpcw0KPiB3aGVyZSBkZXN0LXJl YWxtIGFuZCBhcHAgaWQgYmVjb21lcyBpbXBvcnRhbnQuIEluIHRoaXMgY2FzZSBhcHAgaWQgb2Yg MA0KPiBtaWdodCBub3Qgd29yayBhcyB3ZWxsIC4uLiBvciBtYXliZSBJJ20gd3JvbmcuDQo+DQo+ IFtNU3RdIEluIHRoaXMgY2FzZSBSMSB3b3VsZCBhZHZlcnRpc2UgaXQgc2VsZiBhcyBhIHJlbGF5 IChpLmUuDQo+IDB4ZmZmZmZmZmYpIGl0IHdvbid0IGFkdmVydGlzZSBhcHAgaWQgeCBvciB5IG9y IHouIFNvLCBhbnkgYXBwIGlkDQo+IHdvdWxkIGJlIHJvdXRlZCB0byBSMSBieSBSMi4NCltUT0xH QV0gTGV0IG1lIHRyeSB0byBmdXJ0aGVyIHJlZmluZSB0aGUgc2NlbmFyaW86DQogICAgICAgICAg ICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICogIFJlYWxt IEEgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICAgICAgICAg ICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQog ICAgICAgICAgICAgICogICAgICAgICstLStDMSBBcHA9WCB8ICAgICAqDQogICAgICAgICAgICAg ICogKy0tLS0rIHwgICstLS0tLS0tLS0rICAgICAqDQogICAgICAgICArLS0tLSotKyBQMSArLSsg ICstLS0tLS0tLS0rICAgICAqDQorLS0tKyAgKy0rLS0rICogKy0tLS0rLS0tLStDMiBBcHA9WSB8 ICAgICAqDQp8UzEgKy0tKyBSMSB8ICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQorLS0t KyAgKy0rLS0rICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICB8ICAgICog Ky0tLS0rICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICArLS0tLSotKyBQMiArLS0tLSst LS0tLS0tLS0rICAgICAqDQogICAgICAgICAgICAgICogKy0tLS0rICAgIHxDMyBBcHA9WiB8ICAg ICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQogICAgICAg ICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqDQpJbiB0aGlzIGNhc2UsIFIxIHdvdWxkbid0IGhhdmUg ZW5vdWdoIGtub3dsZWRnZSB0byByb3V0ZSB0aGUgbWVzc2FnZQ0KcHJvcGVybHkgdG8gdGhlIGNv cnJlY3QgcHJveHkganVzdCBieSBsb29raW5nIHRvIHRoZSBBcHAtSWQgaW4gdGhlIG1lc3NhZ2UN CmhlYWRlciwgaWYgQXBwLUlkIGlzIHBvcHVsYXRlZCB3aXRoICIwIi4NCg0KW01TdF0gSSB0aGlu ayB5b3UgYXNzdW1lIFAxIGFuZCBQMiBhZHZlcnRpc2Ugc3VwcG9ydHMgZm9yIEFwcCB4L3kgYW5k IEFwcCB6IHJlc3BlY3RpdmVseSBidXQgSSB3b3VsZCByYXRoZXIgY29uc2lkZXIgdGhpcyBjb25m aWd1cmF0aW9uIGFuIGFjYWRlbWljIHVzZSBjYXNlIHNpbmNlIHR5cGljYWxseSB5b3UgaGF2ZSBv bmx5IG9uZSBsb2dpY2FsIFByb3h5IGFzIGEgaW50ZXJjb25uZWN0IHBvaW50IGZvciBhIGdpdmVu IHJlYWxtIGluIHJlYWwgZGVwbG95bWVudHMgYXMgYSBjZW50cmFsIHBvaW50IGZvciBwb2xpY3kg ZW5mb3JjZW1lbnQuIEhvd2V2ZXIsIGxldCBzZWUgd2hldGhlciBhIHNlcnZlciBpbml0aWF0ZWQg bWVzc2FnZSB1c2luZyBEZXN0aW5hdGlvbi1Ib3N0IGFuZCBhcHAgaWQgMCBiYXNlZCByb3V0aW5n IHdvcmtzLg0KDQpTMSBzZW5kcyBBU1IgdG8gQzMgKEMzIGRpYW1ldGVyIGlkZW50aXR5IGluIERl c3RpbmF0aW9uLUhvc3QgQVZQKSBhcHAgaWQgMC4gSW4gdGhlIHJlYWxtLWJhc2VkIHJvdXRpbmcg dGFibGUgUjEgd2lsbCBjZXJ0YWlubHkgZmluZCBhIG1hdGNoIGZvciByZWFsbSBBIGFuZCBhcHAg aWQgMCwgc2F5IGZvciBpbnN0YW5jZSB0aGUgbWF0Y2ggaXMgZm9yIFAxLiBBU1IgaXMgcm91dGVk IHRvIFAxLCB3aGljaCBkb2Vzbid0IGhhdmUgQzMgaW4gaXRzIHBlZXIgdGFibGUgYW5kIHRoZW4g YW5zd2VycyB3aXRoIERJQU1FVEVSX1VOQUJMRV9UT19ERUxJVkVSLiBSMSBhdHRlbXB0cyB0aGVu IHRvIGRlbGl2ZXIgdGhlIG1lc3NhZ2UgdmlhIHRoZSBhbHRlcm5hdGl2ZSBlbnRyeSBmb3IgUmVh bG0gQSwgaGVuY2UgUDIuIFAyIG5vdyBkZWxpdmVyIHRoZSBtZXNzYWdlIHRvIEMzLiBTbywgYXBw LWlkIDAgd29ya3MgYXQgdGhlIGVuZCBpZiBEZXN0aW5hdGlvbi1Ib3N0IGJhc2VkIHJvdXRpbmcg aXMgdXNlZCBhbmQsIGFjdHVhbGx5LCBpcyB0byBiZSB1c2VkIGZvciBjZXJ0YWluIHNlcnZlciBp bml0aWF0ZWQgbWVzc2FnZXMgYXMgYWxzbyBkZWZpbmVkIGluIFJGQyAzNTg4IGluIHNlY3Rpb24g Ni4xLiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0K --===============0990674632== 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 --===============0990674632==-- From dime-bounces@ietf.org Mon Jul 24 06:16:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xTv-0005XD-5V; Mon, 24 Jul 2006 06:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xTu-0005X8-4F for dime@ietf.org; Mon, 24 Jul 2006 06:16:10 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xTq-0008DG-Os for dime@ietf.org; Mon, 24 Jul 2006 06:16:10 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00CV0L9UN5@szxga02-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:32:19 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00M3OL9U78@szxga02-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:32:18 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W0063YL0OOW@szxml04-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:26:49 +0800 (CST) Date: Mon, 24 Jul 2006 15:45:19 +0530 From: Rajith R To: dime@ietf.org Message-id: <002701c6af0a$1176cd10$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcavCQM0f/WLUf6ATEmGJy45UHC3XQAAQolA X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Dime] FW: [AAA-WG]: Diameter - Failover Implementation 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: , Content-Type: multipart/mixed; boundary="===============0580162925==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0580162925== Content-type: multipart/alternative; boundary="Boundary_(ID_vH2RXH0cfDz4jy1hz1/oAw)" This is a multi-part message in MIME format. --Boundary_(ID_vH2RXH0cfDz4jy1hz1/oAw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT **************************************************************************** ******** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Monal Sengar Sent: Monday, July 24, 2006 3:31 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter - Failover Implementation Hi All, In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id. In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting. But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table. Which option seems to be better? Thanks in advance Monal --Boundary_(ID_vH2RXH0cfDz4jy1hz1/oAw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Monal Sengar
Sent: Monday, July 24, 2006 3:31 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter - Failover Implementation

 

Hi All,

In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id.

In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting.

But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table.

Which option seems to be better?

Thanks in advance
Monal

--Boundary_(ID_vH2RXH0cfDz4jy1hz1/oAw)-- --===============0580162925== 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 --===============0580162925==-- From dime-bounces@ietf.org Mon Jul 24 06:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xZ8-0008OC-H2; Mon, 24 Jul 2006 06:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xZ7-0008IE-59 for dime@ietf.org; Mon, 24 Jul 2006 06:21:33 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xZ5-0000ts-Hk for dime@ietf.org; Mon, 24 Jul 2006 06:21:33 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W008HQKYTML@szxga03-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:25:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00GQEKYT9P@szxga03-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:25:41 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W0067DL1HOW@szxml04-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:27:18 +0800 (CST) Date: Mon, 24 Jul 2006 15:45:48 +0530 From: Rajith R To: dime@ietf.org Message-id: <002c01c6af0a$22bfb280$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcavCJWI2Fd1EdZqR8KBms7lo684wgAAYqxg X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Dime] FW: [AAA-WG]: Realm expiration timer 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: , Content-Type: multipart/mixed; boundary="===============0102223007==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0102223007== Content-type: multipart/alternative; boundary="Boundary_(ID_SBjp5CVPNbVyXjAb8n/lAA)" This is a multi-part message in MIME format. --Boundary_(ID_SBjp5CVPNbVyXjAb8n/lAA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT **************************************************************************** ******** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma Sent: Monday, July 24, 2006 3:34 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Realm expiration timer Hi, As per RFC 3588 section 5.2 "A dynamically discovered peer causes an entry in the Peer Table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value." So we will make an entry into the peer table and realm table (if required) when ever a new peer is discovered, connected and CER, CEA are exchanged. As per our understanding, if the peer expiration timeout happens and if the peer's state is closed we will try to re-connect to the peer. If the peer's state is Open we are doing nothing. Is this correct? What do we need to do when the the realm expiration timeout happens? -- Yours Naveen. --Boundary_(ID_SBjp5CVPNbVyXjAb8n/lAA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma
Sent: Monday, July 24, 2006 3:34 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Realm expiration timer

 

Hi,
    As per RFC 3588 section 5.2

"A dynamically discovered peer causes an entry in the Peer Table (see Section 2.6) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.7) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value."

So we will make an entry into the peer table and realm table (if required) when ever a new peer is discovered, connected and CER, CEA are exchanged.

As per our understanding, if the peer expiration timeout happens and if the peer's state is closed we will try to re-connect to the peer.  If the peer's state is Open we are doing nothing.  Is this correct?

What do we need to do when the the realm expiration timeout happens?

--
Yours
Naveen.

--Boundary_(ID_SBjp5CVPNbVyXjAb8n/lAA)-- --===============0102223007== 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 --===============0102223007==-- From dime-bounces@ietf.org Mon Jul 24 06:29:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xgk-0002is-CD; Mon, 24 Jul 2006 06:29:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xgj-0002in-9k for dime@ietf.org; Mon, 24 Jul 2006 06:29:25 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xgd-0002Qg-KA for dime@ietf.org; Mon, 24 Jul 2006 06:29:25 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W008Q8L52ML@szxga03-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:29:27 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00GVTL52MR@szxga03-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:29:26 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W005FVKT8EU@szxml03-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:22:21 +0800 (CST) Date: Mon, 24 Jul 2006 15:49:33 +0530 From: Rajith R Subject: RE: [Dime] FW: [AAA-WG]: Diameter - Failover Implementation In-reply-to: <002701c6af0a$1176cd10$a905120a@china.huawei.com> To: 'Monal Sengar' , dime@ietf.org Message-id: <003701c6af0a$a8ccb6c0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcavCQM0f/WLUf6ATEmGJy45UHC3XQAAQolAAAAUfWA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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: , Content-Type: multipart/mixed; boundary="===============1991430647==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1991430647== Content-type: multipart/alternative; boundary="Boundary_(ID_17TPYmUlBsS8CEAmtnTJgA)" This is a multi-part message in MIME format. --Boundary_(ID_17TPYmUlBsS8CEAmtnTJgA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi For each app Id, a primary peer may have a different alternate peer. So 2nd option is better. Regards Rajith **************************************************************************** ******** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Rajith R [mailto:rajithr@huawei.com] Sent: Monday, July 24, 2006 3:45 PM To: dime@ietf.org Subject: [Dime] FW: [AAA-WG]: Diameter - Failover Implementation **************************************************************************** ******** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Monal Sengar Sent: Monday, July 24, 2006 3:31 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter - Failover Implementation Hi All, In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id. In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting. But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table. Which option seems to be better? Thanks in advance Monal --Boundary_(ID_17TPYmUlBsS8CEAmtnTJgA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi

            For each app Id, a primary peer may have a different alternate peer. So 2nd option is better.

 

Regards

 

Rajith

 

************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Rajith R [mailto:rajithr@huawei.com]
Sent: Monday, July 24, 2006 3:45 PM
To: dime@ietf.org
Subject: [Dime] FW: [AAA-WG]: Diameter - Failover Implementation

 

 

 

************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Monal Sengar
Sent: Monday, July 24, 2006 3:31 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter - Failover Implementation

 

Hi All,

In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id.

In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting.

But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table.

Which option seems to be better?

Thanks in advance
Monal

--Boundary_(ID_17TPYmUlBsS8CEAmtnTJgA)-- --===============1991430647== 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 --===============1991430647==-- From dime-bounces@ietf.org Mon Jul 24 06:42:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xsu-00088C-0h; Mon, 24 Jul 2006 06:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xss-000887-B2 for dime@ietf.org; Mon, 24 Jul 2006 06:41:58 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xsn-0005Tv-B3 for dime@ietf.org; Mon, 24 Jul 2006 06:41:58 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00CC3M5UN5@szxga02-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:51:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J2W00LGHM5UUG@szxga02-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:51:30 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J2W006QALWNOW@szxml04-in.huawei.com> for dime@ietf.org; Mon, 24 Jul 2006 18:46:00 +0800 (CST) Date: Mon, 24 Jul 2006 18:34:30 +0800 From: Tony Zhang Subject: Re: [Dime] Summary of 3588bis Issues Status To: Ram O V Vishnu-A14676 , "STURA, Marco, VF-IT" , Tolga Asveren , Victor Fajardo Message-id: <00a901c6af0c$bf5b2e10$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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="===============1411793346==" Errors-To: dime-bounces@ietf.org --===============1411793346== Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgQWxsLA0KICAgIEkgYWdyZWUgd2l0aCB0aGlzLg0KICAgIGFsc28gYWJvdXQgYmVsb3cgZm9y bWVyIGRpc2N1c3MsaSBoYXZlIG9uZSBtb3JlIGNvbW1lbnRzOg0KICAgIGlmIGFwcGxpY2F0aW9u IGFjdWFsbHkgaXMgYSAoc2V0IG9mKSBzcGVjaWZpY2F0aW9ucyB0aGF0IGRvY3VtZW50IGhvdyBE aWFtZXRlciBpcyBleHRlbmRlZCBmb3Igc29tZSBwYXJ0aWN1bGFyIHB1cnBvc2UgLndoeSBpbiB0 aGUgUkZDMzU4OCBBY2NvdW50aW5nIE1lc3NhZ2Ugbm90IHVzZSBBcHBsaWNhdGlvbiBJRCAwPw0K DQpUaGFua3MgUmVnYXJkcw0KVG9ueQ0KDQpmb3JtZXIgZGlzY3VzczoNClRvbGdhLA0KDQpUaGlz IGlzIG5vdCB0aGUgZmlyc3QgdGltZSB0aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2N1c3NlZCAoc2Vl IGUuZy4gDQpBQUEgYXJjaGl2ZXMgYXJvdW5kIEp1bHkgMjAwNCkuIFdoYXQgaXQgcmVhbGx5IGJv aWxzIGRvd24gdG8NCmlzIHdoYXQgZXhhY3RseSBhbiAiYXBwbGljYXRpb24iIGlzLiBRdW90aW5n IG15c2VsZiBmcm9tIHR3bw0KeWVhcnMgYWdvOg0KDQo+IFRoaXMgYnJpbmdzIHVzIGJhY2sgdG8g dGhlIHRvcGljIHdoYXQgYW4gImFwcGxpY2F0aW9uIiBhY3R1YWxseQ0KPiBpcy4gSXQgY291bGQg bWVhbiBlLmcuIGEgc29mdHdhcmUgbW9kdWxlIGluIGEgRGlhbWV0ZXINCj4gaW1wbGVtZW50YXRp b24sIG9yIGEgKHNldCBvZikgc3BlY2lmaWNhdGlvbnMgdGhhdCBkb2N1bWVudCBob3cNCj4gRGlh bWV0ZXIgaXMgZXh0ZW5kZWQgZm9yIHNvbWUgcGFydGljdWxhciBwdXJwb3NlIChzdWNoIGFzIFNJ UCBvcg0KPiBNb2JpbGUgSVB2NCkuDQo+DQo+IE15IHJlYWRpbmcgb2YgUkZDMzU4OCBzdXBwb3J0 cyB0aGUgbGF0dGVyIGludGVycHJldGF0aW9uIChidXQgSQ0KPiBndWVzcyB0aGVyZSBpcyBzb21l IHJvb20gZm9yIGRpc2FncmVlbWVudCBhbmQgb3RoZXIgaW50ZXJwcmV0YXRpb25zDQo+IGFzIHdl bGwuLi4pLg0KDQpXaXRoIHRoaXMgaW50ZXJwcmV0YXRpb24sIGl0IGRvZXMgbm90IG1ha2Ugc2Vu c2UgdG8gc2F5IHRoYXQgeW91IHNlbmQNCmEgbWVzc2FnZSBfdG9fIGFuIGFwcGxpY2F0aW9uLCBv ciB0aGF0IGEgbWVzc2FnZSBpcyBpbnRlbmRlZCBfZm9yXyBhbg0KYXBwbGljYXRpb24uIEluc3Rl YWQsIHlvdSBzZW5kIGEgbWVzc2FnZSBkZWZpbmVkIF9pbl8gc29tZQ0KYXBwbGljYXRpb24uDQoN CkJhY2sgdGhlbiwgc2V2ZXJhbCBvdGhlcnMgc2VlbWVkIHRvIGFncmVlIHRoYXQgUkZDIDM1ODgg c3VwcG9ydHMgDQp0aGlzIGludGVycHJldGF0aW9uLiANCg0KKEhvdyBhIERpYW1ldGVyIHNlcnZl ciBpbXBsZW1lbnRhdGlvbiBpcyBvcmdhbml6ZWQgdG8gbW9kdWxlcyBhbmQgDQpob3cgdGhlIG1v ZHVsZXMgY29tbXVuaWNhdGUgaXMgYmV5b25kIHRoZSBzY29wZSBvZiBSRkMgMzU4OC4pDQoNCkJl c3QgcmVnYXJkcywNClBhc2kNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIlJhbSBPIFYgVmlzaG51LUExNDY3NiIgPHZpc2hudUBtb3Rvcm9sYS5jb20+DQpUbzogIlNU VVJBLCBNYXJjbywgVkYtSVQiIDxNYXJjby5TVFVSQUB2b2RhZm9uZS5jb20+OyAiVG9ueSBaaGFu ZyIgPHpoYW5ndGFvX2h3QGh1YXdlaS5jb20+OyAiVG9sZ2EgQXN2ZXJlbiIgPGFzdmVyZW5AdWx0 aWNvbS5jb20+OyAiVmljdG9yIEZhamFyZG8iIDx2ZmFqYXJkb0B0YXJpLnRvc2hpYmEuY29tPg0K Q2M6IDxkaW1lQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIEp1bHkgMjIsIDIwMDYgMToxMyBB TQ0KU3ViamVjdDogUkU6IFtEaW1lXSBTdW1tYXJ5IG9mIDM1ODhiaXMgSXNzdWVzIFN0YXR1cw0K DQoNCkhpIEFsbCwNCg0KSXRzICpub3QqIGEgZ29vZCBpZGVhIHRvIHVzZSBhcHBsaWNhdGlvbiBp ZCAwIGZvciBSQVIsIFJBQSwgQVNSLCBBU0EsIFNUUiwgU1RBLiANCg0KTXkgcmVhc29ucyBhcmU6 IA0KDQoxLiBNeSBkZWZpbml0aW9uIChpbiB0aGUgYWJzZW5jZSBvZiBvbmUgaW4gdGhlIFJGQyAz NTg4KSBvZiAiRGlhbWV0ZXIgQ29tbW9uIE1lc3NhZ2UiIGlzIHRoYXQgLSBvbmx5IHRoZSBvbmVz IHVzZWQgaW4gRlNNIGluIHNlY3Rpb24gNS42IG9mIFJGQyAzNTg4IHNob3VsZCBiZSB0cmVhdGVk IGFzIGNvbW1vbiBtZXNzYWdlcy4NCg0KMi4gSW4gdGhlIHBsYWNlIHdoZXJlIFNlc3Npb25zIGFy ZSBkZWZpbmVkIChpbiBzZWN0aW9uIDEuMykgUkZDIDM1ODgsIGl0IGlzIG1lbnRpb25lZCB0aGF0 ICAiRWFjaCBhcHBsaWNhdGlvbiBTSE9VTEQgcHJvdmlkZSBndWlkZWxpbmVzIGFzIHRvIHdoZW4g YSBzZXNzaW9uIGJlZ2lucyBhbmQgZW5kcy4iIFNvIHNlc3Npb25zIGFyZSBhcHBsaWNhdGlvbiBs ZXZlbCBlbnRpdGllcyBhbmQgaGVuY2Ugc2Vzc2lvbiByZWxhdGVkIG1lc3NhZ2VzIChsaWtlIEFT Ui9TVFIpIHdpdGggYXBwLWlkIDAgZG9lcyBub3QgbWFrZSBzZW5zZS4gVGhleSBzaG91bGQgYmUg d2l0aCBzcGVjaWZpYyBhcHBsaWNhdGlvbiBpZHMgd2hpY2ggbWFpbnRhaW4gdGhvc2Ugc2Vzc2lv bnMuDQoNCjMuIEkgYWdyZWUgd2l0aCBUb255IHRoYXQgdGhpcyB3aWxsIGJyZWFrIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgYmFzZSBwcm90b2NvbC4gQWJvdXQgdGhlIHBhc3QgZGlz Y3Vzc2lvbnMtIFJGQyAzNTg4IHN0aWxsIHN0YXllZCwgaXQgd2FzIG5vdCBjb3JyZWN0ZWQsIGlt cGxlbWVudGF0aW9ucyBoYXZlIGdvbmUgYWhlYWQgLSBJIGd1ZXNzIHdlIHNob3VsZCB0YWtlIGEg ZnJlc2ggbG9vay4NCg0KQWJvdXQgb3RoZXIgUkZDcyB1c2luZyBvdGhlciBpbnRlcnByZXRhdGlv bnMsIEkgdGhpbmsgdGhvc2Ugc2hvdWxkIGJlIGNvcnJlY3RlZC4NCg0KUmVnYXJkcywNClZpc2hu dS4NCg0KTW90b3JvbGEgSW5kaWEgRWxlY3Ryb25pY3MgUHZ0IEx0ZA0KKzkxIDk4NDQxNzgwNTIN ClsqXSBNb3Rvcm9sYSBJbnRlcm5hbCBVc2UgT25seQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFNUVVJBLCBNYXJjbywgVkYtSVQgW21haWx0bzpNYXJjby5TVFVSQUB2 b2RhZm9uZS5jb21dIA0KU2VudDogRnJpZGF5LCBKdWx5IDIxLCAyMDA2IDEyOjQ4IFBNDQpUbzog VG9ueSBaaGFuZzsgVG9sZ2EgQXN2ZXJlbjsgVmljdG9yIEZhamFyZG8NCkNjOiBkaW1lQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW0RpbWVdIFN1bW1hcnkgb2YgMzU4OGJpcyBJc3N1ZXMgU3RhdHVz DQoNCg0KSGkgVG9ueSwNCg0KU2VydmVyIGluaXRpYXRlZCByZXF1ZXN0cyBjYW4gb25seSBiZSBz ZW50IGluIHRoZSBjb250ZXh0IG9mIGV4aXN0aW5nIHNlc3Npb25zIGFuZCByb3V0aW5nIG11c3Qg YmUgZG9uZSBvbiB0aGUgYmFzaXMgb2YgRGVzdGluYXRpb24tSG9zdCB0byBlbnN1cmUgdGhhdCB0 aGUgcmVxdWVzdCBoaXRzIHRoZSBjb3JyZWN0IGNsaWVudCwgc28gYXBwIGlkIGlzIG5vdCBlbm91 Z2guDQoNClRoZSByb3V0aW5nIHByb2JsZW0geW91IGFyZSBkaXNjdXNzaW5nIGhhcyB0byBkbyB3 aXRoIGhvdyBhIHByb3h5IGNhbiBzdGF5IG9uIHRoZSBwYXRoIGR1cmluZyBhIHNlc3Npb24gc28g dGhhdCBhIHNlcnZlciBjYW4gc2VuZCBhIHJlcXVlc3QsIHNheSBBU1Igb3IgUkFSLCB0byBEZXN0 aW5hdGlvbi1Ib3N0IHZpYSBQMSB0byBDMS4gQXMgYWxzbyBzdWdnZXN0ZWQgYnkgVG9sZ2ENCg0K PkkgdGhpbmsgaXQgY2FuIGJlIGRlZHVjdGVkIHRvIHRoZSBnZW5lcmljIHByb2JsZW0gb2YgIkhv dyBjYW4gYSBwcm94eSANCj5zdGF5ID5vbiB0aGUgcGF0aCBkdXJpbmcgYSBzZXNzaW9uIiwgc28g SSBiZWxpZXZlIHRoaXMgaXMgdGhlIHF1ZXN0aW9uIA0KPnRvIGFuc3dlciA+KHdoaWNoIHdlIGFs cmVhZHkgZGlzY3Vzc2VkIHRvIHNvbWUgZXh0ZW50IGluIHRoZSBjb250ZXh0IG9mIA0KPnN0cmlj dC1yb3V0aW5nID5kcmFmdCByZXZpZXcpDQoNClNvIEkgdGhpbmsgeW91ciBpc3N1ZSBjYW4gYmUg ZGlzY3Vzc2VkIGluIHRoYXQgY29udGV4dCwgYXBwIGlkIDAgZm9yIGNvbW1vbiBtZXNzYWdlcyBJ IHRoaW5rIGlzIGZpbmUuDQoNClJlZ2FyZHMNCk1hcmNvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBUb255IFpoYW5nIFttYWlsdG86emhhbmd0YW9faHdAaHVhd2VpLmNvbV0g DQpTZW50OiB2ZW5lcmTsIDIxIGx1Z2xpbyAyMDA2IDUuNDMNClRvOiBTVFVSQSwgTWFyY28sIFZG LUlUOyBUb2xnYSBBc3ZlcmVuOyBWaWN0b3IgRmFqYXJkbw0KQ2M6IGRpbWVAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbRGltZV0gU3VtbWFyeSBvZiAzNTg4YmlzIElzc3VlcyBTdGF0dXMNCg0KSGkg TWFjcm86DQoNCltNU3RdIEkgdGhpbmsgeW91IGFzc3VtZSBQMSBhbmQgUDIgYWR2ZXJ0aXNlIHN1 cHBvcnRzIGZvciBBcHAgeC95IGFuZCBBcHAgeiByZXNwZWN0aXZlbHkgYnV0IEkgd291bGQgcmF0 aGVyIGNvbnNpZGVyIHRoaXMgY29uZmlndXJhdGlvbiBhbiBhY2FkZW1pYyB1c2UgY2FzZSBzaW5j ZSB0eXBpY2FsbHkgeW91IGhhdmUgb25seSBvbmUgbG9naWNhbCBQcm94eSBhcyBhIGludGVyY29u bmVjdCBwb2ludCBmb3IgYSBnaXZlbiByZWFsbSBpbiByZWFsIGRlcGxveW1lbnRzIGFzIGEgY2Vu dHJhbCBwb2ludCBmb3IgcG9saWN5IGVuZm9yY2VtZW50LiBIb3dldmVyLCBsZXQgc2VlIHdoZXRo ZXIgYSBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2UgdXNpbmcgRGVzdGluYXRpb24tSG9zdCBhbmQg YXBwIGlkIDAgYmFzZWQgcm91dGluZyB3b3Jrcy4NCg0KUzEgc2VuZHMgQVNSIHRvIEMzIChDMyBk aWFtZXRlciBpZGVudGl0eSBpbiBEZXN0aW5hdGlvbi1Ib3N0IEFWUCkgYXBwIGlkIDAuIEluIHRo ZSByZWFsbS1iYXNlZCByb3V0aW5nIHRhYmxlIFIxIHdpbGwgY2VydGFpbmx5IGZpbmQgYSBtYXRj aCBmb3IgcmVhbG0gQSBhbmQgYXBwIGlkIDAsIHNheSBmb3IgaW5zdGFuY2UgdGhlIG1hdGNoIGlz IGZvciBQMS4gQVNSIGlzIHJvdXRlZCB0byBQMSwgd2hpY2ggZG9lc24ndCBoYXZlIEMzIGluIGl0 cyBwZWVyIHRhYmxlIGFuZCB0aGVuIGFuc3dlcnMgd2l0aCBESUFNRVRFUl9VTkFCTEVfVE9fREVM SVZFUi4gUjEgYXR0ZW1wdHMgdGhlbiB0byBkZWxpdmVyIHRoZSBtZXNzYWdlIHZpYSB0aGUgYWx0 ZXJuYXRpdmUgZW50cnkgZm9yIFJlYWxtIEEsIGhlbmNlIFAyLiBQMiBub3cgZGVsaXZlciB0aGUg bWVzc2FnZSB0byBDMy4gU28sIGFwcC1pZCAwIHdvcmtzIGF0IHRoZSBlbmQgaWYgRGVzdGluYXRp b24tSG9zdCBiYXNlZCByb3V0aW5nIGlzIHVzZWQgYW5kLCBhY3R1YWxseSwgaXMgdG8gYmUgdXNl ZCBmb3IgY2VydGFpbiBzZXJ2ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIGFzIGFsc28gZGVmaW5lZCBp biBSRkMgMzU4OCBpbiBzZWN0aW9uIDYuMS4gDQoNCltUb255XUJlY2F1c2UgdGhlIEFwcGxpY2F0 aW9uIElkIDAsbm90IGFkdmVydGlzZW1lbnQgaW4gQ0VSL0NFQSxzbyBpdCBtZWFucyBlYWNoIHJl YWxtIHdpbGwgdXNlIHRoZSBwZWV0IHRhYmxlIHNlbGVjdCBuZXh0IGhvcCxhbG1vc3QgcGVlciB0 YWJsZSBoYXZlIG1hbnkgcGVlciBjYW4gc2VsZWN0LGFsc28gaW5jbHVkZSBwZWVyIG9mIHJlY2Vp dmUgdGhlIHJlcXVlc3QuIHNvIGl0IGNhbiBoYXBwZW4gbG9vcCByb3V0aW5nLihtYXliZSBjYW4g YWRkIG9uZSBwcm9jZXNzIGF2b2lkIHRoaXMsd2hlbiByb3V0aW5nIHNob3VsZCBpbnB1dCBwZWVy IG5hbWUgb2YgcmVjZWl2ZSB0aGUgcmVxdWVzdC4pLnRoZSBvdGhlciBwcm9ibGVtLGFmdGVyIHJl dHJ5IG1hbnkgcGVlciAsdGhlbiB3ZSBmaW5kIGNvcnJlY3Qgcm91dGUsaXQgY29uc3VtZSBsb25n IHRpbWUsbWF5YmUgdGhlIGNsaWVudCBhbHJlYWR5IHRpbWVyIGV4cGlyZS5hbHNvIGFwcGxpY2F0 aW9uIGlkIHVzZSBmb3IgZWZmZWN0aXZlbHkgcm91dGluZyxidXQgZm9yIGFib3ZlIHRoZSBjYXNl ICxpdCBpcyBub3QgbGlrZSB0aGlzLg0KDQpzb3JyeSBhYm91dCBpIGRpc2N1c3MgdGhpcyBhZ2Fp bixhZnRlciAyMDA0J3MgZGljdXNzLGl0IGlzIGxpa2VseSBtYW55IHBlb3BsZSBjb25mdXNpb24u aWYgdGhpcyB0aW1lIGhhdmUgc2FtZSBjb25sdXNpb24gbWF5YmUgc3RpbGwgaGF2ZSBzYW1lIHBy b2JsZW0uDQoNClRoYW5rcyENClRvbnkNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CkZyb206ICJTVFVSQSwgTWFyY28sIFZGLUlUIiA8TWFyY28uU1RVUkFAdm9kYWZvbmUuY29tPg0K VG86ICJUb2xnYSBBc3ZlcmVuIiA8YXN2ZXJlbkB1bHRpY29tLmNvbT47ICJWaWN0b3IgRmFqYXJk byIgPHZmYWphcmRvQHRhcmkudG9zaGliYS5jb20+DQpDYzogPGRpbWVAaWV0Zi5vcmc+DQpTZW50 OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMDYgNToxMSBQTQ0KU3ViamVjdDogUkU6IFtEaW1lXSBT dW1tYXJ5IG9mIDM1ODhiaXMgSXNzdWVzIFN0YXR1cw0KDQoNClNlZSBpbiBsaW5lLg0KDQpSZWdh cmRzDQpNYXJjbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9sZ2EgQXN2 ZXJlbiBbbWFpbHRvOmFzdmVyZW5AdWx0aWNvbS5jb21dIA0KU2VudDogbWFydGVk7CAxOCBsdWds aW8gMjAwNiAxOC41Mg0KVG86IFNUVVJBLCBNYXJjbywgVkYtSVQ7IFZpY3RvciBGYWphcmRvDQpD YzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtEaW1lXSBTdW1tYXJ5IG9mIDM1ODhiaXMg SXNzdWVzIFN0YXR1cw0KDQpbLi4gc25pcCAuLl0NCj4gSSBhZ3JlZSB3aXRoIHlvdXIgZXhhbXBs ZSBhYm92ZSByZWdhcmRpbmcgZGVzdGluYXRpb24taG9zdC4gSXQgaXMgDQo+IHJlcXVpcmVkIGlu IHRoZSBjYXNlIG9mIEFTUiAoYW5kIHBlcmhhcHMgc29tZSBvdGhlciBtZXNzYWdlKSB0aG91Z2gg SSANCj4gZ3Vlc3MgSSB3YXMgc3RhdGluZyBhIGNhc2Ugd2hpY2ggaXMgYSBsaXR0bGUgYml0IGRp ZmZlcmVudCB0aGFuIHlvdXIgDQo+IGV4YW1wbGUgYWJvdmUuIEkgd2FzIHRoaW5raW5nIG9mIHRo ZSBmb2xsb3dpbmcgY2FzZToNCj4NCj4gY2xpZW50c1sxLDIsMy4uLnhdIDwtLS0gcmVsYXkxIDwt LS0tIHJlbGF5MiA8LS0tLSBzZXJ2ZXINCj4NCj4gaW4gdGhpcyBjYXNlIHJlbGF5MiB3aWxsIG5v dCBiZSBhYmxlIHRvIHJvdXRlIHVzaW5nIGRlc3QtaG9zdC4gVGhpcyBpcyANCj4gd2hlcmUgZGVz dC1yZWFsbSBhbmQgYXBwIGlkIGJlY29tZXMgaW1wb3J0YW50LiBJbiB0aGlzIGNhc2UgYXBwIGlk IG9mIA0KPiAwIG1pZ2h0IG5vdCB3b3JrIGFzIHdlbGwgLi4uIG9yIG1heWJlIEknbSB3cm9uZy4N Cj4NCj4gW01TdF0gSW4gdGhpcyBjYXNlIFIxIHdvdWxkIGFkdmVydGlzZSBpdCBzZWxmIGFzIGEg cmVsYXkgKGkuZS4NCj4gMHhmZmZmZmZmZikgaXQgd29uJ3QgYWR2ZXJ0aXNlIGFwcCBpZCB4IG9y IHkgb3Igei4gU28sIGFueSBhcHAgaWQgDQo+IHdvdWxkIGJlIHJvdXRlZCB0byBSMSBieSBSMi4N CltUT0xHQV0gTGV0IG1lIHRyeSB0byBmdXJ0aGVyIHJlZmluZSB0aGUgc2NlbmFyaW86DQogICAg ICAgICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQogICAgICAgICAgICAgICog IFJlYWxtIEEgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICAg ICAgICAgICAgICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAg ICAqDQogICAgICAgICAgICAgICogICAgICAgICstLStDMSBBcHA9WCB8ICAgICAqDQogICAgICAg ICAgICAgICogKy0tLS0rIHwgICstLS0tLS0tLS0rICAgICAqDQogICAgICAgICArLS0tLSotKyBQ MSArLSsgICstLS0tLS0tLS0rICAgICAqDQorLS0tKyAgKy0rLS0rICogKy0tLS0rLS0tLStDMiBB cHA9WSB8ICAgICAqDQp8UzEgKy0tKyBSMSB8ICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAq DQorLS0tKyAgKy0rLS0rICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICB8 ICAgICogKy0tLS0rICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICArLS0tLSotKyBQMiAr LS0tLSstLS0tLS0tLS0rICAgICAqDQogICAgICAgICAgICAgICogKy0tLS0rICAgIHxDMyBBcHA9 WiB8ICAgICAqDQogICAgICAgICAgICAgICogICAgICAgICAgICstLS0tLS0tLS0rICAgICAqDQog ICAgICAgICAgICAgICogICAgICAgICAgICAgICAgICAgICAgICAgICAqDQogICAgICAgICAgICAg ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpJbiB0aGlzIGNhc2UsIFIxIHdvdWxkbid0 IGhhdmUgZW5vdWdoIGtub3dsZWRnZSB0byByb3V0ZSB0aGUgbWVzc2FnZSBwcm9wZXJseSB0byB0 aGUgY29ycmVjdCBwcm94eSBqdXN0IGJ5IGxvb2tpbmcgdG8gdGhlIEFwcC1JZCBpbiB0aGUgbWVz c2FnZSBoZWFkZXIsIGlmIEFwcC1JZCBpcyBwb3B1bGF0ZWQgd2l0aCAiMCIuDQoNCltNU3RdIEkg dGhpbmsgeW91IGFzc3VtZSBQMSBhbmQgUDIgYWR2ZXJ0aXNlIHN1cHBvcnRzIGZvciBBcHAgeC95 IGFuZCBBcHAgeiByZXNwZWN0aXZlbHkgYnV0IEkgd291bGQgcmF0aGVyIGNvbnNpZGVyIHRoaXMg Y29uZmlndXJhdGlvbiBhbiBhY2FkZW1pYyB1c2UgY2FzZSBzaW5jZSB0eXBpY2FsbHkgeW91IGhh dmUgb25seSBvbmUgbG9naWNhbCBQcm94eSBhcyBhIGludGVyY29ubmVjdCBwb2ludCBmb3IgYSBn aXZlbiByZWFsbSBpbiByZWFsIGRlcGxveW1lbnRzIGFzIGEgY2VudHJhbCBwb2ludCBmb3IgcG9s aWN5IGVuZm9yY2VtZW50LiBIb3dldmVyLCBsZXQgc2VlIHdoZXRoZXIgYSBzZXJ2ZXIgaW5pdGlh dGVkIG1lc3NhZ2UgdXNpbmcgRGVzdGluYXRpb24tSG9zdCBhbmQgYXBwIGlkIDAgYmFzZWQgcm91 dGluZyB3b3Jrcy4NCg0KUzEgc2VuZHMgQVNSIHRvIEMzIChDMyBkaWFtZXRlciBpZGVudGl0eSBp biBEZXN0aW5hdGlvbi1Ib3N0IEFWUCkgYXBwIGlkIDAuIEluIHRoZSByZWFsbS1iYXNlZCByb3V0 aW5nIHRhYmxlIFIxIHdpbGwgY2VydGFpbmx5IGZpbmQgYSBtYXRjaCBmb3IgcmVhbG0gQSBhbmQg YXBwIGlkIDAsIHNheSBmb3IgaW5zdGFuY2UgdGhlIG1hdGNoIGlzIGZvciBQMS4gQVNSIGlzIHJv dXRlZCB0byBQMSwgd2hpY2ggZG9lc24ndCBoYXZlIEMzIGluIGl0cyBwZWVyIHRhYmxlIGFuZCB0 aGVuIGFuc3dlcnMgd2l0aCBESUFNRVRFUl9VTkFCTEVfVE9fREVMSVZFUi4gUjEgYXR0ZW1wdHMg dGhlbiB0byBkZWxpdmVyIHRoZSBtZXNzYWdlIHZpYSB0aGUgYWx0ZXJuYXRpdmUgZW50cnkgZm9y IFJlYWxtIEEsIGhlbmNlIFAyLiBQMiBub3cgZGVsaXZlciB0aGUgbWVzc2FnZSB0byBDMy4gU28s IGFwcC1pZCAwIHdvcmtzIGF0IHRoZSBlbmQgaWYgRGVzdGluYXRpb24tSG9zdCBiYXNlZCByb3V0 aW5nIGlzIHVzZWQgYW5kLCBhY3R1YWxseSwgaXMgdG8gYmUgdXNlZCBmb3IgY2VydGFpbiBzZXJ2 ZXIgaW5pdGlhdGVkIG1lc3NhZ2VzIGFzIGFsc28gZGVmaW5lZCBpbiBSRkMgMzU4OCBpbiBzZWN0 aW9uIDYuMS4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3Jn DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo= --===============1411793346== 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 --===============1411793346==-- From dime-bounces@ietf.org Mon Jul 24 07:50:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yxZ-0003X1-PT; Mon, 24 Jul 2006 07:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yxZ-0003Wp-2b for dime@ietf.org; Mon, 24 Jul 2006 07:50:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4yxY-0001lW-Vl for dime@ietf.org; Mon, 24 Jul 2006 07:50:53 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G4yxW-0006ST-DI for dime@ietf.org; Mon, 24 Jul 2006 07:50:52 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 7BE1F20678 for ; Mon, 24 Jul 2006 17:17:40 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 66CD020676 for ; Mon, 24 Jul 2006 17:17:40 +0530 (IST) Received: from blr-m2-msg.wipro.com ([10.116.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:20:40 +0530 Received: from [10.116.3.25] ([10.116.3.25]) by blr-m2-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:20:40 +0530 Subject: Re: [Dime] FW: [AAA-WG]: Realm expiration timer From: venkatesh devalapura nagabhushana To: rajithr@huawei.com In-Reply-To: <002c01c6af0a$22bfb280$a905120a@china.huawei.com> References: <002c01c6af0a$22bfb280$a905120a@china.huawei.com> Content-Type: text/plain Date: Mon, 24 Jul 2006 17:22:07 +0530 Message-Id: <1153741928.3273.24.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2006 11:50:40.0278 (UTC) FILETIME=[62C45360:01C6AF17] X-Spam-Score: -2.3 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Rajit, See my observations below: > > > > Hi, > As per RFC 3588 section 5.2 > > "A dynamically discovered peer causes an entry in the Peer Table (see > Section 2.6) to be created. Note that entries created via DNS MUST > expire (or be refreshed) within the DNS TTL. If a peer is discovered > outside of the local realm, a routing table entry (see Section 2.7) > for the peer's realm is created. The routing table entry's expiration > MUST match the peer's expiration value." > So we will make an entry into the peer table and realm table (if > required) when ever a new peer is discovered, connected and CER, CEA > are exchanged. > > As per our understanding, if the peer expiration timeout happens and > if the peer's state is closed we will try to re-connect to the peer. > If the peer's state is Open we are doing nothing. Is this correct? > > What do we need to do when the the realm expiration timeout happens? [Venkatesh]: Section 2.6 mentions about "StatusT" field which maintains the state of peer table entry and also make reference to values list in section 5.6. However it is not clear which value. My interpretation is it might be referring to either Timeout or Error mentioned in 5.6 (or both). But, section 2.7 (Realm based routing table) has no such reference. I think, 5.6 need to specify explicitly what need to be done. Regards, Venkatesh > > > -- > Yours > Naveen. > > > _______________________________________________ > 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 Jul 24 13:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54c7-0006iB-SN; Mon, 24 Jul 2006 13:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54c6-0006i6-Dj for dime@ietf.org; Mon, 24 Jul 2006 13:53:06 -0400 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 1G54c5-0000Sg-Qw for dime@ietf.org; Mon, 24 Jul 2006 13:53:06 -0400 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 k6OHqQiw092185; Mon, 24 Jul 2006 13:52:27 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <44C508DB.3090309@tari.toshiba.com> Date: Mon, 24 Jul 2006 13:52:27 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Tony Zhang Subject: Re: [Dime] Summary of 3588bis Issues Status References: <5371BE300539E6439919CF97203DDEC2077133C0@OIVMEXO01.omnitel.it> <007901c6aee6$55006c40$6291460a@china.huawei.com> In-Reply-To: <007901c6aee6$55006c40$6291460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id k6OHqQiw092185 X-Spam-Score: -2.4 (--) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: dime@ietf.org, "STURA, Marco, VF-IT" 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 guess there is still some contention regarding this issue so I suggest=20 we defer it to the chairs for some guidance. best regards, victor > Hi Marco: > > I also agree the generic problem of "How can a proxy stay >on the p= ath during a session", but i think this problem is address the stateful p= roxy agent,acutal maybe still have stateless proxy agent.so the routing p= roblem still in here. > I still think the routing is common part,independent on start ,end = ,interim session message. > > Regards > Tony > ----- Original Message -----=20 > From: "STURA, Marco, VF-IT" > To: "Tony Zhang" ; "Tolga Asveren" ; "Victor Fajardo" > Cc: > Sent: Friday, July 21, 2006 3:18 PM > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > Hi Tony, > > Server initiated requests can only be sent in the context of existing s= essions and routing must be done on the basis of Destination-Host to ensu= re that the request hits the correct client, so app id is not enough. > > The routing problem you are discussing has to do with how a proxy can s= tay on the path during a session so that a server can send a request, say= ASR or RAR, to Destination-Host via P1 to C1. As also suggested by Tolga > > =20 >> I think it can be deducted to the generic problem of "How can a proxy = stay >on the path during a session", so I believe this is the question to= answer >(which we already discussed to some extent in the context of str= ict-routing >draft review) >> =20 > > So I think your issue can be discussed in that context, app id 0 for co= mmon messages I think is fine. > > Regards > Marco > > -----Original Message----- > From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 > Sent: venerd=EC 21 luglio 2006 5.43 > To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo > Cc: dime@ietf.org > Subject: Re: [Dime] Summary of 3588bis Issues Status > > Hi Macro: > > [MSt] I think you assume P1 and P2 advertise supports for App x/y and A= pp z respectively but I would rather consider this configuration an acade= mic use case since typically you have only one logical Proxy as a interco= nnect point for a given realm in real deployments as a central point for = policy enforcement. However, let see whether a server initiated message u= sing Destination-Host and app id 0 based routing works. > > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app i= d 0. In the realm-based routing table R1 will certainly find a match for = realm A and app id 0, say for instance the match is for P1. ASR is routed= to P1, which doesn't have C3 in its peer table and then answers with DIA= METER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message via the = alternative entry for Realm A, hence P2. P2 now deliver the message to C3= . So, app-id 0 works at the end if Destination-Host based routing is used= and, actually, is to be used for certain server initiated messages as al= so defined in RFC 3588 in section 6.1.=20 > > [Tony]Because the Application Id 0,not advertisement in CER/CEA,so it m= eans each realm will use the peet table select next hop,almost peer table= have many peer can select,also include peer of receive the request. so i= t can happen loop routing.(maybe can add one process avoid this,when rout= ing should input peer name of receive the request.).the other problem,aft= er retry many peer ,then we find correct route,it consume long time,maybe= the client already timer expire.also application id use for effectively = routing,but for above the case ,it is not like this. > > sorry about i discuss this again,after 2004's dicuss,it is likely many = people confusion.if this time have same conlusion maybe still have same p= roblem. > > Thanks! > Tony > > ----- Original Message -----=20 > From: "STURA, Marco, VF-IT" > To: "Tolga Asveren" ; "Victor Fajardo" > Cc: > Sent: Wednesday, July 19, 2006 5:11 PM > Subject: RE: [Dime] Summary of 3588bis Issues Status > > > See in line. > > Regards > Marco > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com]=20 > Sent: marted=EC 18 luglio 2006 18.52 > To: STURA, Marco, VF-IT; Victor Fajardo > Cc: dime@ietf.org > Subject: RE: [Dime] Summary of 3588bis Issues Status > > [.. snip ..] > =20 >> I agree with your example above regarding destination-host. It is >> required in the case of ASR (and perhaps some other message) though I >> guess I was stating a case which is a little bit different than your >> example above. I was thinking of the following case: >> >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >> >> in this case relay2 will not be able to route using dest-host. This is >> where dest-realm and app id becomes important. In this case app id of = 0 >> might not work as well ... or maybe I'm wrong. >> >> [MSt] In this case R1 would advertise it self as a relay (i.e. >> 0xffffffff) it won't advertise app id x or y or z. So, any app id >> would be routed to R1 by R2. >> =20 > [TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=3DX | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * > +---+ +-+--+ * +----+----+C2 App=3DY | * > |S1 +--+ R1 | * +---------+ * > +---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=3DZ | * > * +---------+ * > * * > ***************************** > In this case, R1 wouldn't have enough knowledge to route the message > properly to the correct proxy just by looking to the App-Id in the mess= age > header, if App-Id is populated with "0". > > [MSt] I think you assume P1 and P2 advertise supports for App x/y and A= pp z respectively but I would rather consider this configuration an acade= mic use case since typically you have only one logical Proxy as a interco= nnect point for a given realm in real deployments as a central point for = policy enforcement. However, let see whether a server initiated message u= sing Destination-Host and app id 0 based routing works. > > S1 sends ASR to C3 (C3 diameter identity in Destination-Host AVP) app i= d 0. In the realm-based routing table R1 will certainly find a match for = realm A and app id 0, say for instance the match is for P1. ASR is routed= to P1, which doesn't have C3 in its peer table and then answers with DIA= METER_UNABLE_TO_DELIVER. R1 attempts then to deliver the message via the = alternative entry for Realm A, hence P2. P2 now deliver the message to C3= . So, app-id 0 works at the end if Destination-Host based routing is used= and, actually, is to be used for certain server initiated messages as al= so defined in RFC 3588 in section 6.1.=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 Jul 24 16:03:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56ei-0001KB-PW; Mon, 24 Jul 2006 16:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56eh-0001Jz-DT for dime@ietf.org; Mon, 24 Jul 2006 16:03:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56eg-0000uB-3I for dime@ietf.org; Mon, 24 Jul 2006 16:03:55 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2531154uge for ; Mon, 24 Jul 2006 13:03:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EGJQYMdzYqNm55Q6Kmui7ahSmmXyMNy8NfTQ5DLlqD7RZSGGOuyFaaGTeSJX2tAP4DrPm8HSR3T73uQcUx2gDIfBCHhAf41rVZN4RWDHiBvsydGyFQTPjhd2PCTnrswhcdr0xsyfZeLpi1g0o47n1XpP/kfZUCt1Nt971CqmB2o= Received: by 10.78.160.2 with SMTP id i2mr1942227hue; Mon, 24 Jul 2006 13:03:53 -0700 (PDT) Received: by 10.78.154.20 with HTTP; Mon, 24 Jul 2006 13:03:53 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2006 22:03:53 +0200 From: julien To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Dime] inter-domain: TLS, IPsec ? 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 Hello, I am a student currently working on Diameter and I have some points that are not cleared at all for me. That is why I send you this mail. In fact, I have read Diameter RFC and I do not understand well the inter-domain security considerations. I have made google search on this topic but do not find any clear answers relative to this point. In fact, TLS is recommended for inter-domain relationship: "Note that IPsec is considerably less flexible than TLS when it comes to configuring root CAs. Since use of Port identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs for each application individually; the same policy must be used for all applications." Is this explanation still available with IKEv2? Does it mean that we use CA with IPsec ? If I make the hypothesis that inter-domain actors have trust relationships established together (and for instance pre-shared key), will IPsec be OK for inter-domain security ? Do you think it is a quite true hypothesis ? If I use IPsec between a NAS and a local AAA server, and then TLS between this local AAA server and a remote AAA server, there will be at the same time IPsec and TLS running on the local AAA server. I ask you for this point because I read this paragraph in RFC 3588: "It is recommended that a Diameter peer implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections. Inconsistent use of security mechanisms can result in redundant security mechanisms being used (e.g., TLS over IPsec) or worse, potential security vulnerabilities. When IPsec is used with Diameter, a typical security policy for outbound traffic is "Initiate IPsec, from me to any, destination port Diameter"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port Diameter". " May be I have not enough background in networking to understand the motivation of TLS instead of IPsec in Diameter. That is why I send you this mail in order to understand the use of IPsec and TLS with Diameter. I would be grateful if you could tell me some information on why and when TLS and/or IPsec is better for Diameter. Thanks a lot in advance for your help, Best regards, -- Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 25 10:18:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Nk3-0001tw-Pn; Tue, 25 Jul 2006 10:18:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Nk3-0001tr-Du for dime@ietf.org; Tue, 25 Jul 2006 10:18:35 -0400 Received: from ionians.ncr.disa.mil ([164.117.82.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Nk1-0004bW-50 for dime@ietf.org; Tue, 25 Jul 2006 10:18:35 -0400 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by ionians.ncr.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 10:18:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] diameter redirect (UNCLASSIFIED) Date: Tue, 25 Jul 2006 10:18:30 -0400 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A972AB@vanualevu.disanet.disa-u.mil> in-reply-to: <75D349FBF7C131408F5061B7168072C303329DC6@INOAVREX06.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] diameter redirect (UNCLASSIFIED) Thread-Index: AcarGAvpUemHtRzTRXi8V2s6kKZujwE1uEvg From: "Nguyen, An P CIV NCS NC2" To: "Paulo Rolo" , X-OriginalArrivalTime: 25 Jul 2006 14:18:30.0860 (UTC) FILETIME=[347578C0:01C6AFF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Classification: UNCLASSIFIED=20 Caveats: NONE Paulo, I am interested in discussions of the development of the IMS Cx and Dx = Interfaces, which are based upon DIAMETER protocol. I'd like to ask the = group that how authorized users (associated with ETS.x and WPS.x = namespaces) as in RFC 4412 can be taken into account as far as = registration & deregistration are concerned. Should they be some AVP = values defined for these namespaces? Regards, An -----Original Message----- From: Paulo Rolo [mailto:paulo-j-rolo@ptinovacao.pt]=20 Sent: Wednesday, July 19, 2006 5:31 AM To: dime@ietf.org Subject: [Dime] diameter redirect Hello, We are currently developing a set of Diameter interfaces and some doubts = have arise, concerning SLF usage. On ETSI TS 123 228 (IP Multimedia Subsystem (IMS)) at section 5.8.1 = (User identity to HSS resolution) it is suggested that a Public User = Identity should be selected and used as input to SLF_QUERY, in order to = resolve to the correct HSS name.=20 Also at section 6.1.2 (S-CSCF registration/deregistration notification) = of TS 129 228 (IP Multimedia (IM) Subsystem Cx and Dx Interfaces), it is = suggested that if Routing Information is not available for SAR (S-CSCF = registration/deregistration), it should be routed to next diameter node, = for example SLF. =20 The issue is that on TS 129 229 (Cx and Dx interfaces based on the = Diameter protocol) at section 6.1.3 (Server-Assignment-Request (SAR) = Command) the Public-Identity is presented as an optional attribute. If = it is not present how should be SLF_QUERY performed? All the other = messages (UAR, LIR, MAR) have Public-Identity as mandatory. Thanks in advance, Paulo Rolo Network and Protocols Unit Intelligent Networks Department Portugal Telecom Inova=E7=E3o, S.A =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 26 06:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gy0-0001UK-Nl; Wed, 26 Jul 2006 06:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gxz-0001UF-Gw for dime@ietf.org; Wed, 26 Jul 2006 06:50:15 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5gxx-0002DB-50 for dime@ietf.org; Wed, 26 Jul 2006 06:50:15 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J30005VUBIEGZ@szxga01-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 18:51:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J30007CFBIDEV@szxga01-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 18:51:50 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J30002BABXGO3@szxml04-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 19:00:53 +0800 (CST) Date: Wed, 26 Jul 2006 16:19:20 +0530 From: Rajith R To: dime@ietf.org Message-id: <000901c6b0a1$27006b80$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acawg3BsxXlMtsEEQ0Gj93BxJw4l/wAHaQeQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: naveensharma@huawei.com Subject: [Dime] FW: [AAA-WG]: Fwd: Failover processing 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: , Content-Type: multipart/mixed; boundary="===============1211905305==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1211905305== Content-type: multipart/alternative; boundary="Boundary_(ID_/8N8F7rKX0CTbz+Q8Jbvjg)" This is a multi-part message in MIME format. --Boundary_(ID_/8N8F7rKX0CTbz+Q8Jbvjg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma Sent: Wednesday, July 26, 2006 12:46 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Fwd: Failover processing ---------- Forwarded message ---------- From: naveen sarma Date: Jul 26, 2006 12:35 PM Subject: Failover processing To: dime-request@ietf.org Hi, In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer? Suppose consider the following scenario: P0 is the originating host, to which P1 and P2 are peers (direct connection). P0 is supporting applications 1, 2, 3 P1 is supporting applications 1, 2 P2 is supporting applications 2, 3 After some time if P1 is down. Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1. As part of the failover, we will send the request message M1 to P2. In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1? Can anyone explain the responsibility when the diameter node is acting as an intermidate also? -- Yours Naveen. -- Yours Naveen. --Boundary_(ID_/8N8F7rKX0CTbz+Q8Jbvjg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma
Sent: Wednesday, July 26, 2006 12:46 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Fwd: Failover processing

 



---------- Forwarded message ----------
From: naveen sarma <naveen.sarma@gmail.com>
Date: Jul 26, 2006 12:35 PM
Subject: Failover processing
To: dime-request@ietf.org

Hi,

In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer?

Suppose consider the following scenario:

P0 is the originating host, to which P1 and P2 are peers (direct connection).

P0 is supporting applications 1, 2, 3
P1 is supporting applications 1, 2
P2 is supporting applications 2, 3

After some time if P1 is down.  Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1.  As part of the failover, we will send the request message M1 to P2.

In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1?

Can anyone explain the responsibility when the diameter node is acting as an intermidate also?

--
Yours

Naveen.



--
Yours
Naveen.

--Boundary_(ID_/8N8F7rKX0CTbz+Q8Jbvjg)-- --===============1211905305== 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 --===============1211905305==-- From dime-bounces@ietf.org Wed Jul 26 06:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gzN-000241-2q; Wed, 26 Jul 2006 06:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gzL-00023u-Ft for dime@ietf.org; Wed, 26 Jul 2006 06:51:39 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5gzJ-0002Pm-SJ for dime@ietf.org; Wed, 26 Jul 2006 06:51:39 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3000546C95M9@szxga02-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 19:07:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J30007B1C951Q@szxga02-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 19:07:53 +0800 (CST) Received: from huawei1515 ([10.18.5.169]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J30002G4BZYO3@szxml04-in.huawei.com> for dime@ietf.org; Wed, 26 Jul 2006 19:02:23 +0800 (CST) Date: Wed, 26 Jul 2006 16:20:50 +0530 From: Rajith R To: dime@ietf.org Message-id: <000e01c6b0a1$5c5d7610$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acawg3BsxXlMtsEEQ0Gj93BxJw4l/wAHdx2A X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: naveen.sarma@gmail.com Subject: [Dime] FW: [AAA-WG]: Fwd: Failover processing 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: , Content-Type: multipart/mixed; boundary="===============0712389680==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0712389680== Content-type: multipart/alternative; boundary="Boundary_(ID_R93IGVN3UzPThMuUComMhg)" This is a multi-part message in MIME format. --Boundary_(ID_R93IGVN3UzPThMuUComMhg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Pls ignore the previous post. **************************************************************************** ******** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma Sent: Wednesday, July 26, 2006 12:46 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Fwd: Failover processing ---------- Forwarded message ---------- From: naveen sarma Date: Jul 26, 2006 12:35 PM Subject: Failover processing To: dime-request@ietf.org Hi, In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer? Suppose consider the following scenario: P0 is the originating host, to which P1 and P2 are peers (direct connection). P0 is supporting applications 1, 2, 3 P1 is supporting applications 1, 2 P2 is supporting applications 2, 3 After some time if P1 is down. Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1. As part of the failover, we will send the request message M1 to P2. In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1? Can anyone explain the responsibility when the diameter node is acting as an intermidate also? -- Yours Naveen. -- Yours Naveen. --Boundary_(ID_R93IGVN3UzPThMuUComMhg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Pls ignore the previous post.

 

 

************************************************************************************

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of naveen sarma
Sent: Wednesday, July 26, 2006 12:46 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Fwd: Failover processing

 



---------- Forwarded message ----------
From: naveen sarma <naveen.sarma@gmail.com>
Date: Jul 26, 2006 12:35 PM
Subject: Failover processing
To: dime-request@ietf.org

Hi,

In the case of failover processing, do we need to change the destination host before forwarding to the new alternate peer?

Suppose consider the following scenario:

P0 is the originating host, to which P1 and P2 are peers (direct connection).

P0 is supporting applications 1, 2, 3
P1 is supporting applications 1, 2
P2 is supporting applications 2, 3

After some time if P1 is down.  Cosider that in the pending message queue of P1, there is a message M1 with application id 2 and the destination host as P1.  As part of the failover, we will send the request message M1 to P2.

In this case do we need to change the destination host inside the request message to P2, which was actually having the destination host as P1?

Can anyone explain the responsibility when the diameter node is acting as an intermidate also?

--
Yours

Naveen.



--
Yours
Naveen.

--Boundary_(ID_R93IGVN3UzPThMuUComMhg)-- --===============0712389680== 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 --===============0712389680==-- From dime-bounces@ietf.org Wed Jul 26 19:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5smM-0002qN-TB; Wed, 26 Jul 2006 19:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5smM-0002qE-0G; Wed, 26 Jul 2006 19:27:02 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5smK-0005Rh-Gn; Wed, 26 Jul 2006 19:27:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QNQwpT010360; Thu, 27 Jul 2006 02:26:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:26:58 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:26:58 +0300 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] Summary of 3588bis Issues Status Date: Thu, 27 Jul 2006 02:26:57 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7A= From: To: , , X-OriginalArrivalTime: 26 Jul 2006 23:26:58.0342 (UTC) FILETIME=[FD427C60:01C6B10A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 all, Basically, Pasi is correct here. The specs say to use app id of zero. The=20 consensus when standardizing Diameter Base and RFC 4005, 4072, etc. is that these messages use app id of 0. I don't think that we should re-open this issue, as it was discussed and decided long ago. John =20 >-----Original Message----- >From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 >Sent: 19 July, 2006 05:39 >To: vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >Victor Fajardo wrote: >> I'm still not sure why we 'MUST' use app id of 0 ?=20 > >In the case of RFC 4005 and 4072: because the spec says so? > >RFC 4005, Section 1.3: "All other messages are defined by=20 >[BASE] and use the Base application id value." > >RFC 4072, Section 3, last paragraph: "the others=20 >[RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." > >This should not lead to interoperability problems unless the=20 >implementors can't read the specs. And in that case, producing=20 >more specs is unlikely to be of help. > > > >> Unless I have the wrong take on this issue, there is a=20 >consensus that=20 >> we should just use the app id of the application for simplicity and=20 >> correctness. > >The last time this was discussed, there was consensus that=20 >using 0 is the right answer, and this lead to adding the=20 >above-quoted text to RFC >4005 and 4072. > >So unless the approach in 4005/4072 leads to significant=20 >problems, even when correctly implemented, I'd suggest not changing it. >Changing it could also lead to interoperability problems with=20 >those implementations that correctly implement 4005/4072. > >Best regards, >Pasi > >_______________________________________________ >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 Jul 26 19:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sqE-0006aa-Mh; Wed, 26 Jul 2006 19:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5sqE-0006aV-20 for dime@ietf.org; Wed, 26 Jul 2006 19:31:02 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5sqD-0005eG-AQ for dime@ietf.org; Wed, 26 Jul 2006 19:31:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6QMUsWd029836; Thu, 27 Jul 2006 01:30:56 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:29:59 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 02:29:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 27 Jul 2006 02:29:58 +0300 Message-ID: In-Reply-To: <007901c6aee6$55006c40$6291460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acau5rDA3FhPe+yRRLKfFhtii8PeQQCJGb0g From: To: , , , X-OriginalArrivalTime: 26 Jul 2006 23:29:59.0294 (UTC) FILETIME=[691D91E0:01C6B10B] X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Tony, During the initial work on Diameter, it was hoped that proxies would be a rare occurance. We assumed all proxies will be stateless. If someone needs stateful proxies, I'd like to understand what the = problem stateful proxies are trying to solve is, and why the current solution is insufficient. Wit respect to the App ID =3D 0 issue, we assumed that proxies are stateless. John >-----Original Message----- >From: ext Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 >Sent: 24 July, 2006 02:00 >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo >Cc: dime@ietf.org >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi Marco: > > I also agree the generic problem of "How can a proxy stay=20 >>on the path during a session", but i think this problem is=20 >address the stateful proxy agent,acutal maybe still have=20 >stateless proxy agent.so the routing problem still in here. > I still think the routing is common part,independent on=20 >start ,end ,interim session message. > >Regards >Tony >----- Original Message ----- >From: "STURA, Marco, VF-IT" >To: "Tony Zhang" ; "Tolga Asveren"=20 >; "Victor Fajardo" >Cc: >Sent: Friday, July 21, 2006 3:18 PM >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >Hi Tony, > >Server initiated requests can only be sent in the context of=20 >existing sessions and routing must be done on the basis of=20 >Destination-Host to ensure that the request hits the correct=20 >client, so app id is not enough. > >The routing problem you are discussing has to do with how a=20 >proxy can stay on the path during a session so that a server=20 >can send a request, say ASR or RAR, to Destination-Host via P1=20 >to C1. As also suggested by Tolga > >>I think it can be deducted to the generic problem of "How can=20 >a proxy stay >on the path during a session", so I believe this=20 >is the question to answer >(which we already discussed to some=20 >extent in the context of strict-routing >draft review) > >So I think your issue can be discussed in that context, app id=20 >0 for common messages I think is fine. > >Regards >Marco > >-----Original Message----- >From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 >Sent: venerd=EC 21 luglio 2006 5.43 >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo >Cc: dime@ietf.org >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi Macro: > >[MSt] I think you assume P1 and P2 advertise supports for App=20 >x/y and App z respectively but I would rather consider this=20 >configuration an academic use case since typically you have=20 >only one logical Proxy as a interconnect point for a given=20 >realm in real deployments as a central point for policy=20 >enforcement. However, let see whether a server initiated=20 >message using Destination-Host and app id 0 based routing works. > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20 >AVP) app id 0. In the realm-based routing table R1 will=20 >certainly find a match for realm A and app id 0, say for=20 >instance the match is for P1. ASR is routed to P1, which=20 >doesn't have C3 in its peer table and then answers with=20 >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20 >message via the alternative entry for Realm A, hence P2. P2=20 >now deliver the message to C3. So, app-id 0 works at the end=20 >if Destination-Host based routing is used and, actually, is to=20 >be used for certain server initiated messages as also defined=20 >in RFC 3588 in section 6.1.=20 > >[Tony]Because the Application Id 0,not advertisement in=20 >CER/CEA,so it means each realm will use the peet table select=20 >next hop,almost peer table have many peer can select,also=20 >include peer of receive the request. so it can happen loop=20 >routing.(maybe can add one process avoid this,when routing=20 >should input peer name of receive the request.).the other=20 >problem,after retry many peer ,then we find correct route,it=20 >consume long time,maybe the client already timer expire.also=20 >application id use for effectively routing,but for above the=20 >case ,it is not like this. > >sorry about i discuss this again,after 2004's dicuss,it is=20 >likely many people confusion.if this time have same conlusion=20 >maybe still have same problem. > >Thanks! >Tony > >----- Original Message -----=20 >From: "STURA, Marco, VF-IT" >To: "Tolga Asveren" ; "Victor Fajardo"=20 > >Cc: >Sent: Wednesday, July 19, 2006 5:11 PM >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >See in line. > >Regards >Marco > >-----Original Message----- >From: Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: marted=EC 18 luglio 2006 18.52 >To: STURA, Marco, VF-IT; Victor Fajardo >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >[.. snip ..] >> I agree with your example above regarding destination-host. It is >> required in the case of ASR (and perhaps some other message) though I >> guess I was stating a case which is a little bit different than your >> example above. I was thinking of the following case: >> >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >> >> in this case relay2 will not be able to route using=20 >dest-host. This is >> where dest-realm and app id becomes important. In this case=20 >app id of 0 >> might not work as well ... or maybe I'm wrong. >> >> [MSt] In this case R1 would advertise it self as a relay (i.e. >> 0xffffffff) it won't advertise app id x or y or z. So, any app id >> would be routed to R1 by R2. >[TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=3DX | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * >+---+ +-+--+ * +----+----+C2 App=3DY | * >|S1 +--+ R1 | * +---------+ * >+---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=3DZ | * > * +---------+ * > * * > ***************************** >In this case, R1 wouldn't have enough knowledge to route the message >properly to the correct proxy just by looking to the App-Id in=20 >the message >header, if App-Id is populated with "0". > >[MSt] I think you assume P1 and P2 advertise supports for App=20 >x/y and App z respectively but I would rather consider this=20 >configuration an academic use case since typically you have=20 >only one logical Proxy as a interconnect point for a given=20 >realm in real deployments as a central point for policy=20 >enforcement. However, let see whether a server initiated=20 >message using Destination-Host and app id 0 based routing works. > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20 >AVP) app id 0. In the realm-based routing table R1 will=20 >certainly find a match for realm A and app id 0, say for=20 >instance the match is for P1. ASR is routed to P1, which=20 >doesn't have C3 in its peer table and then answers with=20 >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20 >message via the alternative entry for Realm A, hence P2. P2=20 >now deliver the message to C3. So, app-id 0 works at the end=20 >if Destination-Host based routing is used and, actually, is to=20 >be used for certain server initiated messages as also defined=20 >in RFC 3588 in section 6.1.=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 Jul 26 21:29:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uhG-00022N-T3; Wed, 26 Jul 2006 21:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uhF-00022I-Gl for dime@ietf.org; Wed, 26 Jul 2006 21:29:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uhD-0002RM-6J for dime@ietf.org; Wed, 26 Jul 2006 21:29:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2006 18:29:50 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R1ToSa027815; Wed, 26 Jul 2006 18:29:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6R1ToJi024853; Wed, 26 Jul 2006 18:29:50 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 18:29:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 26 Jul 2006 18:29:48 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3E56@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acau5rDA3FhPe+yRRLKfFhtii8PeQQCJGb0gAAPF/bA= From: "Glen Zorn \(gwz\)" To: , , , , X-OriginalArrivalTime: 27 Jul 2006 01:29:50.0002 (UTC) FILETIME=[271C8920:01C6B11C] DKIM-Signature: a=rsa-sha1; q=dns; l=1114; t=1153963790; x=1154827790; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20Summary=20of=203588bis=20Issues=20Status; X=v=3Dcisco.com=3B=20h=3D4vPGO8qGutP3SBEn1b/FPn+F6U8=3D; b=PR2swLCSB4tPoMFTUAxAWtm2ZgaYxkru+8NbuRfIYvkdqwec5v+s9vgm3JxfE645ftkTUJbg cRz8KBUY3N4nhCOsyqav/gKLMoh5bHEb9KUnI+bF4K4y+2H9tKSVtyLh; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 john.loughney@nokia.com supposedly = scribbled: > Tony, >=20 > During the initial work on Diameter, it was hoped that proxies would > be a rare occurance. =20 Given that Diameter came as a direct result of the work of the roamops = WG to try & find a way to make Internet roaming secure & that Internet = roaming is based on proxies, I find this statement fairly amazing. = Maybe we were working on different Diameters? > We assumed all proxies will be stateless.=20 >From RFC 3588: 6.2.1. Processing received Answers A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests. The corresponding message should be removed from the list of pending requests. It SHOULD ignore answers received that do not match a known Hop-by-Hop Identifier. A "list of pending requests" qualifies as "state" in my mind, anyway. ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 26 22:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vCi-0006dP-E0; Wed, 26 Jul 2006 22:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vCg-0006dG-Mj; Wed, 26 Jul 2006 22:02:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uX5-0008CS-45; Wed, 26 Jul 2006 21:19:23 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5uI3-0004pJ-8E; Wed, 26 Jul 2006 21:03:53 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2006 18:03:51 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="1842193579:sNHT27436492" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R13neg022251; Wed, 26 Jul 2006 18:03:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6R13n79019145; Wed, 26 Jul 2006 18:03:49 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Jul 2006 18:03:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Wed, 26 Jul 2006 18:03:47 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3E3E@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wA== From: "Glen Zorn \(gwz\)" To: , , , X-OriginalArrivalTime: 27 Jul 2006 01:03:49.0679 (UTC) FILETIME=[851623F0:01C6B118] DKIM-Signature: a=rsa-sha1; q=dns; l=2945; t=1153962230; x=1154826230; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20Summary=20of=203588bis=20Issues=20Status; X=v=3Dcisco.com=3B=20h=3D4vPGO8qGutP3SBEn1b/FPn+F6U8=3D; b=v9xXb3n2f5OvQnjDGNR+Yofaqm2jB9AqLaRiZtMGXKwOiwyeAT5PIjhoqeitgL27OBdMiPA2 gmTIFhielnlBvgIWn6ACORBarOLsEckC3pQ3LO5SxUhtGdkWyF2SM9yp; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 john.loughney@nokia.com supposedly = scribbled: > Hi all, >=20 > Basically, Pasi is correct here. The specs say to use app id of > zero.=20 > The > consensus when standardizing Diameter Base and RFC 4005, 4072, etc. > is that these messages use app id of 0.=20 >=20 > I don't think that we should re-open this issue, as it was discussed > and decided long ago.=20 I think that this was a fairly serious error, at least WRT the = session-oriented (including accounting) messages. If it's not an error, = tell me this: an application generates an STR & sends it to the correct = peer with app ID 0. The Diameter Base terminates the session. So what = happens to the state being held by the _application_ peer? Unless the = Base protocol module keeps a map of session IDs to applications, it = doesn't seem that it would know which application to notify of the = session termination. >=20 > John >=20 >=20 >> -----Original Message----- >> From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >> Sent: 19 July, 2006 05:39 >> To: vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >>=20 >> Victor Fajardo wrote: >>> I'm still not sure why we 'MUST' use app id of 0 ? >>=20 >> In the case of RFC 4005 and 4072: because the spec says so? >>=20 >> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and >> use the Base application id value." >>=20 >> RFC 4072, Section 3, last paragraph: "the others >> [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." >>=20 >> This should not lead to interoperability problems unless the >> implementors can't read the specs. And in that case, producing more >> specs is unlikely to be of help. >>=20 >> >>=20 >>> Unless I have the wrong take on this issue, there is a consensus >>> that we should just use the app id of the application for >>> simplicity and correctness. >>=20 >> The last time this was discussed, there was consensus that using 0 is >> the right answer, and this lead to adding the above-quoted text to >> RFC 4005 and 4072.=20 >>=20 >> So unless the approach in 4005/4072 leads to significant problems, >> even when correctly implemented, I'd suggest not changing it. >> Changing it could also lead to interoperability problems with those >> implementations that correctly implement 4005/4072. >>=20 >> Best regards, >> Pasi >>=20 >> _______________________________________________ >> 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 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 27 03:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60SP-0007nc-UD; Thu, 27 Jul 2006 03:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60SO-0007nX-Sl for dime@ietf.org; Thu, 27 Jul 2006 03:38:56 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G60SN-00082b-Dp for dime@ietf.org; Thu, 27 Jul 2006 03:38:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6R7cmZq016788; Thu, 27 Jul 2006 10:38:52 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 10:38:48 +0300 Received: from 4FIL09356 ([10.162.27.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Jul 2006 10:38:48 +0300 From: "Pasi Eronen" To: "'ext Glen Zorn \(gwz\)'" Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 27 Jul 2006 10:38:45 +0300 Message-ID: <000001c6b14f$b144d9d0$03ffa8c0@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAANTp6g In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3E3E@xmb-sjc-215.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 27 Jul 2006 07:38:48.0283 (UTC) FILETIME=[B28E22B0:01C6B14F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Glen Zorn wrote: > > I don't think that we should re-open this issue, as it was discussed > > and decided long ago. > > I think that this was a fairly serious error, at least WRT the > session-oriented (including accounting) messages. If it's not an > error, tell me this: an application generates an STR & sends it to > the correct peer with app ID 0. The Diameter Base terminates the > session. So what happens to the state being held by the > _application_ peer? Unless the Base protocol module keeps a map of > session IDs to applications, it doesn't seem that it would know > which application to notify of the session termination. Once again: this depends on what is meant by an "application". Saying that "an application generates an STR & sends it" or "which application to notify" makes any sense only if by application you mean some kind of module or component in a Diameter server (or something similar) But at least my reading of RFC3588 (which some others agreed when this issue was discussed the last time) was that an "application" in Diameter means a set of specifications (documents). Thus, while you can send a message defined _in_ an application, an application is not a thing that sends or receives messages. However, by now it's quite obvious that most implementors reading the spec for the first time immediately (and quite naturally) assume the "software component" interpretation... and that's why we keep having this discussion every two years (when even the document authors might have forgotten why they wrote that :-) In 3588bis we should clarify this, and probably introduce a new term(s) for the software components and their state (this would allow us to describe more easily that e.g. when a message referring to an existing session is processed, the session state lookup is done by Session-ID, not Application-ID+Session-ID). Best regards, Pasi _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 27 04:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60rC-0002Na-2B; Thu, 27 Jul 2006 04:04:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G60rA-0002NU-FI for dime@ietf.org; Thu, 27 Jul 2006 04:04:32 -0400 Received: from mailout-2.omnitel.it ([194.20.71.226] helo=fmis837.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G60r7-000534-Tr for dime@ietf.org; Thu, 27 Jul 2006 04:04:32 -0400 Received: from omini93.omnitel.it (omini93.omnitel.it [10.21.18.145]) by fmis837.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6R84RI7015257 for ; Thu, 27 Jul 2006 10:04:27 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by ominc75.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jul 2006 10:04:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 27 Jul 2006 10:04:21 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133C6@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAANTp6gAAF8FjA= From: "STURA, Marco, VF-IT" To: "Pasi Eronen" , "ext Glen Zorn \(gwz\)" X-OriginalArrivalTime: 27 Jul 2006 08:04:25.0544 (UTC) FILETIME=[46D58C80:01C6B153] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Pasi Eronen wrote: >In 3588bis we should clarify this, and probably introduce a new term(s) >for the software components and their state (this would allow us to >describe more easily that e.g. when a message referring to an existing >session is processed, the session state lookup is done by Session-ID, >not Application-ID+Session-ID). I think that would be a good thing to clarify, I agree. Regards Marco -----Original Message----- From: Pasi Eronen [mailto:pasi.eronen@nokia.com]=20 Sent: gioved=EC 27 luglio 2006 9.39 To: 'ext Glen Zorn (gwz)' Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Glen Zorn wrote: > > I don't think that we should re-open this issue, as it was discussed > > and decided long ago.=20 >=20 > I think that this was a fairly serious error, at least WRT the > session-oriented (including accounting) messages. If it's not an > error, tell me this: an application generates an STR & sends it to > the correct peer with app ID 0. The Diameter Base terminates the > session. So what happens to the state being held by the > _application_ peer? Unless the Base protocol module keeps a map of > session IDs to applications, it doesn't seem that it would know > which application to notify of the session termination. Once again: this depends on what is meant by an "application". =20 Saying that "an application generates an STR & sends it" or "which application to notify" makes any sense only if by application you mean some kind of module or component in a Diameter server (or something similar) But at least my reading of RFC3588 (which some others agreed when this issue was discussed the last time) was that an "application" in Diameter means a set of specifications (documents). Thus, while you can send a message defined _in_ an application, an application is not a thing that sends or receives messages. However, by now it's quite obvious that most implementors reading the spec for the first time immediately (and quite naturally) assume the "software component" interpretation... and that's why we keep having this discussion every two years (when even the document authors=20 might have forgotten why they wrote that :-) In 3588bis we should clarify this, and probably introduce a new term(s) for the software components and their state (this would allow us to describe more easily that e.g. when a message referring to an existing session is processed, the session state lookup is done by Session-ID, not Application-ID+Session-ID). Best regards, Pasi _______________________________________________ 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 Jul 27 08:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64e2-0005aX-DN; Thu, 27 Jul 2006 08:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64e1-0005aO-8i; Thu, 27 Jul 2006 08:07:13 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G64e0-0008Ac-Aq; Thu, 27 Jul 2006 08:07:13 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200DO19XTR4@szxga02-in.huawei.com>; Thu, 27 Jul 2006 20:13:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200CML9XTSQ@szxga02-in.huawei.com>; Thu, 27 Jul 2006 20:13:05 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3200CSP9OKY6@szxml04-in.huawei.com>; Thu, 27 Jul 2006 20:07:36 +0800 (CST) Date: Thu, 27 Jul 2006 19:55:58 +0800 From: Tony Zhang Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3E3E@xmb-sjc-215.amer.cisco.com> To: "'Glen Zorn (gwz)'" , john.loughney@nokia.com, dime-bounces@ietf.org, vfajardo@tari.toshiba.com, Marco.STURA@vodafone.com Message-id: <000101c6b173$9fe9c190$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAAWuTkg X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 ALL: I agree with Glen. Application id is also use for routing, we cannot requirement the stateless agent will keep the session ID. if Application Id use just for a set of documents, why accounting request not use 0(it define in RFC3588). Thanks! Regards Tony -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Thursday, July 27, 2006 9:04 AM To: john.loughney@nokia.com; dime-bounces@ietf.org; vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status john.loughney@nokia.com supposedly scribbled: > Hi all, > > Basically, Pasi is correct here. The specs say to use app id of > zero. > The > consensus when standardizing Diameter Base and RFC 4005, 4072, etc. > is that these messages use app id of 0. > > I don't think that we should re-open this issue, as it was discussed > and decided long ago. I think that this was a fairly serious error, at least WRT the session-oriented (including accounting) messages. If it's not an error, tell me this: an application generates an STR & sends it to the correct peer with app ID 0. The Diameter Base terminates the session. So what happens to the state being held by the _application_ peer? Unless the Base protocol module keeps a map of session IDs to applications, it doesn't seem that it would know which application to notify of the session termination. > > John > > >> -----Original Message----- >> From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] >> Sent: 19 July, 2006 05:39 >> To: vfajardo@tari.toshiba.com; Marco.STURA@vodafone.com >> Cc: dime@ietf.org >> Subject: RE: [Dime] Summary of 3588bis Issues Status >> >> Victor Fajardo wrote: >>> I'm still not sure why we 'MUST' use app id of 0 ? >> >> In the case of RFC 4005 and 4072: because the spec says so? >> >> RFC 4005, Section 1.3: "All other messages are defined by [BASE] and >> use the Base application id value." >> >> RFC 4072, Section 3, last paragraph: "the others >> [RAR,RAA,STR,STA,ASR,ASA] use 0 (Diameter Common Messages)." >> >> This should not lead to interoperability problems unless the >> implementors can't read the specs. And in that case, producing more >> specs is unlikely to be of help. >> >> >> >>> Unless I have the wrong take on this issue, there is a consensus >>> that we should just use the app id of the application for >>> simplicity and correctness. >> >> The last time this was discussed, there was consensus that using 0 is >> the right answer, and this lead to adding the above-quoted text to >> RFC 4005 and 4072. >> >> So unless the approach in 4005/4072 leads to significant problems, >> even when correctly implemented, I'd suggest not changing it. >> Changing it could also lead to interoperability problems with those >> implementations that correctly implement 4005/4072. >> >> Best regards, >> Pasi >> >> _______________________________________________ >> 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 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ 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 Jul 27 08:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64jS-0000F7-DY; Thu, 27 Jul 2006 08:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64jR-0000Es-Ho for dime@ietf.org; Thu, 27 Jul 2006 08:12:49 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G64jO-0000Me-FR for dime@ietf.org; Thu, 27 Jul 2006 08:12:49 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200DO79WBSD@szxga03-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:12:11 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200JV79WA4C@szxga03-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:12:10 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3200CF99YYY6@szxml04-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:13:49 +0800 (CST) Date: Thu, 27 Jul 2006 20:02:12 +0800 From: Tony Zhang Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: To: john.loughney@nokia.com, Marco.STURA@vodafone.com, asveren@ulticom.com, vfajardo@tari.toshiba.com Message-id: <000201c6b174$7eb0b370$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: Acau5rDA3FhPe+yRRLKfFhtii8PeQQCJGb0gABolASA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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 John: When I read proxy agent definition in RFC3588: Proxies that wish to limit resources MUST maintain session state. All proxies MUST maintain transaction state. Since enforcing policies requires an understanding of the service being provided, Proxies MUST only advertise the Diameter applications they support. Maybe almost the stateful proxy is more. If With respect to the App ID =3D 0 issue, we assumed that proxies are stateless. I think use app Id =3D 0,the routing for some environment is not = effective. Tolga already give one network environment. Thanks! Tony. -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: Thursday, July 27, 2006 7:30 AM To: zhangtao_hw@huawei.com; Marco.STURA@vodafone.com; = asveren@ulticom.com; vfajardo@tari.toshiba.com Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Tony, During the initial work on Diameter, it was hoped that proxies would be a rare occurance. We assumed all proxies will be stateless. If someone needs stateful proxies, I'd like to understand what the = problem stateful proxies are trying to solve is, and why the current solution is insufficient. Wit respect to the App ID =3D 0 issue, we assumed that proxies are stateless. John >-----Original Message----- >From: ext Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 >Sent: 24 July, 2006 02:00 >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo >Cc: dime@ietf.org >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi Marco: > > I also agree the generic problem of "How can a proxy stay=20 >>on the path during a session", but i think this problem is=20 >address the stateful proxy agent,acutal maybe still have=20 >stateless proxy agent.so the routing problem still in here. > I still think the routing is common part,independent on=20 >start ,end ,interim session message. > >Regards >Tony >----- Original Message ----- >From: "STURA, Marco, VF-IT" >To: "Tony Zhang" ; "Tolga Asveren"=20 >; "Victor Fajardo" >Cc: >Sent: Friday, July 21, 2006 3:18 PM >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >Hi Tony, > >Server initiated requests can only be sent in the context of=20 >existing sessions and routing must be done on the basis of=20 >Destination-Host to ensure that the request hits the correct=20 >client, so app id is not enough. > >The routing problem you are discussing has to do with how a=20 >proxy can stay on the path during a session so that a server=20 >can send a request, say ASR or RAR, to Destination-Host via P1=20 >to C1. As also suggested by Tolga > >>I think it can be deducted to the generic problem of "How can=20 >a proxy stay >on the path during a session", so I believe this=20 >is the question to answer >(which we already discussed to some=20 >extent in the context of strict-routing >draft review) > >So I think your issue can be discussed in that context, app id=20 >0 for common messages I think is fine. > >Regards >Marco > >-----Original Message----- >From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 >Sent: venerd=C3=AC 21 luglio 2006 5.43 >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo >Cc: dime@ietf.org >Subject: Re: [Dime] Summary of 3588bis Issues Status > >Hi Macro: > >[MSt] I think you assume P1 and P2 advertise supports for App=20 >x/y and App z respectively but I would rather consider this=20 >configuration an academic use case since typically you have=20 >only one logical Proxy as a interconnect point for a given=20 >realm in real deployments as a central point for policy=20 >enforcement. However, let see whether a server initiated=20 >message using Destination-Host and app id 0 based routing works. > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20 >AVP) app id 0. In the realm-based routing table R1 will=20 >certainly find a match for realm A and app id 0, say for=20 >instance the match is for P1. ASR is routed to P1, which=20 >doesn't have C3 in its peer table and then answers with=20 >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20 >message via the alternative entry for Realm A, hence P2. P2=20 >now deliver the message to C3. So, app-id 0 works at the end=20 >if Destination-Host based routing is used and, actually, is to=20 >be used for certain server initiated messages as also defined=20 >in RFC 3588 in section 6.1.=20 > >[Tony]Because the Application Id 0,not advertisement in=20 >CER/CEA,so it means each realm will use the peet table select=20 >next hop,almost peer table have many peer can select,also=20 >include peer of receive the request. so it can happen loop=20 >routing.(maybe can add one process avoid this,when routing=20 >should input peer name of receive the request.).the other=20 >problem,after retry many peer ,then we find correct route,it=20 >consume long time,maybe the client already timer expire.also=20 >application id use for effectively routing,but for above the=20 >case ,it is not like this. > >sorry about i discuss this again,after 2004's dicuss,it is=20 >likely many people confusion.if this time have same conlusion=20 >maybe still have same problem. > >Thanks! >Tony > >----- Original Message -----=20 >From: "STURA, Marco, VF-IT" >To: "Tolga Asveren" ; "Victor Fajardo"=20 > >Cc: >Sent: Wednesday, July 19, 2006 5:11 PM >Subject: RE: [Dime] Summary of 3588bis Issues Status > > >See in line. > >Regards >Marco > >-----Original Message----- >From: Tolga Asveren [mailto:asveren@ulticom.com]=20 >Sent: marted=C3=AC 18 luglio 2006 18.52 >To: STURA, Marco, VF-IT; Victor Fajardo >Cc: dime@ietf.org >Subject: RE: [Dime] Summary of 3588bis Issues Status > >[.. snip ..] >> I agree with your example above regarding destination-host. It is >> required in the case of ASR (and perhaps some other message) though I >> guess I was stating a case which is a little bit different than your >> example above. I was thinking of the following case: >> >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server >> >> in this case relay2 will not be able to route using=20 >dest-host. This is >> where dest-realm and app id becomes important. In this case=20 >app id of 0 >> might not work as well ... or maybe I'm wrong. >> >> [MSt] In this case R1 would advertise it self as a relay (i.e. >> 0xffffffff) it won't advertise app id x or y or z. So, any app id >> would be routed to R1 by R2. >[TOLGA] Let me try to further refine the scenario: > ***************************** > * Realm A * > * * > * +---------+ * > * +--+C1 App=3DX | * > * +----+ | +---------+ * > +----*-+ P1 +-+ +---------+ * >+---+ +-+--+ * +----+----+C2 App=3DY | * >|S1 +--+ R1 | * +---------+ * >+---+ +-+--+ * * > | * +----+ * > +----*-+ P2 +----+---------+ * > * +----+ |C3 App=3DZ | * > * +---------+ * > * * > ***************************** >In this case, R1 wouldn't have enough knowledge to route the message >properly to the correct proxy just by looking to the App-Id in=20 >the message >header, if App-Id is populated with "0". > >[MSt] I think you assume P1 and P2 advertise supports for App=20 >x/y and App z respectively but I would rather consider this=20 >configuration an academic use case since typically you have=20 >only one logical Proxy as a interconnect point for a given=20 >realm in real deployments as a central point for policy=20 >enforcement. However, let see whether a server initiated=20 >message using Destination-Host and app id 0 based routing works. > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20 >AVP) app id 0. In the realm-based routing table R1 will=20 >certainly find a match for realm A and app id 0, say for=20 >instance the match is for P1. ASR is routed to P1, which=20 >doesn't have C3 in its peer table and then answers with=20 >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20 >message via the alternative entry for Realm A, hence P2. P2=20 >now deliver the message to C3. So, app-id 0 works at the end=20 >if Destination-Host based routing is used and, actually, is to=20 >be used for certain server initiated messages as also defined=20 >in RFC 3588 in section 6.1.=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 Thu Jul 27 08:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64jU-0000H7-I1; Thu, 27 Jul 2006 08:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64jU-0000Gs-3C for dime@ietf.org; Thu, 27 Jul 2006 08:12:52 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G64jS-0000Me-5s for dime@ietf.org; Thu, 27 Jul 2006 08:12:52 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200DYLAD8SD@szxga03-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:22:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J3200JSYAD83Y@szxga03-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:22:20 +0800 (CST) Received: from z26452a ([10.70.145.98]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J3200CIPAFWY6@szxml04-in.huawei.com> for dime@ietf.org; Thu, 27 Jul 2006 20:23:59 +0800 (CST) Date: Thu, 27 Jul 2006 20:12:22 +0800 From: Tony Zhang Subject: RE: [Dime] Summary of 3588bis Issues Status In-reply-to: <000001c6b14f$b144d9d0$03ffa8c0@NOE.Nokia.com> To: 'Pasi Eronen' , "'ext Glen Zorn (gwz)'" Message-id: <000301c6b175$ea020a10$6291460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAANTp6gAAn2qLA= X-Spam-Score: 0.0 (/) 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 -----Original Message----- From: Pasi Eronen [mailto:pasi.eronen@nokia.com] Sent: Thursday, July 27, 2006 3:39 PM To: 'ext Glen Zorn (gwz)' Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Glen Zorn wrote: > > I don't think that we should re-open this issue, as it was discussed > > and decided long ago. > > I think that this was a fairly serious error, at least WRT the > session-oriented (including accounting) messages. If it's not an > error, tell me this: an application generates an STR & sends it to > the correct peer with app ID 0. The Diameter Base terminates the > session. So what happens to the state being held by the > _application_ peer? Unless the Base protocol module keeps a map of > session IDs to applications, it doesn't seem that it would know > which application to notify of the session termination. Once again: this depends on what is meant by an "application". Saying that "an application generates an STR & sends it" or "which application to notify" makes any sense only if by application you mean some kind of module or component in a Diameter server (or something similar) But at least my reading of RFC3588 (which some others agreed when this issue was discussed the last time) was that an "application" in Diameter means a set of specifications (documents). Thus, while you can send a message defined _in_ an application, an application is not a thing that sends or receives messages. However, by now it's quite obvious that most implementors reading the spec for the first time immediately (and quite naturally) assume the "software component" interpretation... and that's why we keep having this discussion every two years (when even the document authors might have forgotten why they wrote that :-) Tony: so why this time not follow easy understand way. In 3588bis we should clarify this, and probably introduce a new term(s) for the software components and their state (this would allow us to describe more easily that e.g. when a message referring to an existing session is processed, the session state lookup is done by Session-ID, not Application-ID+Session-ID). Tony:I donot think , not use app-id 0,it means should use Application-ID+Session-ID lookup session state Best regards, Pasi _______________________________________________ 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 Jul 27 12:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68LN-0005Xk-5q; Thu, 27 Jul 2006 12:04:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68LL-0005Xf-PJ for dime@ietf.org; Thu, 27 Jul 2006 12:04:11 -0400 Received: from mailout-1.omnitel.it ([194.20.77.121] helo=fmis437.omnitel.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68LK-0001Yh-9Z for dime@ietf.org; Thu, 27 Jul 2006 12:04:11 -0400 Received: from omini96.omnitel.it (omini96.omnitel.it [10.21.18.148]) by fmis437.omnitel.it (Switch-3.0.6/Switch-3.0.0) with ESMTP id k6RG48ps010734 for ; Thu, 27 Jul 2006 18:04:08 +0200 (MET DST) Received: from oivmexo01.omnitel.it ([10.31.32.12]) by oming29.omnitel.it with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Jul 2006 18:04:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Thu, 27 Jul 2006 18:03:43 +0200 Message-ID: <5371BE300539E6439919CF97203DDEC2077133CE@OIVMEXO01.omnitel.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAANTp6gAAn2qLAACCO4wA== From: "STURA, Marco, VF-IT" To: "Tony Zhang" , "Pasi Eronen" , "ext Glen Zorn \(gwz\)" X-OriginalArrivalTime: 27 Jul 2006 16:04:04.0211 (UTC) FILETIME=[4841A430:01C6B196] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 >In 3588bis we should clarify this, and probably introduce a new term(s) >for the software components and their state (this would allow us to >describe more easily that e.g. when a message referring to an existing >session is processed, the session state lookup is done by Session-ID, >not Application-ID+Session-ID). >Tony:I donot think , not use app-id 0,it means should use = Application->ID+Session-ID lookup session state All you do with these base common messages is informing of or inferring = session termination. A diameter session is identified solely by the = session-id, not by Application-Id+Session-id. I strongly agree with Pasi = here. Regards Marco -----Original Message----- From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20 Sent: gioved=EC 27 luglio 2006 14.12 To: 'Pasi Eronen'; 'ext Glen Zorn (gwz)' Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status -----Original Message----- From: Pasi Eronen [mailto:pasi.eronen@nokia.com]=20 Sent: Thursday, July 27, 2006 3:39 PM To: 'ext Glen Zorn (gwz)' Cc: dime@ietf.org Subject: RE: [Dime] Summary of 3588bis Issues Status Glen Zorn wrote: > > I don't think that we should re-open this issue, as it was discussed > > and decided long ago.=20 >=20 > I think that this was a fairly serious error, at least WRT the > session-oriented (including accounting) messages. If it's not an > error, tell me this: an application generates an STR & sends it to > the correct peer with app ID 0. The Diameter Base terminates the > session. So what happens to the state being held by the > _application_ peer? Unless the Base protocol module keeps a map of > session IDs to applications, it doesn't seem that it would know > which application to notify of the session termination. Once again: this depends on what is meant by an "application". =20 Saying that "an application generates an STR & sends it" or "which application to notify" makes any sense only if by application you mean some kind of module or component in a Diameter server (or something similar) But at least my reading of RFC3588 (which some others agreed when this issue was discussed the last time) was that an "application" in Diameter means a set of specifications (documents). Thus, while you can send a message defined _in_ an application, an application is not a thing that sends or receives messages. However, by now it's quite obvious that most implementors reading the spec for the first time immediately (and quite naturally) assume the "software component" interpretation... and that's why we keep having this discussion every two years (when even the document authors=20 might have forgotten why they wrote that :-) Tony: so why this time not follow easy understand way. In 3588bis we should clarify this, and probably introduce a new term(s) for the software components and their state (this would allow us to describe more easily that e.g. when a message referring to an existing session is processed, the session state lookup is done by Session-ID, not Application-ID+Session-ID). Tony:I donot think , not use app-id 0,it means should use = Application-ID+Session-ID lookup session state Best regards, Pasi _______________________________________________ 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 Jul 27 13:00:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G69Do-0007So-Kl; Thu, 27 Jul 2006 13:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G64LT-0001hC-9t for dime@ietf.org; Thu, 27 Jul 2006 07:48:03 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G64LR-0004iM-Su for dime@ietf.org; Thu, 27 Jul 2006 07:48:03 -0400 Received: by py-out-1112.google.com with SMTP id s49so222769pyc for ; Thu, 27 Jul 2006 04:48:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NJE2T1BkXaXTN7AgcxZxoU5A2UAETqtmd1AmMqyH0S5sMDxjL/mdCTB2UPCG83X5fBXGK3j9xzhXQibTvkC81WJdv1EGte1C4CsGkq7ueUWiqn1jMFrjzlNmXe4IiTNrTe2bZmXJJhUJpVOcFRtQcI/wCX7ld1ghvanwbon8eE0= Received: by 10.35.90.20 with SMTP id s20mr13030710pyl; Thu, 27 Jul 2006 04:48:01 -0700 (PDT) Received: by 10.35.82.12 with HTTP; Thu, 27 Jul 2006 04:48:01 -0700 (PDT) Message-ID: Date: Thu, 27 Jul 2006 17:18:01 +0530 From: "naveen sarma" To: "Monal Sengar" In-Reply-To: <5be720c40607240301s40646076i3c879042e9044768@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_136175_11030102.1154000881545" References: <5be720c40607240301s40646076i3c879042e9044768@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: fc231bf912a450f71747fa7a4e3e2f5a X-Mailman-Approved-At: Thu, 27 Jul 2006 13:00:27 -0400 Cc: aaa-wg@merit.edu, dime@ietf.org Subject: [Dime] Re: [AAA-WG]: Diameter - Failover Implementation 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 ------=_Part_136175_11030102.1154000881545 Content-Type: multipart/alternative; boundary="----=_Part_136176_28248860.1154000881545" ------=_Part_136176_28248860.1154000881545 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I strictly feel that the failover has to be done per message basis. For more reference just see the attachment. On 7/24/06, Monal Sengar wrote: > > Hi All, > > In case of implementing Failover in Diameter base protocol, do we need to > send the requests in pending message queue on per peer basis or do we need > to distribute the requests based on the application Id. > > In case, we implement the first option then we will have a mapping of > Primary peer to alternate peer.When primary peer is down , all the > requests in pending message queue will be routed to alternate peer.But in > this case , alternate peer must support all the applicaiton Ids which > primary peer is supporting. > > But in case of second option, we can retireve the pending message from the > pending message queue and based on the applicaiton Id , we can retireve the > proper alternate peer (from realm table and peer table) for this request > which will be supproting the application id present in the pending message > and route the request to the same.So for different pending requests we can > have different alternate peers.In such case there will not be any fixed > alternate peer but based on the application Id, we will find the proper > alternate peer from realm table and peer table. > > Which option seems to be better? > > Thanks in advance > Monal > -- Yours Naveen. ------=_Part_136176_28248860.1154000881545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
    I strictly feel that the failover has to be done per message basis.  For more reference just see the attachment.

On 7/24/06, Monal Sengar < monal.sengar@gmail.com> wrote:
Hi All,

In case of implementing Failover in Diameter base protocol, do we need to send the requests in pending message queue on per peer basis or do we need to distribute the requests based on the application Id.

In case, we implement the first option then we will have a mapping of Primary peer to alternate peer.When primary peer is down , all the requests in pending message queue will be routed to alternate peer.But in this case , alternate peer must support all the applicaiton Ids which primary peer is supporting.

But in case of second option, we can retireve the pending message from the pending message queue and based on the applicaiton Id , we can retireve the proper alternate peer (from realm table and peer table) for this request which will be supproting the application id present in the pending message and route the request to the same.So for different pending requests we can have different alternate peers.In such case there will not be any fixed alternate peer but based on the application Id, we will find the proper alternate peer from realm table and peer table.

Which option seems to be better?

Thanks in advance
Monal



--
Yours
Naveen. ------=_Part_136176_28248860.1154000881545-- ------=_Part_136175_11030102.1154000881545 Content-Type: application/rtf; name="Diameter_Failover_Problem_18-Jul-2006.rtf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Diameter_Failover_Problem_18-Jul-2006.rtf" X-Attachment-Id: f_eq51yhc7 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxXGRlZmYwXHN0c2hmZGJjaDBcc3RzaGZsb2NoMFxz dHNoZmhpY2gwXHN0c2hmYmkwXGRlZmxhbmcxMDMzXGRlZmxhbmdmZTEwMzN7XGZvbnR0Ymx7XGYw XGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMDIwNjAzMDUwNDA1MDIwMzA0fVRp bWVzIE5ldyBSb21hbjt9DQp7XGYyXGZtb2Rlcm5cZmNoYXJzZXQwXGZwcnExe1wqXHBhbm9zZSAw MjA3MDMwOTAyMDIwNTAyMDQwNH1Db3VyaWVyIE5ldzt9e1xmMzVcZnN3aXNzXGZjaGFyc2V0MFxm cHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMzA1MDQwNDAyMDR9VGFob21hO317XGYzNlxmc3dpc3Nc ZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjBiMDYwMzAyMDIwMjAyMDIwNH1UcmVidWNoZXQg TVM7fQ0Ke1xmMTA2XGZyb21hblxmY2hhcnNldDIzOFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ0U7 fXtcZjEwN1xmcm9tYW5cZmNoYXJzZXQyMDRcZnBycTIgVGltZXMgTmV3IFJvbWFuIEN5cjt9e1xm MTA5XGZyb21hblxmY2hhcnNldDE2MVxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gR3JlZWs7fXtcZjEx MFxmcm9tYW5cZmNoYXJzZXQxNjJcZnBycTIgVGltZXMgTmV3IFJvbWFuIFR1cjt9DQp7XGYxMTFc ZnJvbWFuXGZjaGFyc2V0MTc3XGZwcnEyIFRpbWVzIE5ldyBSb21hbiAoSGVicmV3KTt9e1xmMTEy XGZyb21hblxmY2hhcnNldDE3OFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEFyYWJpYyk7fXtcZjEx M1xmcm9tYW5cZmNoYXJzZXQxODZcZnBycTIgVGltZXMgTmV3IFJvbWFuIEJhbHRpYzt9e1xmMTE0 XGZyb21hblxmY2hhcnNldDE2M1xmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKFZpZXRuYW1lc2UpO30N CntcZjEyNlxmbW9kZXJuXGZjaGFyc2V0MjM4XGZwcnExIENvdXJpZXIgTmV3IENFO317XGYxMjdc Zm1vZGVyblxmY2hhcnNldDIwNFxmcHJxMSBDb3VyaWVyIE5ldyBDeXI7fXtcZjEyOVxmbW9kZXJu XGZjaGFyc2V0MTYxXGZwcnExIENvdXJpZXIgTmV3IEdyZWVrO317XGYxMzBcZm1vZGVyblxmY2hh cnNldDE2MlxmcHJxMSBDb3VyaWVyIE5ldyBUdXI7fQ0Ke1xmMTMxXGZtb2Rlcm5cZmNoYXJzZXQx NzdcZnBycTEgQ291cmllciBOZXcgKEhlYnJldyk7fXtcZjEzMlxmbW9kZXJuXGZjaGFyc2V0MTc4 XGZwcnExIENvdXJpZXIgTmV3IChBcmFiaWMpO317XGYxMzNcZm1vZGVyblxmY2hhcnNldDE4Nlxm cHJxMSBDb3VyaWVyIE5ldyBCYWx0aWM7fXtcZjEzNFxmbW9kZXJuXGZjaGFyc2V0MTYzXGZwcnEx IENvdXJpZXIgTmV3IChWaWV0bmFtZXNlKTt9DQp7XGY0NTZcZnN3aXNzXGZjaGFyc2V0MjM4XGZw cnEyIFRhaG9tYSBDRTt9e1xmNDU3XGZzd2lzc1xmY2hhcnNldDIwNFxmcHJxMiBUYWhvbWEgQ3ly O317XGY0NTlcZnN3aXNzXGZjaGFyc2V0MTYxXGZwcnEyIFRhaG9tYSBHcmVlazt9e1xmNDYwXGZz d2lzc1xmY2hhcnNldDE2MlxmcHJxMiBUYWhvbWEgVHVyO317XGY0NjFcZnN3aXNzXGZjaGFyc2V0 MTc3XGZwcnEyIFRhaG9tYSAoSGVicmV3KTt9DQp7XGY0NjJcZnN3aXNzXGZjaGFyc2V0MTc4XGZw cnEyIFRhaG9tYSAoQXJhYmljKTt9e1xmNDYzXGZzd2lzc1xmY2hhcnNldDE4NlxmcHJxMiBUYWhv bWEgQmFsdGljO317XGY0NjRcZnN3aXNzXGZjaGFyc2V0MTYzXGZwcnEyIFRhaG9tYSAoVmlldG5h bWVzZSk7fXtcZjQ2NVxmc3dpc3NcZmNoYXJzZXQyMjJcZnBycTIgVGFob21hIChUaGFpKTt9e1xm NDY2XGZzd2lzc1xmY2hhcnNldDIzOFxmcHJxMiBUcmVidWNoZXQgTVMgQ0U7fQ0Ke1xmNDY3XGZz d2lzc1xmY2hhcnNldDIwNFxmcHJxMiBUcmVidWNoZXQgTVMgQ3lyO317XGY0NjlcZnN3aXNzXGZj aGFyc2V0MTYxXGZwcnEyIFRyZWJ1Y2hldCBNUyBHcmVlazt9e1xmNDcwXGZzd2lzc1xmY2hhcnNl dDE2MlxmcHJxMiBUcmVidWNoZXQgTVMgVHVyO317XGY0NzNcZnN3aXNzXGZjaGFyc2V0MTg2XGZw cnEyIFRyZWJ1Y2hldCBNUyBCYWx0aWM7fX17XGNvbG9ydGJsO1xyZWQwXGdyZWVuMFxibHVlMDsN ClxyZWQwXGdyZWVuMFxibHVlMjU1O1xyZWQwXGdyZWVuMjU1XGJsdWUyNTU7XHJlZDBcZ3JlZW4y NTVcYmx1ZTA7XHJlZDI1NVxncmVlbjBcYmx1ZTI1NTtccmVkMjU1XGdyZWVuMFxibHVlMDtccmVk MjU1XGdyZWVuMjU1XGJsdWUwO1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjBc Ymx1ZTEyODtccmVkMFxncmVlbjEyOFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUwO1xyZWQx MjhcZ3JlZW4wXGJsdWUxMjg7DQpccmVkMTI4XGdyZWVuMFxibHVlMDtccmVkMTI4XGdyZWVuMTI4 XGJsdWUwO1xyZWQxMjhcZ3JlZW4xMjhcYmx1ZTEyODtccmVkMTkyXGdyZWVuMTkyXGJsdWUxOTI7 fXtcc3R5bGVzaGVldHtccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1 dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwIFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNc Y2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMgDQpcc25leHQwIFxzdHlyc2lkMTU4NzM1OTEg Tm9ybWFsO317XCpcY3MxMCBcYWRkaXRpdmUgXHNzZW1paGlkZGVuIERlZmF1bHQgUGFyYWdyYXBo IEZvbnQ7fXtcKg0KXHRzMTFcdHNyb3dkXHRyZnRzV2lkdGhCM1x0cnBhZGRsMTA4XHRycGFkZHIx MDhcdHJwYWRkZmwzXHRycGFkZGZ0M1x0cnBhZGRmYjNcdHJwYWRkZnIzXHRzY2VsbHdpZHRoZnRz MFx0c3ZlcnRhbHRcdHNicmRydFx0c2JyZHJsXHRzYnJkcmJcdHNicmRyclx0c2JyZHJkZ2xcdHNi cmRyZGdyXHRzYnJkcmhcdHNicmRydiANClxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFc YXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgXGZzMjBcbGFuZzEwMjRc bGFuZ2ZlMTAyNFxjZ3JpZFxsYW5nbnAxMDI0XGxhbmdmZW5wMTAyNCBcc25leHQxMSBcc3NlbWlo aWRkZW4gTm9ybWFsIFRhYmxlO317XHMxNVxxaiBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFc YXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgDQpcZjM2XGZzMjRcbGFu ZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24w IFxzbmV4dDE1IFxzdHlyc2lkMTU4NzM1OTEgQm9keSBMaW5lMTt9e1xzMTZccWwgXGxpMFxyaTBc d2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0 YXAwIFxjYnBhdDkgDQpcZjM1XGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAx MDMzXGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24wIFxzbmV4dDE2IFxzc2VtaWhpZGRlbiBcc3R5cnNp ZDY1MDk4MjUgRG9jdW1lbnQgTWFwO317XHMxN1xxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxw aGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAgDQpcZjJcZnMyMFxs YW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzYmFzZWRv bjAgXHNuZXh0MTcgXHN0eXJzaWQ3NDczMTQ2IFBsYWluIFRleHQ7fXtcczE4XHFsIFxsaTBccmkw XHdpZGN0bHBhcg0KXHR4OTE2XHR4MTgzMlx0eDI3NDhcdHgzNjY0XHR4NDU4MFx0eDU0OTZcdHg2 NDEyXHR4NzMyOFx0eDgyNDRcdHg5MTYwXHR4MTAwNzZcdHgxMDk5Mlx0eDExOTA4XHR4MTI4MjRc dHgxMzc0MFx0eDE0NjU2XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxs aW4wXGl0YXAwIFxmMlxmczIwXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xs YW5nZmVucDEwMzMgDQpcc2Jhc2Vkb24wIFxzbmV4dDE4IFxzdHlyc2lkNTMyNjkxMyBIVE1MIFBy ZWZvcm1hdHRlZDt9fXtcKlxsYXRlbnRzdHlsZXNcbHNkc3RpbWF4MTU2XGxzZGxvY2tlZGRlZjB9 e1wqXHBncHRibCB7XHBncFxpcGdwMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBc aXRhcDBcbGkwXHJpMFxzYjBcc2EwfX17XCpccnNpZHRibCBccnNpZDkzOTcxXHJzaWQzNTUyNjVc cnNpZDcyNzM5NVxyc2lkMTE5ODE0NFxyc2lkMjMxMjUzNg0KXHJzaWQyNTg3NDYxXHJzaWQyOTU1 NzM1XHJzaWQzMDI2ODUzXHJzaWQzMjk1ODQxXHJzaWQ0MzI2NzM5XHJzaWQ1MzI2OTEzXHJzaWQ1 NzkyMDQ4XHJzaWQ2MDM3MjQ1XHJzaWQ2MTgxODE4XHJzaWQ2NTA5ODI1XHJzaWQ2NzU1NTM1XHJz aWQ2NzY2NzcyXHJzaWQ2OTEyMTE4XHJzaWQ3NDczMTQ2XHJzaWQ3NTM5MjAxXHJzaWQ3ODg2MjM1 XHJzaWQ4NjEzNTEyXHJzaWQ4ODczNzU3XHJzaWQ5ODU0OTI2XHJzaWQxMDU1OTE5NFxyc2lkMTA3 NjQ2NzQNClxyc2lkMTIyMTU0NDFccnNpZDEyODU2MzQwXHJzaWQxMzI2MDYzN1xyc2lkMTM5MDA1 MTZccnNpZDEzOTg4ODI5XHJzaWQxNTY3NzU5Nlxyc2lkMTU4NzM1OTFccnNpZDE2NDA0Mzg3fXtc KlxnZW5lcmF0b3IgTWljcm9zb2Z0IFdvcmQgMTEuMC41NjA0O317XGluZm97XHRpdGxlIERpYW1l dGVyIHN0YWNrIGFyY2hpdGVjdHVyZX17XGF1dGhvciBBZG1pbn17XG9wZXJhdG9yIE5hdmVlbiBL b3R0YXBhbGxpfQ0Ke1xjcmVhdGltXHlyMjAwNlxtbzdcZHkyN1xocjE3XG1pbjd9e1xyZXZ0aW1c eXIyMDA2XG1vN1xkeTI3XGhyMTdcbWluMTZ9e1x2ZXJzaW9uNn17XGVkbWluczEwfXtcbm9mcGFn ZXMzfXtcbm9md29yZHM2ODJ9e1xub2ZjaGFyczM4OTN9e1wqXGNvbXBhbnkgQ0NJTn17XG5vZmNo YXJzd3M0NTY2fXtcdmVybjI0Njg5fX0NClx3aWRvd2N0cmxcZnRuYmpcYWVuZGRvY1xub3hsYXR0 b3llblxleHBzaHJ0blxub3VsdHJsc3BjXGRudGJsbnNiZGJcbm9zcGFjZWZvcnVsXGh5cGhjYXBz MFxmb3Jtc2hhZGVcaG9yemRvY1xkZ21hcmdpblxkZ2hzcGFjZTE4MFxkZ3ZzcGFjZTE4MFxkZ2hv cmlnaW4xODAwXGRndm9yaWdpbjE0NDBcZGdoc2hvdzFcZGd2c2hvdzENClxqZXhwYW5kXHZpZXdr aW5kMVx2aWV3c2NhbGUxMDBccGdicmRyaGVhZFxwZ2JyZHJmb290XHNwbHl0d25pbmVcZnRubHl0 d25pbmVcaHRtYXV0c3Bcbm9sbmh0YWRqdGJsXHVzZWx0YmFsblxhbG50YmxpbmRcbHl0Y2FsY3Ri bHdkXGx5dHRibHJ0Z3JcbG5icmtydWxlXG5vYnJrd3JwdGJsXHNuYXB0b2dyaWRpbmNlbGxcYWxs b3dmaWVsZGVuZHNlbFx3cnBwdW5jdA0KXGFzaWFuYnJrcnVsZVxyc2lkcm9vdDE1ODczNTkxXG5l d3RibHN0eXJ1bHNcbm9ncm93YXV0b2ZpdCBcZmV0MFxzZWN0ZCBcbGluZXgwXGVuZG5oZXJlXHNl Y3RsaW5lZ3JpZDM2MFxzZWN0ZGVmYXVsdGNsXHNmdG5iaiB7XCpccG5zZWNsdmwxXHBudWNybVxw bnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEgLn19e1wqXHBuc2VjbHZsMlxwbnVj bHRyXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0YSAufX0NCntcKlxwbnNlY2x2 bDNccG5kZWNccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRhIC59fXtcKlxwbnNl Y2x2bDRccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEgKX19e1wq XHBuc2VjbHZsNVxwbmRlY1xwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17 XHBudHh0YSApfX17XCpccG5zZWNsdmw2XHBubGNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5o YW5nIHtccG50eHRiICh9DQp7XHBudHh0YSApfX17XCpccG5zZWNsdmw3XHBubGNybVxwbnN0YXJ0 MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw4 XHBubGNsdHJccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRiICh9e1xwbnR4dGEg KX19e1wqXHBuc2VjbHZsOVxwbmxjcm1ccG5zdGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIHtccG50 eHRiICh9e1xwbnR4dGEgKX19XHBhcmRccGxhaW4gDQpcczE1XHFqIFxsaTBccmkwXHdpZGN0bHBh clxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJh cnNpZDEyMjE1NDQxIFxmMzZcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEw MzNcbGFuZ2ZlbnAxMDMzIHtcYlxpbnNyc2lkNzQ3MzE0NlxjaGFycnNpZDEzOTg4ODI5IFRoZSBm YWlsb3ZlciBpbiB0ZXJtcyBvZiBSRkMgMzU4OH17DQpcYlxpbnNyc2lkNTMyNjkxM1xjaGFycnNp ZDEzOTg4ODI5ICAoRGlhbWV0ZXIgQmFzZSBQcm90b2NvbCl9e1xiXGluc3JzaWQ3NDczMTQ2XGNo YXJyc2lkMTM5ODg4MjkgOn17XGJcaW5zcnNpZDE1ODczNTkxXGNoYXJyc2lkMTM5ODg4MjkgDQpc cGFyIH1ccGFyZCBcczE1XHFqIFxmaTcyMFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3Bu dW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDc0NzMxNDYge1xp bnNyc2lkNzQ3MzE0NiANClxwYXIgfXtcaW5zcnNpZDc0NzMxNDZcY2hhcnJzaWQ3NDczMTQ2IElu IHRoZSBldmVudCB0aGF0IGEgdHJhbnNwb3J0IGZhaWx1cmUgaXMgZGV0ZWN0ZWQgd2l0aCBhIHBl ZXIsIGl0IGlzfXtcaW5zcnNpZDc0NzMxNDYgIH17XGluc3JzaWQ3NDczMTQ2XGNoYXJyc2lkNzQ3 MzE0NiBuZWNlc3NhcnkgZm9yIGFsbCB9e1xoaWdobGlnaHQzXGluc3JzaWQ3NDczMTQ2XGNoYXJy c2lkMjU4NzQ2MSANCnBlbmRpbmcgcmVxdWVzdCBtZXNzYWdlcyB0byBiZSBmb3J3YXJkZWQgdG8g YW4gYWx0ZXJuYXRlIGFnZW50fXtcaW5zcnNpZDc0NzMxNDZcY2hhcnJzaWQ3NDczMTQ2ICwgaWYg cG9zc2libGUuICBUaGlzIGlzIGNvbW1vbmx5IHJlZmVycmVkIHRvIGFzfXtcaW5zcnNpZDc0NzMx NDYgIH17XGluc3JzaWQ3NDczMTQ2XGNoYXJyc2lkNzQ3MzE0NiBmYWlsb3Zlci4NClxwYXIgDQpc cGFyIEluIG9yZGVyIGZvciBhIERpYW1ldGVyIG5vZGUgdG8gcGVyZm9ybSBmYWlsb3ZlciBwcm9j ZWR1cmVzLCBpdCBpc317XGluc3JzaWQ3NDczMTQ2ICB9e1xpbnNyc2lkNzQ3MzE0NlxjaGFycnNp ZDc0NzMxNDYgbmVjZXNzYXJ5IGZvciB0aGUgbm9kZSB0byBtYWludGFpbiBhIHBlbmRpbmcgbWVz c2FnZSBxdWV1ZSBmb3IgYX17XGluc3JzaWQ3NDczMTQ2ICB9e1xpbnNyc2lkNzQ3MzE0NlxjaGFy cnNpZDc0NzMxNDYgDQpnaXZlbiBwZWVyLiAgV2hlbiBhbiBhbnN3ZXIgbWVzc2FnZSBpcyByZWNl aXZlZCwgdGhlIGNvcnJlc3BvbmRpbmd9e1xpbnNyc2lkNzQ3MzE0NiAgfXtcaW5zcnNpZDc0NzMx NDZcY2hhcnJzaWQ3NDczMTQ2IHJlcXVlc3QgaXMgcmVtb3ZlZCBmcm9tIHRoZSBxdWV1ZS4gIFRo ZSBIb3AtYnktSG9wIElkZW50aWZpZXIgZmllbGR9e1xpbnNyc2lkNzQ3MzE0NiAgfXtcaW5zcnNp ZDc0NzMxNDZcY2hhcnJzaWQ3NDczMTQ2IA0KaXMgdXNlZCB0byBtYXRjaCB0aGUgYW5zd2VyIHdp dGggdGhlIHF1ZXVlZCByZXF1ZXN0Lg0KXHBhciANClxwYXIgV2hlbiBhIHRyYW5zcG9ydCBmYWls dXJlIGlzIGRldGVjdGVkLCBpZiBwb3NzaWJsZSB9e1xoaWdobGlnaHQzXGluc3JzaWQ3NDczMTQ2 XGNoYXJyc2lkMjU4NzQ2MSBhbGwgbWVzc2FnZXMgaW4gdGhlIHF1ZXVlIGFyZSBzZW50IHRvIGFu IGFsdGVybmF0ZSBhZ2VudCB3aXRoIHRoZSBUIGZsYWcgc2V0fXtcaW5zcnNpZDc0NzMxNDZcY2hh cnJzaWQ3NDczMTQ2IC4gIE9uIGJvb3Rpbmd9e1xpbnNyc2lkNzQ3MzE0NiAgfXsNClxpbnNyc2lk NzQ3MzE0NlxjaGFycnNpZDc0NzMxNDYgYSBEaWFtZXRlciBjbGllbnQgb3IgYWdlbnQsIHRoZSBU IGZsYWcgaXMgYWxzbyBzZXQgb24gYW55IHJlY29yZHN9e1xpbnNyc2lkNzQ3MzE0NiAgfXtcaW5z cnNpZDc0NzMxNDZcY2hhcnJzaWQ3NDczMTQ2IHN0aWxsIHJlbWFpbmluZyB0byBiZSB0cmFuc21p dHRlZCBpbiBub24tdm9sYXRpbGUgc3RvcmFnZS4gIEFufXtcaW5zcnNpZDc0NzMxNDYgIH17DQpc aGlnaGxpZ2h0MTFcaW5zcnNpZDc0NzMxNDZcY2hhcnJzaWQ2MTgxODE4IGV4YW1wbGUgb2YgYSBj YXNlIHdoZXJlIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBmb3J3YXJkIHRoZSBtZXNzYWdlIHRvIGFu IGFsdGVybmF0ZSBzZXJ2ZXIgaXMgd2hlbiB0DQpoZSBtZXNzYWdlIGhhcyBhIGZpeGVkIGRlc3Rp bmF0aW9uLCBhbmQgdGhlIHVuYXZhaWxhYmxlIHBlZXIgaXMgdGhlIG1lc3NhZ2UncyBmaW5hbCBk ZXN0aW5hdGlvbiAoc2VlIERlc3RpbmF0aW9uLUhvc3QgQVZQKX17XGluc3JzaWQ3NDczMTQ2XGNo YXJyc2lkNzQ3MzE0NiAuICBTdWNoIGFuIGVycm9yIHJlcXVpcmVzIHRoYXQgdGhlIGFnZW50IHJl dHVybn17XGluc3JzaWQ3NDczMTQ2ICB9ew0KXGluc3JzaWQ3NDczMTQ2XGNoYXJyc2lkNzQ3MzE0 NiBhbiBhbnN3ZXIgbWVzc2FnZSB3aXRoIHRoZSAnRScgYml0IHNldCBhbmQgdGhlIFJlc3VsdC1D b2RlIEFWUCBzZXQgdG99e1xpbnNyc2lkNzQ3MzE0NiAgfXtcaW5zcnNpZDc0NzMxNDZcY2hhcnJz aWQ3NDczMTQ2IERJQU1FVEVSX1VOQUJMRV9UT19ERUxJVkVSLn17XGluc3JzaWQ3NDczMTQ2IA0K XHBhciANClxwYXIgfVxwYXJkIFxzMTVccWogXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFz cG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkNTMyNjkxMyB7 XGJcaW5zcnNpZDUzMjY5MTNcY2hhcnJzaWQxMzk4ODgyOSBUaGUgZmFpbG92ZXIgaW4gdGVybXMg b2YgUkZDIDM1MzkgKEFBQSBUcmFuKToNClxwYXIgfVxwYXJkIFxzMTVccWogXGZpNzIwXGxpMFxy aTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4w XGl0YXAwXHBhcmFyc2lkNTMyNjkxMyB7XGluc3JzaWQ1MzI2OTEzIA0KXHBhciB9e1x1bFxpbnNy c2lkNTMyNjkxM1xjaGFycnNpZDUzMjY5MTMgU2VjIDMuMSBbM10NClxwYXIgfXtcaW5zcnNpZDUz MjY5MTMgDQpccGFyIFdoZW4gZmFpbG92ZXIgaXMgaW5pdGlhdGVkLCBhbGwgbWVzc2FnZXMgaW4g dGhlIHF1ZXVlIGFyZSBzZW50IHRvIGFuIGFsdGVybmF0ZSBhZ2VudCwgaWYgYXZhaWxhYmxlLiAg TXVsdGlwbGUgaWRlbnRpY2FsIHJlcXVlc3RzIG9yIGFuc3dlcnMgbWF5IGJlIHJlY2VpdmVkIGFz IGEgcmVzdWx0IG8NCmYgYSBmYWlsb3Zlci4gIFRoZSBjb21iaW5hdGlvbiBvZiBhbiBlbmQtdG8t ZW5kIGlkZW50aWZpZXIgYW5kIHRoZSBvcmlnaW4gaG9zdCBNVVNUIGJlIHVzZWQgdG8gaWRlbnRp ZnkgZHVwbGljYXRlIG1lc3NhZ2VzLg0KXHBhciB9XHBhcmRccGxhaW4gXHMxOFxxbCBcbGkwXHJp MFx3aWRjdGxwYXJcdHg5MTZcdHgxODMyXHR4Mjc0OFx0eDM2NjRcdHg0NTgwXHR4NTQ5Nlx0eDY0 MTJcdHg3MzI4XHR4ODI0NFx0eDkxNjBcdHgxMDA3Nlx0eDEwOTkyXHR4MTE5MDhcdHgxMjgyNFx0 eDEzNzQwXHR4MTQ2NTZcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxp bjBcaXRhcDBccGFyYXJzaWQ1MzI2OTEzIA0KXGYyXGZzMjBcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xj Z3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQ1MzI2OTEzIA0KXHBhciB9XHBh cmRccGxhaW4gXHMxNVxxaiBcZmk3MjBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVt XGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQ1MzI2OTEzIFxmMzZc ZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtc dWxcaW5zcnNpZDUzMjY5MTNcY2hhcnJzaWQ1MzI2OTEzIFNlYyAzLjEwDQpccGFyIH17XGluc3Jz aWQ1MzI2OTEzIA0KXHBhciBOb3RlIHRoYXQgdGhlc2UgbWVzc2FnZXMgZGlmZmVyIGluIHRoZWly IHNjb3BlLiAgVGhlICJCdXN5IiBtZXNzYWdlIHRlbGxzIHRoZSBOQVMgdGhhdCB0aGUgYWdlbnQv c2VydmVyIGlzIHRvbyBidXN5IGZvciBBDQpOWSByZXF1ZXN0LiAgVGhlICJDYW4ndCBMb2NhdGUi IGFuZCAiQ2FuJ3QgRm9yd2FyZCIgbWVzc2FnZXMgaW5kaWNhdGUgdGhhdCB0aGUgdWx0aW1hdGUg ZGVzdGluYXRpb24gY2Fubm90IGJlIHJlYWNoZWQgb3IgaXNuJ3QgcmVzcG9uZGluZywgfXtcaGln aGxpZ2h0M1xpbnNyc2lkNTMyNjkxM1xjaGFycnNpZDEzMjYwNjM3IGltcGx5aW5nIHBlci1yZXF1 ZXN0IGZhaWxvdmVyfXtcaW5zcnNpZDUzMjY5MTMgLg0KXHBhciANClxwYXIgfXtcaW5zcnNpZDEz MjYwNjM3IA0KXHBhciB9e1xoaWdobGlnaHQzXGluc3JzaWQ5Mzk3MVxjaGFycnNpZDkzOTcxIERv ZXMgdGhlIGZhaWxvdmVyIHRvIGJlIGRvbmUgb24gcGVyLXJlcXVlc3QgYmFzaXMgb3IgcGVyIHBl ci1wZWVyIGJhc2lzP317XGluc3JzaWQ5Mzk3MVxjaGFycnNpZDkzOTcxIA0KXHBhciB9e1xpbnNy c2lkOTM5NzEgDQpccGFyIH17XGluc3JzaWQ2MDM3MjQ1IExldCB1cyBldm9sdmUgYm90aCB0aGUg Y2FzZXMgc2VwYXJhdGVseS4NClxwYXIgDQpccGFyIA0KXHBhciANClxwYXIgDQpccGFyIH17XGJc dWxcaW5zcnNpZDkzOTcxXGNoYXJyc2lkOTM5NzEgRmFpbG92ZXIgfXtcYlx1bFxpbnNyc2lkNjc1 NTUzNSBQZXItUGVlcn17XGJcdWxcaW5zcnNpZDI5NTU3MzUgIGJhc2lzfXtcYlx1bFxpbnNyc2lk OTM5NzFcY2hhcnJzaWQ5Mzk3MSA6DQpccGFyIH17XGluc3JzaWQ5Mzk3MSANClxwYXIgVGhpcyBx dWVzdGlvbiB3YXMgcmFpc2VkIGJlY2F1c2UgdW5kZXIgdGhlIGN1cnJlbnQgYXNzdW1wdGlvbiB0 aGF0IHRoZSBmYWlsb3ZlciB3aWxsIGJlIGRvbmUgb24gcGVyIHBlZXIgYmFzaXMsIHdoaWNoIG1l YW5zIGFsbCB0aGUgcGVuZGluZyBtZXNzYWdlcyBvZiB0aGUgZmFpbGVkIHBlZXIgd2lsbCBiZSBy b3V0ZWQgdG8gb25lIGFuZCBvbmx5IG9uZSBhbHRlcm5hdGUgcGVlci4NClxwYXIgfXtcaW5zcnNp ZDYwMzcyNDUgDQpccGFyIH17XGJcdWxcaW5zcnNpZDkzOTcxXGNoYXJyc2lkOTM5NzEgRmFpbG92 ZXIgfXtcYlx1bFxpbnNyc2lkNjc1NTUzNSBQZXItTWVzc2FnZX17XGJcdWxcaW5zcnNpZDI5NTU3 MzUgIGJhc2lzfXtcYlx1bFxpbnNyc2lkOTM5NzFcY2hhcnJzaWQ5Mzk3MSA6DQpccGFyIH17XGlu c3JzaWQ5Mzk3MSANClxwYXIgVGhlcmUgaXMgYWxzbyBhbm90aGVyIGFyZ3VtZW50IHRoYXQgdGhl IGZhaWxvdmVyIGhhcyB0byBiZSBkb25lIGZvciBhbGwgdGhlIG1lc3NhZ2VzIG9mIHRoZSBmYWls ZWQgcGVlciBiYXNlZCBvbiB0aGUgcGVyLW1lc3NhZ2UuDQpccGFyIA0KXHBhciB9e1xiXHVsXGlu c3JzaWQ5Mzk3MVxjaGFycnNpZDkzOTcxIFByb2JsZW19e1xiXHVsXGluc3JzaWQ2MDM3MjQ1IHN9 e1xiXHVsXGluc3JzaWQ5Mzk3MVxjaGFycnNpZDkzOTcxICBpbiB9e1xiXHVsXGluc3JzaWQyOTU1 NzM1IFBlci1QZWVyIGJhc2lzfXtcYlx1bFxpbnNyc2lkOTM5NzFcY2hhcnJzaWQ5Mzk3MSA6DQpc cGFyIH17XGluc3JzaWQ5Mzk3MSANClxwYXIgVGhlcmUgYXJlIHNvbWUgY2FzZXMgdG8gbm90ZSBp ZiB0aGUgZmFpbG92ZXIgaXMgZG9uZSBwZXItcGVlciBiYXNpcy59e1xpbnNyc2lkNjc1NTUzNSAN ClxwYXIgDQpccGFyIH17XGJcdWxcaW5zcnNpZDI5NTU3MzVcY2hhcnJzaWQ3NTM5MjAxIENhc2Ug MTp9e1xpbnNyc2lkMjk1NTczNSAgIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgY29uZmlndXJhdGlv biBpbiB0aGUgcmVhbG0tcm91dGluZyB0YWJsZX17XGluc3JzaWQxMDU1OTE5NCAgd2l0aCB0aGUg YXBwbGljYXRpb24taWRzIDEsIDIsIDMsIDR9e1xpbnNyc2lkMjk1NTczNSAufXtcaW5zcnNpZDcy NzM5NSANCiAgRWFjaCBwZWVyIGlzIGlkZW50aWZpZWQgd2l0aCBwcmVmaXggXGxxdW90ZSBQXHJx dW90ZSAgZm9sbG93ZWQgYnkgdGhlIHBlZXIgbnVtYmVyLn17XGluc3JzaWQyOTU1NzM1IA0KXHBh ciANClxwYXIgfXtcaW5zcnNpZDcyNzM5NSBbZXhhbXBsZS5uZXRdDQpccGFyIDEgPSBQMSwgUDMN ClxwYXIgMiA9IFAxLCBQMiwgUDQNClxwYXIgMyA9IFAyLCBQMw0KXHBhciA0ID0gUDQNClxwYXIg DQpccGFyIFRoZSBhYm92ZSBjb25maWd1cmF0aW9uIGlzIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRo YXQgdGhlIGN1cnJlbnQgbm9kZSAod2hvIGlzIGhvbGRpbmcgdGhlc2UgcGVlcn17XGluc3JzaWQ3 ODg2MjM1IHN9e1xpbnNyc2lkNzI3Mzk1ICBlbnRyaWVzKSBpcyBzdXBwb3J0aW5nIGFsbCB0aGUg YXBwbGljYXRpb25zIDEsIDIsIDMsIDR9e1xpbnNyc2lkNzg4NjIzNSAufXtcaW5zcnNpZDcyNzM5 NSANClxwYXIgfXtcbGFuZzEwMjRcbGFuZ2ZlMTAyNFxub3Byb29mXGluc3JzaWQ2NzY2NzcyIHtc c2hwZ3Jwe1wqXHNocGluc3Rcc2hwbGVmdDcyMFxzaHB0b3AyNjhcc2hwcmlnaHQ4NDYwXHNocGJv dHRvbTQ0MDhcc2hwZmhkcjBcc2hwYnhjb2x1bW5cc2hwYnhpZ25vcmVcc2hwYnlwYXJhXHNocGJ5 aWdub3JlXHNocHdyM1xzaHB3cmswXHNocGZibHd0eHQwXHNocHowXHNocGxpZDEwMjYNCntcc3B7 XHNuIGdyb3VwTGVmdH17XHN2IDI1MjB9fXtcc3B7XHNuIGdyb3VwVG9wfXtcc3YgODQ4OH19e1xz cHtcc24gZ3JvdXBSaWdodH17XHN2IDEwMjYwfX17XHNwe1xzbiBncm91cEJvdHRvbX17XHN2IDEy NjI4fX17XHNwe1xzbiBmRmxpcEh9e1xzdiAwfX17XHNwe1xzbiBmRmxpcFZ9e1xzdiAwfX17XHNw e1xzbiBwb3NofXtcc3YgMH19e1xzcHtcc24gcG9zdn17XHN2IDB9fXtcc3B7XHNuIGZMYXlvdXRJ bkNlbGx9e1xzdiAxfX0NCntcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX17XHNocHtcKlxz aHBpbnN0XHNocGxpZDEwMjd7XHNwe1xzbiByZWxMZWZ0fXtcc3YgMjUyMH19e1xzcHtcc24gcmVs VG9wfXtcc3YgODQ4OH19e1xzcHtcc24gcmVsUmlnaHR9e1xzdiAxMDI2MH19e1xzcHtcc24gcmVs Qm90dG9tfXtcc3YgMTI2Mjh9fXtcc3B7XHNuIGZSZWxGbGlwSH17XHN2IDB9fXtcc3B7XHNuIGZS ZWxGbGlwVn17XHN2IDB9fXtcc3B7XHNuIHNoYXBlVHlwZX17XHN2IDF9fQ0Ke1xzcHtcc24gZkxh eW91dEluQ2VsbH17XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX19fXtcc2hw e1wqXHNocGluc3Rcc2hwbGlkMTAyOHtcc3B7XHNuIHJlbExlZnR9e1xzdiAyODgwfX17XHNwe1xz biByZWxUb3B9e1xzdiA5OTAwfX17XHNwe1xzbiByZWxSaWdodH17XHN2IDQ1OTB9fXtcc3B7XHNu IHJlbEJvdHRvbX17XHN2IDEwODAwfX17XHNwe1xzbiBmUmVsRmxpcEh9e1xzdiAwfX0NCntcc3B7 XHNuIGZSZWxGbGlwVn17XHN2IDB9fXtcc3B7XHNuIHNoYXBlVHlwZX17XHN2IDN9fXtcc3B7XHNu IGxUeGlkfXtcc3YgNjU1MzZ9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX17XHNwe1xz biBmTGF5b3V0SW5DZWxsfXtcc3YgMX19e1xzaHB0eHQgXHBhcmRccGxhaW4gXHFjIFxsaTBccmkw XHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxp dGFwMFxwYXJhcnNpZDM1NTI2NSANClxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFu Z25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkMzU1MjY1IFAwfXtcZjM2XGluc3JzaWQzNTUy NjUgDQpccGFyIH17XGYzNlxpbnNyc2lkMzU1MjY1XGNoYXJyc2lkMzU1MjY1IDEsIDIsIDMsIDQN ClxwYXIgfX19fXtcc2hwe1wqXHNocGluc3Rcc2hwbGlkMTAyOXtcc3B7XHNuIHJlbExlZnR9e1xz diA1NTgwfX17XHNwe1xzbiByZWxUb3B9e1xzdiA4ODIwfX17XHNwe1xzbiByZWxSaWdodH17XHN2 IDcyOTB9fXtcc3B7XHNuIHJlbEJvdHRvbX17XHN2IDk3MjB9fXtcc3B7XHNuIGZSZWxGbGlwSH17 XHN2IDB9fXtcc3B7XHNuIGZSZWxGbGlwVn17XHN2IDB9fXtcc3B7XHNuIHNoYXBlVHlwZX17XHN2 IDN9fXtcc3B7XHNuIGxUeGlkfXtcc3YgMTMxMDcyfX0NCntcc3B7XHNuIGZMYXlvdXRJbkNlbGx9 e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtcc3YgMX19e1xzaHB0eHQgXHBhcmRccGxh aW4gXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDM1NTI2NSBcZnMyNFxsYW5nMTAzM1xsYW5nZmUx MDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcaW5zcnNpZDM1NTI2NSBQMX17DQpc ZjM2XGluc3JzaWQzNTUyNjUgDQpccGFyIH17XGYzNlxpbnNyc2lkMzU1MjY1XGNoYXJyc2lkMzU1 MjY1IDEsIDINClxwYXIgfX19fXtcc2hwe1wqXHNocGluc3Rcc2hwbGlkMTAzMHtcc3B7XHNuIHJl bExlZnR9e1xzdiA4MjgwfX17XHNwe1xzbiByZWxUb3B9e1xzdiA4ODIwfX17XHNwe1xzbiByZWxS aWdodH17XHN2IDk5OTB9fXtcc3B7XHNuIHJlbEJvdHRvbX17XHN2IDk3MjB9fXtcc3B7XHNuIGZS ZWxGbGlwSH17XHN2IDB9fXtcc3B7XHNuIGZSZWxGbGlwVn17XHN2IDB9fXtcc3B7XHNuIHNoYXBl VHlwZX17XHN2IDN9fXtcc3B7XHNuIGxUeGlkfXtcc3YgMTk2NjA4fX0NCntcc3B7XHNuIGZMYXlv dXRJbkNlbGx9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtcc3YgMX19e1xzaHB0eHQg XHBhcmRccGxhaW4gXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRv XGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDM1NTI2NSBcZnMyNFxsYW5nMTAz M1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcaW5zcnNpZDQzMjY3 MzkgUDJ9ew0KXGYzNlxpbnNyc2lkNDMyNjczOSANClxwYXIgfXtcaW5zcnNpZDQzMjY3MzkgMiwg M317XGYzNlxpbnNyc2lkNDMyNjczOVxjaGFycnNpZDM1NTI2NSANClxwYXIgfX19fXtcc2hwe1wq XHNocGluc3Rcc2hwbGlkMTAzMXtcc3B7XHNuIHJlbExlZnR9e1xzdiA1NTgwfX17XHNwe1xzbiBy ZWxUb3B9e1xzdiAxMTE2MH19e1xzcHtcc24gcmVsUmlnaHR9e1xzdiA3MjkwfX17XHNwe1xzbiBy ZWxCb3R0b219e1xzdiAxMjA2MH19e1xzcHtcc24gZlJlbEZsaXBIfXtcc3YgMH19DQp7XHNwe1xz biBmUmVsRmxpcFZ9e1xzdiAwfX17XHNwe1xzbiBzaGFwZVR5cGV9e1xzdiAzfX17XHNwe1xzbiBs VHhpZH17XHN2IDI2MjE0NH19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fXtcc3B7XHNu IGZMYXlvdXRJbkNlbGx9e1xzdiAxfX17XHNocHR4dCBccGFyZFxwbGFpbiBccWMgXGxpMFxyaTBc d2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0 YXAwXHBhcmFyc2lkMzU1MjY1IA0KXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5n bnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQ0MzI2NzM5IFAzfXtcZjM2XGluc3JzaWQ0MzI2 NzM5IA0KXHBhciB9e1xmMzZcaW5zcnNpZDQzMjY3MzlcY2hhcnJzaWQzNTUyNjUgMSwgfXtcZjM2 XGluc3JzaWQ0MzI2NzM5IDN9e1xmMzZcaW5zcnNpZDQzMjY3MzlcY2hhcnJzaWQzNTUyNjUgDQpc cGFyIH19fX17XHNocHtcKlxzaHBpbnN0XHNocGxpZDEwMzJ7XHNwe1xzbiByZWxMZWZ0fXtcc3Yg ODI4MH19e1xzcHtcc24gcmVsVG9wfXtcc3YgMTExNjB9fXtcc3B7XHNuIHJlbFJpZ2h0fXtcc3Yg OTk5MH19e1xzcHtcc24gcmVsQm90dG9tfXtcc3YgMTIwNjB9fXtcc3B7XHNuIGZSZWxGbGlwSH17 XHN2IDB9fQ0Ke1xzcHtcc24gZlJlbEZsaXBWfXtcc3YgMH19e1xzcHtcc24gc2hhcGVUeXBlfXtc c3YgM319e1xzcHtcc24gbFR4aWR9e1xzdiAzMjc2ODB9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9 e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtcc3YgMX19e1xzaHB0eHQgXHBhcmRccGxh aW4gXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDM1NTI2NSANClxmczI0XGxhbmcxMDMzXGxhbmdm ZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkNDMyNjczOSBQNH17 XGYzNlxpbnNyc2lkNDMyNjczOSANClxwYXIgfXtcaW5zcnNpZDQzMjY3MzkgMiwgNH17XGYzNlxp bnNyc2lkNDMyNjczOVxjaGFycnNpZDM1NTI2NSANClxwYXIgfX19fXtcc2hwe1wqXHNocGluc3Rc c2hwbGlkMTAzM3tcc3B7XHNuIHJlbExlZnR9e1xzdiA0MzUwfX17XHNwe1xzbiByZWxUb3B9e1xz diA5MzQ1fX17XHNwe1xzbiByZWxSaWdodH17XHN2IDU2MTB9fXtcc3B7XHNuIHJlbEJvdHRvbX17 XHN2IDEwMDY1fX17XHNwe1xzbiBmUmVsRmxpcEh9e1xzdiAwfX17XHNwe1xzbiBmUmVsRmxpcFZ9 e1xzdiAxfX17XHNwe1xzbiBzaGFwZVR5cGV9e1xzdiAyMH19e1xzcHtcc24gc2hhcGVQYXRofXtc c3YgNH19DQp7XHNwe1xzbiBmRmlsbE9LfXtcc3YgMH19e1xzcHtcc24gZkZpbGxlZH17XHN2IDB9 fXtcc3B7XHNuIGZBcnJvd2hlYWRzT0t9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtc c3YgMX19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fX19e1xzaHB7XCpcc2hwaW5zdFxz aHBsaWQxMDM0e1xzcHtcc24gcmVsTGVmdH17XHN2IDQ0ODV9fXtcc3B7XHNuIHJlbFRvcH17XHN2 IDk0NTB9fQ0Ke1xzcHtcc24gcmVsUmlnaHR9e1xzdiA1Njg1fX17XHNwe1xzbiByZWxCb3R0b219 e1xzdiAxMDEzNn19e1xzcHtcc24gZlJlbEZsaXBIfXtcc3YgMH19e1xzcHtcc24gZlJlbEZsaXBW fXtcc3YgMX19e1xzcHtcc24gc2hhcGVUeXBlfXtcc3YgMjB9fXtcc3B7XHNuIHNoYXBlUGF0aH17 XHN2IDR9fXtcc3B7XHNuIGZGaWxsT0t9e1xzdiAwfX17XHNwe1xzbiBmRmlsbGVkfXtcc3YgMH19 e1xzcHtcc24gZkFycm93aGVhZHNPS317XHN2IDF9fQ0Ke1xzcHtcc24gZkxheW91dEluQ2VsbH17 XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX19fXtcc2hwe1wqXHNocGluc3Rc c2hwbGlkMTAzNXtcc3B7XHNuIHJlbExlZnR9e1xzdiA0NDQwfX17XHNwe1xzbiByZWxUb3B9e1xz diAxMDU3NX19e1xzcHtcc24gcmVsUmlnaHR9e1xzdiA1NjU1fX17XHNwe1xzbiByZWxCb3R0b219 e1xzdiAxMTQwNH19e1xzcHtcc24gZlJlbEZsaXBIfXtcc3YgMH19DQp7XHNwe1xzbiBmUmVsRmxp cFZ9e1xzdiAwfX17XHNwe1xzbiBzaGFwZVR5cGV9e1xzdiAyMH19e1xzcHtcc24gc2hhcGVQYXRo fXtcc3YgNH19e1xzcHtcc24gZkZpbGxPS317XHN2IDB9fXtcc3B7XHNuIGZGaWxsZWR9e1xzdiAw fX17XHNwe1xzbiBmQXJyb3doZWFkc09LfXtcc3YgMX19e1xzcHtcc24gZkxheW91dEluQ2VsbH17 XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX19fQ0Ke1xzaHB7XCpcc2hwaW5z dFxzaHBsaWQxMDM2e1xzcHtcc24gcmVsTGVmdH17XHN2IDQzODB9fXtcc3B7XHNuIHJlbFRvcH17 XHN2IDEwNjYzfX17XHNwe1xzbiByZWxSaWdodH17XHN2IDU1ODB9fXtcc3B7XHNuIHJlbEJvdHRv bX17XHN2IDExNTIwfX17XHNwe1xzbiBmUmVsRmxpcEh9e1xzdiAwfX17XHNwe1xzbiBmUmVsRmxp cFZ9e1xzdiAwfX17XHNwe1xzbiBzaGFwZVR5cGV9e1xzdiAyMH19e1xzcHtcc24gc2hhcGVQYXRo fXtcc3YgNH19DQp7XHNwe1xzbiBmRmlsbE9LfXtcc3YgMH19e1xzcHtcc24gZkZpbGxlZH17XHN2 IDB9fXtcc3B7XHNuIGZBcnJvd2hlYWRzT0t9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxs fXtcc3YgMX19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fX19e1xzaHB7XCpcc2hwaW5z dFxzaHBsaWQxMDM3e1xzcHtcc24gcmVsTGVmdH17XHN2IDQ1MDB9fXtcc3B7XHNuIHJlbFRvcH17 XHN2IDk0ODB9fQ0Ke1xzcHtcc24gcmVsUmlnaHR9e1xzdiA4NDAwfX17XHNwe1xzbiByZWxCb3R0 b219e1xzdiAxMDE4NX19e1xzcHtcc24gZlJlbEZsaXBIfXtcc3YgMH19e1xzcHtcc24gZlJlbEZs aXBWfXtcc3YgMX19e1xzcHtcc24gc2hhcGVUeXBlfXtcc3YgMjB9fXtcc3B7XHNuIHNoYXBlUGF0 aH17XHN2IDR9fXtcc3B7XHNuIGZGaWxsT0t9e1xzdiAwfX17XHNwe1xzbiBmRmlsbGVkfXtcc3Yg MH19e1xzcHtcc24gZkFycm93aGVhZHNPS317XHN2IDF9fQ0Ke1xzcHtcc24gZkxheW91dEluQ2Vs bH17XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX19fXtcc2hwe1wqXHNocGlu c3Rcc2hwbGlkMTAzOHtcc3B7XHNuIHJlbExlZnR9e1xzdiA0NTkwfX17XHNwe1xzbiByZWxUb3B9 e1xzdiA5NTg1fX17XHNwe1xzbiByZWxSaWdodH17XHN2IDg1NDN9fXtcc3B7XHNuIHJlbEJvdHRv bX17XHN2IDEwMzA0fX17XHNwe1xzbiBmUmVsRmxpcEh9e1xzdiAwfX0NCntcc3B7XHNuIGZSZWxG bGlwVn17XHN2IDF9fXtcc3B7XHNuIHNoYXBlVHlwZX17XHN2IDIwfX17XHNwe1xzbiBzaGFwZVBh dGh9e1xzdiA0fX17XHNwe1xzbiBmRmlsbE9LfXtcc3YgMH19e1xzcHtcc24gZkZpbGxlZH17XHN2 IDB9fXtcc3B7XHNuIGZBcnJvd2hlYWRzT0t9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxs fXtcc3YgMX19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fX19DQp7XHNocHtcKlxzaHBp bnN0XHNocGxpZDEwMzl7XHNwe1xzbiByZWxMZWZ0fXtcc3YgNDU2MH19e1xzcHtcc24gcmVsVG9w fXtcc3YgMTA0NDB9fXtcc3B7XHNuIHJlbFJpZ2h0fXtcc3YgODc0NX19e1xzcHtcc24gcmVsQm90 dG9tfXtcc3YgMTEyMDV9fXtcc3B7XHNuIGZSZWxGbGlwSH17XHN2IDB9fXtcc3B7XHNuIGZSZWxG bGlwVn17XHN2IDB9fXtcc3B7XHNuIHNoYXBlVHlwZX17XHN2IDIwfX17XHNwe1xzbiBzaGFwZVBh dGh9e1xzdiA0fX0NCntcc3B7XHNuIGZGaWxsT0t9e1xzdiAwfX17XHNwe1xzbiBmRmlsbGVkfXtc c3YgMH19e1xzcHtcc24gZkFycm93aGVhZHNPS317XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNl bGx9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtcc3YgMX19fX17XHNocHtcKlxzaHBp bnN0XHNocGxpZDEwNDB7XHNwe1xzbiByZWxMZWZ0fXtcc3YgNDUwMH19e1xzcHtcc24gcmVsVG9w fXtcc3YgMTA1NDV9fQ0Ke1xzcHtcc24gcmVsUmlnaHR9e1xzdiA4NDkwfX17XHNwe1xzbiByZWxC b3R0b219e1xzdiAxMTI5NX19e1xzcHtcc24gZlJlbEZsaXBIfXtcc3YgMH19e1xzcHtcc24gZlJl bEZsaXBWfXtcc3YgMH19e1xzcHtcc24gc2hhcGVUeXBlfXtcc3YgMjB9fXtcc3B7XHNuIHNoYXBl UGF0aH17XHN2IDR9fXtcc3B7XHNuIGZGaWxsT0t9e1xzdiAwfX17XHNwe1xzbiBmRmlsbGVkfXtc c3YgMH19e1xzcHtcc24gZkFycm93aGVhZHNPS317XHN2IDF9fQ0Ke1xzcHtcc24gZkxheW91dElu Q2VsbH17XHN2IDF9fXtcc3B7XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX19fXtcc2hwe1wqXHNo cGluc3Rcc2hwbGlkMTA0MXtcc3B7XHNuIHJlbExlZnR9e1xzdiA0MTQwfX17XHNwe1xzbiByZWxU b3B9e1xzdiA5MzYwfX17XHNwe1xzbiByZWxSaWdodH17XHN2IDQ5ODB9fXtcc3B7XHNuIHJlbEJv dHRvbX17XHN2IDk3MjB9fXtcc3B7XHNuIGZSZWxGbGlwSH17XHN2IDB9fQ0Ke1xzcHtcc24gZlJl bEZsaXBWfXtcc3YgMH19e1xzcHtcc24gc2hhcGVUeXBlfXtcc3YgMjAyfX17XHNwe1xzbiBsVHhp ZH17XHN2IDM5MzIxNn19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fXtcc3B7XHNuIGZM YXlvdXRJbkNlbGx9e1xzdiAxfX17XHNocHR4dCBccGFyZFxwbGFpbiANClxxYyBcbGkwXHJpMFx3 aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRh cDBccGFyYXJzaWQ4ODczNzU3IFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25w MTAzM1xsYW5nZmVucDEwMzMge1xmczE2XGluc3JzaWQ4ODczNzU3XGNoYXJyc2lkMTY0MDQzODcg UE1RfXtcZnMxNlxpbnNyc2lkMTY0MDQzODdcY2hhcnJzaWQxNjQwNDM4NyBQfXsNClxmczE2XGlu c3JzaWQ4ODczNzU3XGNoYXJyc2lkMTY0MDQzODcgMQ0KXHBhciB9fX19e1xzaHB7XCpcc2hwaW5z dFxzaHBsaWQxMDQye1xzcHtcc24gcmVsTGVmdH17XHN2IDcyMDB9fXtcc3B7XHNuIHJlbFRvcH17 XHN2IDk3MjB9fXtcc3B7XHNuIHJlbFJpZ2h0fXtcc3YgODA0MH19e1xzcHtcc24gcmVsQm90dG9t fXtcc3YgMTAwODB9fXtcc3B7XHNuIGZSZWxGbGlwSH17XHN2IDB9fQ0Ke1xzcHtcc24gZlJlbEZs aXBWfXtcc3YgMH19e1xzcHtcc24gc2hhcGVUeXBlfXtcc3YgMjAyfX17XHNwe1xzbiBsVHhpZH17 XHN2IDQ1ODc1Mn19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fXtcc3B7XHNuIGZMYXlv dXRJbkNlbGx9e1xzdiAxfX17XHNocHR4dCBccGFyZFxwbGFpbiANClxxYyBcbGkwXHJpMFx3aWRj dGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBc cGFyYXJzaWQ4ODczNzU3IFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAz M1xsYW5nZmVucDEwMzMge1xmczE2XGluc3JzaWQxNjQwNDM4N1xjaGFycnNpZDE2NDA0Mzg3IFBN UVB9e1xmczE2XGluc3JzaWQxNjQwNDM4NyAyfXsNClxmczE2XGluc3JzaWQxNjQwNDM4N1xjaGFy cnNpZDE2NDA0Mzg3IA0KXHBhciB9fX19e1xzaHB7XCpcc2hwaW5zdFxzaHBsaWQxMDQze1xzcHtc c24gcmVsTGVmdH17XHN2IDcyMDB9fXtcc3B7XHNuIHJlbFRvcH17XHN2IDEwNjIwfX17XHNwe1xz biByZWxSaWdodH17XHN2IDgwNDB9fXtcc3B7XHNuIHJlbEJvdHRvbX17XHN2IDEwOTgwfX17XHNw e1xzbiBmUmVsRmxpcEh9e1xzdiAwfX0NCntcc3B7XHNuIGZSZWxGbGlwVn17XHN2IDB9fXtcc3B7 XHNuIHNoYXBlVHlwZX17XHN2IDIwMn19e1xzcHtcc24gbFR4aWR9e1xzdiA1MjQyODh9fXtcc3B7 XHNuIGZMYXlvdXRJbkNlbGx9e1xzdiAxfX17XHNwe1xzbiBmTGF5b3V0SW5DZWxsfXtcc3YgMX19 e1xzaHB0eHQgXHBhcmRccGxhaW4gDQpccWMgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFz cG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkODg3Mzc1NyBc ZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtc ZnMxNlxpbnNyc2lkMTY0MDQzODdcY2hhcnJzaWQxNjQwNDM4NyBQTVFQfXtcZnMxNlxpbnNyc2lk MTY0MDQzODcgNH17DQpcZnMxNlxpbnNyc2lkMTY0MDQzODdcY2hhcnJzaWQxNjQwNDM4NyANClxw YXIgfX19fXtcc2hwe1wqXHNocGluc3Rcc2hwbGlkMTA0NHtcc3B7XHNuIHJlbExlZnR9e1xzdiA0 NjgwfX17XHNwe1xzbiByZWxUb3B9e1xzdiAxMTM0MH19e1xzcHtcc24gcmVsUmlnaHR9e1xzdiA1 NTIwfX17XHNwe1xzbiByZWxCb3R0b219e1xzdiAxMTcwMH19e1xzcHtcc24gZlJlbEZsaXBIfXtc c3YgMH19DQp7XHNwe1xzbiBmUmVsRmxpcFZ9e1xzdiAwfX17XHNwe1xzbiBzaGFwZVR5cGV9e1xz diAyMDJ9fXtcc3B7XHNuIGxUeGlkfXtcc3YgNTg5ODI0fX17XHNwe1xzbiBmTGF5b3V0SW5DZWxs fXtcc3YgMX19e1xzcHtcc24gZkxheW91dEluQ2VsbH17XHN2IDF9fXtcc2hwdHh0IFxwYXJkXHBs YWluIA0KXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVz dHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDg4NzM3NTcgXGZzMjRcbGFuZzEwMzNcbGFu Z2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGZzMTZcaW5zcnNpZDE2NDA0 Mzg3XGNoYXJyc2lkMTY0MDQzODcgUE1RUH17XGZzMTZcaW5zcnNpZDE2NDA0Mzg3IDN9ew0KXGZz MTZcaW5zcnNpZDE2NDA0Mzg3XGNoYXJyc2lkMTY0MDQzODcgDQpccGFyIH19fX19e1xzaHByc2x0 e1wqXGRvXGRvYnhjb2x1bW5cZG9ieXBhcmFcZG9kaGd0ODE5MlxkcGdyb3VwXGRwY291bnQxOVxk cHg3MjBcZHB5MjY4XGRweHNpemU3NzQwXGRweXNpemU0MTQwXGRwcmVjdFxkcHgwXGRweTBcZHB4 c2l6ZTc3NDBcZHB5c2l6ZTQxNDANClxkcGZpbGxmZ2NyMjU1XGRwZmlsbGZnY2cyNTVcZHBmaWxs ZmdjYjI1NVxkcGZpbGxiZ2NyMjU1XGRwZmlsbGJnY2cyNTVcZHBmaWxsYmdjYjI1NVxkcGZpbGxw YXQxXGRwbGluZXcxNVxkcGxpbmVjb3IwXGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcHR4YnhcZHB0 eGxydGJ7XGRwdHhieHRleHRccGFyZFxwbGFpbiANClxxYyBcbGkwXHJpMFx3aWRjdGxwYXJcYXNw YWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQz NTUyNjUgXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyB7XGluc3JzaWQzNTUyNjUgUDB9e1xmMzZcaW5zcnNpZDM1NTI2NSANClxwYXIgfXtcZjM2 XGluc3JzaWQzNTUyNjVcY2hhcnJzaWQzNTUyNjUgMSwgMiwgMywgNA0KXHBhciB9fVxkcHgzNjBc ZHB5MTQxMlxkcHhzaXplMTcxMFxkcHlzaXplOTAwXGRwZmlsbGZnY3IyNTVcZHBmaWxsZmdjZzI1 NVxkcGZpbGxmZ2NiMjU1XGRwZmlsbGJnY3IyNTVcZHBmaWxsYmdjZzI1NVxkcGZpbGxiZ2NiMjU1 XGRwZmlsbHBhdDFcZHBsaW5ldzE1XGRwbGluZWNvcjBcZHBsaW5lY29nMFxkcGxpbmVjb2IwXGRw dHhieFxkcHR4bHJ0YntcZHB0eGJ4dGV4dFxwYXJkXHBsYWluIA0KXHFjIFxsaTBccmkwXHdpZGN0 bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxw YXJhcnNpZDM1NTI2NSBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNc bGFuZ2ZlbnAxMDMzIHtcaW5zcnNpZDM1NTI2NSBQMX17XGYzNlxpbnNyc2lkMzU1MjY1IA0KXHBh ciB9e1xmMzZcaW5zcnNpZDM1NTI2NVxjaGFycnNpZDM1NTI2NSAxLCAyDQpccGFyIH19XGRweDMw NjBcZHB5MzMyXGRweHNpemUxNzEwXGRweXNpemU5MDBcZHBmaWxsZmdjcjI1NVxkcGZpbGxmZ2Nn MjU1XGRwZmlsbGZnY2IyNTVcZHBmaWxsYmdjcjI1NVxkcGZpbGxiZ2NnMjU1XGRwZmlsbGJnY2Iy NTVcZHBmaWxscGF0MVxkcGxpbmV3MTVcZHBsaW5lY29yMFxkcGxpbmVjb2cwXGRwbGluZWNvYjBc ZHB0eGJ4XGRwdHhscnRie1xkcHR4Ynh0ZXh0XHBhcmRccGxhaW4gDQpccWMgXGxpMFxyaTBcd2lk Y3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAw XHBhcmFyc2lkMzU1MjY1IFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAz M1xsYW5nZmVucDEwMzMge1xpbnNyc2lkNDMyNjczOSBQMn17XGYzNlxpbnNyc2lkNDMyNjczOSAN ClxwYXIgfXtcaW5zcnNpZDQzMjY3MzkgMiwgM317XGYzNlxpbnNyc2lkNDMyNjczOVxjaGFycnNp ZDM1NTI2NSANClxwYXIgfX1cZHB4NTc2MFxkcHkzMzJcZHB4c2l6ZTE3MTBcZHB5c2l6ZTkwMFxk cGZpbGxmZ2NyMjU1XGRwZmlsbGZnY2cyNTVcZHBmaWxsZmdjYjI1NVxkcGZpbGxiZ2NyMjU1XGRw ZmlsbGJnY2cyNTVcZHBmaWxsYmdjYjI1NVxkcGZpbGxwYXQxXGRwbGluZXcxNVxkcGxpbmVjb3Iw XGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcHR4YnhcZHB0eGxydGJ7XGRwdHhieHRleHRccGFyZFxw bGFpbiANClxxYyBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1 c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQzNTUyNjUgXGZzMjRcbGFuZzEwMzNcbGFu Z2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQ0MzI2NzM5IFAz fXtcZjM2XGluc3JzaWQ0MzI2NzM5IA0KXHBhciB9e1xmMzZcaW5zcnNpZDQzMjY3MzlcY2hhcnJz aWQzNTUyNjUgMSwgfXtcZjM2XGluc3JzaWQ0MzI2NzM5IDN9e1xmMzZcaW5zcnNpZDQzMjY3Mzlc Y2hhcnJzaWQzNTUyNjUgDQpccGFyIH19XGRweDMwNjBcZHB5MjY3MlxkcHhzaXplMTcxMFxkcHlz aXplOTAwXGRwZmlsbGZnY3IyNTVcZHBmaWxsZmdjZzI1NVxkcGZpbGxmZ2NiMjU1XGRwZmlsbGJn Y3IyNTVcZHBmaWxsYmdjZzI1NVxkcGZpbGxiZ2NiMjU1XGRwZmlsbHBhdDFcZHBsaW5ldzE1XGRw bGluZWNvcjBcZHBsaW5lY29nMFxkcGxpbmVjb2IwXGRwdHhieFxkcHR4bHJ0YntcZHB0eGJ4dGV4 dFxwYXJkXHBsYWluIA0KXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFh dXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDM1NTI2NSBcZnMyNFxsYW5n MTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIHtcaW5zcnNpZDQz MjY3MzkgUDR9e1xmMzZcaW5zcnNpZDQzMjY3MzkgDQpccGFyIH17XGluc3JzaWQ0MzI2NzM5IDIs IDR9e1xmMzZcaW5zcnNpZDQzMjY3MzlcY2hhcnJzaWQzNTUyNjUgDQpccGFyIH19XGRweDU3NjBc ZHB5MjY3MlxkcHhzaXplMTcxMFxkcHlzaXplOTAwXGRwZmlsbGZnY3IyNTVcZHBmaWxsZmdjZzI1 NVxkcGZpbGxmZ2NiMjU1XGRwZmlsbGJnY3IyNTVcZHBmaWxsYmdjZzI1NVxkcGZpbGxiZ2NiMjU1 XGRwZmlsbHBhdDFcZHBsaW5ldzE1XGRwbGluZWNvcjBcZHBsaW5lY29nMFxkcGxpbmVjb2IwXGRw bGluZVxkcHB0eDEyNjBcZHBwdHkwXGRwcHR4MFxkcHB0eTcyMA0KXGRweDE4MzBcZHB5ODU3XGRw eHNpemUxMjYwXGRweXNpemU3MjBcZHBsaW5ldzE1XGRwbGluZWNvcjBcZHBsaW5lY29nMFxkcGxp bmVjb2IwXGRwbGluZVxkcHB0eDEyMDBcZHBwdHkwXGRwcHR4MFxkcHB0eTY4NlxkcHgxOTY1XGRw eTk2MlxkcHhzaXplMTIwMFxkcHlzaXplNjg2XGRwbGluZXcxNVxkcGxpbmVjb3IwXGRwbGluZWNv ZzBcZHBsaW5lY29iMFxkcGxpbmVcZHBwdHgwXGRwcHR5MFxkcHB0eDEyMTVcZHBwdHk4MjkNClxk cHgxOTIwXGRweTIwODdcZHB4c2l6ZTEyMTVcZHB5c2l6ZTgyOVxkcGxpbmV3MTVcZHBsaW5lY29y MFxkcGxpbmVjb2cwXGRwbGluZWNvYjBcZHBsaW5lXGRwcHR4MFxkcHB0eTBcZHBwdHgxMjAwXGRw cHR5ODU3XGRweDE4NjBcZHB5MjE3NVxkcHhzaXplMTIwMFxkcHlzaXplODU3XGRwbGluZXcxNVxk cGxpbmVjb3IwXGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcGxpbmVcZHBwdHgzOTAwXGRwcHR5MFxk cHB0eDBcZHBwdHk3MDUNClxkcHgxOTgwXGRweTk5MlxkcHhzaXplMzkwMFxkcHlzaXplNzA1XGRw bGluZXcxNVxkcGxpbmVjb3IwXGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcGxpbmVcZHBwdHgzOTUz XGRwcHR5MFxkcHB0eDBcZHBwdHk3MTlcZHB4MjA3MFxkcHkxMDk3XGRweHNpemUzOTUzXGRweXNp emU3MTlcZHBsaW5ldzE1XGRwbGluZWNvcjBcZHBsaW5lY29nMFxkcGxpbmVjb2IwXGRwbGluZVxk cHB0eDBcZHBwdHkwXGRwcHR4NDE4NVxkcHB0eTc2NQ0KXGRweDIwNDBcZHB5MTk1MlxkcHhzaXpl NDE4NVxkcHlzaXplNzY1XGRwbGluZXcxNVxkcGxpbmVjb3IwXGRwbGluZWNvZzBcZHBsaW5lY29i MFxkcGxpbmVcZHBwdHgwXGRwcHR5MFxkcHB0eDM5OTBcZHBwdHk3NTBcZHB4MTk4MFxkcHkyMDU3 XGRweHNpemUzOTkwXGRweXNpemU3NTBcZHBsaW5ldzE1XGRwbGluZWNvcjBcZHBsaW5lY29nMFxk cGxpbmVjb2IwXGRwdHhieFxkcHR4bHJ0YntcZHB0eGJ4dGV4dFxwYXJkXHBsYWluIA0KXHFjIFxs aTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBc bGluMFxpdGFwMFxwYXJhcnNpZDg4NzM3NTcgXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3Jp ZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGZzMTZcaW5zcnNpZDg4NzM3NTdcY2hhcnJzaWQx NjQwNDM4NyBQTVF9e1xmczE2XGluc3JzaWQxNjQwNDM4N1xjaGFycnNpZDE2NDA0Mzg3IFB9ew0K XGZzMTZcaW5zcnNpZDg4NzM3NTdcY2hhcnJzaWQxNjQwNDM4NyAxDQpccGFyIH19XGRweDE2MjBc ZHB5ODcyXGRweHNpemU4NDBcZHB5c2l6ZTM2MFxkcGZpbGxmZ2NyMjU1XGRwZmlsbGZnY2cyNTVc ZHBmaWxsZmdjYjI1NVxkcGZpbGxiZ2NyMjU1XGRwZmlsbGJnY2cyNTVcZHBmaWxsYmdjYjI1NVxk cGZpbGxwYXQxXGRwbGluZXcxNVxkcGxpbmVjb3IwXGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcHR4 YnhcZHB0eGxydGJ7XGRwdHhieHRleHRccGFyZFxwbGFpbiANClxxYyBcbGkwXHJpMFx3aWRjdGxw YXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFy YXJzaWQ4ODczNzU3IFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xs YW5nZmVucDEwMzMge1xmczE2XGluc3JzaWQxNjQwNDM4N1xjaGFycnNpZDE2NDA0Mzg3IFBNUVB9 e1xmczE2XGluc3JzaWQxNjQwNDM4NyAyfXsNClxmczE2XGluc3JzaWQxNjQwNDM4N1xjaGFycnNp ZDE2NDA0Mzg3IA0KXHBhciB9fVxkcHg0NjgwXGRweTEyMzJcZHB4c2l6ZTg0MFxkcHlzaXplMzYw XGRwZmlsbGZnY3IyNTVcZHBmaWxsZmdjZzI1NVxkcGZpbGxmZ2NiMjU1XGRwZmlsbGJnY3IyNTVc ZHBmaWxsYmdjZzI1NVxkcGZpbGxiZ2NiMjU1XGRwZmlsbHBhdDFcZHBsaW5ldzE1XGRwbGluZWNv cjBcZHBsaW5lY29nMFxkcGxpbmVjb2IwXGRwdHhieFxkcHR4bHJ0YntcZHB0eGJ4dGV4dFxwYXJk XHBsYWluIA0KXHFjIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFk anVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDg4NzM3NTcgXGZzMjRcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGZzMTZcaW5zcnNpZDE2 NDA0Mzg3XGNoYXJyc2lkMTY0MDQzODcgUE1RUH17XGZzMTZcaW5zcnNpZDE2NDA0Mzg3IDR9ew0K XGZzMTZcaW5zcnNpZDE2NDA0Mzg3XGNoYXJyc2lkMTY0MDQzODcgDQpccGFyIH19XGRweDQ2ODBc ZHB5MjEzMlxkcHhzaXplODQwXGRweXNpemUzNjBcZHBmaWxsZmdjcjI1NVxkcGZpbGxmZ2NnMjU1 XGRwZmlsbGZnY2IyNTVcZHBmaWxsYmdjcjI1NVxkcGZpbGxiZ2NnMjU1XGRwZmlsbGJnY2IyNTVc ZHBmaWxscGF0MVxkcGxpbmV3MTVcZHBsaW5lY29yMFxkcGxpbmVjb2cwXGRwbGluZWNvYjBcZHB0 eGJ4XGRwdHhscnRie1xkcHR4Ynh0ZXh0XHBhcmRccGxhaW4gDQpccWMgXGxpMFxyaTBcd2lkY3Rs cGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBh cmFyc2lkODg3Mzc1NyBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNc bGFuZ2ZlbnAxMDMzIHtcZnMxNlxpbnNyc2lkMTY0MDQzODdcY2hhcnJzaWQxNjQwNDM4NyBQTVFQ fXtcZnMxNlxpbnNyc2lkMTY0MDQzODcgM317DQpcZnMxNlxpbnNyc2lkMTY0MDQzODdcY2hhcnJz aWQxNjQwNDM4NyANClxwYXIgfX1cZHB4MjE2MFxkcHkyODUyXGRweHNpemU4NDBcZHB5c2l6ZTM2 MFxkcGZpbGxmZ2NyMjU1XGRwZmlsbGZnY2cyNTVcZHBmaWxsZmdjYjI1NVxkcGZpbGxiZ2NyMjU1 XGRwZmlsbGJnY2cyNTVcZHBmaWxsYmdjYjI1NVxkcGZpbGxwYXQxXGRwbGluZXcxNVxkcGxpbmVj b3IwXGRwbGluZWNvZzBcZHBsaW5lY29iMFxkcGVuZGdyb3VwXGRweDBcZHB5MFxkcHhzaXplMFxk cHlzaXplMH19fX17XGluc3JzaWQ3ODg2MjM1IA0KXHBhciB9e1xpbnNyc2lkMTA3NjQ2NzQgVGhp cyBjYW4gYmUgc2VlbiBwaWN0b3JpYWxseSBhcyBmb2xsb3dzOg0KXHBhciB9e1xpbnNyc2lkOTM5 NzEgDQpccGFyIA0KXHBhciB9e1xpbnNyc2lkMTU2Nzc1OTYgDQpccGFyIA0KXHBhciANClxwYXIg DQpccGFyIA0KXHBhciANClxwYXIgDQpccGFyIA0KXHBhciANClxwYXIgDQpccGFyIA0KXHBhciAN ClxwYXIgDQpccGFyIH17XGluc3JzaWQxMTk4MTQ0IFRoZSBQTVFQMSB3aWxsIGNvbnRhaW4gdGhl IHBlbmRpbmcgbWVzc2FnZXMgb2YgYXBwbGljYXRpb25zIDEsIDIufXtcaW5zcnNpZDg2MTM1MTIg DQpccGFyIH17XGluc3JzaWQxMTk4MTQ0IFRoZSBQTVFQMiB3aWxsIGNvbnRhaW4gdGhlIHBlbmRp bmcgbWVzc2FnZXMgb2YgYXBwbGljYXRpb25zIDIsIDMuDQpccGFyIH1ccGFyZCBcczE1XHFqIFxm aTcyMFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0 XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDExOTgxNDQge1xpbnNyc2lkMTE5ODE0NCBUaGUgUE1R UDMgd2lsbCBjb250YWluIHRoZSBwZW5kaW5nIG1lc3NhZ2VzIG9mIGFwcGxpY2F0aW9ucyAxLCAz Lg0KXHBhciBUaGUgUE1RUDQgd2lsbCBjb250YWluIHRoZSBwZW5kaW5nIG1lc3NhZ2VzIG9mIGFw cGxpY2F0aW9ucyAyLCA0Ln17XGluc3JzaWQxMTk4MTQ0XGNoYXJyc2lkNzQ3MzE0NiANClxwYXIg fVxwYXJkIFxzMTVccWogXGZpNzIwXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxm YWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkNTMyNjkxMyB7XGluc3Jz aWQxMTk4MTQ0IA0KXHBhciBJZiB0aGUgcGVlciBQMSBpcyBkb3duLCB0aGVuIHRvIHdoaWNofXtc aW5zcnNpZDEyODU2MzQwICBwZWVyIH17XGluc3JzaWQ2OTEyMTE4IHRoZSBwZW5kaW5nIG1lc3Nh Z2VzIG9mIDEsIDIgYXBwbGljYXRpb25zIHdpbGwgYmUgc2VudC59e1xpbnNyc2lkNzUzOTIwMSAg IEFzIHBlciB0aGUgYWJvdmUgY29uZmlnDQp1cmF0aW9uIHRoZXJlIGlzIG5vIGFsdGVybmF0ZSBw ZWVyIGZvciB0aGUgUDEgd2l0aCB0aGUgc2FtZSBhcHBsaWNhdGlvbiBpZHMgc3VwcG9ydGVkICgx LCAyKS59e1xpbnNyc2lkMTE5ODE0NCANClxwYXIgfXtcaW5zcnNpZDYwMzcyNDUgDQpccGFyIH17 XGJcdWxcaW5zcnNpZDc1MzkyMDFcY2hhcnJzaWQ3NTM5MjAxIENhc2UgMjp9e1xiXHVsXGluc3Jz aWQ3NTM5MjAxICB9e1xpbnNyc2lkNzUzOTIwMSAgSW4gdGhpcyBjYXMNCmUgd2UgbmVlZCB0byBo YXZlIGEgZGF0YWJhc2UgbGlrZSB0aGF0IGRpZmZlcmVudGlhdGVzIHRoZSBwcmltYXJ5IHBlZXJz IGFuZCB0aGUgY29ycmVzcG9uZGluZyBzZWNvbmRhcnkgcGVlcnMuICBJdCBpcyB2ZXJ5IGRpZmZp Y3VsdCB0byBhc3NpZ24gbm9kZXMgc3BlY2lmaWNhbGx5IGZvciB0aGUgcHJpbWFyeSBhbmQgc2Vj b25kYXJ5IGZvciB0aGUgcGVlcnMuDQpccGFyIH17XGluc3JzaWQzMjk1ODQxIA0KXHBhciBJZiB0 aGUgZmFpbG92ZXIgfXtcYlxpbnNyc2lkMzI5NTg0MVxjaGFycnNpZDIzMTI1MzYgaGFzIGJlZW4g ZG9uZSBwZXItbWVzc2FnZSBiYXNpc317XGluc3JzaWQzMjk1ODQxICB0aGUgYWJvdmUgdHdvIGlz c3VlcyBjYW4gYmUgc29sdmVkIGxpa2U6DQpccGFyIA0KXHBhciB9e1xiXGluc3JzaWQzMjk1ODQx XGNoYXJyc2lkMzI5NTg0MSBDYXNlMTp9e1xpbnNyc2lkMzI5NTg0MSAgd2Ugd2lsbCBjaG9vc2Ug cGVlciBQMiBmb3IgYWxsIHRoZSBtZXNzYWdlcyBvZiBhcHBsaWNhdGlvbi1pZCAyLiAgV2Ugd2ls bCBjaG9vc2UgcGVlciAzIGZvciBhbGwgdGhlIG1lc3NhZ2VzIG9mIGFwcGxpY2F0aW9uLWlkIDEu ICANClxwYXIgDQpccGFyIH17XGJcaW5zcnNpZDMyOTU4NDFcY2hhcnJzaWQzMjk1ODQxIENhc2Ug Mjp9e1xpbnNyc2lkMzI5NTg0MVxjaGFycnNpZDMyOTU4NDEgIH17XGluc3JzaWQzMjk1ODQxIFdl IG5lZWQgbm90IG1haW50YWluIGRpZmZlcmVudCBkYXRhYmFzZXMgbGlrZSBwcmltYXJ5IHBlZXIg dGFibGUgYQ0KbmQgc2Vjb25kYXJ5IHBlZXIgdGFibGUuICBBbGwgdGhlIHBlZXJzIHdpbGwgYmUg b25seSBpbiBvbmUgdGFibGUgYW5kIG91ciBzZWFyY2ggY3JpdGVyaWEgb25seSB3aWxsIGNoYW5n ZSBkZXBlbmRpbmcgb24gdGhlIGFwcGxpY2F0aW9uLWlkcyB0aGF0IGFyZSBiZWluZyBzdXBwb3J0 ZWQgYnkgdGhlIHBlZXJ9e1xpbnNyc2lkMzI5NTg0MVxjaGFycnNpZDMyOTU4NDEgIH17XGluc3Jz aWQzMjk1ODQxIGZhaWxlZC4NClxwYXIgfXtcaW5zcnNpZDEzOTAwNTE2IA0KXHBhciB9XHBhcmQg XHMxNVxxaiBcZmk3MjBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xh ZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxMzkwMDUxNiB7XGluc3JzaWQxMzkw MDUxNiBUaGUgYWJvdmUgY29uZmlndXJhdGlvbiBjYW4gaGFwcGVuZWQgYW5kIHcNCmlsbCBhbHdh eXMgYmUgc3VjY2Vzc2Z1bCwgYmVjYXVzZSB0aGUgbm9kZXMgd2lsbCByZXR1cm4gTElNSVRFRF9T VUNDRVNTIGR1cmluZyB0aGUgZXhjaGFuZ2Ugb2YgdGhlIENFUiBhbmQgQ0VBLiAgSWYgdGhlIGZh aWxvdmVyIGlzIGRvbmUgcGVyIHBlZXIgYmFzaXMsIHdlIGFyZSBsb29zaW5nIHRoZSBmbGV4aWJp bGl0eSBvZiBjaG9vc2luZyB0aGUgbm9kZXMgZXZlbiB0aG91Z2ggdGhlIHBlZXIgaXMgc3VwcG9y dGluZyANCnRoZSBhcHBsaWNhdGlvbi1pZCBvZiB0aGUgZmFpbGVkIHBlZXIuDQpccGFyIH1ccGFy ZCBcczE1XHFqIFxmaTcyMFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRv XGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDUzMjY5MTMge1xpbnNyc2lkMTM5 MDA1MTYgDQpccGFyIH1ccGFyZCBcczE1XHFqIFxmaTcyMFxsaTBccmkwXHdpZGN0bHBhclxhc3Bh bHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDIz MTI1MzYge1xpbnNyc2lkNjAzNzI0NSBCYXNlZCBvbiB0aGUgYWJvdmUgYW5hbHlzaXMgSSBzdHJp Y3RseSB9e1xpbnNyc2lkMjMxMjUzNiBvcHQgfXtcaW5zcnNpZDYwMzcyNDUgdGhhdCBmYWlsb3Zl ciBoYXMgdG8gYmUgZG9uZSBwZXIgbWVzc2FnZSBiYXNpcy59ew0KXGluc3JzaWQyMzEyNTM2IA0K XHBhciB9e1xpbnNyc2lkMTM5MDA1MTZcY2hhcnJzaWQzMjk1ODQxIA0KXHBhciB9fQ== ------=_Part_136175_11030102.1154000881545 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 ------=_Part_136175_11030102.1154000881545-- From dime-bounces@ietf.org Mon Jul 31 11:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZUM-0003s7-2X; Mon, 31 Jul 2006 11:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZUK-0003s1-LG for dime@ietf.org; Mon, 31 Jul 2006 11:15:24 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZUJ-00040x-8y for dime@ietf.org; Mon, 31 Jul 2006 11:15:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2006 08:15:24 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="308814627:sNHT28264204" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6VFFMYu012984; Mon, 31 Jul 2006 08:15:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6VFFM2D003240; Mon, 31 Jul 2006 08:15:22 -0700 (PDT) Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Jul 2006 08:15:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Summary of 3588bis Issues Status Date: Mon, 31 Jul 2006 08:15:20 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F488E@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Summary of 3588bis Issues Status Thread-Index: Acaqlq2bd5eX3G6fQmm05ANCFjtWjQAf3WrwAX0jk7AAAz86wAANTp6gANmkoJA= From: "Glen Zorn \(gwz\)" To: "Pasi Eronen" X-OriginalArrivalTime: 31 Jul 2006 15:15:22.0417 (UTC) FILETIME=[24624210:01C6B4B4] DKIM-Signature: a=rsa-sha1; q=dns; l=2502; t=1154358922; x=1155222922; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Dime]=20Summary=20of=203588bis=20Issues=20Status; X=v=3Dcisco.com=3B=20h=3D4vPGO8qGutP3SBEn1b/FPn+F6U8=3D; b=afZ5lDY6Q2Zn58vfM52ogpc38cb+k6uf3nTnK3SB8tqqN8/tcn2I5n4VBrgZyjhMhCVt/27M vHF297a1WFQJPgTN8JaIkBa+InhLBB8nN6mk8tSygYfcV7BviRRVYx8s; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Pasi Eronen supposedly scribbled: > Glen Zorn wrote: >>> I don't think that we should re-open this issue, as it was discussed >>> and decided long ago. >>=20 >> I think that this was a fairly serious error, at least WRT the >> session-oriented (including accounting) messages. If it's not an >> error, tell me this: an application generates an STR & sends it to >> the correct peer with app ID 0. The Diameter Base terminates the >> session. So what happens to the state being held by the >> _application_ peer? Unless the Base protocol module keeps a map of >> session IDs to applications, it doesn't seem that it would know >> which application to notify of the session termination. >=20 > Once again: this depends on what is meant by an "application". > Saying that "an application generates an STR & sends it" or "which > application to notify" makes any sense only if by application you > mean some kind of module or component in a Diameter server (or > something =20 > similar) >=20 > But at least my reading of RFC3588 (which some others agreed when > this issue was discussed the last time) was that an "application" in > Diameter means a set of specifications (documents). Thus, while you > can send a message defined _in_ an application, an application is not > a thing that sends or receives messages. =20 Interesting. So why are application IDs part of the protocol? Do we = expect Diameter peers to go read the appropriate specification?=20 =20 >=20 > However, by now it's quite obvious that most implementors reading the > spec for the first time immediately (and quite naturally) assume the > "software component" interpretation... and that's why we keep having > this discussion every two years (when even the document authors might > have forgotten why they wrote that :-) =20 >=20 > In 3588bis we should clarify this, and probably introduce a new > term(s) for the software components and their state (this would allow > us to describe more easily that e.g. when a message referring to an > existing session is processed, the session state lookup is done by > Session-ID, not Application-ID+Session-ID). =20 So, apparently the entire software system must be rewritten in order to = support a new "application"? =20 >=20 > Best regards, > Pasi Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime