From dime-bounces@ietf.org Fri Dec 01 05:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5xP-0002kW-Ik; Fri, 01 Dec 2006 05:49:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5xN-0002kJ-M4 for dime@ietf.org; Fri, 01 Dec 2006 05:49:25 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5xL-0001aK-I9 for dime@ietf.org; Fri, 01 Dec 2006 05:49:25 -0500 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kB1ApsXb003858 for ; Fri, 1 Dec 2006 16:21:54 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kB1Apqsp003834 for ; Fri, 1 Dec 2006 16:21:53 +0530 In-Reply-To: To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Fri, 1 Dec 2006 16:23:26 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 01/12/2006 04:19:21 PM, Serialize complete at 01/12/2006 04:19:21 PM X-Spam-Score: 0.6 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Dime] Application Id to be used in STR/STA/ASR/ASA/RAR/RAA 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="===============1072097257==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1072097257== Content-Type: multipart/alternative; boundary="=_alternative 003B6EA665257237_=" This is a multipart message in MIME format. --=_alternative 003B6EA665257237_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9uIHRvIGFzay4NCg0KV2hhdCBzaG91bGQg YmUgdGhlIEFwcGxpY2F0aW9uIElEIGJlIHVzZWQgYnkgQVNSL0FTQSwgUkFSL1JBQSwgU1RSL1NU QSANCm1lc3NhZ2VzDQoNClJlZ2FyZHMNClByZWV0aQ0KDQoqKioqKioqKioqKioqKioqKioqKioq KiAgQXJpY2VudC0gQ29uZmlkZW50aWFsICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVND TEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBp cyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBw dXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2lu ZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMg bWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBk YW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVk IGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 003B6EA665257237_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5IaSAhPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zPjx0dD5JIGhhdmUgZm9sbG93aW5nIHF1ZXN0aW9uIHRvIGFzay48L3R0PjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+PHR0PldoYXQgc2hvdWxkIGJlIHRoZSBBcHBsaWNhdGlv biBJRCBiZSB1c2VkIGJ5IEFTUi9BU0EsDQpSQVIvUkFBLCBTVFIvU1RBIG1lc3NhZ2VzPC90dD48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5SZWdhcmRzPC90dD48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPjx0dD5QcmVldGk8YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKiAmbmJzcDtBcmljZW50LSBDb25maWRlbnRpYWwgJm5ic3A7ICoqKioqKioqKioqKioqKioq KioqKioqPC90dD48L2ZvbnQ+DQo8dGFibGU+PHRyPjx0ZCBiZ2NvbG9yPSNmZmZmZmY+PGZvbnQg Y29sb3I9IzAwMDAwMD48cHJlPiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRh cnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhl IGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZp bGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJj dWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMg aW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmlj dGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3Np bmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3Bv bnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBm cm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 003B6EA665257237_=-- --===============1072097257== 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 --===============1072097257==-- From dime-bounces@ietf.org Fri Dec 01 05:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64v-0004cf-RN; Fri, 01 Dec 2006 05:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq64u-0004cS-I8 for dime@ietf.org; Fri, 01 Dec 2006 05:57:12 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq64t-0003WX-9u for dime@ietf.org; Fri, 01 Dec 2006 05:57:12 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1164970630!15972284!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 14845 invoked from network); 1 Dec 2006 10:57:10 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-119.messagelabs.com with SMTP; 1 Dec 2006 10:57:10 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kB1Av9Ww025076 for ; Fri, 1 Dec 2006 03:57:09 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kB1Av7N3011437 for ; Fri, 1 Dec 2006 04:57:08 -0600 (CST) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Fri, 1 Dec 2006 18:57:05 +0800 Message-ID: <457009F0.2060708@motorola.com> Date: Fri, 01 Dec 2006 16:24:40 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Preeti Shandilya Subject: Re: [Dime] Application Id to be used in STR/STA/ASR/ASA/RAR/RAA References: In-Reply-To: X-OriginalArrivalTime: 01 Dec 2006 10:57:05.0594 (UTC) FILETIME=[705DF9A0:01C71537] X-Spam-Score: 2.0 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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="===============0159631989==" Errors-To: dime-bounces@ietf.org --===============0159631989== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi

As discussed and concluded in the last IETF meeting, the value of the appid in ASR/ASA, STR/STA and RAR/RAA messages should be that of the target application. Please refer meeting minutes(Issue 21).

Here's the link- http://www3.ietf.org/proceedings/06nov/minutes/dime.txt
Regards,
Liyaqatali G Nadaf


Preeti Shandilya wrote:

Hi !

I have following question to ask.

What should be the Application ID be used by ASR/ASA, RAR/RAA, STR/STA messages

Regards
Preeti

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

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--===============0159631989== 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 --===============0159631989==-- From dime-bounces@ietf.org Fri Dec 01 11:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBQb-0006GV-Mk; Fri, 01 Dec 2006 11:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBQa-0006G8-BH for dime@ietf.org; Fri, 01 Dec 2006 11:39:56 -0500 Received: from web90404.mail.mud.yahoo.com ([216.252.100.156]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GqBQW-0007rM-Ma for dime@ietf.org; Fri, 01 Dec 2006 11:39:56 -0500 Received: (qmail 46741 invoked by uid 60001); 1 Dec 2006 16:39:46 -0000 Message-ID: <20061201163946.46739.qmail@web90404.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1RF7N5zZw7Chquc6CciDiPyc9dtnKQtQXrhk++inohd/0CIx6NrB/PQPOQJCY5dkVaATlFnL4m0GnImgdbIiLtf/KntJ3ZWOyeb/GUhShRkMPJ0OLF+cCZwjq9Yj1u2tkkVnxyue3MEVXWqPxgaskceUjqINUOonbjPdqTarMJI=; X-YMail-OSG: PQvrIMQVM1mxFWVl4akCCkaL8MEK2xs8kjt02UrKui4vcu.8HuzJQ9pKZBENrZ4Szk7rc2CYsiAZ33.._AY2jCYZrd4mn54gKLX1h8mm7WXOKOO2z6snuWGjK8O8Of9gtUp2_6ZCMGAi_0GedxRKQN1dxrEQVFQ9DA-- Received: from [125.19.62.5] by web90404.mail.mud.yahoo.com via HTTP; Fri, 01 Dec 2006 08:39:46 PST Date: Fri, 1 Dec 2006 08:39:46 -0800 (PST) From: himanshu bahl Subject: Re: [Dime] RFC3588bis Issue12 To: Tolga Asveren , dime@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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, can you please specify how has the following issue been resolved. I`m unable to locate the thread for that. and one more thing. If a redirect agent replies with the redirectHost avp value in the DiameterIdentity format instead of diameterURI format is the message incorrect ? sincerely, Himanshu. http://thebahls.blogspot.com --- Tolga Asveren wrote: > >From issue tracker, Issue12: > > " > There seems to be two concepts of node identity in > the base spec. > > 1. FQDN for indexing the peer table > 2. FQDN+port (+more) in redirect URI. > " > > AFACS, there is no problem here.The Host Identity in > peer table is of type > DiameterIdentity, whereas Redirect-Host AVP is of > type DiameterURI. This > makes sense to me, because one needs to know > transport/port in addition to > FQDN, to be able to establish a connection after an > asnwer with > DIAMETER_REDIRECT_INDICATION result code. If one > wants first to perform a > check in peer table based on Redirect-Host AVP > value, this is also possible > by extracting FQDN portion of it. > > Should this issue be closed with no action or am I > missing something? > > Thanks, > Tolga > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 01 11:52:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBcZ-0000Da-Ii; Fri, 01 Dec 2006 11:52:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBcZ-0000DV-1Y for dime@ietf.org; Fri, 01 Dec 2006 11:52:19 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBcX-0001yZ-OG for dime@ietf.org; Fri, 01 Dec 2006 11:52:19 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id EBA7D67ABE for ; Fri, 1 Dec 2006 11:52:13 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kB1GqCHW022371 for ; Fri, 1 Dec 2006 11:52:12 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] RFC3588bis Issue12 Date: Fri, 1 Dec 2006 11:49:26 -0500 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: <20061201163946.46739.qmail@web90404.mail.mud.yahoo.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Himanshu, > -----Original Message----- > From: himanshu bahl [mailto:hbahl52@yahoo.com] > Sent: Friday, December 01, 2006 11:40 AM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] RFC3588bis Issue12 > > > Hi Tolga, > can you please specify how has the following issue > been resolved. I`m unable to locate the thread for > that. [TOLGA]I guess the agreement was that there is no real issue here. The Redirect-Host AVP is of type DiameterURI, not of type DiameterIdentity. So, there is no conflict in the definition of types. > > and one more thing. > If a redirect agent replies with the redirectHost avp > value in the DiameterIdentity format instead of > diameterURI format is the message incorrect ? [TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN portion. So, I would think a Redirect-Host AVP with only a FQDN is valid. > > sincerely, > Himanshu. > http://thebahls.blogspot.com > > --- Tolga Asveren wrote: > > > >From issue tracker, Issue12: > > > > " > > There seems to be two concepts of node identity in > > the base spec. > > > > 1. FQDN for indexing the peer table > > 2. FQDN+port (+more) in redirect URI. > > " > > > > AFACS, there is no problem here.The Host Identity in > > peer table is of type > > DiameterIdentity, whereas Redirect-Host AVP is of > > type DiameterURI. This > > makes sense to me, because one needs to know > > transport/port in addition to > > FQDN, to be able to establish a connection after an > > asnwer with > > DIAMETER_REDIRECT_INDICATION result code. If one > > wants first to perform a > > check in peer table based on Redirect-Host AVP > > value, this is also possible > > by extracting FQDN portion of it. > > > > Should this issue be closed with no action or am I > > missing something? > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > __________________________________________________________________ > __________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 01 12:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCfg-0003eT-2U; Fri, 01 Dec 2006 12:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCfe-0003eN-PX for dime@ietf.org; Fri, 01 Dec 2006 12:59:34 -0500 Received: from web90409.mail.mud.yahoo.com ([216.252.100.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GqCfd-0007ZR-DG for dime@ietf.org; Fri, 01 Dec 2006 12:59:34 -0500 Received: (qmail 74280 invoked by uid 60001); 1 Dec 2006 17:59:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kEN9XkY8euHQnI+NCUhDzUDs43Alce4mAJQkA6P9JAhZ79I8uiHZ5BEZHysyf6xN3syfG+VBxJ0DVXFgcE0NL3iw6ZANZEgYEuOsYMCIjG0vrYtd8Q3RUcHNoh+Dsykim57Mrns9Vy7FjuRb58VeJ/KSoo4BT0ZFizr1BuX+q4s=; X-YMail-OSG: r59pPqEVM1knnV1BcKlXBoicBExM_seOcnTU53Y7.kKRkZJhUuHqHMQwA7mv.3c.7HvxxjRkbv7NnlMnURCpl2Nt1TpC5BfHHatIwDNSkzgF55Af2oM8tIipaNWAkIpALqDHxd1R5MifuBQuvPbfjEKvrWiwdLXaiw-- Received: from [203.187.132.67] by web90409.mail.mud.yahoo.com via HTTP; Fri, 01 Dec 2006 09:59:32 PST Date: Fri, 1 Dec 2006 09:59:32 -0800 (PST) From: himanshu bahl Subject: [Dime] issue regarding precedence of real routing table over peer table. To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <893991.74074.qm@web90409.mail.mud.yahoo.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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,
suppose if we have the a diameter node configured in
the realm routing table and another node configure in
the peer table but both in the same realm and the
application sends message with the only
destination-realm in the message. then which will be
given higher priority ? peer table or realm routing
table. also should we use application id for the
secondary key in this case ?

suppose we were to give realm routing table precedence
over peer table would that be a non compliance ?

sincerely,
Himanshu.
http://thebahls.blogspot.com
____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 01 13:11:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCrJ-0004tG-Aq; Fri, 01 Dec 2006 13:11:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCrI-0004t3-W7 for dime@ietf.org; Fri, 01 Dec 2006 13:11:36 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCrG-0002aj-8T for dime@ietf.org; Fri, 01 Dec 2006 13:11:36 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kB1IBQw3009624 for ; Fri, 1 Dec 2006 13:11:26 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB1IBKjE420188 for ; Fri, 1 Dec 2006 11:11:26 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB1IBKjT000558 for ; Fri, 1 Dec 2006 11:11:20 -0700 Received: from d03nm114.boulder.ibm.com (d03nm114.boulder.ibm.com [9.17.195.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB1IBKgD000549; Fri, 1 Dec 2006 11:11:20 -0700 In-Reply-To: To: "Tolga Asveren" Subject: RE: [Dime] RFC3588bis Issue12 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Timothy Smith Date: Fri, 1 Dec 2006 13:11:19 -0500 X-MIMETrack: Serialize by Router on D03NM114/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 12/01/2006 11:11:20, Serialize complete at 12/01/2006 11:11:20 X-Spam-Score: 0.1 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 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="===============0030075802==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0030075802== Content-Type: multipart/alternative; boundary="=_alternative 0063E9A285257237_=" This is a multipart message in MIME format. --=_alternative 0063E9A285257237_= Content-Type: text/plain; charset="US-ASCII" Hi Tolga, I'm not sure I come to the same conclusion on this: > and one more thing. > If a redirect agent replies with the redirectHost avp > value in the DiameterIdentity format instead of > diameterURI format is the message incorrect ? [TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN portion. So, I would think a Redirect-Host AVP with only a FQDN is valid. > My feeling is that if it is to be a URI format, then it must have the URI prefix as defined in the RFC: The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below: "aaa://" FQDN [ port ] [ transport ] [ protocol ] ; No transport security "aaas://" FQDN [ port ] [ transport ] [ protocol ] ; Transport security used FQDN = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (3868) is ; assumed. transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [SCTP] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. transport-protocol = ( "tcp" / "sctp" / "udp" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. aaa-protocol = ( "diameter" / "radius" / "tacacs+" ) The following are examples of valid Diameter host identities: aaa://host.example.com;transport=tcp aaa://host.example.com:6666;transport=tcp aaa://host.example.com;protocol=diameter aaa://host.example.com:6666;protocol=diameter aaa://host.example.com:6666;transport=tcp;protocol=diameter aaa://host.example.com:1813;transport=udp;protocol=radius A Redirect-Host AVPI with a value of simply "host.example.com" does not seem to be valid... Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Tolga Asveren" 12/01/2006 11:49 AM To cc Subject RE: [Dime] RFC3588bis Issue12 Hi Himanshu, > -----Original Message----- > From: himanshu bahl [mailto:hbahl52@yahoo.com] > Sent: Friday, December 01, 2006 11:40 AM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] RFC3588bis Issue12 > > > Hi Tolga, > can you please specify how has the following issue > been resolved. I`m unable to locate the thread for > that. [TOLGA]I guess the agreement was that there is no real issue here. The Redirect-Host AVP is of type DiameterURI, not of type DiameterIdentity. So, there is no conflict in the definition of types. > > and one more thing. > If a redirect agent replies with the redirectHost avp > value in the DiameterIdentity format instead of > diameterURI format is the message incorrect ? [TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN portion. So, I would think a Redirect-Host AVP with only a FQDN is valid. > > sincerely, > Himanshu. > http://thebahls.blogspot.com > > --- Tolga Asveren wrote: > > > >From issue tracker, Issue12: > > > > " > > There seems to be two concepts of node identity in > > the base spec. > > > > 1. FQDN for indexing the peer table > > 2. FQDN+port (+more) in redirect URI. > > " > > > > AFACS, there is no problem here.The Host Identity in > > peer table is of type > > DiameterIdentity, whereas Redirect-Host AVP is of > > type DiameterURI. This > > makes sense to me, because one needs to know > > transport/port in addition to > > FQDN, to be able to establish a connection after an > > asnwer with > > DIAMETER_REDIRECT_INDICATION result code. If one > > wants first to perform a > > check in peer table based on Redirect-Host AVP > > value, this is also possible > > by extracting FQDN portion of it. > > > > Should this issue be closed with no action or am I > > missing something? > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > __________________________________________________________________ > __________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --=_alternative 0063E9A285257237_= Content-Type: text/html; charset="US-ASCII"
Hi Tolga,

I'm not sure I come to the same conclusion on this:

> and one more thing.
> If a redirect agent replies with the redirectHost avp
> value in the DiameterIdentity format instead of
> diameterURI format is the message incorrect ?
[TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN
portion. So, I would think a Redirect-Host AVP with only a FQDN is valid.
>

My feeling is that if it is to be a URI format, then it must have the URI prefix as defined in the RFC:

      The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
      syntax [URI] rules specified below:

      "aaa://" FQDN [ port ] [ transport ] [ protocol ]

                      ; No transport security

      "aaas://" FQDN [ port ] [ transport ] [ protocol ]

                      ; Transport security used

      FQDN               = Fully Qualified Host Name

      port               = ":" 1*DIGIT

                      ; One of the ports used to listen for
                      ; incoming connections.
                      ; If absent,
                      ; the default Diameter port (3868) is
                      ; assumed.

      transport          = ";transport=" transport-protocol

                      ; One of the transports used to listen
                      ; for incoming connections.  If absent,
                      ; the default SCTP [SCTP] protocol is
                      ; assumed.  UDP MUST NOT be used when
                      ; the aaa-protocol field is set to
                      ; diameter.

      transport-protocol = ( "tcp" / "sctp" / "udp" )

      protocol           = ";protocol=" aaa-protocol

                      ; If absent, the default AAA protocol
                      ; is diameter.

      aaa-protocol       = ( "diameter" / "radius" / "tacacs+" )

      The following are examples of valid Diameter host identities:

      aaa://host.example.com;transport=tcp
      aaa://host.example.com:6666;transport=tcp
      aaa://host.example.com;protocol=diameter
      aaa://host.example.com:6666;protocol=diameter
      aaa://host.example.com:6666;transport=tcp;protocol=diameter
      aaa://host.example.com:1813;transport=udp;protocol=radius

A Redirect-Host AVPI with a value of simply "host.example.com" does not seem to be valid...

Best Regards,
Timothy Smith


tjsmith@us.ibm.com
(919) 254-4723


"Tolga Asveren" <asveren@ulticom.com>

12/01/2006 11:49 AM

To
<dime@ietf.org>
cc
Subject
RE: [Dime] RFC3588bis Issue12





Hi Himanshu,

> -----Original Message-----
> From: himanshu bahl [mailto:hbahl52@yahoo.com]
> Sent: Friday, December 01, 2006 11:40 AM
> To: Tolga Asveren; dime@ietf.org
> Subject: Re: [Dime] RFC3588bis Issue12
>
>
> Hi Tolga,
> can you please specify how has the following issue
> been resolved. I`m unable to locate the thread for
> that.
[TOLGA]I guess the agreement was that there is no real issue here. The
Redirect-Host AVP is of type DiameterURI, not of type DiameterIdentity. So,
there is no conflict in the definition of types.
>
> and one more thing.
> If a redirect agent replies with the redirectHost avp
> value in the DiameterIdentity format instead of
> diameterURI format is the message incorrect ?
[TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN
portion. So, I would think a Redirect-Host AVP with only a FQDN is valid.
>
> sincerely,
> Himanshu.
> http://thebahls.blogspot.com
>
> --- Tolga Asveren <asveren@ulticom.com> wrote:
>
> > >From issue tracker, Issue12:
> >
> > "
> > There seems to be two concepts of node identity in
> > the base spec.
> >
> > 1. FQDN for indexing the peer table
> > 2. FQDN+port (+more) in redirect URI.
> > "
> >
> > AFACS, there is no problem here.The Host Identity in
> > peer table is of type
> > DiameterIdentity, whereas Redirect-Host AVP is of
> > type DiameterURI. This
> > makes sense to me, because one needs to know
> > transport/port in addition to
> > FQDN, to be able to establish a connection after an
> > asnwer with
> > DIAMETER_REDIRECT_INDICATION result code. If one
> > wants first to perform a
> > check in peer table based on Redirect-Host AVP
> > value, this is also possible
> > by extracting FQDN portion of it.
> >
> > Should this issue be closed with no action or am I
> > missing something?
> >
> >     Thanks,
> >     Tolga
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
>
>
>
> __________________________________________________________________
> __________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--=_alternative 0063E9A285257237_=-- --===============0030075802== 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 --===============0030075802==-- From dime-bounces@ietf.org Fri Dec 01 13:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqD2i-0005sO-38; Fri, 01 Dec 2006 13:23:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqD2h-0005s7-QC for dime@ietf.org; Fri, 01 Dec 2006 13:23:23 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GqD2e-0004W9-9I for dime@ietf.org; Fri, 01 Dec 2006 13:23:21 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 1BCA8449E3; Fri, 1 Dec 2006 13:23:15 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kB1INDUi029509; Fri, 1 Dec 2006 13:23:14 -0500 (EST) From: "Tolga Asveren" To: "Timothy Smith" Subject: RE: [Dime] RFC3588bis Issue12 Date: Fri, 1 Dec 2006 13:20:27 -0500 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: 2bf730a014b318fd3efd65b39b48818c 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 Tim, Yes you are right. aaa(s):// must be there. Thanks, Tolga -----Original Message----- From: Timothy Smith [mailto:tjsmith@us.ibm.com] Sent: Friday, December 01, 2006 1:11 PM To: Tolga Asveren Cc: dime@ietf.org Subject: RE: [Dime] RFC3588bis Issue12 Hi Tolga, I'm not sure I come to the same conclusion on this: > and one more thing. > If a redirect agent replies with the redirectHost avp > value in the DiameterIdentity format instead of > diameterURI format is the message incorrect ? [TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN portion. So, I would think a Redirect-Host AVP with only a FQDN is valid. > My feeling is that if it is to be a URI format, then it must have the URI prefix as defined in the RFC: The DiameterURI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below: "aaa://" FQDN [ port ] [ transport ] [ protocol ] ; No transport security "aaas://" FQDN [ port ] [ transport ] [ protocol ] ; Transport security used FQDN = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (3868) is ; assumed. transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [SCTP] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. transport-protocol = ( "tcp" / "sctp" / "udp" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. aaa-protocol = ( "diameter" / "radius" / "tacacs+" ) The following are examples of valid Diameter host identities: aaa://host.example.com;transport=tcp aaa://host.example.com:6666;transport=tcp aaa://host.example.com;protocol=diameter aaa://host.example.com:6666;protocol=diameter aaa://host.example.com:6666;transport=tcp;protocol=diameter aaa://host.example.com:1813;transport=udp;protocol=radius A Redirect-Host AVPI with a value of simply "host.example.com" does not seem to be valid... Best Regards, Timothy Smith tjsmith@us.ibm.com (919) 254-4723 "Tolga Asveren" 12/01/2006 11:49 AM To cc SubjectRE: [Dime] RFC3588bis Issue12 Hi Himanshu, > -----Original Message----- > From: himanshu bahl [mailto:hbahl52@yahoo.com] > Sent: Friday, December 01, 2006 11:40 AM > To: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] RFC3588bis Issue12 > > > Hi Tolga, > can you please specify how has the following issue > been resolved. I`m unable to locate the thread for > that. [TOLGA]I guess the agreement was that there is no real issue here. The Redirect-Host AVP is of type DiameterURI, not of type DiameterIdentity. So, there is no conflict in the definition of types. > > and one more thing. > If a redirect agent replies with the redirectHost avp > value in the DiameterIdentity format instead of > diameterURI format is the message incorrect ? [TOLGA]I guess DiameterURI includes DiemterIdentity because it has a FQDN portion. So, I would think a Redirect-Host AVP with only a FQDN is valid. > > sincerely, > Himanshu. > http://thebahls.blogspot.com > > --- Tolga Asveren wrote: > > > >From issue tracker, Issue12: > > > > " > > There seems to be two concepts of node identity in > > the base spec. > > > > 1. FQDN for indexing the peer table > > 2. FQDN+port (+more) in redirect URI. > > " > > > > AFACS, there is no problem here.The Host Identity in > > peer table is of type > > DiameterIdentity, whereas Redirect-Host AVP is of > > type DiameterURI. This > > makes sense to me, because one needs to know > > transport/port in addition to > > FQDN, to be able to establish a connection after an > > asnwer with > > DIAMETER_REDIRECT_INDICATION result code. If one > > wants first to perform a > > check in peer table based on Redirect-Host AVP > > value, this is also possible > > by extracting FQDN portion of it. > > > > Should this issue be closed with no action or am I > > missing something? > > > > Thanks, > > Tolga > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > __________________________________________________________________ > __________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 04:22:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWVX-0007ey-U5; Tue, 05 Dec 2006 04:22:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWVW-0007et-Ld for dime@ietf.org; Tue, 05 Dec 2006 04:22:34 -0500 Received: from web90405.mail.mud.yahoo.com ([216.252.100.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrWVU-00054A-V3 for dime@ietf.org; Tue, 05 Dec 2006 04:22:34 -0500 Received: (qmail 32825 invoked by uid 60001); 5 Dec 2006 09:22:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=pBgx3L0z4oyT2w7UdqFVgc3fMysVzHZCIeiKQ70Hv5J9gg1DLz3u+m8fhQKofLh27UXNQw70G5cEWy79g576NmfphE1zx/rQcZNYVYB8PGlYwsWwyuMby3mJ0p/iLYoOx0u6xWRW0Q1uyxtXWZdtBlJSyPcM6f6gtvCMMsrs+XE=; X-YMail-OSG: WhUVyoQVM1nSVw1XWRw9KFVNaeaWixaFyEhpzSYfktfhqbmcX7SPhmyiwZLv0tRlkDTGBxtPtlqR417_BFklDgevA6BvlUXpotBmbtR5ZAtOE_ZkJFVEreuKhQVCLZnfg.24JFVzK71K300- Received: from [125.19.62.5] by web90405.mail.mud.yahoo.com via HTTP; Tue, 05 Dec 2006 01:22:29 PST Date: Tue, 5 Dec 2006 01:22:29 -0800 (PST) From: himanshu bahl To: Tolga Asveren , Timothy Smith In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <687498.32543.qm@web90405.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org Subject: [Dime] concern reagarding same host on both sides. 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 clerify me on this one. suppose we get the same host id on both sides . i.e on both peers we have host1.x.com for example. then what kind of processing are we supposed to do ? 1. will there be election lost hence an error code of 4003 ( Election lost) be returned on both sides.? 2. Will there be an error returned with code 5012 ( unable to comply ) ? 3. will the message be silently be discarded with no answer messages and connection will be torn down ? a fast reply will be helpfull. Sincerely, Himanshu. http://thebahls.blogspot.com ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 04:34:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWgm-00046q-Ot; Tue, 05 Dec 2006 04:34:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWgl-00045C-F1 for dime@ietf.org; Tue, 05 Dec 2006 04:34:11 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWgR-00006z-Mc for dime@ietf.org; Tue, 05 Dec 2006 04:34:11 -0500 Received: by wx-out-0506.google.com with SMTP id h27so4126140wxd for ; Tue, 05 Dec 2006 01:33:51 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=J6cIpFCYT/BH+LdyP1hmbimBqFaUUy0hDEbwjMfxe0Z71kU9xcH+BKRV5vnE5ckRf9UxuDVrYrnRKoLROUowex5+NLkFgvZGC8ARUrV62jGFy5eUk2ffLl49qWMBcNNjqvU/V0mlKJUBHDHYSNrLL4pPr6MJT7i5s37GKwJkv24= Received: by 10.70.19.20 with SMTP id 20mr17085465wxs.1165311231303; Tue, 05 Dec 2006 01:33:51 -0800 (PST) Received: by 10.70.21.7 with HTTP; Tue, 5 Dec 2006 01:33:51 -0800 (PST) Message-ID: <5e2406980612050133p7764a8e1udb8d7a42a66ab42@mail.gmail.com> Date: Tue, 5 Dec 2006 10:33:51 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <001701c714b1$e71294b0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> <001701c714b1$e71294b0$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 madjid, sorry for the late response On 11/30/06, Madjid Nakhjiri wrote: > Actually Julien, let me explain, The issue is that since you are decoupling > the authentication from authorization, during the authorization you have no > assurance that the client identity has actually been authenticated. One question is: is this really an issue ? > Things > that cause problem are when the AAA-MIP is different from AAA_EAP, Is this really a problem if the authorization server trust the HA ? > or if the > AAA server does not keep any authentication state (ok for Diameter), why is it a problem ? > or if > the client uses a different ID for authorization (we agreed that we should > not do this), or issues related to HA: > > 1) HA change is needed (e.g. keeping AAA_EAP ID, and other MN-authentication > state to send to AAA_MIP). Currently, we are saying that the HA needs to > keep state on the authentication. > > 2) HA must be trusted with its reporting (it does not fake an authentication > that never happened), so it does not launch DoS attacks on the AAA_MIP by > sending a lot of fake authorization requests. > > 3) HA is under attack itself, where its databases are manipulated. > > Now back to your options, I don't think you can sweep this under the rug. > This is probably the first place in the IETF where you are separating > authentication from authorization, so you will get a lot of scrutiny down > the road and you cannot ignore the security issues for the scenario you are > presenting (especially the separation of the AAA servers and service > providers). So option 1 is out. I think we should take the issue seriously. that's true that we are introducing a new scheme: we're decoupling the authorization from the authentication process. However, the HA is responsible of the binding. And yes I'm wondering if this is really a security issue. > > However, I don't think the solution you present in option 2 is needed. You > don't need new command modes, you simply need attributes that carry > information related to a previous authentication of the MN by the AAA-EAP > and this can be done by attributes. I'm not sure that "simply" is adequate here...if we need to add attributes to 4072 and define a token-based mechanism that would give a proof to the AAA-MIP6, i'm not sure that so simple. Julien > Please see my other email to Ahmad. > Yes, we need to find a way to carry the new attributes, and may be that has > to be through Diameter EAP, not sure, need to investigate. > > R, > > Madjid > > > > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Thursday, November 23, 2006 12:42 AM > To: Ahmad Muhanna > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > HI Ahmad, > > thanks a lot for your review. I respond to your proposal and try to > sum up a little our current situation with this highligting three > different ways to move forward. > > On 11/22/06, Ahmad Muhanna wrote: > > > > Hi all, > > > > The following is an idea that I would like to throw out as a possible > > solution: > > > > I believe the easiest way is for the HA to include an explicit attribute > > that the user has been authenticated successfully. This way, the > > AAAH-MIP6 have an explicit indication and record from the serving HA, > > regardless if it is in the Home or Visited Network. We may also require > > that the HA include the identity of the AAAH-EAP server which did the > > authentication. > > > > Comments: > > ?? > > hmm, the threat mentionned by madjid was that the HA is compromised > and uses a fake AAA-EAP server. In this case, the HA would be able to > send your proposed attribute. I'm not sure this solve the issue. > > Personnally, before solving this issue, I think we should agree or > not on the fact that it si effectivily an issue. The fact that we use > 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new > application for the Authorization/Accounting part was to avoid to > update all Diameter Application using EAP for Authentication if 4072 > has to be updated. As we define a new application for > Authorization/Accounting, we lost the binding between Authentication > and Authorization/Accounting at the AAA server. However, AAAH-EAP and > AAAH-MIP6 belong to the MSA and finally the HA is now responsible of > this binding. > > To move forward with this I see 3 options: > > 1/ We continue with the current approach and decide that this is not > an issue if the Authz/Acctg server has no "proof" that the user has > been authenticated. The HA is responsible for this. > > We consider that this is an issue. So we consider that the > Authz/Acctg need to be bound to the Authentication. Then we have 2 > options: > > 2/ We include DER/DEA messages in the MIP6 Application but define a > new command-code. An update of 4072 would certainly lead to an update > of this application. > > 3/ We define a generic mechanism that permits to give a proof to the > AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. > > Comments ? > > > Let me know if you see others options. > > Julien > > > > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Friday, November 10, 2006 6:26 PM > > > To: dime@ietf.org > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > > > Hi all, > > > > > > during the DIME meeting Glen raised an important question > > > that impacts the design of the protocol, namely: > > > " > > > Do we need to support the scenario where the Diameter EAP > > > authentication and the Diameter MIPv6 authorization exchange > > > terminate at different servers? > > > " > > > > > > Currently, we assume that these two exchanges could be > > > terminated at different servers. As a consequence, security > > > concerns were raised (see slide 5 of > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > > > How do people think about restricting the Diameter MIPv6 > > > HA-to-AAAH document to terminate the authentication and > > > authorization exchange at the same server? > > > > > > Ciao > > > Hannes > > > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > > App-ID for the Diameter EAP exchange if we decide that both > > > exchanges terminate at the same server. As a consequence the > > > open issue described at slide 6 of > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > would also be resolved. The changes to the existing document > > > would be minimal (about 2 additional sentences). > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 04:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWh8-0004ab-Mu; Tue, 05 Dec 2006 04:34:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWh7-0004aI-0B for dime@ietf.org; Tue, 05 Dec 2006 04:34:33 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWh5-00006z-M1 for dime@ietf.org; Tue, 05 Dec 2006 04:34:32 -0500 Received: by wx-out-0506.google.com with SMTP id h27so4126140wxd for ; Tue, 05 Dec 2006 01:34:31 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=NlmW4RwmBQ82vlMPyeCdOyR8sDj7d2osjRFn6bOKY4bztAIwvlyCY8Li7/AA1qyvRcjmHvQtsA6lIDF/ZoDwjQLi3VKsOyB7iMM9ryMBeH5+MTfbjo8SOYejA46up7IhEFvOd+mYkFMOjEkXaoBR9fZCX85XxUy/qhB8vVIZN5s= Received: by 10.70.80.14 with SMTP id d14mr17167741wxb.1165311271508; Tue, 05 Dec 2006 01:34:31 -0800 (PST) Received: by 10.70.21.7 with HTTP; Tue, 5 Dec 2006 01:34:31 -0800 (PST) Message-ID: <5e2406980612050134p68c67051uba144cc25f35688f@mail.gmail.com> Date: Tue, 5 Dec 2006 10:34:31 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <001801c714b2$05c4db70$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> <001801c714b2$05c4db70$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) 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 HI madjid, On 11/30/06, Madjid Nakhjiri wrote: > PS. I missed your 3rd option. I agree this can be a generic mechanism, but > not sure about the details, can you elaborate? I don't have the details. This should be investigated. Julien > > Madjid > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Thursday, November 23, 2006 12:42 AM > To: Ahmad Muhanna > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > HI Ahmad, > > thanks a lot for your review. I respond to your proposal and try to > sum up a little our current situation with this highligting three > different ways to move forward. > > On 11/22/06, Ahmad Muhanna wrote: > > > > Hi all, > > > > The following is an idea that I would like to throw out as a possible > > solution: > > > > I believe the easiest way is for the HA to include an explicit attribute > > that the user has been authenticated successfully. This way, the > > AAAH-MIP6 have an explicit indication and record from the serving HA, > > regardless if it is in the Home or Visited Network. We may also require > > that the HA include the identity of the AAAH-EAP server which did the > > authentication. > > > > Comments: > > ?? > > hmm, the threat mentionned by madjid was that the HA is compromised > and uses a fake AAA-EAP server. In this case, the HA would be able to > send your proposed attribute. I'm not sure this solve the issue. > > Personnally, before solving this issue, I think we should agree or > not on the fact that it si effectivily an issue. The fact that we use > 4072 in AUTHENTICATE_ONLY mode for Authentication and define a new > application for the Authorization/Accounting part was to avoid to > update all Diameter Application using EAP for Authentication if 4072 > has to be updated. As we define a new application for > Authorization/Accounting, we lost the binding between Authentication > and Authorization/Accounting at the AAA server. However, AAAH-EAP and > AAAH-MIP6 belong to the MSA and finally the HA is now responsible of > this binding. > > To move forward with this I see 3 options: > > 1/ We continue with the current approach and decide that this is not > an issue if the Authz/Acctg server has no "proof" that the user has > been authenticated. The HA is responsible for this. > > We consider that this is an issue. So we consider that the > Authz/Acctg need to be bound to the Authentication. Then we have 2 > options: > > 2/ We include DER/DEA messages in the MIP6 Application but define a > new command-code. An update of 4072 would certainly lead to an update > of this application. > > 3/ We define a generic mechanism that permits to give a proof to the > AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. > > Comments ? > > > Let me know if you see others options. > > Julien > > > > > > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Friday, November 10, 2006 6:26 PM > > > To: dime@ietf.org > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > > > > > Hi all, > > > > > > during the DIME meeting Glen raised an important question > > > that impacts the design of the protocol, namely: > > > " > > > Do we need to support the scenario where the Diameter EAP > > > authentication and the Diameter MIPv6 authorization exchange > > > terminate at different servers? > > > " > > > > > > Currently, we assume that these two exchanges could be > > > terminated at different servers. As a consequence, security > > > concerns were raised (see slide 5 of > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > > > How do people think about restricting the Diameter MIPv6 > > > HA-to-AAAH document to terminate the authentication and > > > authorization exchange at the same server? > > > > > > Ciao > > > Hannes > > > > > > PS: Glen also suggested to consider using the Diameter MIPv6 > > > App-ID for the Diameter EAP exchange if we decide that both > > > exchanges terminate at the same server. As a consequence the > > > open issue described at slide 6 of > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > would also be resolved. The changes to the existing document > > > would be minimal (about 2 additional sentences). > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 04:47:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWtf-0007yQ-LG; Tue, 05 Dec 2006 04:47:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrWte-0007yL-W6 for dime@ietf.org; Tue, 05 Dec 2006 04:47:30 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrWte-0004U3-Kk for dime@ietf.org; Tue, 05 Dec 2006 04:47:30 -0500 Received: by wx-out-0506.google.com with SMTP id h27so4129216wxd for ; Tue, 05 Dec 2006 01:47:28 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=ZKDg0goFVJuCSIaHxJEn3OuKDZGHVcjurOv4a6ImLbhdRDG0o8hPmooTjjmTfRwFyI7ZiKVv6oSziFhUID7znpvjHwPsAMM1xED37dqviJ2dqBn+RjG7GOgptXbgeSv/T4zwaI5mURtiHgLU9eItiCKQdeNEGkgi1+wZu34K44k= Received: by 10.70.50.10 with SMTP id x10mr17179561wxx.1165312048027; Tue, 05 Dec 2006 01:47:28 -0800 (PST) Received: by 10.70.21.7 with HTTP; Tue, 5 Dec 2006 01:47:27 -0800 (PST) Message-ID: <5e2406980612050147q3c82f009t557e483a255b72be@mail.gmail.com> Date: Tue, 5 Dec 2006 10:47:27 +0100 From: "Julien Bournelle" To: "Ahmad Muhanna" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111994AE2@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980611230042n642f6d7dua442db4e7839a4e9@mail.gmail.com> <6FC4416DDE56C44DA0AEE67BC7CA437111994AE2@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Ahmad, inline. On 11/23/06, Ahmad Muhanna wrote: > > hmm, the threat mentionned by madjid was that the HA is > > compromised and uses a fake AAA-EAP server. In this case, the > > HA would be able to send your proposed attribute. I'm not > > sure this solve the issue. > > [Ahmad] > I am not sure what the exact meaning and the extent of the HA being > compromised? (IMO) If the HA is compromised, why the HA needs > authorization from AAAH-MIP6 to start with. HA will be able to offer the > service without the need to contact the AAAH-MIP6 server. yes you're right. That's one of the reason i'm wondering if we really need to inform the authorization server that the authentication is ok. > > On the other hand, we probably should come up with a mechanism which > allows the HA to communicate both Authentication and authorization to > the same server. basically this can be done by configuration. > > Personnally, before solving this issue, I think we should > > agree or not on the fact that it si effectivily an issue. The > > fact that we use > > 4072 in AUTHENTICATE_ONLY mode for Authentication and define > > a new application for the Authorization/Accounting part was > > to avoid to update all Diameter Application using EAP for > > Authentication if 4072 has to be updated. As we define a new > > application for Authorization/Accounting, we lost the binding > > between Authentication and Authorization/Accounting at the > > AAA server. However, AAAH-EAP and > > AAAH-MIP6 belong to the MSA and finally the HA is now > > responsible of this binding. > > > > To move forward with this I see 3 options: > > > > 1/ We continue with the current approach and decide that > > this is not an issue if the Authz/Acctg server has no "proof" > > that the user has been authenticated. The HA is responsible for this. > > > > [Ahmad] > It is ok as long as the HA include something to indicate that the user > has been authenticated. > Possibly: HA include an attribute to indicate > that user have been authenticated and/or the identity of the AAAH-EAP > server which done the authentication. At least there will be some record > that HA has communicated that. Especially when HA is in the visited > network. what is the goal of this indication ? > > > We consider that this is an issue. So we consider that the > > Authz/Acctg need to be bound to the Authentication. Then we have 2 > > options: > > > > 2/ We include DER/DEA messages in the MIP6 Application but > > define a new command-code. An update of 4072 would certainly > > lead to an update of this application. > > [Ahmad] > Basically this option assumes that the same AAAH server support > authentication and authorization. Right? yes. It would be the same application and we won't need anymore specific authorization messages. > What about if we think of a mechanism that allows the HA to send the MAR > to the same AAAH which done EAP authentication and at the same time it > supports AAAH-MIP6. This way we avoid the update for the existing RFC > and at the same time guarantee that the same server does both > operations. the problem is the AAA routing. Let me know if I'm wrong but if we use different application-id code, we are not sure that AAA messages will hit the same AAA server. > > Here I am throwing a couple of thoughts: > > Option 1: > 1. Mandating that AAAH server which support EAP to support MIP6 > Authorization. > 2. Then HA always sends the MAR to the same server which done the EAP > authentication via the AAAH-EAP identity. > > Option 2 (this gives more flexibility): > 1. HA and/or proxy Diameter server should track Diameter servers which > support both EAP and MIP6 Authorization during capabilities exchange. > 2. HA and/or Proxy Diameter Server should forward the EAP authentication > to a server that support both EAP authentication + MIP6 authorization. > 3. HA sends the MIP6 Authorization request (MAR) to the same AAAH-EAP > server which performed the EAP authentication. > > Comments ? I fear it would add complexity in proxy agents. What do others think ? Julien > > > > > 3/ We define a generic mechanism that permits to give a proof to the > > AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. > > [Ahmad] > If we agree on one of the options above, then this is already addressed. > > > > > Comments ? > > > > > > Let me know if you see others options. > > > > Julien > > > > > > > > > > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Friday, November 10, 2006 6:26 PM > > > > To: dime@ietf.org > > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server > > > > Split > > > > > > > > Hi all, > > > > > > > > during the DIME meeting Glen raised an important question that > > > > impacts the design of the protocol, namely: > > > > " > > > > Do we need to support the scenario where the Diameter EAP > > > > authentication and the Diameter MIPv6 authorization exchange > > > > terminate at different servers? > > > > " > > > > > > > > Currently, we assume that these two exchanges could be > > terminated at > > > > different servers. As a consequence, security concerns > > were raised > > > > (see slide 5 of > > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > > > > > How do people think about restricting the Diameter MIPv6 > > HA-to-AAAH > > > > document to terminate the authentication and > > authorization exchange > > > > at the same server? > > > > > > > > Ciao > > > > Hannes > > > > > > > > PS: Glen also suggested to consider using the Diameter > > MIPv6 App-ID > > > > for the Diameter EAP exchange if we decide that both exchanges > > > > terminate at the same server. As a consequence the open issue > > > > described at slide 6 of > > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > > would also be resolved. The changes to the existing > > document would > > > > be minimal (about 2 additional sentences). > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 10:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrchY-0001YR-WB; Tue, 05 Dec 2006 10:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrchW-0001Us-W0 for dime@ietf.org; Tue, 05 Dec 2006 10:59:23 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrchV-0007We-MW for dime@ietf.org; Tue, 05 Dec 2006 10:59:22 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB5FxI826428; Tue, 5 Dec 2006 10:59:19 -0500 (EST) Received: from [47.130.17.253] ([47.130.17.253] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 10:59:00 -0500 Message-ID: <45759736.3050105@nortel.com> Date: Tue, 05 Dec 2006 10:58:46 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hannes Tschofenig References: <455CC1A7.7000601@gmx.net> In-Reply-To: <455CC1A7.7000601@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2006 15:59:00.0796 (UTC) FILETIME=[47856FC0:01C71886] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dime@ietf.org Subject: [Dime] Re: Input for Diameter Test Cases 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 MultiService Forum (MSF) is working through their liaison process. We should have the material to you in two to three weeks. Hannes Tschofenig wrote: > Hi Tom, > > during the DIME meeting you mentioned that you could provide us with > some test cases (collected from another interop event). > > Ciao > Hannes > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 11:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrclY-0002Sg-5t; Tue, 05 Dec 2006 11:03:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrclX-0002SY-Kd for dime@ietf.org; Tue, 05 Dec 2006 11:03:31 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrclS-0005ng-Jg for dime@ietf.org; Tue, 05 Dec 2006 11:03:31 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kB5G3MgE005921; Tue, 5 Dec 2006 17:03:22 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id kB5G3M7t024031; Tue, 5 Dec 2006 17:03:22 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.165]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 17:03:22 +0100 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: AW: [Dime] Re: Input for Diameter Test Cases Date: Tue, 5 Dec 2006 17:03:23 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC023232E8@MCHP7R6A.ww002.siemens.net> In-Reply-To: <45759736.3050105@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: Input for Diameter Test Cases Thread-Index: AccYhpNGbbDma31iQtOW2lkgFaNFqAAABiqg From: "Tschofenig, Hannes" To: "Tom-PT Taylor" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Dec 2006 16:03:22.0423 (UTC) FILETIME=[E3768C70:01C71886] 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 Thanks Tom.=20 We are looking forward to inspect the input.=20 In the meanwhile we need to work on the test cases. Would you like to = give us some feedback? Here is the current draft version:=20 http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-= 02.txt=20 I have created a Wiki page to collect information.=20 Ciao Hannes=20 -----Urspr=FCngliche Nachricht----- Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 Gesendet: Dienstag, 5. Dezember 2006 16:59 An: Hannes Tschofenig Cc: dime@ietf.org Betreff: [Dime] Re: Input for Diameter Test Cases The MultiService Forum (MSF) is working through their liaison process.=20 We should have the material to you in two to three weeks. Hannes Tschofenig wrote: > Hi Tom, >=20 > during the DIME meeting you mentioned that you could provide us with=20 > some test cases (collected from another interop event). >=20 > Ciao > Hannes >=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 Dec 05 16:03:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhRN-0003tI-P5; Tue, 05 Dec 2006 16:03:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrhRM-0003sJ-1U; Tue, 05 Dec 2006 16:03:00 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GrhR8-00058q-PF; Tue, 05 Dec 2006 16:02:59 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 16:02:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Dec 2006 16:02:41 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49F4@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consideration of draft-lior-radius-attribute-type-extension-01 in RADEXT WG Thread-Index: AccYsLOR0FxEg7QgQhip5ojm8f5C0Q== From: "Nelson, David" To: , X-OriginalArrivalTime: 05 Dec 2006 21:02:41.0415 (UTC) FILETIME=[B3DB4170:01C718B0] X-imss-version: 2.044 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org Subject: [Dime] Consideration of draft-lior-radius-attribute-type-extension-01 in RADEXT WG 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 RADEXT WG has a charter deliverable for an extended form of RADIUS attribute. The apparent consensus in the WG is to solve a very simple set of problems in this space, including the pending exhaustion of the standard RADIUS attribute IDs, a consistent mechanism for application layer fragmentation and reassembly for Diameter interoperability, and a consistent mechanism for grouping of attributes for data structuring, also for Diameter interoperability. Given the list of proposed work in RADEXT and other IETF WGs with RADIUS extensions work on their charters, it is conceivable that we might exhaust the existing IANA RADIUS registry for Attribute Types fairly soon. Therefore, this work is considered to be of some urgency. The structure of the extended attribute format currently under consideration may require changes in various RADIUS extensions drafts in RADEXT and other working groups. This assumes that at least some of these documents will ultimately use the RADIUS extended attribute allocations. The RADEXT WG Chairs are requesting that the RADEXT WG and all other affected WGs please review the following document: http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-01.txt Please comment as to whether this document is ready for adoption as a RADEXT WG work item, and provide comments as to suggested changes or improvements. Please use the RADEXT Issue Tracker format template, found at http://www.drizzle.com/~aboba/RADEXT/ and submit your comments to the RADEXT WG mailing list with the keyword "New Issue" in the subject header. radiusext@ops.ietf.org Please respond by December 22, 2006. Once all the resultant open issues have been resolved, the RADEXT WG Chairs expect that a WGLC will be issued on the revised draft soon thereafter, early in 2007. Thank you, in advance, for your timely review, especially during this busy holiday season. Regards, =20 Dave Nelson Bernard Aboba Co-Chairs, RADEXT WG _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 21:56:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grmx0-0005Mn-AZ; Tue, 05 Dec 2006 21:56:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grmx0-0005Mg-12 for dime@ietf.org; Tue, 05 Dec 2006 21:56:02 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grmwq-0008QV-6J for dime@ietf.org; Tue, 05 Dec 2006 21:56:02 -0500 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 <0J9T009NJZYIEN@szxga03-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 10:51: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 <0J9T00879ZYHGZ@szxga03-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 10:51:54 +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 <0J9T006DAZYEW4@szxml04-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 10:51:53 +0800 (CST) Date: Wed, 06 Dec 2006 10:51:50 +0800 From: Tony Zhang Subject: RE: [Dime] Re: Input for Diameter Test Cases In-reply-to: <6F0CB04509C11D46A54232E852E390AC023232E8@MCHP7R6A.ww002.siemens.net> To: "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' Message-id: <003901c718e1$7a99b370$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: AccYhpNGbbDma31iQtOW2lkgFaNFqAAABiqgABXCxzA= 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 All I suggest add test cases: (1)Use DWR/DWA detect connection status. (2)Routing based on longest-match-from-the-right on the realm = rather than requiring an exact match. =20 (3)For Redirect,the loop maybe happen, should test it? (4)Routing should test default route entry? (5)For connection ,should test more Negative test?like no = response.no CER etc? Thanks! Tony -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Wednesday, December 06, 2006 12:03 AM To: Tom-PT Taylor; Hannes Tschofenig Cc: dime@ietf.org Subject: AW: [Dime] Re: Input for Diameter Test Cases Thanks Tom.=20 We are looking forward to inspect the input.=20 In the meanwhile we need to work on the test cases. Would you like to = give us some feedback? Here is the current draft version:=20 http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-= 02.txt=20 I have created a Wiki page to collect information.=20 Ciao Hannes=20 -----Urspr=C3=BCngliche Nachricht----- Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 Gesendet: Dienstag, 5. Dezember 2006 16:59 An: Hannes Tschofenig Cc: dime@ietf.org Betreff: [Dime] Re: Input for Diameter Test Cases The MultiService Forum (MSF) is working through their liaison process.=20 We should have the material to you in two to three weeks. Hannes Tschofenig wrote: > Hi Tom, >=20 > during the DIME meeting you mentioned that you could provide us with=20 > some test cases (collected from another interop event). >=20 > Ciao > Hannes >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 05 22:11:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrnBj-0003xV-Js; Tue, 05 Dec 2006 22:11:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrnBi-0003xJ-0l for dime@ietf.org; Tue, 05 Dec 2006 22:11:14 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrnBg-0003JC-EJ for dime@ietf.org; Tue, 05 Dec 2006 22:11:14 -0500 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 <0J9U008T80T3NC@szxga01-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 11:10:15 +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 <0J9U0093C0T3OV@szxga01-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 11:10:15 +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 <0J9U006SI0T0W4@szxml04-in.huawei.com> for dime@ietf.org; Wed, 06 Dec 2006 11:10:15 +0800 (CST) Date: Wed, 06 Dec 2006 11:10:12 +0800 From: Tony Zhang Subject: RE: [Dime] Re: Input for Diameter Test Cases In-reply-to: <6F0CB04509C11D46A54232E852E390AC023232E8@MCHP7R6A.ww002.siemens.net> To: "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' Message-id: <003c01c718e4$0b4e4f00$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: AccYhpNGbbDma31iQtOW2lkgFaNFqAAABiqgABdTvcA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 suggest add test cases: (1)Use DWR/DWA detect connection status. (2)Routing based on longest-match-from-the-right on the realm rather than requiring an exact match. (3)For Redirect,the loop maybe happen, should test it? (4)Routing should test default route entry? (5)For connection ,should test more Negative test?like no response.no CER etc? Thanks! Tony _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 00:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAu-00088e-MO; Wed, 06 Dec 2006 00:18:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAt-00088D-3R for dime@ietf.org; Wed, 06 Dec 2006 00:18:31 -0500 Received: from web90410.mail.mud.yahoo.com ([216.252.100.162]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrpAo-0006OP-Mu for dime@ietf.org; Wed, 06 Dec 2006 00:18:31 -0500 Received: (qmail 65460 invoked by uid 60001); 6 Dec 2006 05:18:26 -0000 Message-ID: <20061206051826.65458.qmail@web90410.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Cj4EigXpPCQp7UgRgk84Qhx9tWVO2Is8F/9rowTc74X3zFmOSVIC/k9JW2e4Ao4W/2gPPf/+kvHRW/vbMFTtNiZrfRShz5kqvCLBw0SnD7BU20xjK6UFARqu2tB1obQGIzwbNxjeKtdejldgz7ah68mPghxZJ2pwHYtfsHnGiqI=; X-YMail-OSG: 1YsvTvoVM1kQb9IbeK6mc.nfRKecumcHYgl6L4vbtenCwqjwJZ.Jd7b722oYGI3HxCle3f.gFBBP5_1LAmXoEbufuQj5.lAJXkhLKGkfJropqDAw8O9PsQ-- Received: from [125.19.62.5] by web90410.mail.mud.yahoo.com via HTTP; Tue, 05 Dec 2006 21:18:26 PST Date: Tue, 5 Dec 2006 21:18:26 -0800 (PST) From: himanshu bahl To: Tony Zhang , "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' In-Reply-To: <003901c718e1$7a99b370$6291460a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dime@ietf.org Subject: [Dime] regarding test case in interop doc for same host on both sides 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 have asked this before also. please clarify me on this one. suppose we get the same host id on both sides . i.e on both peers we have host1.x.com for example. then what kind of processing are we supposed to do ? 1. will there be election lost hence an error code of 4003 ( Election lost) be returned on both sides.? 2. Will there be an error returned with code 5012 (unable to comply ) ? 3. will the message be silently be discarded with no answer messages and connection will be torn down ? a fast reply will be help full. Sincerely, Himanshu. http://thebahls.blogspot.com --- Tony Zhang wrote: > Hi All > I suggest add test cases: > (1)Use DWR/DWA detect connection status. > (2)Routing based on > longest-match-from-the-right on the realm > rather than requiring an exact match. > (3)For Redirect,the loop maybe happen, should > test it? > (4)Routing should test default route entry? > (5)For connection ,should test more Negative > test?like no response.no CER etc? > Thanks! > Tony > > -----Original Message----- > From: Tschofenig, Hannes > [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, December 06, 2006 12:03 AM > To: Tom-PT Taylor; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Re: Input for Diameter Test > Cases > > Thanks Tom. > > We are looking forward to inspect the input. > > In the meanwhile we need to work on the test cases. > Would you like to give us some feedback? Here is the > current draft version: > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-02.txt > > >From dime-bounces@ietf.org Wed Dec 06 00:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAu-00088e-MO; Wed, 06 Dec 2006 00:18:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAt-00088D-3R for dime@ietf.org; Wed, 06 Dec 2006 00:18:31 -0500 Received: from web90410.mail.mud.yahoo.com ([216.252.100.162]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrpAo-0006OP-Mu for dime@ietf.org; Wed, 06 Dec 2006 00:18:31 -0500 Received: (qmail 65460 invoked by uid 60001); 6 Dec 2006 05:18:26 -0000 Message-ID: <20061206051826.65458.qmail@web90410.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Cj4EigXpPCQp7UgRgk84Qhx9tWVO2Is8F/9rowTc74X3zFmOSVIC/k9JW2e4Ao4W/2gPPf/+kvHRW/vbMFTtNiZrfRShz5kqvCLBw0SnD7BU20xjK6UFARqu2tB1obQGIzwbNxjeKtdejldgz7ah68mPghxZJ2pwHYtfsHnGiqI=; X-YMail-OSG: 1YsvTvoVM1kQb9IbeK6mc.nfRKecumcHYgl6L4vbtenCwqjwJZ.Jd7b722oYGI3HxCle3f.gFBBP5_1LAmXoEbufuQj5.lAJXkhLKGkfJropqDAw8O9PsQ-- Received: from [125.19.62.5] by web90410.mail.mud.yahoo.com via HTTP; Tue, 05 Dec 2006 21:18:26 PST Date: Tue, 5 Dec 2006 21:18:26 -0800 (PST) From: himanshu bahl To: Tony Zhang , "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' In-Reply-To: <003901c718e1$7a99b370$6291460a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dime@ietf.org Subject: [Dime] regarding test case in interop doc for same host on both sides 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 have asked this before also. please clarify me on this one. suppose we get the same host id on both sides . i.e on both peers we have host1.x.com for example. then what kind of processing are we supposed to do ? 1. will there be election lost hence an error code of 4003 ( Election lost) be returned on both sides.? 2. Will there be an error returned with code 5012 (unable to comply ) ? 3. will the message be silently be discarded with no answer messages and connection will be torn down ? a fast reply will be help full. Sincerely, Himanshu. http://thebahls.blogspot.com --- Tony Zhang wrote: > Hi All > I suggest add test cases: > (1)Use DWR/DWA detect connection status. > (2)Routing based on > longest-match-from-the-right on the realm > rather than requiring an exact match. > (3)For Redirect,the loop maybe happen, should > test it? > (4)Routing should test default route entry? > (5)For connection ,should test more Negative > test?like no response.no CER etc? > Thanks! > Tony > > -----Original Message----- > From: Tschofenig, Hannes > [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, December 06, 2006 12:03 AM > To: Tom-PT Taylor; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Re: Input for Diameter Test > Cases > > Thanks Tom. > > We are looking forward to inspect the input. > > In the meanwhile we need to work on the test cases. > Would you like to give us some feedback? Here is the > current draft version: > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-02.txt > > > I have created a Wiki page to collect information. > > Ciao > Hannes > > -----Ursprüngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Dienstag, 5. Dezember 2006 16:59 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: [Dime] Re: Input for Diameter Test Cases > > The MultiService Forum (MSF) is working through > their liaison process. > We should have the material to you in two to three > weeks. > > Hannes Tschofenig wrote: > > Hi Tom, > > > > during the DIME meeting you mentioned that you > could provide us with > > some test cases (collected from another interop > event). > > > > 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 > ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 00:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAt-00088I-IS; Wed, 06 Dec 2006 00:18:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAs-000885-NM for dime@ietf.org; Wed, 06 Dec 2006 00:18:30 -0500 Received: from web90408.mail.mud.yahoo.com ([216.252.100.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrpAo-0006OO-Al for dime@ietf.org; Wed, 06 Dec 2006 00:18:30 -0500 Received: (qmail 11060 invoked by uid 60001); 6 Dec 2006 05:18:25 -0000 Message-ID: <20061206051825.11058.qmail@web90408.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nkTDBjHNrBU4cLs+yKo1OiXJrY1cu7Voe/xXP9/vtQ2vtoYu43irzoxiRtrJngVIvu5aEOq0/8jP7obcsNMpZmJrGkcGXvILvRaPBmT9ZcPQ78InuLtnkApSk58LxZtIchm/iAkUSHOkcotm5NjOyv4wdwV5zIlW/gnAZe+By/Y=; X-YMail-OSG: o0vVINEVM1n0lFmZbz4wDER5xJzplyjdidbpoq1eJ9iHFM6uUycZMwNMI48Lq1mBYZUyZ4A_vkcnwNlQzCsCXnD2S7W6.Dfps3g_UqEpnugoExS_QM_0kWeIiWRdiSQiYK7oWDw8eQf4hd0- Received: from [125.19.62.5] by web90408.mail.mud.yahoo.com via HTTP; Tue, 05 Dec 2006 21:18:25 PST Date: Tue, 5 Dec 2006 21:18:25 -0800 (PST) From: himanshu bahl To: Tony Zhang , "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' In-Reply-To: <003901c718e1$7a99b370$6291460a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dime@ietf.org Subject: [Dime] regarding test case in interop doc for same host on both sides 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 have asked this before also. please clarify me on this one. suppose we get the same host id on both sides . i.e on both peers we have host1.x.com for example. then what kind of processing are we supposed to do ? 1. will there be election l I have created a Wiki page to collect information. > > Ciao > Hannes > > -----Ursprüngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Dienstag, 5. Dezember 2006 16:59 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: [Dime] Re: Input for Diameter Test Cases > > The MultiService Forum (MSF) is working through > their liaison process. > We should have the material to you in two to three > weeks. > > Hannes Tschofenig wrote: > > Hi Tom, > > > > during the DIME meeting you mentioned that you > could provide us with > > some test cases (collected from another interop > event). > > > > 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 > ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 00:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAt-00088I-IS; Wed, 06 Dec 2006 00:18:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrpAs-000885-NM for dime@ietf.org; Wed, 06 Dec 2006 00:18:30 -0500 Received: from web90408.mail.mud.yahoo.com ([216.252.100.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrpAo-0006OO-Al for dime@ietf.org; Wed, 06 Dec 2006 00:18:30 -0500 Received: (qmail 11060 invoked by uid 60001); 6 Dec 2006 05:18:25 -0000 Message-ID: <20061206051825.11058.qmail@web90408.mail.mud.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nkTDBjHNrBU4cLs+yKo1OiXJrY1cu7Voe/xXP9/vtQ2vtoYu43irzoxiRtrJngVIvu5aEOq0/8jP7obcsNMpZmJrGkcGXvILvRaPBmT9ZcPQ78InuLtnkApSk58LxZtIchm/iAkUSHOkcotm5NjOyv4wdwV5zIlW/gnAZe+By/Y=; X-YMail-OSG: o0vVINEVM1n0lFmZbz4wDER5xJzplyjdidbpoq1eJ9iHFM6uUycZMwNMI48Lq1mBYZUyZ4A_vkcnwNlQzCsCXnD2S7W6.Dfps3g_UqEpnugoExS_QM_0kWeIiWRdiSQiYK7oWDw8eQf4hd0- Received: from [125.19.62.5] by web90408.mail.mud.yahoo.com via HTTP; Tue, 05 Dec 2006 21:18:25 PST Date: Tue, 5 Dec 2006 21:18:25 -0800 (PST) From: himanshu bahl To: Tony Zhang , "'Tschofenig, Hannes'" , 'Tom-PT Taylor' , 'Hannes Tschofenig' In-Reply-To: <003901c718e1$7a99b370$6291460a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: dime@ietf.org Subject: [Dime] regarding test case in interop doc for same host on both sides 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 have asked this before also. please clarify me on this one. suppose we get the same host id on both sides . i.e on both peers we have host1.x.com for example. then what kind of processing are we supposed to do ? 1. will there be election lost hence an error code of 4003 ( Election lost) be returned on both sides.? 2. Will there be an error returned with code 5012 (unable to comply ) ? 3. will the message be silently be discarded with no answer messages and connection will be torn down ? a fast reply will be help full. Sincerely, Himanshu. http://thebahls.blogspot.com --- Tony Zhang wrote: > Hi All > I suggest add test cases: > (1)Use DWR/DWA detect connection status. > (2)Routing based on > longest-match-from-the-right on the realm > rather than requiring an exact match. > (3)For Redirect,the loop maybe happen, should > test it? > (4)Routing should test default route entry? > (5)For connection ,should test more Negative > test?like no response.no CER etc? > Thanks! > Tony > > -----Original Message----- > From: Tschofenig, Hannes > [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, December 06, 2006 12:03 AM > To: Tom-PT Taylor; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Re: Input for Diameter Test > Cases > > Thanks Tom. > > We are looking forward to inspect the input. > > In the meanwhile we need to work on the test cases. > Would you like to give us some feedback? Here is the > current draft version: > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-02.txt > > > I have created a Wiki page to collect information. > > Ciao > Hannes > > -----Ursprüngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Dienstag, 5. Dezember 2006 16:59 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: [Dime] Re: Input for Diameter Test Cases > > The MultiService Forum (MSF) is working through > their liaison process. > We should have the material to you in two to three > weeks. > > Hannes Tschofenig wrote: > > Hi Tom, > > > > during the DIME meeting you mentioned that you > could provide us with > > some test cases (collected from another interop > event). > > > > 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 > ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ost hence an error code of 4003 ( Election lost) be returned on both sides.? 2. Will there be an error returned with code 5012 (unable to comply ) ? 3. will the message be silently be discarded with no answer messages and connection will be torn down ? a fast reply will be help full. Sincerely, Himanshu. http://thebahls.blogspot.com --- Tony Zhang wrote: > Hi All > I suggest add test cases: > (1)Use DWR/DWA detect connection status. > (2)Routing based on > longest-match-from-the-right on the realm > rather than requiring an exact match. > (3)For Redirect,the loop maybe happen, should > test it? > (4)Routing should test default route entry? > (5)For connection ,should test more Negative > test?like no response.no CER etc? > Thanks! > Tony > > -----Original Message----- > From: Tschofenig, Hannes > [mailto:hannes.tschofenig@siemens.com] > Sent: Wednesday, December 06, 2006 12:03 AM > To: Tom-PT Taylor; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Re: Input for Diameter Test > Cases > > Thanks Tom. > > We are looking forward to inspect the input. > > In the meanwhile we need to work on the test cases. > Would you like to give us some feedback? Here is the > current draft version: > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-02.txt > > > I have created a Wiki page to collect information. > > Ciao > Hannes > > -----Ursprüngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Dienstag, 5. Dezember 2006 16:59 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: [Dime] Re: Input for Diameter Test Cases > > The MultiService Forum (MSF) is working through > their liaison process. > We should have the material to you in two to three > weeks. > > Hannes Tschofenig wrote: > > Hi Tom, > > > > during the DIME meeting you mentioned that you > could provide us with > > some test cases (collected from another interop > event). > > > > 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 > ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 05:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruCN-0007es-8b; Wed, 06 Dec 2006 05:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruCL-0007e9-Ks for dime@ietf.org; Wed, 06 Dec 2006 05:40:21 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruCH-0002AI-Ch for dime@ietf.org; Wed, 06 Dec 2006 05:40:21 -0500 Received: (qmail invoked by alias); 06 Dec 2006 10:40:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp041) with SMTP; 06 Dec 2006 11:40:14 +0100 X-Authenticated: #29516787 Message-ID: <45769E0D.7050203@gmx.net> Date: Wed, 06 Dec 2006 11:40:13 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Dime] DIME Wiki Pages 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 have setup a Wiki to collect information about the DIME working group. Please take a look at: http://www.tschofenig.priv.at/twiki/bin/view/Dime/WebHome Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 05:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruDG-0007mr-MK; Wed, 06 Dec 2006 05:41:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruDF-0007mk-3c for dime@ietf.org; Wed, 06 Dec 2006 05:41:17 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruDD-0002Fb-Mp for dime@ietf.org; Wed, 06 Dec 2006 05:41:17 -0500 Received: (qmail invoked by alias); 06 Dec 2006 10:41:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp017) with SMTP; 06 Dec 2006 11:41:14 +0100 X-Authenticated: #29516787 Message-ID: <45769E4A.8010706@gmx.net> Date: Wed, 06 Dec 2006 11:41:14 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Dime] Diameter Interop Update 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, we have setup a Wiki page for the Diameter Interop preparation. Please find it here: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DiameterInterop2007 To modify the Wiki page use the following credentials: Username: DimeGroup Passwd: dime If you hit the 'edit' button then you will be asked to perform a log in. Alternatively, you can also use the 'log in' button. Decisions to be made NOW: * Exact date * Test specifications * Participants Please incorporate your info into the Wiki page to make the interop organization easier. Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 05:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruF1-0008Sg-M1; Wed, 06 Dec 2006 05:43:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruF0-0008SX-7O for dime@ietf.org; Wed, 06 Dec 2006 05:43:06 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruEy-0002MM-QA for dime@ietf.org; Wed, 06 Dec 2006 05:43:06 -0500 Received: (qmail invoked by alias); 06 Dec 2006 10:43:03 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp004) with SMTP; 06 Dec 2006 11:43:03 +0100 X-Authenticated: #29516787 Message-ID: <45769EB6.60603@gmx.net> Date: Wed, 06 Dec 2006 11:43:02 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Dime] Milestone Update / Rechartering 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, as stated at the last IETF meeting we need to discuss a milestone update in relationship with a rechartering activity. If you look at the DIME charter page (see http://www.ietf.org/html.charters/dime-charter.html) then you will find the following: Mar 2006 Submit Diameter API to IESG as an information RFC May 2006 Submit Diameter URI to IESG as an information RFC Sep 2006 Submit Diameter QoS Application to IESG as a Proposed Standard Sep 2006 Submit Diameter Application Design Guidelines to IESG as an informational RFC Jan 2007 Submit Diameter Base to IESG as a Draft Standard The WGLC for the Diameter API draft finished and the draft will be forwarded to the IESG (together with a PROTO writeup). As suggested during the last meeting we will remove the Diameter URI charter item. The chairs will interact with IANA to get the problem fixed. We need to update the charter items for the subsequent items to reflect reality. Here is a proposal: July 2007: Submit Diameter QoS Application to IESG as a Proposed Standard Sep 2007: Submit Diameter Application Design Guidelines to IESG as an informational RFC July 2007: Submit Diameter Base to IESG as a Draft Standard Aug 2007: Submit Diameter Mobility to IESG as a Draft Standard As you might have the Diameter Mobility work was, for whatever reason, not listed in the milestones. As soon as we get some work accomplished we might also think about adding new work. We saw a lot of contributions for new work and it would be useful todo some ranking. Please let us know what you feel about some of the submitted documents. The document authors might actually want to make it easier for the group by letting us know what their plans regarding some of their documents actually are. From the feedback we received at the last two DIME meetings we have seen at least some interest in the Diameter Auditing work. Comments? Deadline for providing input (regarding the milestone update): 18th December 2006 Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 05:43:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruFW-00019e-Tr; Wed, 06 Dec 2006 05:43:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruFV-00019Y-8F for dime@ietf.org; Wed, 06 Dec 2006 05:43:37 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruFT-0002Pd-W0 for dime@ietf.org; Wed, 06 Dec 2006 05:43:37 -0500 Received: (qmail invoked by alias); 06 Dec 2006 10:43:35 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp007) with SMTP; 06 Dec 2006 11:43:35 +0100 X-Authenticated: #29516787 Message-ID: <45769ED6.3090008@gmx.net> Date: Wed, 06 Dec 2006 11:43:34 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Dime] DIME Road Map Wiki 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, we have created a Wiki page to keep the DIME working group members up-to-date about the upcoming activities in the working group. Although we distribute emails to discuss all sorts of things we thought it would be nice to have a single place to look at. Please find the webpage here: http://www.tschofenig.priv.at/twiki/bin/view/Dime/IetfDimeRoadMap Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 05:43:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruFk-0001CH-34; Wed, 06 Dec 2006 05:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruFi-0001CB-PA for dime@ietf.org; Wed, 06 Dec 2006 05:43:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruFh-0002Qe-HH for dime@ietf.org; Wed, 06 Dec 2006 05:43:50 -0500 Received: (qmail invoked by alias); 06 Dec 2006 10:43:48 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp017) with SMTP; 06 Dec 2006 11:43:48 +0100 X-Authenticated: #29516787 Message-ID: <45769EE3.2010005@gmx.net> Date: Wed, 06 Dec 2006 11:43:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ulf.Bodin@operax.com, avri@ltu.se 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: d17f825e43c9aed4fd65b7edddddec89 Cc: dime@ietf.org Subject: [Dime] Diameter Auditing & ETSI TISPAN 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 Ulf, Hi Avri, what is the status of the liaison between ETSI TISPAN and the IETF DIME working group regarding the Diameter Auditing work? Ciao Hannes & John PS: We encourage you to continue your work on the Diameter Auditing requirements draft and also to start your work on the solution document. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 06:02:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruY0-0000zU-Go; Wed, 06 Dec 2006 06:02:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GruXy-0000zM-Uq for dime@ietf.org; Wed, 06 Dec 2006 06:02:42 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GruXx-0005Kt-Fm for dime@ietf.org; Wed, 06 Dec 2006 06:02:42 -0500 Received: (qmail 16659 invoked by uid 0); 6 Dec 2006 11:02:33 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 6 Dec 2006 11:02:33 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Dec 2006 12:02:32 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB4C1A@lulex02.ad.operax.com> In-Reply-To: <45769EE3.2010005@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Auditing & ETSI TISPAN Thread-Index: AccZI3BcpjvZzBzESiKYfIcwWGhGOgAAkqig From: "Ulf Bodin" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dime@ietf.org Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN 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,=20 I've submitted a draft LS for the meeting next week jointly signed by myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition will be taken next week on sending the LS to IETF.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 6 december 2006 11:44 To: Ulf Bodin; avri@ltu.se Cc: dime@ietf.org Subject: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Avri, what is the status of the liaison between ETSI TISPAN and the IETF DIME working group regarding the Diameter Auditing work? Ciao Hannes & John PS: We encourage you to continue your work on the Diameter Auditing requirements draft and also to start your work on the solution document. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 06:33:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grv1V-0005cN-E5; Wed, 06 Dec 2006 06:33:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grv1T-0005cD-Co for dime@ietf.org; Wed, 06 Dec 2006 06:33:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Grv1R-000208-W1 for dime@ietf.org; Wed, 06 Dec 2006 06:33:11 -0500 Received: (qmail invoked by alias); 06 Dec 2006 11:33:09 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 06 Dec 2006 12:33:09 +0100 X-Authenticated: #29516787 Message-ID: <4576AA74.7070404@gmx.net> Date: Wed, 06 Dec 2006 12:33:08 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ulf Bodin References: <33656995C5C5094A983DE84DA649A924CB4C1A@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924CB4C1A@lulex02.ad.operax.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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org, avri@ltu.se Subject: [Dime] Re: Diameter Auditing & ETSI TISPAN 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 Ulf, thanks for the quick response. Please keep us up-to-date with regard to the outcome of the discussion next week. Ciao Hannes Ulf Bodin wrote: > Hi Hannes, > > I've submitted a draft LS for the meeting next week jointly signed by > myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition > will be taken next week on sending the LS to IETF. > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 6 december 2006 11:44 > To: Ulf Bodin; avri@ltu.se > Cc: dime@ietf.org > Subject: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Avri, > > what is the status of the liaison between ETSI TISPAN and the IETF DIME > working group regarding the Diameter Auditing work? > > Ciao > Hannes & John > > PS: We encourage you to continue your work on the Diameter Auditing > requirements draft and also to start your work on the solution document. > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 06:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvAN-00023i-TQ; Wed, 06 Dec 2006 06:42:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvAM-0001zm-Bi for dime@ietf.org; Wed, 06 Dec 2006 06:42:22 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrvA3-0003Wi-1z for dime@ietf.org; Wed, 06 Dec 2006 06:42:22 -0500 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kB6Bi1Au020962 for ; Wed, 6 Dec 2006 17:14:12 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kB6BhxoB020925; Wed, 6 Dec 2006 17:13:59 +0530 To: zhangtao_hw@huawei.com, hannes.tschofenig@siemens.com, taylor@nortel.com, Hannes.Tschofenig@gmx.net MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Himanshu Bahl Date: Wed, 6 Dec 2006 17:10:15 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 06/12/2006 05:11:36 PM, Serialize complete at 06/12/2006 05:11:36 PM X-Spam-Score: 1.5 (+) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: dime@ietf.org Subject: [Dime] Issue regarding diameter node behavior for same host Identity on both sides. 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="===============0501745478==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0501745478== Content-Type: multipart/related; boundary="=_related 004036BF6525723C_=" This is a multipart message in MIME format. --=_related 004036BF6525723C_= Content-Type: multipart/alternative; boundary="=_alternative 004036C06525723C_=" --=_alternative 004036C06525723C_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IG1lIG9uIHRoZSBmb2xsb3dpbmcgaXNz dWUuIA0KU3VwcG9zZSB3ZSBnZXQgdGhlIHNhbWUgaG9zdCBpZCBvbiBib3RoIHNpZGVzIC4gaS5l IG9uIGxvY2FsIG5vZGUgYW5kIHBlZXIgDQp3ZSBoYXZlIGhvc3QxLnguY29tIChleGFtcGxlKS4g VGhlbiB3aGF0IGtpbmQgb2YgcHJvY2Vzc2luZyBhcmUgd2UgDQpzdXBwb3NlZCB0byBkbyBhdCB0 aGUgbm9kZXMgPw0KDQoxLiBXaWxsIHRoZXJlIGJlIGVsZWN0aW9uIGxvc3QgaGVuY2UgYW4gZXJy b3IgY29kZSBvZiA0MDAzICggRWxlY3Rpb24gDQpsb3N0KSBiZSByZXR1cm5lZCBvbiBib3RoIHNp ZGVzLj8NCg0KMi4gV2lsbCB0aGVyZSBiZSBhbiBlcnJvciByZXR1cm5lZCB3aXRoIGNvZGUgNTAx MiAoVU5BQkxFX1RPX0NPTVBMWSApID8NCg0KMy4gV2lsbCB0aGUgbWVzc2FnZSBiZSBzaWxlbnRs eSBkaXNjYXJkZWQgd2l0aCBubyBhbnN3ZXIgbWVzc2FnZXMgYW5kIA0KY29ubmVjdGlvbiB3aWxs IGJlIHRvcm4gZG93biA/DQoNCkEgZmFzdCByZXBseSB3aWxsIGJlIGhlbHAgZnVsbC4NCg0KU2lu Y2VyZWx5LA0KSGltYW5zaHUgQmFobC4NCktub3cgTWUgDQoNCg0KDQoqKioqKioqKioqKioqKioq KioqKioqKiAgQXJpY2VudC1Qcml2YXRlICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJESVND TEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBp cyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBw dXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2lu ZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMg bWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBk YW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVk IGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 004036C06525723C_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5IaSBhbGwsPGJyPg0KPGJyPg0KQ2FuIHlvdSBwbGVhc2Ug Y2xhcmlmeSBtZSBvbiB0aGUgZm9sbG93aW5nIGlzc3VlLiA8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTM+PHR0PlN1cHBvc2Ugd2UgZ2V0IHRoZSBzYW1lIGhvc3QgaWQgb24gYm90aCBzaWRl cyAuIGkuZQ0Kb24gbG9jYWwgbm9kZSBhbmQgcGVlciB3ZSBoYXZlIGhvc3QxLnguY29tIChleGFt cGxlKS4gVGhlbiB3aGF0IGtpbmQgb2YNCnByb2Nlc3NpbmcgYXJlIHdlIHN1cHBvc2VkIHRvIGRv IGF0IHRoZSBub2RlcyA/PGJyPg0KPGJyPg0KMS4gV2lsbCB0aGVyZSBiZSBlbGVjdGlvbiBsb3N0 IGhlbmNlIGFuIGVycm9yIGNvZGUgb2YgNDAwMyAoIEVsZWN0aW9uIGxvc3QpDQpiZSByZXR1cm5l ZCBvbiBib3RoIHNpZGVzLj88YnI+DQo8YnI+DQoyLiBXaWxsIHRoZXJlIGJlIGFuIGVycm9yIHJl dHVybmVkIHdpdGggY29kZSA1MDEyIChVTkFCTEVfVE9fQ09NUExZICkgPzxicj4NCjxicj4NCjMu IFdpbGwgdGhlIG1lc3NhZ2UgYmUgc2lsZW50bHkgZGlzY2FyZGVkIHdpdGggbm8gYW5zd2VyIG1l c3NhZ2VzIGFuZCBjb25uZWN0aW9uDQp3aWxsIGJlIHRvcm4gZG93biA/PGJyPg0KPGJyPg0KQSBm YXN0IHJlcGx5IHdpbGwgYmUgaGVscCBmdWxsLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mz48dHQ+U2luY2VyZWx5LDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48dHQ+ SGltYW5zaHUgQmFobC48L3R0PjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRk IHdpZHRoPTEwMCU+PGEgaHJlZj1odHRwOi8vdGhlYmFobHMuYmxvZ3Nwb3QuY29tLz48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5Lbm93DQpNZTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4g PC9mb250Pg0KPHRyPg0KPHRkPjxpbWcgc3JjPWNpZDpfMl8wOTZGMjdEODA5NkYyM0YwMDA0MDM2 QkQ2NTI1NzIzQz48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQo8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVByaXZhdGUg Jm5ic3A7ICoqKioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdj b2xvcj0jZmZmZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBt ZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJ dCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQg c2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0 aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1l c3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5 LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVk IHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFs dGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNl bnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcg ZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWls IGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90 YWJsZT4= --=_alternative 004036C06525723C_=-- --=_related 004036BF6525723C_= Content-Type: image/jpeg Content-ID: <_2_096F27D8096F23F0004036BD6525723C> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAB/AOwDASIA AhEBAxEB/8QAHwAAAQQCAwEBAAAAAAAAAAAAAAEICQoCBwMFBgQL/8QAQRAAAQQCAQMDAgQEAwUF CQAAAQIDBAUGBxEACCEJEjETQRQVIlEWYXGBFzKRCiMlQrEYUnah8CczODlicrfB0f/EABwBAQAC AgMBAAAAAAAAAAAAAAAFBwEIBAYJA//EAC8RAAAGAgEDAwIFBQEAAAAAAAABAgMEBQYHEQgSIRMU MUFRFSIjYXEJkaGx8CT/2gAMAwEAAhEDEQA/AL/HR0dHQAdHR0dAB1xPgKaWCQPghRBISoKBSrgA k+1QB4+/HXIpSUgqUQkD5KiAB/UnwOuB95ltp1S3WkJaQVuKWsANoQkOKWvggpCEf7znxwOFEgee nPHn44+D/f8Ax+31IYP7fU/BceTM+DPgi+p+DPj9hHH3o+oJr7s52n2r64ycwJEjfezUY/kMmRNV FRhmAuRn6hWZOKV7IseOjNLjG4rkmfIZhIqIOQyHFE1y1MSLMO/rQglKlKSok8cL4SEqJ44HB4da Ch9jzzySCfzmvVE7obDvE7y9s7Ix9+ba65wF04Pr16AH5ESs15hVqmmTkiHIwcZhsZXlM6fkZslL SwHsiq4IeU5+GQq516S3dY33Zdl2rMutrJubsLA4w1Ts1KnAqUrKsLrYkaLdSQXVuEZPjj1PkTjr iGwuZavtIJMZXupzCNmJyjNMpoVLL2DK/Wx5xSSL3Mev7YE1SFeDUmS8n3zRJ7uEKXyZISZl6TdU 3Q1M0L0y9Pm2GoshOTWcIq3dUQzdcdpsgyxD2UYgxKYUs0wfwarddxWzWRek5Yw69wlKVLQapOej rH3o5A9yeSeAPcOSQCSAOeSeATx+wJ+B1l1cY82v+/xz/oyP+DB0dHR0AHR0dHQAdHR0dAB0dHR0 AHR0dHQAdHR0dAB0dHR0AHR0dHQAdHR0dAB0dHR0AHR0dHQAdHR0ilJSPcpQSkcAlRAHJIAHJ4Hk kAfuSAPJ6fPwMGZERmZkRERmZmfBEReTMzPwREXyYwd49iuTwDwPjn5UABx/MnjqJn1ju7A9q3ZV n8rHbVMXZO4mn9Ra5Uh1svxLDKYshWU3rHJ5ZXj2Is2syDN5SiJcSKULcSXWUrlikLb+kvlSSRwo DnnyhYIJCeVe0KT+ogfpAUSQASKRfq9bVyvv29SDAO0PU0o2dRrTJIOmMejtB12AjYuRWECVs7K5 zbP1EIiY43FrqafMX7Wqmvwq6lSlxmlylIrraWSPY9iUxuCa1W944iiqWmiM3zl2BKaU60aSNSFM RzeeJRFyTiGiLyobpdA+l67cXUTjzuUqjx9c6uhS9rbInTyJNWzjuHqamR4litf6So0+5VXszmFG XdTJt3VdyGVJN1Xol+nPie0uzruO2Ntqk/T3UY1kWncBmzISnp9Pr2lefTMzCtDqEoRInbGj18qI lKi8ZevoU0LEWaoOtu9EnduUdmffls/s020+5T12zLm51tMhS3lNxq/cuupll/C85kPFCCzldY3c 4/XuMp5u5VhjLccvExkqtmYa1o3tE1BrzV0vN8E1vhWucRosRo3c1yjH8QZfh00JqCJ0iTdTa+K7 YWjjKrCe771resJExxZcd+pxTq9a+/0XH7wNe91HahvPWeaZRkTNPPzRGtcxoMjsMX2hrKZVHHsr mIobCS3GYvahmkbXIUlP1bLFZLjy3Xpr5XVOTUMPXVHgd9XSYLdzhshhFywiS2mTbRbJ5tVq0Rc+ s6hL78plpSkGbbLq1EZk3yW+mgtv5B1o7R6stTZzU5ArWHU3T2UzXVnJp58uiwDJcBjNt67U5IbQ dfXPppK2tnWam320T7zHIbJEl2yUbt6BlxC1JIcQVEFaggp9qgUgAge5RCeFJI4PjwCTyOfr5H7j /XqI/Q3rEdjuxNXa5yXOO4DXmvc8vcQoZmZYXks6VTScfyxdZG/iCtVJlxG4S4sO0/GoiuuTFfiY y2XkkkJT09nAO8DtS2g9Fb173JaNy6TIUW2a+i2lg8+yW4W1r+mK5m3/ADD6vtSpRbDBWEpJUAAT 1f8ACyXHrFLKoV1Vv+4bbcaaROjm+pLvBoI2u8lJX57FNmXeSyMi5MyIeReVaQ3JhMiyjZVq7Pab 8Jmy4E2ZNxHIGq0nYb7kd1xiyOtOFJiqU0tUeY0+qM+wSHUPdpmSXMdHXEiQw4hDjb7LjboSW1oc QpDgUOUlCkqKVhQ8pKSeR5HI6z+oj/vo8kgfqHkjnkfPyODyPkcHn46myMj7eDI+4uU8Hz3EXkzT 9yIvPJcirj8GZH4Mj4Mj8GR8mngy+/cRp4+eSMvkhl0dJyCeAQT+3I56XrIA6Ojo6ADo6OjoAOjo 6OgA6Ojo6ADo6OjoAOjo6OgA6Ojo6ADo6OjoAOgkD5IHkDz48k8Af1JIA/cnjoJA+Tx8Dz+5PAH9 z4H8+uFa0KQQlaVc+wEIWOSlSwk8FJJAPJHI48/BB8gfj7Fz8cnwX9/9jBmREZn9Pp9T8GfBfufB 8fwf2HIXED5Wgf1UB/1PXS5DdUtFSWd3e29XS0tTDXZ2tvbWMasq66tiD8RLnT7CW/HiRIbMdp11 6RKfaioaQtUhxLIcUGf96nfBozsf1o7nW47x1djZNPsYRgNG+lzMs5t4rKXFQKWvU6j6MGO69HTZ XkhAgVLbgdfdD6okd6s7LofUs9cnI3LmUtXb/wBnbNktVXHnuWsHXv4eA6tLciJXtIjX26sviJWp b9w4pOJQ5za0RJeLpbcgyOiZNnUakltUtVXy8iyiSklMUkAkF6LZqJJSrKY4tLEGKf5u03jSpZoP yls/UTtjojpTvtp0crZmeZZRaX0NSzVRLvbGZLNiPNlMuGl6lweiQ+1aZhkSjQpDEWuNmMlwnG1z Ezm2IMuRfvR9f7ty1FGv8G7bIljvnYjMOXCZzGueRT6nx61/DuNxJSL6wjOTMwENS1SlCgrV0Ult gBOSvIU62qs72xdp/qK7zzv/ABS7cteblj5Nd2FzYDc0ObN1vXPSslZlJv7ODsO5ssVgKftotnN/ NV01m/Idgy5UJxh4ThFkSF9xdb22+lVt2i7b+3TR+Jd0ndq7T41Jvdy75r05vX4hlGZyPfjGLYBp msjoxqFkK4T9bdwly35lxFNvULem2LMqOzJuH6BxzYmI6l1nQ7byUZltCHiFUNhZK3X1FXFnZhJh Nzb9uBW0jLFZCqa6xfdrqduElTSK1iK2HHQAoU9HoLbaOROxcuyFcV3FHFKdrcYikzEqpUlSSTFK 7fWlL1qS2u71GI01LTcVRJeUpxbafRi23BrvoJ0pRXHTtqGPfQeoBltuDnW9L16Zkmy8doYj/OSq 1lQR2W6zBEndNM18W1ucQsJ5Wzb83HJSO+WVT7A/9nH7rdjyBkncF3F4NiNpYe12wRXoyrb+UqPK llqxsbiTiVcqWVqUHJEe2tmeFrUh53wFuNzD/ZqtbY/qrO7HF98bPy/bMDD7ydhEB+kw/H8RtMwi VkiRS1VpCLFraCss7JtiBIUzdNPttSVL97vtLa7UfXDIBLKwCoc+0EpJSoJKkhXsUOClXtJ9qgQU q4V7k8cixmdK6+bYUy5UOTHloWk59hPnyJne4nt9dSkSGWFOoPhaFKjnwoi5I0kSS03u/wCp51k3 FjElM7Lg47VQpUeQ1jON4fi1ZQkxHdQ4UBw1Vci6dgLbQUd1ldya1Mckh1CzNw/z5/Sa7Pe2DvK3 VsPQPclZ7Rw7N4tC/kWvG8HyXHMb/FSsXlvRM4xG6hZBheTyJFzAjuxLeubjvRVtV9LeB9vmHISm dTI/9ms7UrALOI7z35j7wCvp/mkjAsiaaUSpKFusRsRo1yEoUhYU0X4ylLbUA8hSSUxc+plgmR+m 16puH90Os4JiYznWVR9843Gio/DQZFq5OXB3PgfvYShltm3etLBctptKWodTm8QFDSUsLN0/WWf4 3tLBMK2PiNim1xjP8Xpcwx2wbWhSJlLkFXEs4T6g0VttPhmS23IjpcX+GfS42Vck819rPCcRmN5F iWS49CkX2LWj0dyYr1mXp1XMcUuG+brLra3FeVJUtPHDLjB/KiUe3nW11QdQuML0z1FaL29mFBqD fmA19jEx9h+tsqbFs6omY0HKccch2NbKYZW064jvbV3k/dQshW2fpkSU1w6j0bfUR7Y1uT+zn1Er FEaIlL0PDMzhZZh+NyFNkBEeXQRrPaGHzStBWFOS6FDJc9jn4ZlxLbjW78a76vU47VH2YXft2X3W 0Ne1TjYn767amot9+CggfSdyHJMXx6VcwRCQtTQkLlx9dFtlbjjNW9JbYgy7BpJA5A5/l/frhfQp xohPIWfbwUkBQAUCSPclQJA5IBT+oj2+OeRasfXzFOr1MWvb6gMjJXsymrtqp3jj8jtbbLeaNJkl Ke5l6K8SfBSE+FJ0GuOsS82QhUff2qdSbmS+RpkZG7ikXXGyGiMuDcrs61qnHXm3j8qU3cVN9XPK 4KVWyEG4242Hto7vu3fu0xtGVaH2bRZnHjp993RB81mZYy64VNtx8oxCwbjXVMpa1obaflRhGku8 JiPvIJUp0QcQeOFoPPPHCgeePB44P2Pg/t0xzc/YJoPbmWx9oVlFYaY3nVOKkUe+dHzTrvZsWUpC vcLyfVxXKTOK+Ulx6LOqc6p8np5dbKl1kmA4y+oDYmoZvcFh9lFwPeESr2KkodTju8cEpk0EXIo8 eJJfETZev/xEtOAZSluOsmwxiyvsGv5TqPwy8WmyYOOnstfKuGzRFuo0Zxw+0mrSq9U4T5mZclJh PJTIrX1cl+RLkyKSj592lSm2V0hldDrizjv3+rru0iR2yckWOAZ67XtZVTMJT3uu02TQG4dJntfH LhK3mqzFciSRGprEn6yLJt2nRdHSA+B4Pn/y8c+f+n9el6nRVYOjo6OgA6Ojo6ADo6OjoAOjo6Og A6Ojo6ADo6OjoAOjo6OgDhkFKWiVe0JCm+fd8f8AvEcD+ZJ4A/mR56Yh35d8uveyDUKs2v4r2VbC yl5yg1Fq2reWb/Ps0cTFZiV7DMYqmt0kCTY1xvLGHEmPttyGq+DHkW0+uiTHV7d2ng2l9Y5xtfYd 7FocJ1/j1hk+R2jy21fRr6tkyVsR2C4hU2fOWluDW1rCvxdnPkxoEMKlSWUmKjtO7W8s7jdwp9Q7 vHopCM7voyUdsPb9dhyXTdvmqX4i1U0u6rZjJbmbPySFMXdXrk2E3LpZtlIXKZjT5DdZjfWb+wsy U1TY/wBhXdgg1e7cSTkekgo7ietZTZkff5MmYTPH/ok8Ev8ASbcMry0/h+FKbsdobbOUrV+GyWmD x6vkrh3ez8vcZ93V69oZSVNHXxHGe20zbI0uKRjeNk2kk/i97j8ae0vtM9LfZ/dVs5zva9UZ5/MM 4yhyJaYJ28SlKh47h9AHTLp6vLadhbjcKlpkkO0+toby4rjn17LOZlvdWltWxLGEOpi1EKFV09ZF qKuviM19fArIrcODCgR20tw4MSJDYS3FixkpLbDLKWY8NpLTLTJQSvrtmwpLrXLKkj2kqcV7iEkp WpSFefaFEkq94H0k8loH3KHX3cjnjkcnkgcjkhJAJ4/kSAf2JAPz19McxerxiMbcNDjsuQv3FlZy XPWsbKY4SVSJEuUrucUbzhKX6aVJaR3GTbaCPgcDc+8873jdxZ+VSIdbj9HFTU4TgOOxiqsIwHHo 6UMxaPFaBtSocSK0wyy07LeRInWRNpenyH1Ggm4RcN9FvAIPeinvV2Tu3N9q5cNl3ez3cPvcWpIO OuXsr8yXi8NT7Lrs1VZhj0ineqG0JAV/DtfHWlLJWRNdHbKF8lCv1F0+4hQ4K3FL58jwHPJIUR7f agDwtI6+3o65VPQVFCiaiqhNxTsZrljNcSa1uypjpmbj7zjilqWo+VERckhKT4SkvJnDbK3Bsjb8 nG5Wxcok5GrEMdh4pjLLkKrrYVJj9ebhw6yvr6aDXQWGGSecSSyjm+42TDTry2osdDZ1xu8/TPA5 PKeB7VK/50/ITyeB8k/A+T4B6z9yfjkc/HyPnkDj/Ugf1I/foJA+SB5A8kfJIAH9SSAB8kkcfPUx /wB9hWhlyRl9yMvJcl/b6/wI8/UJ9P3XnqEa0xfAc2vrnCbXCMvRlWN5pR1EGztYgXXzqm0pFxZy o7MiruWHYz8tBkAIfr4ElI97aEq2f2Tdscns+0RjGg07GyDadFh8+6Xi+Q5LTxKS0rKK3kqtWcdX EhKeaciVljKtVQ31OIUzFmxq8BSIjaW3fcj9/wCX9+OeP9PP9OjqHbx+mau3cjagNN3MiGUGRObU 4hb8VJNEht5BL9Jw2/Ra7FmjvL00l3cEXFkStu7HnavrdLzcplS9ZU2RO5VUYtJhVL7FXevlLTIn V9g9XruYhvpnS0vR2LFEJz3Utw4xPSXXTOjpApJ4IIIIBHBB5BBII/cEAkEfIB6UkAEk8AeST8Af uepgVwDo6QEHngg8fPBB48c+eP5EH+h56Xkfv/P+379AB0dBIAJJAAHJJ8AAfJJ+wHSBST8KSePn gg8f6dAC9HScj9x4+fPx8f8A9H+o6XkfPPj9+gA6Ojo+PnoAOjpOQSQCCQeCORyDwDwf58EHj9iD 0vQAdHR8fPSBSSSAQSPkAgkeAfI/opJ/ooH7joAXo6OkCkk8AgngK4BBPtVz7T/Q8Hg/B4PHwegB ejpCQPkgckAckDkkgAefuSQAPuSB0vI8+R4+f5f1/boAOjpPcnz+ofpISryPCiAQk/sSFJIB8kKB +46UEHyCCPPkefg8H/Q+D/PoAaBt3UVlvvZWA4zltW4jRmqbOp2nfVE6M+YG1toVchT+uaSfBUlB scO11IYczi5r3VuRrzMhhEV5DzFBdRHXWRWnGvoNrW59NkL496VIKllIbSVK5LZSVF1SGx7faFtI SkBtPPZ9YqBUkgHjngH5/wAvI9wHBBBKeQCD4JB+3XFZiNMuy5BF3SJjqVvPqIvUNDfBMsJPjlLD KS7UNkfHKnFmXc4oxN2l9Ota6hp3TbZqschuRq2AylSWESZchU21tHSNXc/Z2s1xTsuY8bjpsMV0 BCkwquAyz8thOhVsGZYWEyPAgwIr06dOlOtsRYMOM2t5+ZKedUhpiLHaacefedWhptltxa1JQhRE Rnp0eoWnux3L3N4JeTkNxa/LpWfaPjvtpiyHdRttVeMOV76FqSpc6pU1QZFNSlK1B/NpyHuDAJT9 vrGdyo0b2p2mDU8xUPOt9S5WA1Jjuq/FwcVRGjy8/vG22iJX6Kl1nGWS0CPxWTQ/1h12OlcME/T2 del1sbsY7nJ7lmqJmuNR5O3q9YeJqLmzXNez3CH2kNoQlYwTJI8mPHkcOHJcYu5DaB9FoM8oQguI Ag88EHjweD8H9j+3Qfg/fx11dNbV15V1NxUTY9hU29ZCtaybHdbeZm19jGblV8th5tS23mpMVf1W 3W1KQ4g+9JKTz12vQBAx31+pJ3Qdvvdmnt10lrzAc7/MsZwmfjdZZ47ld1mF1kOVN2HFVWMUmTQv xLrq4v048duCt59Q+iyhb6+ToS59Wf1BtLSItv3CdndXjuHOPobmGxwnZ+ufe2ocOJj5TeTbmgiP O+5IbcsYTscrKW1rjBf4lrpO8ydCrPW20DYWMyNX18K07eJU2dNksQ4kSKxOvnH35MqStuOww22l SnXHXEISgHlQ6mL7yO5ntfxDt721W7A2NrHIm7/AMop67B2MioL+8yy0tKR2LVV9ZjsCTMsJDr0y bAKZzDHtrULTZF1pMdLiQDc3a33J6+7sNQ0G4NcrlN1lk/LrrqktGw1d4nk9cloWuNW7KWmUtzYK JUdxl/2J/G10mJLQktSUlLi1AEcHnjkfHPPIII+PI4PB5+3zyOOeoGvQKxXJ6nt727lFmy6xi+Xb PhIxRSvrpjT3McxaurL+fAbeAQuKmapir/GxytmdJq5X+8U7FdCJ5ugCHDVfqAblzX1Ms57OrXHs BY1njNpnkCHdQq+4ay51GLYhHvYSn5bt6qsUXJbyG3vZVOksKdSkNKCHWpjVn2pJ58jjj+Z5HtT8 jkqPCQOfJPH36rH9vv8A8+LbX/iTcv8A+Na3qze5z7FFIUVAchKSElRB5CfcQQkK/wApV/ygkggj kADde5Puf1P2qa6lbI2vd/gq1UlNfj9PDDczIsvu3m0uR6rHa1Cw7Nd9riVylstrRBgpfnyvpxmV uGCRHqb+o33U2to92d9uLNbhUCS621aNYkvN7FgAOfQYu8uvLOl13DnOIQXFVsUzZiASgttuhDrf jO7qJb9/XqsY12uzbSZG1lrWbHxSdGiyHW0t09FjYz3aNyhDZLLV9eqlv4jEfdSlcKPHgocLaX0A 2ZsFwjFtbYxSYPg+PVuLYpj0FiupaGliMQq+vhsAtIabZYabQuQpKW5EyQ+49Ikvrff+o4palrAK +mtfUg9QzT+4tY6z7v8AQ0Fmj2Rm2MYPHv52GWeBTxJyO1jUyJFVklVPs8JtnITs1ua/GZRIdejs PNM/SecQ6mxuQv2pSnzwtQPuUpfuSj3JBWogpT71hAWAhZSCogAgLb6DJsVxvMK9NdlNBWZDWMT6 +3YhW8BqxaZs6Sxi2tXNYjSWSpqVBsYESdDdaWlaJMdpaOfAV6NKT7vjjgnnkEpACQE/TBICOQeV e33DkKTzz5ABHj6lfdbsXs60LRbR1jUYrc39lsyjwx2HmMOymVSa21pMms3nmmKqyqpKZCX6dltp RlNpV7iSHEBKFxV416mvqpZpR1OU4h2h1eVYzeQ02FPf0Gndp2dHbwV8obmV1pFyiRHnRFufpTIi LdaWoewOAklLvvXbIHZ/hvJUnnf2CpSUqCD9RWNZ2loFR8BBcKQ5zwPYVckDz1o/tB9W3tK0d2za W0/nLu0TmOA4LVY3kLdbgTlhXNWUMqL6o89VlGbkoUuWwPAPHKTwPggD1vT97ku83fOTbJg90mhl aep8bpccm4jMXgOZ4Ym3tLKXZtWsRp3LbGy/HLhR2GFvIiupXHDzRcShDyQuUBzj2K5HI48j2lY/ ugEFSR8qSD+pPKfPPHTM+1Dvn0d3kzc6i6bVmK166boHMhGVY2vHShOVKuV1qoqHH5AkoV+SSU+9 tfHP/fKHFB5/9egCIvc3qSVnbL30y9Dbjbjx9K5Pg2v7OnzKOgtv69yi4N/FluX6Twmdilq5Dr0y J44TQKfE+W4xBjSAZZK2dBtYUK0q5kOxqrGKzPrrCBIZmwZ8OY0iTDn18yOt2PIhyorqXmH2HFsu tOIW0taFBSqnPqva7ttuepjiGrMesIVZebBwvVOLU0+wW4ivjWtxMu4ta5OdZSt1mGqWppEiQ2lS mGVOPpBLfjt+ybvx2v2CbHsO0zuzrL2HrWltnK1sWjMmXcacdcdbiwrLGlcLfyDUN66hFk0kLdbq BMMuqffrTYFABY97rNp5BpHtw3PtzE4tVOyXXmB3eUUkO7bkO1MmxrGA9HYsW4kuDIVGcXwl0NS2 VcHklSeUKbt6avdVsPvC0FabU2VVYpTZBA2RkWHtw8Nh2MKnVWVNPjsyK+WbW0uZn4px6zkB0iUy 3whBS2B4Pe99l9SZN2Cdxd/jdpXXVDeaRyG1prWoksyq2xrZ1e09En1z7CltuwZba0uJKVq9jqgj lXghpHoS+OzbJOfHO881SOfH6hj2Gkp/+4DyR8geT0ASvbhyDLMT1PsvKcDpjkWb43geWX2H48IU qyVfZPUUc6fRUyK6C/Gmz3LSzjxoLcKG8mXKW+liMlx5aGl1zcz9U/1ONY0DmVbH7V8ZwPGGpcSu cv8AK9TbVx6jZsJ7q240Iz7TLYTKZMp/2NRG1hS5JJ+kkjlQs8H48c/I+OOfkfv4/wDXjz1EZ62n jsYuwBwFbT1d7h+gc/8AHxx/9Xk8c+3zwPP6eOgBh+Hepv6pWwKelyvDu0mpy3D7wtvVuS4zqHaV rS2kFMxUSTJqraFlMqNNQy63IZU7FXIaRIZcadHLbqBZTil9UOO4+221IUwwt5LaVewOqbaL6UJc JDfsdHDBddd4Skcq9o5DDPSzSlXYD20ghKknD7nlJb+4zXJT8nx4IHkj9X9upAyASOftzwPt8ff7 f056AI5Mn2t3mYvGcTT68ibCesLDfeOxkw9d29E5TT6PNavCtM5ZIK8hlx5+O3jJl5tkLfsjrs8b nTrCoW5CgJcS/XFpVxPxnHrC7jmuu7Ckqpt1BMOSyYttJgsO2EcMOSHXYyGZSnWm4z7i347SEMvH 6iFdem4H7D/TpegAJA+SB5A8+PJPAH9SSAP3J46wWQUnjz9jwfIHPCiOATygcngDnkcDz1kQD8+f IP8AcEEf6EA9Nx7sso2tiXb5tKy0ZhV7nm3pWMTqLX9DQJjCa3kF+W6iNffVnSIkFlnGxOXkLxlS mUPoqlR2y486hpwAq0d/ndTF3J3/ADeWMYrO2nqvt0ySkxeiwWukyxX5bEw26/MsvmS5lXXXZiQ8 izY2FQqwEF9mVTVVQwXENONuo9N3jepTl3eNpmXqTJ+0yZi0lq7qMmxrKod1kN3Kxy6pZbrK/wAN XO4TXIlRrWoXNppDQnMI+hYJnBL30W21zCekJ2dZb2z6ey7L9s4xMxnbu1cqdftqi5MGTd0eK4yq dAoYc2VEfnoVMuJsy6yCxdblIMr8dAUv6iW2+ZeXEpW2tKx7kKSQtBQHAtB/zoKClfvStPKVJ9pJ SSB54PQBD/6L/cd/jD2vtauvLBczM+32XDw1apL4emTdf2cQWOv7FxxThdkliC3OxxyR7Cgrx4K+ oVPcCYLkc8cjnjnjkc8fHPHzxz45+Oq/usu2XuC7QvU/ybM9ValynKO2Dc02Y1kVxj4qXarGa/Pl m8dYkpn2Ilx0YTsOOuQ079BJi4xLdaBYjSQ4J+wnnjn3LWCOSUrQB7SptS2yQPYpQ8kJPtcT5A9q /eQCsD3s0tTknrT6PoL+sg3VBfPaFp7qqs47Muus6eydyKFaQpbEhDjLsd+G8+06FAFIUVJW2tKX Es87m+0bWfYz3kYtXbhwy9zPtIzG/OQUAqLCbUz5mFvuPIuMcm2MRQluXmvJ01h+2gNORLLMqRUd 6KqI/NtnYUovcx2x9wGY+rZo3eeM6jyi61Ljljo1y9z2GquZpq5nHrO5kXUib9Wx/Er/ACxtTan2 2Ya3El2Ol4NIeDolK7zO1XGO73R2Rasu0tV12lKb7X2UvtlyVima18RYqZ6fYfqGrkhTtVf1yv0W FfPlfp+s0ytIBu/UsHXVZrvBoeoYWPRNXpxmqdwdOKpjtUJxmXCal1MqsbipQw4zPZWqVJf4TJel rU9KbkOuuSxsskAEkgADkk+AAPkk/YDqD70nIHedoo3nbR3EaXz+r1fWO3VlrHYc6RS2dDj02JIe NvjKpcW1dntYzkDiX7zG3HYi0sWsmVGaCIdhGW3OAocpUCOQQQQQCCCODyDwCP3H36AKxvb4QfXj 22AQT/Ee5TwD9v8ADauTz/T3Ap5/cEfIPVnI88Hj5+fjn488f3+P79QAaT7Yu4LH/WI2Pvu81VlV dpy3uNnPV2fykU5x+Q1c4SmDXuxyi0Nk2mbODURlaYTwddK0LKEJdcan+X/lP6fcQQQnz5UCCn45 4/UB+o+E/wCY+AegCq9nmSR+zP1p5Gws75gYJsbJFWxu5TTjcNvG9s4ezjL1oZcgNsJh47liYiLa b9X8NXx2ZC5TraG1nq0xGksyGmZDEhEph9tDjMhlba4zzLyC+y+04glt1DjJQpDjSloW2tLiSUH3 BhXfh2G4J3ta8h1Vi81i2zMVROcwHYCYCZJr0WCW12GN3UMvNPzcRvXEJ/MIpW9MqpLaJ8CNJU0q HMh1wnJfWN7EYidasansd5a6oVqZx5xOK2G4KGFBcfb+mxj19idzWZtU0v6EOtVuR/SVXEliPVNr KV9AFogqSPlSR+oJ8kD9SuPanyf8yuRwPk8jj5HS+5Pg8jg8AHkeSTwAP35JAH8zx1Wpxu39XHvP 2rq4bB13bag0hjWy8HzTLKZyikalx6yqMZympvJMG0Zye1l51mjYRVocr4AifQTYpivucsIfX1ZN SlZ8f7xKf8iSkBASAp3yEFQKR7VJT5bJHAUPACwAQveu6QOzvEv1FPO+MLT7kngjnFs9QeSASACo BfA8AkeOevT9iPZN2l7A7Pu3vNsy7fNY5HlOSa1p7S8vrOhalzrKxkofakypMmQ6pxxT30mwFBHt JQDxx+oek9X/AEttfe3bHi+Gaf1/ebCySLuTEr6ZSUP5eiWzRQ6LMYc6Z7p0qIEoZcnxfqLU+02S 6hHKnHENrjH1PmvraaX13h2qsH7f5cPEMCoI9Bj8axwDB7WUxXww19EO2CsxZdedUX3EHyVAJWop IQUgAsVak7ddGaIfu3dN6tw7XByRutZvTi1RFqxaJqBOdrfxBZQVPfh/zacEkuJ49x8KA5O7VeBy fjkf9R1Fr6fGx/UGzrKtlsd6WvnMLx6BSY/JwKQvFMcxxU+2kTLBi2YL9BeWzk1LENllxTU5DRZ+ qy4OFON++Uo88eP3H3I+48+P2+ePhXwfB6AKxveh49bDtnJK0/8AE+3cgtr+ks+3JLUn2L+3HI9x +ADwrgHnqXHvu7Ctc96GBqjzlRsT21jEKR/h/sNuOHzAfDQeXjuRxR+Hdu8QtUpXHsGBIbnwVv8A 5lWvMPx0pMf/AHVdsfcDmnqvaI3dimqMovdT43ZaTeyDOYIrW6muTj17YSrlUpT9h+J+lCje0u/T hL+it5kv/TaV9YT9K+p7VK4V7gSEpA4UoKDagCk/o+okj2JcKvY3x7lH2hSegClS3v7uN7M8B7ie w3emO3czFc0w7JMbpaCdZOqdwu7uFttQ8vwG5kstsWeAZIt5LzrMMqqn5spmdHFVdKuq2TN16FHP /Y5yb3BfuG9845cV+lTi/wCGMGC23U+AXWlJV7vaB5VyR08PvY7HtZd6OvHKHKI7dHsCkalva+2P DhNm4xmctBQuusB7UuW+L2aQuJb1jrji3Y8l+RXFp8hw6a9J3Quzu23QmwdV7YoHaPJ6femZPtSG koXTZHSuY/iEaryTH5SU+yTRWgivKiJZW4YT8eRBkOCQw82ACUU/H9x/1HURfrakf9hq6PI4G09X cn7D/jwPk/A8efP28/HUuakhQ9pAIJSSD8EBQPx9/jwPgn58dRnerHqHZu7O0S3wfU2GXGe5i9sL X9yzj1GY4nPwam2U7PdaEyRFjBEaNy664/IZSkDlBW6ptlQB7H0sf/gC7af/AAfc/wDnmmTEf6jz /Tz1IF0yj07df5tqzsz0NgGw8assQzPGsYs4mQY9chk2lZIk5Rfz2WZTkV+THU4Y8lhfsS4SltxB JTykLev0AHR0dHQAdHQSACSeAPJJ+AP3PXk84zfENcYlf5xneQ1WL4jjFe7aX19cy2IddXQ2iEhx 959SUfUeeU3GisJ9z8uW6zFjNuyXWm1AHqwQSQCCRxyAfI5+Of6/b9+l6bzqruh0puXJZeIYNlVg 7lkOlTk/8M5TiGbYDez8YcXFYGT0dRnmO4/OvaBEmfCiuXFI3Mq21zowckgyI4ccH9RsjkOII8+f cnjx7ufPP29i+f29iuf8p4AM+jrErQByVJA8+SoAfpISr7/ZRAP7EgHz0oUkkgEEjyQCCQCSASPt yUqH9UkfIPQAvR0nuSDwVJBBAI5HPKv8o4/c/Yff7dJ7kgFRUkJCfcVcjgJ4J9xPPATwCefjgHz4 6AMujpOR58jweD5Hg8e7g/z488ft5+OsHFN+1SVqQP0qUpKiOfpo9pcPHuBASFJ5VzwgqST8gEAy 9ySUgKSSpJUkcjlSR7QVJHPJSCpPJHge5PJ8jnLrxUzNaOqzbHsDmOzk5BldPkOQ1aGaW5mVi4WL qp49sqdfMRXKenke+6giBCspbDs9piT+DS642tCfaFSQQCQCfIBIBIBAJA+/BUkf1UB8kdAC9Yr/ AMpHnyQDwAfBIB5B5HHHPJI8Dk/boKkj5UkfqCfJA/UfhPz/AJj9h8n7ddU1e0ku1ssfiXFVKvqm HXz7WkYnxJFtWQbdc5qpm2NY08qbEh2btZZNwJEhltqcuuntxVuriPhsA7JJAV7R7QE/oSn28KAC eTxx49p8ccAJ48Dz88vXisDzih2HQQ8qxp+wep57lnFjm0qrSjnl+mtptTYfXqbiJDnxEJlxj+FW 8yj8XFcakshyM4y6r2fvQRyFp4Pt4PuHH6vb7fv/AM3uT7f39yePkdAGXQSB8nj4Hn9yeAP7nwP5 9YhSTyApJI45AIPHu+OfPjn7fv8AbpFLT7SQtPABVyVhI4QR71E/91P/AD/YfB456AFKkhXtKkhX HPtJHu45CeeOeePcQOfjkgfJ6X3J9xT7h7gOSnke4A/BI+eD+/Wkdr9wGqdLScaq88yGXGvsvcsk Yvi2O45k+a5dfM1bba7ifXYhhdTfZBKralMhkz5yat2JDLzKX3mlOBXXpdX7VwPcOLozHXt7+c0K bSzpZKn6uypJ1XdUjrkO3pbalu4ddc0lrXSUqROgWcOPLjOAtPNNqJHQBsr/ANf6/HRyOeORyPkf f7j/AKgj+x/brgkOtMsuOuuoabaT9V1xSkBLbaOVLWr3ggJCULJ8c8JV7SFAEahwDe2rNkYaxsTF 8oZRgcm//huqye/gz8RprqydnsU9Ycdl5NAqWbyqvbCXHiY/bVb0mFdy340WqfluPhroA3L1ilKU 8+0AcnzwOOT/APv+vSFxAIBWgEoU4AVAEoR7fescnyhPvR7lfCfcnkj3DnL3J549w58eORz5JA8f zIIH7kED4PQAvR0gIJIBBI+QCCR5I8/3BH9QR9j1ipxCUqWpaEoSkrUtSgEpQkElalEgBIAJKiQA AST46AM+jrErQkcqUlI8jkqAHKQVEck/ZKVE/sASfAPShSVc+1QVwSDwQeClRSQePuFJUkj7KBB8 g9AC9HR0dAGKyQk8fJ4A8c+VHgEj9gSCf2HJ6Y936qgp1jqo3TrKMd/7VXbD/Eip3tTVJoTuLFkz DdIebXGXUpkmIX/xiPwri1sMuqAWFF8RIA8/ukf3KgB/5kdeRzbB8Q2Til3g+e43V5TimTQn6+8x +3jplwZ8V0BJ5CihTLzRSiRFlx1sTIcltqXDeYlstupAPA5ajTR2pqNeXJxv/F9KM9TqAzVOnJPo t0f/ALQ/yV2O6txNYzSPJRPVKAhV/uYS2EzDFZMeadn7rb1nH7vf8bcqkPy+5pnXX+BCazFXdaDX 7/cc7oJvEG68UTWVHL2qt2Jl6MkRfRrI20f8E/FejPuxXn3607X9J6iyVeZ4RiMxnJ3aFjF2L/I8 yz3P7qux1t1qQzSUNlsPKcofx6lU9FiuqqaUVsdcmOyp9TjTaeuvT2n6BGeObMOBn+Jmsve2A1EX lmcuYY1nrzSlHMG9bHI/8N2MpeDypku+ZxM2jtlIcsBPM5AkdADT86kbrzncneqzQ9xOxtdVHb7j OsrvWeL4rDwdVKMgstSysysBlKchxG1sMlo7KxhK/GVi7GMpyMt5ceQ062gp+HV2Zbpx617HtlZN unLNiNd2TcKPsbBb+qw6JhdAvINH3G1aO013BpaOLY4wKCfTJgymZt/ZLtotk44GElIDcgqdSa+Z tdnXYogq03NCrKnZMhyxuFjJ4NTSSMVgQ1NGwU3Wts0r8iAw7WGG4y077wr6iQofGzpLWUSv1FWs 4uhUPQrsV/UzbltePqxAwcWn4RHLTkq0fdtExcTspVQlNy7ZAMvfXYQ3MZjvtAEZOwMm7hE637yt +0ncdnVLZaB3Vsin1rr8UmDzNdjF8LbxYzKfLq9eJC/ydNsbSwRHEjIIS6ySY76TKTHdjLc/gbW0 dTdzeB6xv90ZxuLFNs6Z2JnNqnYsLDW7LHM419kWuIq7LEX8QxbH2q3Hbevzh+K/is1NkmHIr62R ClcIkOOONnaJ1VOxDZGASsXbkYpty6vsm2HSrs74JyS7ypyJ+fT1zE27cyvNoIjDK2K6TEYQAkFn 6P1W1+rlYBh87NsW2BIqg9l+IY3kOKY5ciZZIXX47lb1HMuaz8L+NEGX+YvYxTvrkT40l1C6xv2L ZU57iARx4xvXaszs/wC03P5Odz3c1zvuc1dgGYX6Y9c5Ju6G17gLbEL6keakQ/wwD9FBXVyChCH4 xbeWk/XZ4T9mxX93ZhsPvftMc7hs811UdvFPg1vrDGcXrsMmULGRK0ZUZ9Ndy9i8xq4tcroLKzmj 69UidCDyUvJiqcfbS0pzqOyvtu/ietyoa/mItaTPY+1KiEzn2yI+JUmwW7k338WUGBN5cvCaOdMu UuyZDNZQxYziXJDbzKm5Lrbu4nNTYEXtmTl0SFv7ihR4myHTNsgcmZiYs1hsZt9LU5hEFKcdaRX+ 6nRWyFJHvVISrhSQBtGI7dzfJtq9oDb8/wDL6Pa/bBsvZuYYzFZjJr52Tw4egplRIaUliRIa/JUZ jfMJTFcjxXmrpAWh1+K22rzfa1C21uTGsC7lcj39mrKsws8ns7DT0Grwgaqr8SiXGR0dXgrcIY0n J6zIMYXHYTb5a3fsW0mwiuwbGPIaS9GU7Ot1Br+muMCvKyhTBsdY4PY6zwOYzYWzzmPYhaooI0uq jtzJ0iPJSsYnQoL9jGmy/wDh7CzNX/vUueFpu1XReO5szsKiw+dS5GzlVlm0SLCzjYLeHQswuGZ0 K2yCBrlGVf4eQbac3ZykyZ0fFkKfekuSVs/WCXAAMJ2XuvZFXkFjtrV+fdzmWUNX3C4lrx6bc4pq en7aVUMrcVVq/KsHiVjqKvYFqqqek3VRG2NVxrF05dXR4Fg80lE5EdxGusSlK9QDuJyNGc5qmPF0 328T04oLGlOKT2bZzdVVHYlxW6P81eraZyCJ9HFXaRpMe5sb6fJU9Gmw2nNoWfZh24Wt3Ju7HBLR xb2cs7QdoI+wdkQMKGeRsgYylGYo1/XZhFwNm8eySELt+ZGx5pyXOkSFzG3C86Tt5/UeByNmQNyP VEtjY9fjycVORQr2+rRYY+HLB+PWZDR1NnBxzIm69+2slVbl1VWbta5KMiE4xIaYeZAI7cU3HuHY Oi+03HXNlX2N5L3Dbz21gOabQhQMdOVVOJYLabwyGPR44ZlZaY1XZLc1mv4GLQrGTWvSYNYbGwaS LOC28xx5ptTdOutI97eDVu3LzJsw0BlWv6bXO272vxyRmcat2FQ63yRNblDddWRscurXFp2VWVc5 OXWtvS65yKZ8VpD7a+nzzO2bSE7WdVqGVg7f8BUN67lVDVM32UQbLHMikZDYZOu9x7Ka66jZXR2p vbSwmtzaa7r5SES34n1URHlx1YVnbVpOs1vkupIuEF/Bcxt3r3KoNjkuV29xlF8udBmuWmRZlb3s zM7q3EungtCxsr2W8qvr40FUgw0/hlADYFtb+1dt7LdSYzuXJ9yT8+7VNn7NwdG3YOFNox/cWFX2 JY9Wfg5NBjuLsQ8OyWRm0Z2ZSWjdjXU6qxLTkgIfUlzn7ZMzyKj2PTYDtXLO6iFsXM8AsLn+Dt/0 OsZOE5Fk+KyacZtkWt8v11SOoQ5SqsmY6cXXexa4UEyqnNVLMj2PLeFl2otcZzcPZDldA1cXE7AM k1e/IXNuI6ZmC5tJqp97RKYjWEdlCLObj1S+qYQJ8V2A25GlxXCl1Pldd9tGmtY5NHzHEcZu15LD xxWK1d3l2f7D2NOosYdVXPPUGNubGzDK04zVvmur0SIVA1XMvpitocUUAAAGvdw6g2jO3JiG8NE5 tgdNsei1zf66uMO2nS293iuWYTa39HkKHxY4xcQsgxu0qr2uZaFuxFvTYNvGC9G+ilTitH5h3WbX TozebD1FjOtN4ap3brnQmR32PTm85wGon7YyHWUeBsfHJl5X0apkaoxXY8W5nU+S10ZdbfQlM2v4 xtl2HIdzsztv09tzIabL8zxmxVmVDBfqabMMVzTOte5bHqnXvrv1ZyXX2TYpdSYX1EuOtwrCfKht vrLwQtS3AvOj7c9I0GsMi0xXa+pxrbLHbaRlOPT37S3Vkk60XHFlb3V3bTrDJLe7cfZjFN/Pt/zq O/XV70GVHMOK82ANdgx9k4lsncvbbc7n2BsnFsg7ZpG08ayjLFYwzsrCr5y/u8Qt6hq+oMapIEqp yBJg21W1aUZsKZ2LNgwnn4yXXGmupwWyd9MftNaRsXPkrssj7ML5uwTY0aJUFrIc91bVQaSCEY4W U0NA9L/iTGWpLC5LVxHjvWDxaWUIlA15246g1gjKnMMxWQzLziBGpcnvL7MM5zDJ7mlr470SFSuZ TmGQ3mRQqaC1JmswaWDZNVkQuCUw2h4cHtJmhNRzNN1+g7DDYknUtRR0GM1GJrn2zTdfXYu/Ecxo V9vFnNXtbY08uur5tZbwbCPZVsyLGlw5jMhhDqQBp/cLurLO1TN8Zvb3K7rJtbXnbvsTHaKuyA1z su13/rViBlWFvypUSqhKlZDsLHnL2nejRfpt2NhWIS1FU5G4RrfSm4+4DIMv0T2zZxmb690ay2Ps u17mMgq4dM0Ml13gmN1lxhhXGMNTECnz+y2preCqbXpDzzVDkDcN5Uhtz6L/AHK9H6wzqkwHGMyx oZRT6yynFc1wtm8tb2ymVuVYGhtnG7963m20i3vJNWpQDxyOdZu2ii6bJdgyotvffWam13T7Nync 1XjMGDtHM8XocNyjLWX5ypU/HcWmWD9DXLjLd/Lymvflywl9iBGkzGGI0efIeZjREoAIzbHdmex8 51/s7XOw+5PMcEzPuixDVcm0y7ENT03bdb4VlOz3deTqfFKJtis2UHcbJMDGszhoVIyG7pIkuSqZ WWswnfsSk2puLuf7jMeR3A7JwDDdPWekHMTxLBouDNQjb5BhELKr5V5MyHCruXc1NkFIjmAuQ2Gi 69IZWh9lvjb0bsw7cGLupvYmC2zKse2BH2pQ06NjbQ/gyjz9i2VkDGS0WAOZurBqeWLKS9LcZrsa ixHHHngqOAr29byqcFxbGcmzPN6quTDyTPjRP5famRNfNy5i9R+S1MmRCXJMBhUOpQ3GSK6JDcdC T9ZT3I4AIq802l3QZ1mfcZkWq4u/3bvTO0p+v9UYfg9RpFnSc9rCaLFrqxr9mrzbJYmb20/OnLl1 1+zaNE1jdfJp5MFDzldIivS+1zjz8WFIlRnIMt6FHdlQnXEOqiSHGWluRVOIeebW5FUpbK3GVuNO K+otLivdyW9ZZ2n6JznMLfN8jw6zVkeRO07mUv0meZ9itRlsnHlRXKKRmGL4pk9HjGUzatuvr1RJ d5TT3mvwsYpfL8GGttxrCA0lCEkpb5QlpBBIDaWAENpP1Fke0IJUpRBUoK8EKCiAfT0dHR0Af//Z --=_related 004036BF6525723C_=-- --===============0501745478== 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 --===============0501745478==-- From dime-bounces@ietf.org Wed Dec 06 07:03:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvVA-0003us-7n; Wed, 06 Dec 2006 07:03:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvV9-0003un-Hm for dime@ietf.org; Wed, 06 Dec 2006 07:03:51 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrvV6-0006ie-1X for dime@ietf.org; Wed, 06 Dec 2006 07:03:51 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1165406625!7388163!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3375 invoked from network); 6 Dec 2006 12:03:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 6 Dec 2006 12:03:45 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kB6C3f57017649 for ; Wed, 6 Dec 2006 05:03:45 -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 kB6C3dEk015815 for ; Wed, 6 Dec 2006 06:03:39 -0600 (CST) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 6 Dec 2006 20:03:37 +0800 Message-ID: <4576B0F9.50506@motorola.com> Date: Wed, 06 Dec 2006 17:30:57 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Himanshu Bahl Subject: Re: [Dime] Issue regarding diameter node behavior for same host Identity on both sides. References: In-Reply-To: X-OriginalArrivalTime: 06 Dec 2006 12:03:37.0608 (UTC) FILETIME=[8FDBB880:01C7192E] X-Spam-Score: 2.0 (++) 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: , Content-Type: multipart/mixed; boundary="===============0459833396==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0459833396== Content-Type: multipart/related; boundary="------------030801010100060507040805" This is a multi-part message in MIME format. --------------030801010100060507040805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

Since this is not clearly stated in the RFC, there are couple of solutions to this problem.

-If, you have a static configuration of peers and you expect to have connections only with the configured peers then, CEA should carry DIAMETER_UNKNOWN_PEER as the result code.
-If, you consider this as an permanent failure and don't expect this to happen again then, DIAMETER_UNABLE_TO_COMPLY is the most appropriate option.
-But if you discard the CER and tear down the connection then, the other peer may initiate the connection again later.
-Election is an option, only when both the peers have initiated a connection towards each other.

Looking at the all the options, I would go with DIAMETER_UNABLE_TO_COMPLY since its a permanent failure.

Regards,
Liyaqatali G Nadaf


Himanshu Bahl wrote:

Hi all,

Can you please clarify me on the following issue.
Suppose we get the same host id on both sides . i.e on local node and peer we have host1.x.com (example). Then what kind of processing are we supposed to do at the nodes ?

1. Will there be election lost hence an error code of 4003 ( Election lost) be returned on both sides.?

2. Will there be an error returned with code 5012 (UNABLE_TO_COMPLY ) ?

3. Will the message be silently discarded with no answer messages and connection will be torn down ?

A fast reply will be help full.

Sincerely,
Himanshu Bahl.
Know Me



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

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--------------030801010100060507040805 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAAR CAB/AOwDASIAAhEBAxEB/8QAHwAAAQQCAwEBAAAAAAAAAAAAAAEICQoCBwMFBgQL/8QAQRAA AQQCAQMDAgQEAwUFCQAAAQIDBAUGBxEACCEJEjETQRQVIlEWYXGBFzKRCiMlQrEYUnah8Ccz ODlicrfB0f/EABwBAQACAgMBAAAAAAAAAAAAAAAFBwEIBAYJA//EAC8RAAAGAgEDAwIFBQEA AAAAAAABAgMEBQYHEQgSIRMUMUFRFSIjYXEJkaGx8CT/2gAMAwEAAhEDEQA/AL/HR0dHQAdH R0dAB1xPgKaWCQPghRBISoKBSrgAk+1QB4+/HXIpSUgqUQkD5KiAB/UnwOuB95ltp1S3WkJa QVuKWsANoQkOKWvggpCEf7znxwOFEgeenPHn44+D/f8Ax+31IYP7fU/BceTM+DPgi+p+DPj9 hHH3o+oJr7s52n2r64ycwJEjfezUY/kMmRNVFRhmAuRn6hWZOKV7IseOjNLjG4rkmfIZhIqI OQyHFE1y1MSLMO/rQglKlKSok8cL4SEqJ44HB4daCh9jzzySCfzmvVE7obDvE7y9s7Ix9+ba 65wF04Pr16AH5ESs15hVqmmTkiHIwcZhsZXlM6fkZslLSwHsiq4IeU5+GQq516S3dY33Zdl2 rMutrJubsLA4w1Ts1KnAqUrKsLrYkaLdSQXVuEZPjj1PkTjriGwuZavtIJMZXupzCNmJyjNM poVLL2DK/Wx5xSSL3Mev7YE1SFeDUmS8n3zRJ7uEKXyZISZl6TdU3Q1M0L0y9Pm2GoshOTWc Iq3dUQzdcdpsgyxD2UYgxKYUs0wfwarddxWzWRek5Yw69wlKVLQapOejrH3o5A9yeSeAPcOS QCSAOeSeATx+wJ+B1l1cY82v+/xz/oyP+DB0dHR0AHR0dHQAdHR0dAB0dHR0AHR0dHQAdHR0 dAB0dHR0AHR0dHQAdHR0dAB0dHR0AHR0dHQAdHR0ilJSPcpQSkcAlRAHJIAHJ4HkkAfuSAPJ 6fPwMGZERmZkRERmZmfBEReTMzPwREXyYwd49iuTwDwPjn5UABx/MnjqJn1ju7A9q3ZVn8rH bVMXZO4mn9Ra5Uh1svxLDKYshWU3rHJ5ZXj2Is2syDN5SiJcSKULcSXWUrlikLb+kvlSSRwo DnnyhYIJCeVe0KT+ogfpAUSQASKRfq9bVyvv29SDAO0PU0o2dRrTJIOmMejtB12AjYuRWECV s7K5zbP1EIiY43FrqafMX7Wqmvwq6lSlxmlylIrraWSPY9iUxuCa1W944iiqWmiM3zl2BKaU 60aSNSFMRzeeJRFyTiGiLyobpdA+l67cXUTjzuUqjx9c6uhS9rbInTyJNWzjuHqamR4litf6 So0+5VXszmFGXdTJt3VdyGVJN1Xol+nPie0uzruO2Ntqk/T3UY1kWncBmzISnp9Pr2lefTMz CtDqEoRInbGj18qIlKi8ZevoU0LEWaoOtu9EnduUdmffls/s020+5T12zLm51tMhS3lNxq/c uupll/C85kPFCCzldY3c4/XuMp5u5VhjLccvExkqtmYa1o3tE1BrzV0vN8E1vhWucRosRo3c 1yjH8QZfh00JqCJ0iTdTa+K7YWjjKrCe771resJExxZcd+pxTq9a+/0XH7wNe91HahvPWeaZ RkTNPPzRGtcxoMjsMX2hrKZVHHsrmIobCS3GYvahmkbXIUlP1bLFZLjy3Xpr5XVOTUMPXVHg d9XSYLdzhshhFywiS2mTbRbJ5tVq0Rc+s6hL78plpSkGbbLq1EZk3yW+mgtv5B1o7R6stTZz U5ArWHU3T2UzXVnJp58uiwDJcBjNt67U5IbQdfXPppK2tnWam320T7zHIbJEl2yUbt6BlxC1 JIcQVEFaggp9qgUgAge5RCeFJI4PjwCTyOfr5H7j/XqI/Q3rEdjuxNXa5yXOO4DXmvc8vcQo ZmZYXks6VTScfyxdZG/iCtVJlxG4S4sO0/GoiuuTFfiYy2XkkkJT09nAO8DtS2g9Fb173JaN y6TIUW2a+i2lg8+yW4W1r+mK5m3/ADD6vtSpRbDBWEpJUAAT1f8ACyXHrFLKoV1Vv+4bbcaa ROjm+pLvBoI2u8lJX57FNmXeSyMi5MyIeReVaQ3JhMiyjZVq7Pab8Jmy4E2ZNxHIGq0nYb7k d1xiyOtOFJiqU0tUeY0+qM+wSHUPdpmSXMdHXEiQw4hDjb7LjboSW1ocQpDgUOUlCkqKVhQ8 pKSeR5HI6z+oj/vo8kgfqHkjnkfPyODyPkcHn46myMj7eDI+4uU8Hz3EXkzT9yIvPJcirj8G ZH4Mj4Mj8GR8mngy+/cRp4+eSMvkhl0dJyCeAQT+3I56XrIA6Ojo6ADo6OjoAOjo6OgA6Ojo 6ADo6OjoAOjo6OgA6Ojo6ADo6OjoAOgkD5IHkDz48k8Af1JIA/cnjoJA+Tx8Dz+5PAH9z4H8 +uFa0KQQlaVc+wEIWOSlSwk8FJJAPJHI48/BB8gfj7Fz8cnwX9/9jBmREZn9Pp9T8GfBfufB 8fwf2HIXED5Wgf1UB/1PXS5DdUtFSWd3e29XS0tTDXZ2tvbWMasq66tiD8RLnT7CW/HiRIbM dp116RKfaioaQtUhxLIcUGf96nfBozsf1o7nW47x1djZNPsYRgNG+lzMs5t4rKXFQKWvU6j6 MGO69HTZXkhAgVLbgdfdD6okd6s7LofUs9cnI3LmUtXb/wBnbNktVXHnuWsHXv4eA6tLciJX tIjX26sviJWpb9w4pOJQ5za0RJeLpbcgyOiZNnUakltUtVXy8iyiSklMUkAkF6LZqJJSrKY4 tLEGKf5u03jSpZoPyls/UTtjojpTvtp0crZmeZZRaX0NSzVRLvbGZLNiPNlMuGl6lweiQ+1a ZhkSjQpDEWuNmMlwnG1zEzm2IMuRfvR9f7ty1FGv8G7bIljvnYjMOXCZzGueRT6nx61/DuNx JSL6wjOTMwENS1SlCgrV0UltgBOSvIU62qs72xdp/qK7zzv/ABS7cteblj5Nd2FzYDc0ObN1 vXPSslZlJv7ODsO5ssVgKftotnN/NV01m/Idgy5UJxh4ThFkSF9xdb22+lVt2i7b+3TR+Jd0 ndq7T41Jvdy75r05vX4hlGZyPfjGLYBpmsjoxqFkK4T9bdwly35lxFNvULem2LMqOzJuH6Bx zYmI6l1nQ7byUZltCHiFUNhZK3X1FXFnZhJhNzb9uBW0jLFZCqa6xfdrqduElTSK1iK2HHQA oU9HoLbaOROxcuyFcV3FHFKdrcYikzEqpUlSSTFK7fWlL1qS2u71GI01LTcVRJeUpxbafRi2 3BrvoJ0pRXHTtqGPfQeoBltuDnW9L16Zkmy8doYj/OSq1lQR2W6zBEndNM18W1ucQsJ5Wzb8 3HJSO+WVT7A/9nH7rdjyBkncF3F4NiNpYe12wRXoyrb+UqPKllqxsbiTiVcqWVqUHJEe2tme FrUh53wFuNzD/ZqtbY/qrO7HF98bPy/bMDD7ydhEB+kw/H8RtMwiVkiRS1VpCLFraCss7Jti BIUzdNPttSVL97vtLa7UfXDIBLKwCoc+0EpJSoJKkhXsUOClXtJ9qgQUq4V7k8cixmdK6+bY Uy5UOTHloWk59hPnyJne4nt9dSkSGWFOoPhaFKjnwoi5I0kSS03u/wCp51k3FjElM7Lg47VQ pUeQ1jON4fi1ZQkxHdQ4UBw1Vci6dgLbQUd1ldya1Mckh1CzNw/z5/Sa7Pe2DvK3VsPQPclZ 7Rw7N4tC/kWvG8HyXHMb/FSsXlvRM4xG6hZBheTyJFzAjuxLeubjvRVtV9LeB9vmHISmdTI/ 9ms7UrALOI7z35j7wCvp/mkjAsiaaUSpKFusRsRo1yEoUhYU0X4ylLbUA8hSSUxc+plgmR+m 16puH90Os4JiYznWVR9843Gio/DQZFq5OXB3PgfvYShltm3etLBctptKWodTm8QFDSUsLN0/ WWf43tLBMK2PiNim1xjP8Xpcwx2wbWhSJlLkFXEs4T6g0VttPhmS23IjpcX+GfS42Vck819r PCcRmN5FiWS49CkX2LWj0dyYr1mXp1XMcUuG+brLra3FeVJUtPHDLjB/KiUe3nW11QdQuML0 z1FaL29mFBqDfmA19jEx9h+tsqbFs6omY0HKccch2NbKYZW064jvbV3k/dQshW2fpkSU1w6j 0bfUR7Y1uT+zn1ErFEaIlL0PDMzhZZh+NyFNkBEeXQRrPaGHzStBWFOS6FDJc9jn4ZlxLbjW 78a76vU47VH2YXft2X3W0Ne1TjYn767amot9+CggfSdyHJMXx6VcwRCQtTQkLlx9dFtlbjjN W9JbYgy7BpJA5A5/l/frhfQpxohPIWfbwUkBQAUCSPclQJA5IBT+oj2+OeRasfXzFOr1MWvb 6gMjJXsymrtqp3jj8jtbbLeaNJklKe5l6K8SfBSE+FJ0GuOsS82QhUff2qdSbmS+RpkZG7ik XXGyGiMuDcrs61qnHXm3j8qU3cVN9XPK4KVWyEG4242Hto7vu3fu0xtGVaH2bRZnHjp993RB 81mZYy64VNtx8oxCwbjXVMpa1obaflRhGku8JiPvIJUp0QcQeOFoPPPHCgeePB44P2Pg/t0x zc/YJoPbmWx9oVlFYaY3nVOKkUe+dHzTrvZsWUpCvcLyfVxXKTOK+Ulx6LOqc6p8np5dbKl1 kmA4y+oDYmoZvcFh9lFwPeESr2KkodTju8cEpk0EXIo8eJJfETZev/xEtOAZSluOsmwxiyvs Gv5TqPwy8WmyYOOnstfKuGzRFuo0Zxw+0mrSq9U4T5mZclJhPJTIrX1cl+RLkyKSj592lSm2 V0hldDrizjv3+rru0iR2yckWOAZ67XtZVTMJT3uu02TQG4dJntfHLhK3mqzFciSRGprEn6yL Jt2nRdHSA+B4Pn/y8c+f+n9el6nRVYOjo6OgA6Ojo6ADo6OjoAOjo6OgA6Ojo6ADo6OjoAOj o6OgDhkFKWiVe0JCm+fd8f8AvEcD+ZJ4A/mR56Yh35d8uveyDUKs2v4r2VbCyl5yg1Fq2reW b/Ps0cTFZiV7DMYqmt0kCTY1xvLGHEmPttyGq+DHkW0+uiTHV7d2ng2l9Y5xtfYd7FocJ1/j 1hk+R2jy21fRr6tkyVsR2C4hU2fOWluDW1rCvxdnPkxoEMKlSWUmKjtO7W8s7jdwp9Q7vHop CM7voyUdsPb9dhyXTdvmqX4i1U0u6rZjJbmbPySFMXdXrk2E3LpZtlIXKZjT5DdZjfWb+wsy U1TY/wBhXdgg1e7cSTkekgo7ietZTZkff5MmYTPH/ok8Ev8ASbcMry0/h+FKbsdobbOUrV+G yWmDx6vkrh3ez8vcZ93V69oZSVNHXxHGe20zbI0uKRjeNk2kk/i97j8ae0vtM9LfZ/dVs5zv a9UZ5/MM4yhyJaYJ28SlKh47h9AHTLp6vLadhbjcKlpkkO0+toby4rjn17LOZlvdWltWxLGE Opi1EKFV09ZFqKuviM19fArIrcODCgR20tw4MSJDYS3FixkpLbDLKWY8NpLTLTJQSvrtmwpL rXLKkj2kqcV7iEkpWpSFefaFEkq94H0k8loH3KHX3cjnjkcnkgcjkhJAJ4/kSAf2JAPz19Mc xerxiMbcNDjsuQv3FlZyXPWsbKY4SVSJEuUrucUbzhKX6aVJaR3GTbaCPgcDc+8873jdxZ+V SIdbj9HFTU4TgOOxiqsIwHHo6UMxaPFaBtSocSK0wyy07LeRInWRNpenyH1Ggm4RcN9FvAIP einvV2Tu3N9q5cNl3ez3cPvcWpIOOuXsr8yXi8NT7Lrs1VZhj0ineqG0JAV/DtfHWlLJWRNd HbKF8lCv1F0+4hQ4K3FL58jwHPJIUR7fagDwtI6+3o65VPQVFCiaiqhNxTsZrljNcSa1uypj pmbj7zjilqWo+VERckhKT4SkvJnDbK3Bsjb8nG5Wxcok5GrEMdh4pjLLkKrrYVJj9ebhw6yv r6aDXQWGGSecSSyjm+42TDTry2osdDZ1xu8/TPA5PKeB7VK/50/ITyeB8k/A+T4B6z9yfjkc /HyPnkDj/Ugf1I/foJA+SB5A8kfJIAH9SSAB8kkcfPUx/wB9hWhlyRl9yMvJcl/b6/wI8/UJ 9P3XnqEa0xfAc2vrnCbXCMvRlWN5pR1EGztYgXXzqm0pFxZyo7MiruWHYz8tBkAIfr4ElI97 aEq2f2Tdscns+0RjGg07GyDadFh8+6Xi+Q5LTxKS0rKK3kqtWcdXEhKeaciVljKtVQ31OIUz Fmxq8BSIjaW3fcj9/wCX9+OeP9PP9OjqHbx+mau3cjagNN3MiGUGRObU4hb8VJNEht5BL9Jw 2/Ra7FmjvL00l3cEXFkStu7HnavrdLzcplS9ZU2RO5VUYtJhVL7FXevlLTInV9g9XruYhvpn S0vR2LFEJz3Utw4xPSXXTOjpApJ4IIIIBHBB5BBII/cEAkEfIB6UkAEk8AeST8AfuepgVwDo 6QEHngg8fPBB48c+eP5EH+h56Xkfv/P+379AB0dBIAJJAAHJJ8AAfJJ+wHSBST8KSePngg8f 6dAC9HScj9x4+fPx8f8A9H+o6XkfPPj9+gA6Ojo+PnoAOjpOQSQCCQeCORyDwDwf58EHj9iD 0vQAdHR8fPSBSSSAQSPkAgkeAfI/opJ/ooH7joAXo6OkCkk8AgngK4BBPtVz7T/Q8Hg/B4PH wegBejpCQPkgckAckDkkgAefuSQAPuSB0vI8+R4+f5f1/boAOjpPcnz+ofpISryPCiAQk/sS FJIB8kKB+46UEHyCCPPkefg8H/Q+D/PoAaBt3UVlvvZWA4zltW4jRmqbOp2nfVE6M+YG1toV chT+uaSfBUlBscO11IYczi5r3VuRrzMhhEV5DzFBdRHXWRWnGvoNrW59NkL496VIKllIbSVK 5LZSVF1SGx7faFtISkBtPPZ9YqBUkgHjngH5/wAvI9wHBBBKeQCD4JB+3XFZiNMuy5BF3SJj qVvPqIvUNDfBMsJPjlLDKS7UNkfHKnFmXc4oxN2l9Ota6hp3TbZqschuRq2AylSWESZchU21 tHSNXc/Z2s1xTsuY8bjpsMV0BCkwquAyz8thOhVsGZYWEyPAgwIr06dOlOtsRYMOM2t5+ZKe dUhpiLHaacefedWhptltxa1JQhRERnp0eoWnux3L3N4JeTkNxa/LpWfaPjvtpiyHdRttVeMO V76FqSpc6pU1QZFNSlK1B/NpyHuDAJT9vrGdyo0b2p2mDU8xUPOt9S5WA1Jjuq/FwcVRGjy8 /vG22iJX6Kl1nGWS0CPxWTQ/1h12OlcME/T2del1sbsY7nJ7lmqJmuNR5O3q9YeJqLmzXNez 3CH2kNoQlYwTJI8mPHkcOHJcYu5DaB9FoM8oQguIAg88EHjweD8H9j+3Qfg/fx11dNbV15V1 NxUTY9hU29ZCtaybHdbeZm19jGblV8th5tS23mpMVf1W3W1KQ4g+9JKTz12vQBAx31+pJ3Qd vvdmnt10lrzAc7/MsZwmfjdZZ47ld1mF1kOVN2HFVWMUmTQvxLrq4v048duCt59Q+iyhb6+T oS59Wf1BtLSItv3CdndXjuHOPobmGxwnZ+ufe2ocOJj5TeTbmgiPO+5IbcsYTscrKW1rjBf4 lrpO8ydCrPW20DYWMyNX18K07eJU2dNksQ4kSKxOvnH35MqStuOww22lSnXHXEISgHlQ6mL7 yO5ntfxDt721W7A2NrHIm7/AMop67B2MioL+8yy0tKR2LVV9ZjsCTMsJDr0ybAKZzDHtrULT ZF1pMdLiQDc3a33J6+7sNQ0G4NcrlN1lk/LrrqktGw1d4nk9cloWuNW7KWmUtzYKJUdxl/2J /G10mJLQktSUlLi1AEcHnjkfHPPIII+PI4PB5+3zyOOeoGvQKxXJ6nt727lFmy6xi+XbPhIx RSvrpjT3McxaurL+fAbeAQuKmapir/GxytmdJq5X+8U7FdCJ5ugCHDVfqAblzX1Ms57OrXHs BY1njNpnkCHdQq+4ay51GLYhHvYSn5bt6qsUXJbyG3vZVOksKdSkNKCHWpjVn2pJ58jjj+Z5 HtT8jkqPCQOfJPH36rH9vv8A8+LbX/iTcv8A+Na3qze5z7FFIUVAchKSElRB5CfcQQkK/wAp V/ygkggjkADde5Puf1P2qa6lbI2vd/gq1UlNfj9PDDczIsvu3m0uR6rHa1Cw7Nd9riVylstr RBgpfnyvpxmVuGCRHqb+o33U2to92d9uLNbhUCS621aNYkvN7FgAOfQYu8uvLOl13DnOIQXF VsUzZiASgttuhDrfjO7qJb9/XqsY12uzbSZG1lrWbHxSdGiyHW0t09FjYz3aNyhDZLLV9eql v4jEfdSlcKPHgocLaX0A2ZsFwjFtbYxSYPg+PVuLYpj0FiupaGliMQq+vhsAtIabZYabQuQp KW5EyQ+49Ikvrff+o4palrAK+mtfUg9QzT+4tY6z7v8AQ0Fmj2Rm2MYPHv52GWeBTxJyO1jU yJFVklVPs8JtnITs1ua/GZRIdejsPNM/SecQ6mxuQv2pSnzwtQPuUpfuSj3JBWogpT71hAWA hZSCogAgLb6DJsVxvMK9NdlNBWZDWMT6+3YhW8BqxaZs6Sxi2tXNYjSWSpqVBsYESdDdaWla JMdpaOfAV6NKT7vjjgnnkEpACQE/TBICOQeVe33DkKTzz5ABHj6lfdbsXs60LRbR1jUYrc39 lsyjwx2HmMOymVSa21pMms3nmmKqyqpKZCX6dltpRlNpV7iSHEBKFxV416mvqpZpR1OU4h2h 1eVYzeQ02FPf0Gndp2dHbwV8obmV1pFyiRHnRFufpTIiLdaWoewOAklLvvXbIHZ/hvJUnnf2 CpSUqCD9RWNZ2loFR8BBcKQ5zwPYVckDz1o/tB9W3tK0d2zaW0/nLu0TmOA4LVY3kLdbgTlh XNWUMqL6o89VlGbkoUuWwPAPHKTwPggD1vT97ku83fOTbJg90mhlaep8bpccm4jMXgOZ4Ym3 tLKXZtWsRp3LbGy/HLhR2GFvIiupXHDzRcShDyQuUBzj2K5HI48j2lY/ugEFSR8qSD+pPKfP PHTM+1Dvn0d3kzc6i6bVmK166boHMhGVY2vHShOVKuV1qoqHH5AkoV+SSU+9tfHP/fKHFB5/ 9egCIvc3qSVnbL30y9Dbjbjx9K5Pg2v7OnzKOgtv69yi4N/FluX6Twmdilq5Dr0yJ44TQKfE +W4xBjSAZZK2dBtYUK0q5kOxqrGKzPrrCBIZmwZ8OY0iTDn18yOt2PIhyorqXmH2HFsutOIW 0taFBSqnPqva7ttuepjiGrMesIVZebBwvVOLU0+wW4ivjWtxMu4ta5OdZSt1mGqWppEiQ2lS mGVOPpBLfjt+ybvx2v2CbHsO0zuzrL2HrWltnK1sWjMmXcacdcdbiwrLGlcLfyDUN66hFk0k LdbqBMMuqffrTYFABY97rNp5BpHtw3PtzE4tVOyXXmB3eUUkO7bkO1MmxrGA9HYsW4kuDIVG cXwl0NS2VcHklSeUKbt6avdVsPvC0FabU2VVYpTZBA2RkWHtw8Nh2MKnVWVNPjsyK+WbW0uZ n4px6zkB0iUy3whBS2B4Pe99l9SZN2Cdxd/jdpXXVDeaRyG1prWoksyq2xrZ1e09En1z7Clt uwZba0uJKVq9jqgjlXghpHoS+OzbJOfHO881SOfH6hj2Gkp/+4DyR8geT0ASvbhyDLMT1Psv KcDpjkWb43geWX2H48IUqyVfZPUUc6fRUyK6C/Gmz3LSzjxoLcKG8mXKW+liMlx5aGl1zcz9 U/1ONY0DmVbH7V8ZwPGGpcSucv8AK9TbVx6jZsJ7q240Iz7TLYTKZMp/2NRG1hS5JJ+kkjlQ s8H48c/I+OOfkfv4/wDXjz1EZ62njsYuwBwFbT1d7h+gc/8AHxx/9Xk8c+3zwPP6eOgBh+He pv6pWwKelyvDu0mpy3D7wtvVuS4zqHaVrS2kFMxUSTJqraFlMqNNQy63IZU7FXIaRIZcadHL bqBZTil9UOO4+221IUwwt5LaVewOqbaL6UJcJDfsdHDBddd4Skcq9o5DDPSzSlXYD20ghKkn D7nlJb+4zXJT8nx4IHkj9X9upAyASOftzwPt8ff7f056AI5Mn2t3mYvGcTT68ibCesLDfeOx kw9d29E5TT6PNavCtM5ZIK8hlx5+O3jJl5tkLfsjrs8bnTrCoW5CgJcS/XFpVxPxnHrC7jmu u7Ckqpt1BMOSyYttJgsO2EcMOSHXYyGZSnWm4z7i347SEMvH6iFdem4H7D/TpegAJA+SB5A8 +PJPAH9SSAP3J46wWQUnjz9jwfIHPCiOATygcngDnkcDz1kQD8+fIP8AcEEf6EA9Nx7sso2t iXb5tKy0ZhV7nm3pWMTqLX9DQJjCa3kF+W6iNffVnSIkFlnGxOXkLxlSmUPoqlR2y486hpwA q0d/ndTF3J3/ADeWMYrO2nqvt0ySkxeiwWukyxX5bEw26/MsvmS5lXXXZiQ8izY2FQqwEF9m VTVVQwXENONuo9N3jepTl3eNpmXqTJ+0yZi0lq7qMmxrKod1kN3Kxy6pZbrK/wANXO4TXIlR rWoXNppDQnMI+hYJnBL30W21zCekJ2dZb2z6ey7L9s4xMxnbu1cqdftqi5MGTd0eK4yqdAoY c2VEfnoVMuJsy6yCxdblIMr8dAUv6iW2+ZeXEpW2tKx7kKSQtBQHAtB/zoKClfvStPKVJ9pJ SSB54PQBD/6L/cd/jD2vtauvLBczM+32XDw1apL4emTdf2cQWOv7FxxThdkliC3OxxyR7Cgr x4K+oVPcCYLkc8cjnjnjkc8fHPHzxz45+Oq/usu2XuC7QvU/ybM9ValynKO2Dc02Y1kVxj4q XarGa/Plm8dYkpn2Ilx0YTsOOuQ079BJi4xLdaBYjSQ4J+wnnjn3LWCOSUrQB7SptS2yQPYp Q8kJPtcT5A9q/eQCsD3s0tTknrT6PoL+sg3VBfPaFp7qqs47Muus6eydyKFaQpbEhDjLsd+G 8+06FAFIUVJW2tKXEs87m+0bWfYz3kYtXbhwy9zPtIzG/OQUAqLCbUz5mFvuPIuMcm2MRQlu XmvJ01h+2gNORLLMqRUd6KqI/NtnYUovcx2x9wGY+rZo3eeM6jyi61Ljljo1y9z2GquZpq5n HrO5kXUib9Wx/Er/ACxtTan22Ya3El2Ol4NIeDolK7zO1XGO73R2Rasu0tV12lKb7X2Uvtly Vima18RYqZ6fYfqGrkhTtVf1yv0WFfPlfp+s0ytIBu/UsHXVZrvBoeoYWPRNXpxmqdwdOKpj tUJxmXCal1MqsbipQw4zPZWqVJf4TJelrU9KbkOuuSxsskAEkgADkk+AAPkk/YDqD70nIHed oo3nbR3EaXz+r1fWO3VlrHYc6RS2dDj02JIeNvjKpcW1dntYzkDiX7zG3HYi0sWsmVGaCIdh GW3OAocpUCOQQQQQCCCODyDwCP3H36AKxvb4QfXj22AQT/Ee5TwD9v8ADauTz/T3Ap5/cEfI PVnI88Hj5+fjn488f3+P79QAaT7Yu4LH/WI2Pvu81VlVdpy3uNnPV2fykU5x+Q1c4SmDXuxy i0Nk2mbODURlaYTwddK0LKEJdcan+X/lP6fcQQQnz5UCCn454/UB+o+E/wCY+AegCq9nmSR+ zP1p5Gws75gYJsbJFWxu5TTjcNvG9s4ezjL1oZcgNsJh47liYiLab9X8NXx2ZC5TraG1nq0x GksyGmZDEhEph9tDjMhlba4zzLyC+y+04glt1DjJQpDjSloW2tLiSUH3BhXfh2G4J3ta8h1V i81i2zMVROcwHYCYCZJr0WCW12GN3UMvNPzcRvXEJ/MIpW9MqpLaJ8CNJU0qHMh1wnJfWN7E Yidasansd5a6oVqZx5xOK2G4KGFBcfb+mxj19idzWZtU0v6EOtVuR/SVXEliPVNrKV9AFogq SPlSR+oJ8kD9SuPanyf8yuRwPk8jj5HS+5Pg8jg8AHkeSTwAP35JAH8zx1Wpxu39XHvP2rq4 bB13bag0hjWy8HzTLKZyikalx6yqMZympvJMG0Zye1l51mjYRVocr4AifQTYpivucsIfX1ZN SlZ8f7xKf8iSkBASAp3yEFQKR7VJT5bJHAUPACwAQveu6QOzvEv1FPO+MLT7kngjnFs9QeSA SACoBfA8AkeOevT9iPZN2l7A7Pu3vNsy7fNY5HlOSa1p7S8vrOhalzrKxkofakypMmQ6pxxT 30mwFBHtJQDxx+oek9X/AEttfe3bHi+Gaf1/ebCySLuTEr6ZSUP5eiWzRQ6LMYc6Z7p0qIEo ZcnxfqLU+02S6hHKnHENrjH1PmvraaX13h2qsH7f5cPEMCoI9Bj8axwDB7WUxXww19EO2Csx ZdedUX3EHyVAJWopIQUgAsVak7ddGaIfu3dN6tw7XByRutZvTi1RFqxaJqBOdrfxBZQVPfh/ zacEkuJ49x8KA5O7VeByfjkf9R1Fr6fGx/UGzrKtlsd6WvnMLx6BSY/JwKQvFMcxxU+2kTLB i2YL9BeWzk1LENllxTU5DRZ+qy4OFON++Uo88eP3H3I+48+P2+ePhXwfB6AKxveh49bDtnJK 0/8AE+3cgtr+ks+3JLUn2L+3HI9x+ADwrgHnqXHvu7Ctc96GBqjzlRsT21jEKR/h/sNuOHzA fDQeXjuRxR+Hdu8QtUpXHsGBIbnwVv8A5lWvMPx0pMf/AHVdsfcDmnqvaI3dimqMovdT43Za TeyDOYIrW6muTj17YSrlUpT9h+J+lCje0u/ThL+it5kv/TaV9YT9K+p7VK4V7gSEpA4UoKDa gCk/o+okj2JcKvY3x7lH2hSegClS3v7uN7M8B7iew3emO3czFc0w7JMbpaCdZOqdwu7uFttQ 8vwG5kstsWeAZIt5LzrMMqqn5spmdHFVdKuq2TN16FHP/Y5yb3BfuG9845cV+lTi/wCGMGC2 3U+AXWlJV7vaB5VyR08PvY7HtZd6OvHKHKI7dHsCkalva+2PDhNm4xmctBQuusB7UuW+L2aQ uJb1jrji3Y8l+RXFp8hw6a9J3Quzu23QmwdV7YoHaPJ6femZPtSGkoXTZHSuY/iEaryTH5SU +yTRWgivKiJZW4YT8eRBkOCQw82ACUU/H9x/1HURfrakf9hq6PI4G09Xcn7D/jwPk/A8efP2 8/HUuakhQ9pAIJSSD8EBQPx9/jwPgn58dRnerHqHZu7O0S3wfU2GXGe5i9sLX9yzj1GY4nPw am2U7PdaEyRFjBEaNy664/IZSkDlBW6ptlQB7H0sf/gC7af/AAfc/wDnmmTEf6jz/Tz1IF0y j07df5tqzsz0NgGw8assQzPGsYs4mQY9chk2lZIk5Rfz2WZTkV+THU4Y8lhfsS4SltxBJTyk Lev0AHR0dHQAdHQSACSeAPJJ+AP3PXk84zfENcYlf5xneQ1WL4jjFe7aX19cy2IddXQ2iEhx 959SUfUeeU3GisJ9z8uW6zFjNuyXWm1AHqwQSQCCRxyAfI5+Of6/b9+l6bzqruh0puXJZeIY NlVg7lkOlTk/8M5TiGbYDez8YcXFYGT0dRnmO4/OvaBEmfCiuXFI3Mq21zowckgyI4ccH9Rs jkOII8+fcnjx7ufPP29i+f29iuf8p4AM+jrErQByVJA8+SoAfpISr7/ZRAP7EgHz0oUkkgEE jyQCCQCSASPtyUqH9UkfIPQAvR0nuSDwVJBBAI5HPKv8o4/c/Yff7dJ7kgFRUkJCfcVcjgJ4 J9xPPATwCefjgHz46AMujpOR58jweD5Hg8e7g/z488ft5+OsHFN+1SVqQP0qUpKiOfpo9pcP HuBASFJ5VzwgqST8gEAy9ySUgKSSpJUkcjlSR7QVJHPJSCpPJHge5PJ8jnLrxUzNaOqzbHsD mOzk5BldPkOQ1aGaW5mVi4WLqp49sqdfMRXKenke+6giBCspbDs9piT+DS642tCfaFSQQCQC fIBIBIBAJA+/BUkf1UB8kdAC9Yr/AMpHnyQDwAfBIB5B5HHHPJI8Dk/boKkj5UkfqCfJA/Uf hPz/AJj9h8n7ddU1e0ku1ssfiXFVKvqmHXz7WkYnxJFtWQbdc5qpm2NY08qbEh2btZZNwJEh ltqcuuntxVuriPhsA7JJAV7R7QE/oSn28KACeTxx49p8ccAJ48Dz88vXisDzih2HQQ8qxp+w ep57lnFjm0qrSjnl+mtptTYfXqbiJDnxEJlxj+FW8yj8XFcakshyM4y6r2fvQRyFp4Pt4PuH H6vb7fv/AM3uT7f39yePkdAGXQSB8nj4Hn9yeAP7nwP59YhSTyApJI45AIPHu+OfPjn7fv8A bpFLT7SQtPABVyVhI4QR71E/91P/AD/YfB456AFKkhXtKkhXHPtJHu45CeeOeePcQOfjkgfJ 6X3J9xT7h7gOSnke4A/BI+eD+/Wkdr9wGqdLScaq88yGXGvsvcskYvi2O45k+a5dfM1bba7i fXYhhdTfZBKralMhkz5yat2JDLzKX3mlOBXXpdX7VwPcOLozHXt7+c0KbSzpZKn6uypJ1XdU jrkO3pbalu4ddc0lrXSUqROgWcOPLjOAtPNNqJHQBsr/ANf6/HRyOeORyPkff7j/AKgj+x/b rgkOtMsuOuuoabaT9V1xSkBLbaOVLWr3ggJCULJ8c8JV7SFAEahwDe2rNkYaxsTF8oZRgcm/ /huqye/gz8RprqydnsU9Ycdl5NAqWbyqvbCXHiY/bVb0mFdy340WqfluPhroA3L1ilKU8+0A cnzwOOT/APv+vSFxAIBWgEoU4AVAEoR7fescnyhPvR7lfCfcnkj3DnL3J549w58eORz5JA8f zIIH7kED4PQAvR0gIJIBBI+QCCR5I8/3BH9QR9j1ipxCUqWpaEoSkrUtSgEpQkElalEgBIAJ KiQAAST46AM+jrErQkcqUlI8jkqAHKQVEck/ZKVE/sASfAPShSVc+1QVwSDwQeClRSQePuFJ Ukj7KBB8g9AC9HR0dAGKyQk8fJ4A8c+VHgEj9gSCf2HJ6Y936qgp1jqo3TrKMd/7VXbD/Eip 3tTVJoTuLFkzDdIebXGXUpkmIX/xiPwri1sMuqAWFF8RIA8/ukf3KgB/5kdeRzbB8Q2Til3g +e43V5TimTQn6+8x+3jplwZ8V0BJ5CihTLzRSiRFlx1sTIcltqXDeYlstupAPA5ajTR2pqNe XJxv/F9KM9TqAzVOnJPot0f/ALQ/yV2O6txNYzSPJRPVKAhV/uYS2EzDFZMeadn7rb1nH7vf 8bcqkPy+5pnXX+BCazFXdaDX7/cc7oJvEG68UTWVHL2qt2Jl6MkRfRrI20f8E/FejPuxXn36 07X9J6iyVeZ4RiMxnJ3aFjF2L/I8yz3P7qux1t1qQzSUNlsPKcofx6lU9FiuqqaUVsdcmOyp 9TjTaeuvT2n6BGeObMOBn+Jmsve2A1EXlmcuYY1nrzSlHMG9bHI/8N2MpeDypku+ZxM2jtlI csBPM5AkdADT86kbrzncneqzQ9xOxtdVHb7jOsrvWeL4rDwdVKMgstSysysBlKchxG1sMlo7 KxhK/GVi7GMpyMt5ceQ062gp+HV2Zbpx617HtlZNunLNiNd2TcKPsbBb+qw6JhdAvINH3G1a O013BpaOLY4wKCfTJgymZt/ZLtotk44GElIDcgqdSa+ZtdnXYogq03NCrKnZMhyxuFjJ4NTS SMVgQ1NGwU3Wts0r8iAw7WGG4y077wr6iQofGzpLWUSv1FWs4uhUPQrsV/UzbltePqxAwcWn 4RHLTkq0fdtExcTspVQlNy7ZAMvfXYQ3MZjvtAEZOwMm7hE637yt+0ncdnVLZaB3Vsin1rr8 UmDzNdjF8LbxYzKfLq9eJC/ydNsbSwRHEjIIS6ySY76TKTHdjLc/gbW0dTdzeB6xv90ZxuLF Ns6Z2JnNqnYsLDW7LHM419kWuIq7LEX8QxbH2q3Hbevzh+K/is1NkmHIr62RClcIkOOONnaJ 1VOxDZGASsXbkYpty6vsm2HSrs74JyS7ypyJ+fT1zE27cyvNoIjDK2K6TEYQAkFn6P1W1+rl YBh87NsW2BIqg9l+IY3kOKY5ciZZIXX47lb1HMuaz8L+NEGX+YvYxTvrkT40l1C6xv2LZU57 iARx4xvXaszs/wC03P5Odz3c1zvuc1dgGYX6Y9c5Ju6G17gLbEL6keakQ/wwD9FBXVyChCH4 xbeWk/XZ4T9mxX93ZhsPvftMc7hs811UdvFPg1vrDGcXrsMmULGRK0ZUZ9Ndy9i8xq4tcroL Kzmj69UidCDyUvJiqcfbS0pzqOyvtu/ietyoa/mItaTPY+1KiEzn2yI+JUmwW7k338WUGBN5 cvCaOdMuUuyZDNZQxYziXJDbzKm5Lrbu4nNTYEXtmTl0SFv7ihR4myHTNsgcmZiYs1hsZt9L U5hEFKcdaRX+6nRWyFJHvVISrhSQBtGI7dzfJtq9oDb8/wDL6Pa/bBsvZuYYzFZjJr52Tw4e gplRIaUliRIa/JUZjfMJTFcjxXmrpAWh1+K22rzfa1C21uTGsC7lcj39mrKsws8ns7DT0Grw gaqr8SiXGR0dXgrcIY0nJ6zIMYXHYTb5a3fsW0mwiuwbGPIaS9GU7Ot1Br+muMCvKyhTBsdY 4PY6zwOYzYWzzmPYhaooI0uqjtzJ0iPJSsYnQoL9jGmy/wDh7CzNX/vUueFpu1XReO5szsKi w+dS5GzlVlm0SLCzjYLeHQswuGZ0K2yCBrlGVf4eQbac3ZykyZ0fFkKfekuSVs/WCXAAMJ2X uvZFXkFjtrV+fdzmWUNX3C4lrx6bc4pqen7aVUMrcVVq/KsHiVjqKvYFqqqek3VRG2NVxrF0 5dXR4Fg80lE5EdxGusSlK9QDuJyNGc5qmPF0328T04oLGlOKT2bZzdVVHYlxW6P81eraZyCJ 9HFXaRpMe5sb6fJU9Gmw2nNoWfZh24Wt3Ju7HBLRxb2cs7QdoI+wdkQMKGeRsgYylGYo1/XZ hFwNm8eySELt+ZGx5pyXOkSFzG3C86Tt5/UeByNmQNyPVEtjY9fjycVORQr2+rRYY+HLB+PW ZDR1NnBxzIm69+2slVbl1VWbta5KMiE4xIaYeZAI7cU3HuHYOi+03HXNlX2N5L3Dbz21gOab QhQMdOVVOJYLabwyGPR44ZlZaY1XZLc1mv4GLQrGTWvSYNYbGwaSLOC28xx5ptTdOutI97eD Vu3LzJsw0BlWv6bXO272vxyRmcat2FQ63yRNblDddWRscurXFp2VWVc5OXWtvS65yKZ8VpD7 a+nzzO2bSE7WdVqGVg7f8BUN67lVDVM32UQbLHMikZDYZOu9x7Ka66jZXR2pvbSwmtzaa7r5 SES34n1URHlx1YVnbVpOs1vkupIuEF/Bcxt3r3KoNjkuV29xlF8udBmuWmRZlb3szM7q3Eun gtCxsr2W8qvr40FUgw0/hlADYFtb+1dt7LdSYzuXJ9yT8+7VNn7NwdG3YOFNox/cWFX2JY9W fg5NBjuLsQ8OyWRm0Z2ZSWjdjXU6qxLTkgIfUlzn7ZMzyKj2PTYDtXLO6iFsXM8AsLn+Dt/0 OsZOE5Fk+KyacZtkWt8v11SOoQ5SqsmY6cXXexa4UEyqnNVLMj2PLeFl2otcZzcPZDldA1cX E7AMk1e/IXNuI6ZmC5tJqp97RKYjWEdlCLObj1S+qYQJ8V2A25GlxXCl1Pldd9tGmtY5NHzH EcZu15LDxxWK1d3l2f7D2NOosYdVXPPUGNubGzDK04zVvmur0SIVA1XMvpitocUUAAAGvdw6 g2jO3JiG8NE5tgdNsei1zf66uMO2nS293iuWYTa39HkKHxY4xcQsgxu0qr2uZaFuxFvTYNvG C9G+ilTitH5h3WbXTozebD1FjOtN4ap3brnQmR32PTm85wGon7YyHWUeBsfHJl5X0apkaoxX Y8W5nU+S10ZdbfQlM2v4xtl2HIdzsztv09tzIabL8zxmxVmVDBfqabMMVzTOte5bHqnXvrv1 ZyXX2TYpdSYX1EuOtwrCfKhtvrLwQtS3AvOj7c9I0GsMi0xXa+pxrbLHbaRlOPT37S3Vkk60 XHFlb3V3bTrDJLe7cfZjFN/Pt/zqO/XV70GVHMOK82ANdgx9k4lsncvbbc7n2BsnFsg7ZpG0 8ayjLFYwzsrCr5y/u8Qt6hq+oMapIEqpyBJg21W1aUZsKZ2LNgwnn4yXXGmupwWyd9MftNaR sXPkrssj7ML5uwTY0aJUFrIc91bVQaSCEY4WU0NA9L/iTGWpLC5LVxHjvWDxaWUIlA15246g 1gjKnMMxWQzLziBGpcnvL7MM5zDJ7mlr470SFSuZTmGQ3mRQqaC1JmswaWDZNVkQuCUw2h4c HtJmhNRzNN1+g7DDYknUtRR0GM1GJrn2zTdfXYu/EcxoV9vFnNXtbY08uur5tZbwbCPZVsyL Glw5jMhhDqQBp/cLurLO1TN8Zvb3K7rJtbXnbvsTHaKuyA1zsu13/rViBlWFvypUSqhKlZDs LHnL2nejRfpt2NhWIS1FU5G4RrfSm4+4DIMv0T2zZxmb690ay2Psu17mMgq4dM0Ml13gmN1l xhhXGMNTECnz+y2preCqbXpDzzVDkDcN5Uhtz6L/AHK9H6wzqkwHGMyxoZRT6yynFc1wtm8t b2ymVuVYGhtnG7963m20i3vJNWpQDxyOdZu2ii6bJdgyotvffWam13T7Nync1XjMGDtHM8Xo cNyjLWX5ypU/HcWmWD9DXLjLd/Lymvflywl9iBGkzGGI0efIeZjREoAIzbHdmex851/s7XOw +5PMcEzPuixDVcm0y7ENT03bdb4VlOz3deTqfFKJtis2UHcbJMDGszhoVIyG7pIkuSqZWWsw nfsSk2puLuf7jMeR3A7JwDDdPWekHMTxLBouDNQjb5BhELKr5V5MyHCruXc1NkFIjmAuQ2Gi 69IZWh9lvjb0bsw7cGLupvYmC2zKse2BH2pQ06NjbQ/gyjz9i2VkDGS0WAOZurBqeWLKS9Lc ZrsaixHHHngqOAr29byqcFxbGcmzPN6quTDyTPjRP5famRNfNy5i9R+S1MmRCXJMBhUOpQ3G SK6JDcdCT9ZT3I4AIq802l3QZ1mfcZkWq4u/3bvTO0p+v9UYfg9RpFnSc9rCaLFrqxr9mrzb JYmb20/OnLl11+zaNE1jdfJp5MFDzldIivS+1zjz8WFIlRnIMt6FHdlQnXEOqiSHGWluRVOI eebW5FUpbK3GVuNOK+otLivdyW9ZZ2n6JznMLfN8jw6zVkeRO07mUv0meZ9itRlsnHlRXKKR mGL4pk9HjGUzatuvr1RJd5TT3mvwsYpfL8GGttxrCA0lCEkpb5QlpBBIDaWAENpP1Fke0IJU pRBUoK8EKCiAfT0dHR0Af//Z --------------030801010100060507040805-- --===============0459833396== 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 --===============0459833396==-- From dime-bounces@ietf.org Wed Dec 06 10:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryWg-0004Iy-6e; Wed, 06 Dec 2006 10:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryWf-0004HE-1W for dime@ietf.org; Wed, 06 Dec 2006 10:17:37 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GryWd-0003pl-IJ for dime@ietf.org; Wed, 06 Dec 2006 10:17:37 -0500 Received: (qmail 69264 invoked by uid 0); 6 Dec 2006 15:17:34 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 6 Dec 2006 15:17:34 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Dec 2006 16:17:32 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB4CAF@lulex02.ad.operax.com> In-Reply-To: <4576AA74.7070404@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Auditing & ETSI TISPAN Thread-Index: AccZKlUiUtvDQ1RwScSNYV8CxUPn4wAH0erQ From: "Ulf Bodin" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dime@ietf.org, avri@ltu.se Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN 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 Absolutely.=20 Rgs Ulf =20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 6 december 2006 12:33 To: Ulf Bodin Cc: avri@ltu.se; dime@ietf.org Subject: Re: Diameter Auditing & ETSI TISPAN Hi Ulf, thanks for the quick response. Please keep us up-to-date with regard to the outcome of the discussion next week. Ciao Hannes Ulf Bodin wrote: > Hi Hannes, > > I've submitted a draft LS for the meeting next week jointly signed by=20 > myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition=20 > will be taken next week on sending the LS to IETF. > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 6 december 2006 11:44 > To: Ulf Bodin; avri@ltu.se > Cc: dime@ietf.org > Subject: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Avri, > > what is the status of the liaison between ETSI TISPAN and the IETF=20 > DIME working group regarding the Diameter Auditing work? > > Ciao > Hannes & John > > PS: We encourage you to continue your work on the Diameter Auditing=20 > requirements draft and also to start your work on the solution document. > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 06 17:45:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5W9-0008Pz-4U; Wed, 06 Dec 2006 17:45:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs5W7-0008Pu-SO for dime@ietf.org; Wed, 06 Dec 2006 17:45:31 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs5W6-00078Z-FO for dime@ietf.org; Wed, 06 Dec 2006 17:45:31 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kB6Mj5j7021692; Wed, 6 Dec 2006 17:45:05 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <457747F2.7020002@tari.toshiba.com> Date: Wed, 06 Dec 2006 17:45:06 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Tony Zhang Subject: Re: [Dime] Re: Input for Diameter Test Cases References: <003901c718e1$7a99b370$6291460a@china.huawei.com> In-Reply-To: <003901c718e1$7a99b370$6291460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id kB6Mj5j7021692 X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: dime@ietf.org, "'Tschofenig, Hannes'" 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 suggest add test cases: > (1)Use DWR/DWA detect connection status. > =20 I think this is already covered in Sec 3.1.1.5 > (2)Routing based on longest-match-from-the-right on the realm = rather than requiring an exact match. =20 > (3)For Redirect,the loop maybe happen, should test it? > (4)Routing should test default route entry? > =20 For (2) and (4) I'm not sure but I think this is an implementation=20 specific functionality. If we add this as a test case and others does=20 not support this then we are raising an issue that may not be an issue=20 at all. > (5)For connection ,should test more Negative test?like no respons= e.no CER etc? > =20 It maybe a general statement but Sec 3.1.1 says test participants must=20 conform to the peer statemachine. This includes Timeout during=20 Wait-Conn-Ack. I know there is a tendency to add minute test cases into=20 this document but we have to think more carefully on what we want to add=20 since the document may get extremely large and therefore maybe less usefu= l. best regards, victor > Thanks! > Tony > > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Wednesday, December 06, 2006 12:03 AM > To: Tom-PT Taylor; Hannes Tschofenig > Cc: dime@ietf.org > Subject: AW: [Dime] Re: Input for Diameter Test Cases > > Thanks Tom.=20 > > We are looking forward to inspect the input.=20 > > In the meanwhile we need to work on the test cases. Would you like to g= ive us some feedback? Here is the current draft version:=20 > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suit= e-02.txt=20 > > I have created a Wiki page to collect information.=20 > > Ciao > Hannes=20 > > -----Urspr=C3=BCngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Gesendet: Dienstag, 5. Dezember 2006 16:59 > An: Hannes Tschofenig > Cc: dime@ietf.org > Betreff: [Dime] Re: Input for Diameter Test Cases > > The MultiService Forum (MSF) is working through their liaison process.=20 > We should have the material to you in two to three weeks. > > Hannes Tschofenig wrote: > =20 >> Hi Tom, >> >> during the DIME meeting you mentioned that you could provide us with=20 >> some test cases (collected from another interop event). >> >> Ciao >> Hannes >> >> =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 > > > > _______________________________________________ > 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 Thu Dec 07 17:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSDF-0001Fw-MN; Thu, 07 Dec 2006 17:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSDE-0001Fi-Qs for dime@ietf.org; Thu, 07 Dec 2006 17:59:32 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSDC-0006mz-HB for dime@ietf.org; Thu, 07 Dec 2006 17:59:32 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9X0029KEJ550@usaga01-in.huawei.com> for dime@ietf.org; Thu, 07 Dec 2006 14:59:29 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9X009QAEJ5Y2@usaga01-in.huawei.com> for dime@ietf.org; Thu, 07 Dec 2006 14:59:29 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9X00NR7EZU2Q@usaml03-in.huawei.com> for dime@ietf.org; Thu, 07 Dec 2006 15:09:36 -0800 (PST) Date: Thu, 07 Dec 2006 14:59:22 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <5e2406980612050133p7764a8e1udb8d7a42a66ab42@mail.gmail.com> To: 'Julien Bournelle' Message-id: <001a01c71a53$56c33570$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccYUHyVoAKa47SvTGugD7y6eiq+9gCAUwAw 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 Julien, -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Tuesday, December 05, 2006 1:34 AM To: Madjid Nakhjiri Cc: Ahmad Muhanna; dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Hi madjid, sorry for the late response On 11/30/06, Madjid Nakhjiri wrote: > Actually Julien, let me explain, The issue is that since you are decoupling > the authentication from authorization, during the authorization you have no > assurance that the client identity has actually been authenticated. One question is: is this really an issue ? Madjid>>yes, see below. > Things > that cause problem are when the AAA-MIP is different from AAA_EAP, Is this really a problem if the authorization server trust the HA ? Madjid>>well, define trust? Just because HA as a AAA client shares a key with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. The AAA_EAP may authenticate somebody, while HA tries to get authorization for somebody else! So basically the HA can help the MN steal service. > 3) HA is under attack itself, where its databases are manipulated. > > Now back to your options, I don't think you can sweep this under the rug. > This is probably the first place in the IETF where you are separating > authentication from authorization, so you will get a lot of scrutiny down > the road and you cannot ignore the security issues for the scenario you are > presenting (especially the separation of the AAA servers and service > providers). So option 1 is out. I think we should take the issue seriously. that's true that we are introducing a new scheme: we're decoupling the authorization from the authentication process. However, the HA is responsible of the binding. Madjid>> the decoupling if not done right can cause security issues. And yes I'm wondering if this is really a security issue. Madjid>>I gave you an example above. > > However, I don't think the solution you present in option 2 is needed. You > don't need new command modes, you simply need attributes that carry > information related to a previous authentication of the MN by the AAA-EAP > and this can be done by attributes. I'm not sure that "simply" is adequate here...if we need to add attributes to 4072 and define a token-based mechanism that would give a proof to the AAA-MIP6, i'm not sure that so simple. Madjid>>Ok, sorry for the exaggeration on simplicity, but it does solve the security problem. Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 08 08:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfTK-0006cS-Ue; Fri, 08 Dec 2006 08:09:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfTK-0006cN-MR for dime@ietf.org; Fri, 08 Dec 2006 08:09:02 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsfTG-0002F9-7y for dime@ietf.org; Fri, 08 Dec 2006 08:09:02 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id kB8D8vtc029915 for ; Fri, 8 Dec 2006 15:08:57 +0200 (EET) Received: from [131.177.37.116] (l50029133.pool.sonera.fi [131.177.37.116]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id kB8D8qi5029908; Fri, 8 Dec 2006 15:08:52 +0200 (EET) Message-ID: <457963E5.6010800@teliasonera.com> Date: Fri, 08 Dec 2006 15:08:53 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org References: <003901c718e1$7a99b370$6291460a@china.huawei.com> <457747F2.7020002@tari.toshiba.com> In-Reply-To: <457747F2.7020002@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "'Tschofenig, Hannes'" Subject: [Dime] MIPv6 NAS - HAAA interface draft 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, Based on the comments received in the last IETF Dime meeting I have updated the draft. The latest unofficial snapshot is available at: http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt I would appreciate feedback on the latest (unofficial) draft revision. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 08 08:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg3E-0003vP-7o; Fri, 08 Dec 2006 08:46:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsg3C-0003u6-OM for dime@ietf.org; Fri, 08 Dec 2006 08:46:06 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsg3A-00020g-Ge for dime@ietf.org; Fri, 08 Dec 2006 08:46:06 -0500 Received: by wx-out-0506.google.com with SMTP id h27so850601wxd for ; Fri, 08 Dec 2006 05:46:04 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=YnAArH7IVrKGNABN0673V8ZIQLVDKntAeG6o4ic910ECv+EliSONQFIkIb7SGDYQiUTGUu+evqtTa79Rh6jrHT2GPYhzqzQKAZ7ArwzZagtjQdD5E99BJ/8fvjXV6DpcHxafE4rrE8O4eKkwEm+kIHE9tQt2mMQvQZjybszfwvg= Received: by 10.70.125.11 with SMTP id x11mr5987902wxc.1165585563642; Fri, 08 Dec 2006 05:46:03 -0800 (PST) Received: by 10.70.21.7 with HTTP; Fri, 8 Dec 2006 05:46:03 -0800 (PST) Message-ID: <5e2406980612080546x40823c3bpe81630e7a2aba1e7@mail.gmail.com> Date: Fri, 8 Dec 2006 14:46:03 +0100 From: "Julien Bournelle" To: "Jouni Korhonen" Subject: Re: [Dime] MIPv6 NAS - HAAA interface draft In-Reply-To: <457963E5.6010800@teliasonera.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003901c718e1$7a99b370$6291460a@china.huawei.com> <457747F2.7020002@tari.toshiba.com> <457963E5.6010800@teliasonera.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org, "Tschofenig, Hannes" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org HI Jouni, Just a quick comment, I saw on http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt that the AAA server can send the HoA info to the NAS. Maybe we also should add this AVP. what do you think ? Julien On 12/8/06, Jouni Korhonen wrote: > Hi all, > > Based on the comments received in the last IETF Dime meeting I have > updated the draft. The latest unofficial snapshot is available at: > http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt > > I would appreciate feedback on the latest (unofficial) draft revision. > > Cheers, > Jouni > > > > _______________________________________________ > 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 Dec 08 10:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshHn-0002TR-Oe; Fri, 08 Dec 2006 10:05:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshHn-0002TM-3I for dime@ietf.org; Fri, 08 Dec 2006 10:05:15 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GshHi-0000D2-1g for dime@ietf.org; Fri, 08 Dec 2006 10:05:15 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id kB8F58Tx026691; Fri, 8 Dec 2006 16:05:08 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id kB8F57hk018745; Fri, 8 Dec 2006 16:05:07 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 16:05:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Dec 2006 16:05:06 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC023C96FE@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Upcoming Diameter Interop Thread-Index: Acca2j7u63tLlaryShaGyMzXEIJBaQ== From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 08 Dec 2006 15:05:07.0736 (UTC) FILETIME=[3FB4E180:01C71ADA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Dime] Upcoming Diameter Interop 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,=20 our interop event planning is finished. =20 WHAT? Diameter Interoperability Event Further information regarding agenda, test framework, venue and travel information as well as on-line registration are available at: http://www.diameterinterop.com =20 WHEN? January 29 - February 2, 2007=20 =20 WHERE? Orlando, Florida (hosted by IntelliNet Technologies) =20 WHO? Companies implementing Diameter, Diameter extensions and Diameter applications A copy-and-paste from the press announcement:=20 "=20 The Diameter Interoperability Event provides an excellent opportunity for vendors of the Diameter protocol and applications to test their implementations in a friendly setting and get a better understanding of the protocol behavior. Discussions with peers and the experts from DiME provide a forum to realize an industry leading implementation. We are expecting a substantial number of participating companies and products, including the base protocol from several vendors as well as a broad range of applications using the protocol. This offers you the opportunity to further refine your own products and assure their interoperability. " IMPORTANT: Please register at http://www.diameterinterop.com=20 (deadline: January 15, 2007)=20 Ciao Hannes & John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 08 11:03:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiBg-0000Gu-LG; Fri, 08 Dec 2006 11:03:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiBe-0000GY-JU for dime@ietf.org; Fri, 08 Dec 2006 11:02:58 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsiBd-0001xT-6z for dime@ietf.org; Fri, 08 Dec 2006 11:02:58 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kB8G2pXh014735 for ; Fri, 8 Dec 2006 17:02:52 +0100 Received: from blnss35a.ww100.siemens.net (blnss35a.ww100.siemens.net [194.138.127.221]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id kB8G2pBc020676 for ; Fri, 8 Dec 2006 17:02:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Dec 2006 17:02:50 +0100 Message-ID: <9455E8227DC5C14E82337653F583A9AC045CA02D@blnss35a.ww100.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DCCA: RATING_FAILED without Failed-AVP Thread-Index: Acca4k+6WtD1B15CR2q1neLtHpNn5g== From: "Schendel, Jens" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Dime] DCCA: RATING_FAILED without Failed-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, RFC 4006 says in section 4.1.3. Handling of Unsupported/Incorrect Rating Input and=20 in 9.2. Permanent Failures 4.1.3 that Failed-AVP MUST be populated if RATING_FAILED Result-Code is used, e.g. DIAMETER_RATING_FAILED 5031 This error code is used to inform the credit-control client that the credit-control server cannot rate the service request due to insufficient rating input, an incorrect AVP combination, or an AVP or an AVP value that is not recognized or supported in the rating. The Failed-AVP AVP MUST be included and contain a copy of the entire AVP(s) that could not be processed successfully or an example of the missing AVP complete with the Vendor-Id if applicable. The value field of the missing AVP should be of correct minimum length and contain zeros. I wonder if this value DIAMETER_RATING_FAILED should also be applied when some server internal (rating engine) error occurred (e.g. improper administration). Then, however, actually no rating relevant AVP was at fault which could be reported. It seems that the mentioned error situation cannot be indicated appropriately without violating the RFC4006. Though, I believe that there should be no crucial client processing associated with the occurrence or value of the Failed-AVP. There is of course the - not very satisfying - workaround to send some generic value such as DIAMETER_UNABLE_TO_COMPLY 5012.=20 Any views? Jens _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 08 12:33:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsjbg-0003Kg-RL; Fri, 08 Dec 2006 12:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsjbg-0003K5-6I for dime@ietf.org; Fri, 08 Dec 2006 12:33:56 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsjbe-00075t-Mu for dime@ietf.org; Fri, 08 Dec 2006 12:33:56 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 2089358580; Fri, 8 Dec 2006 12:33:46 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kB8HXe34017918; Fri, 8 Dec 2006 12:33:40 -0500 (EST) From: "Tolga Asveren" To: "Schendel, Jens" , Subject: RE: [Dime] DCCA: RATING_FAILED without Failed-AVP Date: Fri, 8 Dec 2006 12:30:05 -0500 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: <9455E8227DC5C14E82337653F583A9AC045CA02D@blnss35a.ww100.siemens.net> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Jens, IMHO, even if there is some misconfiguration on rating engine, it still is running some type of algorithm to rate. It could be that it is looking for an AVP which it shouldn't, but in any case I would expect that logic to be able to tell what is wrong from its point of view, e.g. missing AVP, incorrect AVP combination. It could be that the problem is with rating engine rather than with the message but still it is usefull information in terms of troubleshooting to include in error answer what the engine believes is wrong. If the failure can't be correlated with the content of the received message, IMO UNABLE_TO_COMPLY is a better alternative. Thanks, Tolga > -----Original Message----- > From: Schendel, Jens [mailto:jens.schendel@siemens.com] > Sent: Friday, December 08, 2006 11:03 AM > To: dime@ietf.org > Subject: [Dime] DCCA: RATING_FAILED without Failed-AVP > > > Hi all, > > RFC 4006 says in section 4.1.3. Handling of Unsupported/Incorrect > Rating Input and > in 9.2. Permanent Failures 4.1.3 that Failed-AVP MUST be populated if > RATING_FAILED Result-Code is used, e.g. > > DIAMETER_RATING_FAILED 5031 > This error code is used to inform the credit-control client that > the credit-control server cannot rate the service request due to > insufficient rating input, an incorrect AVP combination, or an AVP > or an AVP value that is not recognized or supported in the rating. > The Failed-AVP AVP MUST be included and contain a copy of the > entire AVP(s) that could not be processed successfully or an > example of the missing AVP complete with the Vendor-Id if > applicable. The value field of the missing AVP should be of > correct minimum length and contain zeros. > > I wonder if this value DIAMETER_RATING_FAILED should also be applied > when some server internal (rating engine) error occurred (e.g. improper > administration). Then, however, actually no rating relevant AVP was at > fault which could be reported. > It seems that the mentioned error situation cannot be indicated > appropriately without violating the RFC4006. > Though, I believe that there should be no crucial client processing > associated with the occurrence or value of the Failed-AVP. There is of > course the - not very satisfying - workaround to send some generic value > such as DIAMETER_UNABLE_TO_COMPLY 5012. > > Any views? > > Jens > > _______________________________________________ > 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 Dec 09 05:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gszsr-0000C9-38; Sat, 09 Dec 2006 05:56:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gszsp-00009M-Bk for dime@ietf.org; Sat, 09 Dec 2006 05:56:43 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gszsg-0003Bl-72 for dime@ietf.org; Sat, 09 Dec 2006 05:56:43 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kB9AuRi15067; Sat, 9 Dec 2006 05:56:27 -0500 (EST) Received: from [47.130.16.55] ([47.130.16.55] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 05:56:35 -0500 Message-ID: <457A9650.2080106@nortel.com> Date: Sat, 09 Dec 2006 05:56:16 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Redundancy support AVPs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2006 10:56:35.0703 (UTC) FILETIME=[B1DAF870:01C71B80] 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 A bit late to the party, but I suggest a small wording change to clarify intent. Tolga Asveren wrote: > Hi All, > [snip] > > ================================================================ > 8.22 > Session-Info AVP is used by application sessions to store session related > opaque data in the messages. This AVP carries state information that are > communicated between Diameter application end-points only. It provides > applications with a generic method to store opaque data in messages for high > availability, redundancy or other purposes that may not be defined in the > Diameter application itself. > > AVP Flag Rules > AVP Data SHLD MUST MAY > Attribute Name Code Type MUST MAY NOT NOT Encr > Session-Info XYZ Grouped M P V Y > Origin-Host 264 DiamIdent M P V Y > Session-Data XYZ OctetString M P V Y > > Session-Info AVP > The Session-Info AVP (AVP code xyz) is of type Grouped and is used by > Diameter entities serving as application endpoints to send and receive > session related opaque data. An application originating a request or answer > message MAY include the Session-Info AVP in the message. The receiver of the > message that includes a Session-Info AVP inserted by the remote peer MUST > include the same Session-Info AVP in the subsequent request or answer > messages. The originating Diameter endpoints MAY update the opaque data carried in ^^^^^^^^^^^ > Session-info AVP. Receiving Diameter endpoints MUST use the last received Session-Info ^^^^^^^^^ > AVP in the subsequent request and answers they generate. > [snip] _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Dec 09 05:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gszvk-0001BT-J0; Sat, 09 Dec 2006 05:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gszvj-0001BM-4T for dime@ietf.org; Sat, 09 Dec 2006 05:59:43 -0500 Received: from roof.dave.sonera.fi ([131.177.130.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gszvg-0003mF-KW for dime@ietf.org; Sat, 09 Dec 2006 05:59:43 -0500 Received: from roof.dave.sonera.fi (localhost [127.0.0.1]) by roof.dave.sonera.fi (Sendmail) with ESMTP id kB9Axcwg022673 for ; Sat, 9 Dec 2006 12:59:39 +0200 (EET) Received: from [131.177.105.113] (ws113.secureuser.sonera.fi [131.177.105.113]) by roof.dave.sonera.fi (Sendmail) with ESMTP id kB9AxVH5022670; Sat, 9 Dec 2006 12:59:32 +0200 (EET) Message-ID: <457A9715.1060507@teliasonera.com> Date: Sat, 09 Dec 2006 12:59:33 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Dime] MIPv6 NAS - HAAA interface draft References: <003901c718e1$7a99b370$6291460a@china.huawei.com> <457747F2.7020002@tari.toshiba.com> <457963E5.6010800@teliasonera.com> <5e2406980612080546x40823c3bpe81630e7a2aba1e7@mail.gmail.com> In-Reply-To: <5e2406980612080546x40823c3bpe81630e7a2aba1e7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dime@ietf.org, "Tschofenig, Hannes" 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 Julien, HoA was considered at some point of time. Comments back then were that "HoA is given by the HA and not by the AAA in the integrated scenario" and "integrated solution I-D inherits the HoA and IKEv2 SA bootstrapping parts from the split solution I-D" etc. However, I assume there are now emerging deployment cases where it would make sense to return HoA also as a part of the general integrated scenario bootstrapping. I would add an AVP for HoA. Cheers, Jouni Julien Bournelle kirjoitti: > HI Jouni, > > Just a quick comment, I saw on > http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-01.txt > that the AAA server can send the HoA info to the NAS. > > Maybe we also should add this AVP. > > what do you think ? > > Julien > > On 12/8/06, Jouni Korhonen wrote: >> Hi all, >> >> Based on the comments received in the last IETF Dime meeting I have >> updated the draft. The latest unofficial snapshot is available at: >> http://www.tschofenig.priv.at/svn/draft-ietf-dime-mip6-integrated/draft-ietf-dime-mip6-integrated-02.txt >> >> >> I would appreciate feedback on the latest (unofficial) draft revision. >> >> Cheers, >> Jouni >> >> >> >> _______________________________________________ >> 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 Dec 10 08:39:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOtm-0005if-Ru; Sun, 10 Dec 2006 08:39:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOtl-0005iQ-E6 for dime@ietf.org; Sun, 10 Dec 2006 08:39:21 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GtOtj-0004iq-ME for dime@ietf.org; Sun, 10 Dec 2006 08:39:21 -0500 Received: (qmail invoked by alias); 10 Dec 2006 13:39:18 -0000 Received: from p5498718E.dip.t-dialin.net (EHLO [192.168.2.32]) [84.152.113.142] by mail.gmx.net (mp048) with SMTP; 10 Dec 2006 14:39:18 +0100 X-Authenticated: #29516787 Message-ID: <457C0E08.3010105@gmx.net> Date: Sun, 10 Dec 2006 14:39:20 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Reminder! [Dime] Expert Reviewers Nominated References: <455515A0.9050106@gmx.net> In-Reply-To: <455515A0.9050106@gmx.net> 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: ea4ac80f790299f943f0a53be7e1a21a Cc: lionel.morand@francetelecom.com, mamuhanna@nortel.com, dime@ietf.org, "Glen Zorn \(gwz\)" 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 Ahmad Muhanna has already sent his expert review to the mailing list. We are still missing Glen's and Lionel's review. Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > during the DIME meeting we selected expert reviewers for the HA<->AAAH > document > (http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt): > > * Glen Zorn > * Lionel Morand > * Ahmad Muhanna > > Since a number of issues have been raised during the meeting I would > suggest to also jump into the discussions. I will send a separate mail > with a description of the raised aspects. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 07:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtkeF-0001tK-90; Mon, 11 Dec 2006 07:52:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtkeE-0001sf-Gz for dime@ietf.org; Mon, 11 Dec 2006 07:52:46 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtkeD-0004Dk-7R for dime@ietf.org; Mon, 11 Dec 2006 07:52:46 -0500 Received: by nf-out-0910.google.com with SMTP id h2so1957150nfe for ; Mon, 11 Dec 2006 04:52:44 -0800 (PST) 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; b=GF+0dE+UW7nqMsdLw3heuSLMMX/yqfLpZFd/0c2CQiOvxLNiForCELfXw2O9tsvRjk1+BBfFrd4d5LajSxEpcJCjaQeaOHFvvbY5h6wPhLcaWfHsBlY+V/ZaFwzf5n/td/n3mI4nUqxRig9qSqAIoezC2tilbh25IzKmK4xRPTM= Received: by 10.82.136.4 with SMTP id j4mr968066bud.1165841563853; Mon, 11 Dec 2006 04:52:43 -0800 (PST) Received: by 10.82.184.12 with HTTP; Mon, 11 Dec 2006 04:52:43 -0800 (PST) Message-ID: <9addac050612110452o5715de08i98228fa2822c30ed@mail.gmail.com> Date: Mon, 11 Dec 2006 18:22:43 +0530 From: "Himanshu Rawat" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Dime] Info about Service authorization AVPS and Credit authorization AVP's(Rating AVP's) 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="===============0751428615==" Errors-To: dime-bounces@ietf.org --===============0751428615== Content-Type: multipart/alternative; boundary="----=_Part_84752_20562891.1165841563832" ------=_Part_84752_20562891.1165841563832 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Currently I'm working on Diameter applications (have gone through RFC's 3588 and 4006) and have some doubt related to Service authorization AVPS and Credit authorization AVP's(Rating AVP's). I've tried to segregate the AVP's but still I'm not able to get all AVP's. Please if anybody has info about the Service authorization AVPS and Credit authorization AVP's(Rating AVP's) send me some informaton about this. I have also some doubt on this "Where does Initial Authorization will be done? Where does AAA server sits?" What are the AVP's required for initial/service authorization? Waiting for your reply Thanks and Regards -- Himanshu Rawat ------=_Part_84752_20562891.1165841563832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
Currently I'm working on Diameter applications (have gone through RFC's 3588 and 4006) and have some doubt related to Service authorization AVPS and Credit authorization AVP's(Rating AVP's). I've tried to segregate  the  AVP's but still  I'm not able to get all AVP's.

Please if anybody has info about the Service authorization AVPS and Credit authorization AVP's(Rating AVP's) send me some informaton about this.

I have also some doubt on this "Where does Initial Authorization will be done? Where does AAA server sits?"
What are the AVP's required for initial/service authorization?

Waiting for your reply

Thanks and Regards

--
Himanshu Rawat ------=_Part_84752_20562891.1165841563832-- --===============0751428615== 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 --===============0751428615==-- From dime-bounces@ietf.org Mon Dec 11 08:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtkw5-0001OD-19; Mon, 11 Dec 2006 08:11:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtkw3-0001Nk-Kc for dime@ietf.org; Mon, 11 Dec 2006 08:11:11 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtkw1-0006ug-Bu for dime@ietf.org; Mon, 11 Dec 2006 08:11:11 -0500 Received: by wx-out-0506.google.com with SMTP id h27so1577421wxd for ; Mon, 11 Dec 2006 05:11:09 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=naV04sO38x6l9osJYF07aYHEfFkgYNjLfLUgWeN7bpjRvZt+I/n2RRFkR8oRB7rLqW3mJ+a7FyWsojkwSwQ25hY3SmLIebx15YkC8eiefOcXeEZM4qbwhHTHQR4siAvTHV4dbynkJh48flzUJk8Hz5DswUsZg81adjVXbGXuzBg= Received: by 10.70.83.8 with SMTP id g8mr9499091wxb.1165842668889; Mon, 11 Dec 2006 05:11:08 -0800 (PST) Received: by 10.70.21.7 with HTTP; Mon, 11 Dec 2006 05:11:08 -0800 (PST) Message-ID: <5e2406980612110511x67d58099k277d8ffe07e1d949@mail.gmail.com> Date: Mon, 11 Dec 2006 14:11:08 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <001a01c71a53$56c33570$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980612050133p7764a8e1udb8d7a42a66ab42@mail.gmail.com> <001a01c71a53$56c33570$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) 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 Hi madjid, all, On 12/7/06, Madjid Nakhjiri wrote: > > sorry for the late response > > On 11/30/06, Madjid Nakhjiri wrote: > > Actually Julien, let me explain, The issue is that since you are > decoupling > > the authentication from authorization, during the authorization you have > no > > assurance that the client identity has actually been authenticated. > > One question is: is this really an issue ? > > Madjid>>yes, see below. maybe others have a different opinion. > > Things > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > Is this really a problem if the authorization server trust the HA ? > > Madjid>>well, define trust? > Just because HA as a AAA client shares a key > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. sure. > The AAA_EAP may authenticate somebody, while HA tries to get authorization > for somebody else! So basically the HA can help the MN steal service. The assumption that the HA could be compromised is the reason why we are talking about this. One question is if this assumption doesn't bring concerns more important. As an example, if the HA is compromised, why should it contact the AAA_MIP6 ? Julien > > 3) HA is under attack itself, where its databases are manipulated. > > > > Now back to your options, I don't think you can sweep this under the rug. > > This is probably the first place in the IETF where you are separating > > authentication from authorization, so you will get a lot of scrutiny down > > the road and you cannot ignore the security issues for the scenario you > are > > presenting (especially the separation of the AAA servers and service > > providers). So option 1 is out. I think we should take the issue > seriously. > > that's true that we are introducing a new scheme: we're decoupling > the authorization from the authentication process. However, the HA is > responsible of the binding. > > Madjid>> the decoupling if not done right can cause security issues. > > And yes I'm wondering if this is really a security issue. > > Madjid>>I gave you an example above. > > > > > However, I don't think the solution you present in option 2 is needed. You > > don't need new command modes, you simply need attributes that carry > > information related to a previous authentication of the MN by the AAA-EAP > > and this can be done by attributes. > > I'm not sure that "simply" is adequate here...if we need to add > attributes to 4072 and define a token-based mechanism that would give > a proof to the AAA-MIP6, i'm not sure that so simple. > > > Madjid>>Ok, sorry for the exaggeration on simplicity, but it does solve the > security problem. > > > Julien > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 09:40:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmKr-0005TK-GR; Mon, 11 Dec 2006 09:40:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtmKq-0005TF-6Z for dime@ietf.org; Mon, 11 Dec 2006 09:40:52 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtmKo-0005rQ-Rt for dime@ietf.org; Mon, 11 Dec 2006 09:40:52 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kBBEXXX04165 for ; Mon, 11 Dec 2006 09:33:33 -0500 (EST) Received: from [47.130.18.234] ([47.130.18.234] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 09:40:58 -0500 Message-ID: <457D6DE5.9030802@nortel.com> Date: Mon, 11 Dec 2006 09:40:37 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 14:40:58.0531 (UTC) FILETIME=[5F26FF30:01C71D32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] Application Id for commands in Gq and similar applications X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have been mulling over the use of application-ids in the new ITU-T Rs application, which builds on 3GPP Gq. It has introduced a stateless mode of operation which has caused us to reuse a couple of 3GPP Cx commands, Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is running in stateless mode. That means we have a new application, not Gq. To ensure that Rs messages are routed to the right application at the destination, the application-Id in the Diameter header has to be that of the Rs application rather than of the application (mostly base, but also NASREQ and Cx as I said) that originally defined the command. And the application-Id presented in the body of the command has to be consistent with the header. My conclusion is that Gq should not have preserved the mandatory Auth-Application-Id AVPs of the commands it took from base and RFC 4005, but should instead have accepted that it was an experimental vendor-specific application within the context of Diameter rules and replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs application should do the same, using its own application-id and the ITU-T vendor-id. Comments? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 12:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp19-0005sM-M3; Mon, 11 Dec 2006 12:32:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtp19-0005qO-1Q for dime@ietf.org; Mon, 11 Dec 2006 12:32:43 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtp15-0003HV-Tc for dime@ietf.org; Mon, 11 Dec 2006 12:32:43 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBBHWbJ11806; Mon, 11 Dec 2006 12:32:37 -0500 (EST) 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] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Date: Mon, 11 Dec 2006 11:32:34 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111DE0D43@zrc2hxm2.corp.nortel.com> In-Reply-To: <5e2406980612050147q3c82f009t557e483a255b72be@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Thread-Index: AccYUmShExUMdvRFQH6iqTYptafPKAE9yINA From: "Ahmad Muhanna" To: "Julien Bournelle" X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 Julien, Sorry for the late response, please see one comment below. Regards, Ahmad =20 > > > > > > To move forward with this I see 3 options: > > > > > > 1/ We continue with the current approach and decide that this is=20 > > > not an issue if the Authz/Acctg server has no "proof" > > > that the user has been authenticated. The HA is=20 > responsible for this. > > > > > > > [Ahmad] > > It is ok as long as the HA include something to indicate=20 > that the user=20 > > has been authenticated. > > Possibly: HA include an attribute to indicate that user have been=20 > > authenticated and/or the identity of the AAAH-EAP server which done=20 > > the authentication. At least there will be some record that HA has=20 > > communicated that. Especially when HA is in the visited network. >=20 > what is the goal of this indication ? [Ahmad] IMHO, I believe the HA is responsible for this, but the HA still needs to communicate to the Authorizing server that the user has been authenticated vi a certain server (AAAH-EAP), especially when the HA is in the visited network. If we guarantee the delivery of authorization request to the same server which done the authentication, then this becomes no issue. >=20 > > > > > We consider that this is an issue. So we consider that the=20 > > > Authz/Acctg need to be bound to the Authentication. Then we have 2 > > > options: > > > > > > 2/ We include DER/DEA messages in the MIP6 Application=20 > but define a=20 > > > new command-code. An update of 4072 would certainly lead to an=20 > > > update of this application. > > > > [Ahmad] > > Basically this option assumes that the same AAAH server support=20 > > authentication and authorization. Right? >=20 > yes. It would be the same application and we won't need=20 > anymore specific authorization messages. >=20 > > What about if we think of a mechanism that allows the HA to=20 > send the=20 > > MAR to the same AAAH which done EAP authentication and at the same=20 > > time it supports AAAH-MIP6. This way we avoid the update for the=20 > > existing RFC and at the same time guarantee that the same=20 > server does=20 > > both operations. >=20 > the problem is the AAA routing. Let me know if I'm wrong but=20 > if we use different application-id code, we are not sure that=20 > AAA messages will hit the same AAA server. >=20 > > > > Here I am throwing a couple of thoughts: > > > > Option 1: > > 1. Mandating that AAAH server which support EAP to support MIP6=20 > > Authorization. > > 2. Then HA always sends the MAR to the same server which=20 > done the EAP=20 > > authentication via the AAAH-EAP identity. > > > > Option 2 (this gives more flexibility): > > 1. HA and/or proxy Diameter server should track Diameter=20 > servers which=20 > > support both EAP and MIP6 Authorization during capabilities=20 > exchange. > > 2. HA and/or Proxy Diameter Server should forward the EAP=20 > > authentication to a server that support both EAP=20 > authentication + MIP6 authorization. > > 3. HA sends the MIP6 Authorization request (MAR) to the=20 > same AAAH-EAP=20 > > server which performed the EAP authentication. > > > > Comments ? >=20 > I fear it would add complexity in proxy agents. > What do others think ? >=20 > Julien >=20 > > > > > > > > 3/ We define a generic mechanism that permits to give a proof to=20 > > > the > > > AAAH-MIP6 that AAAH-EAP has correctly authenticated the user. > > > > [Ahmad] > > If we agree on one of the options above, then this is=20 > already addressed. > > > > > > > > Comments ? > > > > > > > > > Let me know if you see others options. > > > > > > Julien > > > > > > > > > > > > > > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Sent: Friday, November 10, 2006 6:26 PM > > > > > To: dime@ietf.org > > > > > Subject: [Dime] Diameter Mobile IPv6 HA-to-AAAH=20 > Support: Server=20 > > > > > Split > > > > > > > > > > Hi all, > > > > > > > > > > during the DIME meeting Glen raised an important=20 > question that=20 > > > > > impacts the design of the protocol, namely: > > > > > " > > > > > Do we need to support the scenario where the Diameter EAP=20 > > > > > authentication and the Diameter MIPv6 authorization exchange=20 > > > > > terminate at different servers? > > > > > " > > > > > > > > > > Currently, we assume that these two exchanges could be > > > terminated at > > > > > different servers. As a consequence, security concerns > > > were raised > > > > > (see slide 5 of > > > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt). > > > > > > > > > > How do people think about restricting the Diameter MIPv6 > > > HA-to-AAAH > > > > > document to terminate the authentication and > > > authorization exchange > > > > > at the same server? > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > PS: Glen also suggested to consider using the Diameter > > > MIPv6 App-ID > > > > > for the Diameter EAP exchange if we decide that both=20 > exchanges=20 > > > > > terminate at the same server. As a consequence the open issue=20 > > > > > described at slide 6 of=20 > > > > > http://www3.ietf.org/proceedings/06nov/slides/dime-4.ppt > > > > > would also be resolved. The changes to the existing > > > document would > > > > > be minimal (about 2 additional sentences). > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 13:41:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtq5U-0005SH-2j; Mon, 11 Dec 2006 13:41:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtq5S-0005SB-Pt for dime@ietf.org; Mon, 11 Dec 2006 13:41:14 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtq5M-00088y-4H for dime@ietf.org; Mon, 11 Dec 2006 13:41:14 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBBIf5208877 for ; Mon, 11 Dec 2006 13:41:06 -0500 (EST) Received: from [47.129.0.171] ([47.129.0.171] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 13:41:11 -0500 Message-ID: <457DA632.7000002@nortel.com> Date: Mon, 11 Dec 2006 13:40:50 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: <457D6DE5.9030802@nortel.com> In-Reply-To: <457D6DE5.9030802@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 18:41:11.0093 (UTC) FILETIME=[EDB56E50:01C71D53] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Sorry, read Sh rather than Cx below. Taylor, Tom-PT (CAR:AR00) wrote: > I have been mulling over the use of application-ids in the new ITU-T Rs > application, which builds on 3GPP Gq. It has introduced a stateless mode > of operation which has caused us to reuse a couple of 3GPP Cx commands, > Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is > running in stateless mode. That means we have a new application, not Gq. > > To ensure that Rs messages are routed to the right application at the > destination, the application-Id in the Diameter header has to be that of > the Rs application rather than of the application (mostly base, but also > NASREQ and Cx as I said) that originally defined the command. And the > application-Id presented in the body of the command has to be consistent > with the header. > > My conclusion is that Gq should not have preserved the mandatory > Auth-Application-Id AVPs of the commands it took from base and RFC 4005, > but should instead have accepted that it was an experimental > vendor-specific application within the context of Diameter rules and > replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs > application should do the same, using its own application-id and the > ITU-T vendor-id. > > Comments? > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 16:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsKh-00078g-3Z; Mon, 11 Dec 2006 16:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtsKg-00078R-CK for dime@ietf.org; Mon, 11 Dec 2006 16:05:06 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtsKQ-0007OA-EH for dime@ietf.org; Mon, 11 Dec 2006 16:05:06 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id AA37A67A8E; Mon, 11 Dec 2006 16:04:45 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBBL4hhV015928; Mon, 11 Dec 2006 16:04:44 -0500 (EST) From: "Tolga Asveren" To: "Tom-PT Taylor" , Subject: RE: [Dime] Application Id for commands in Gq and similar applications Date: Mon, 11 Dec 2006 16:01:47 -0500 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: <457D6DE5.9030802@nortel.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Tom, Considering that application Id namespace is flat, it seems that it doesn't matter much whether Auth-App-Id or Vendor-Specific-App-Id is used. Actually I even don't know why both the Application-Id in the message header and the X-App-Id AVPs are used. They have to have the same value, so probably X-App-Id AVPs are redundant. I think for the Gq interface the idea why Auth-Application-Id was preserved is that it is defined as a mandatory AVP for AAR/AAA in RFC4005. OTOH, Gq does something inconsistent with this by dropping Auth-Request-Type AVP in AAR/AAA, which is a mandatory AVP according to the command grammar(defined in {} ). I believe, one important question to answer is how much freedom do new applications have, when they are reusing commands defined by other applications in terms of changing the grammar. For example, are they allowed/supposed to drop some mandatory AVPs in the new grammar definition of the command? It could be a good idea not to touch mandatory AVPs, which are supposed to be vital from the commands semantics point of view. If there is such a need, probably a new command could be justified. OTOH, this may cause the number of new commands to explode. Thanks, Tolga > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Monday, December 11, 2006 9:41 AM > To: dime@ietf.org > Subject: [Dime] Application Id for commands in Gq and similar > applications > > > I have been mulling over the use of application-ids in the new ITU-T Rs > application, which builds on 3GPP Gq. It has introduced a stateless mode > of operation which has caused us to reuse a couple of 3GPP Cx commands, > Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is > running in stateless mode. That means we have a new application, not Gq. > > To ensure that Rs messages are routed to the right application at the > destination, the application-Id in the Diameter header has to be that of > the Rs application rather than of the application (mostly base, but also > NASREQ and Cx as I said) that originally defined the command. And the > application-Id presented in the body of the command has to be consistent > with the header. > > My conclusion is that Gq should not have preserved the mandatory > Auth-Application-Id AVPs of the commands it took from base and RFC 4005, > but should instead have accepted that it was an experimental > vendor-specific application within the context of Diameter rules and > replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs > application should do the same, using its own application-id and the > ITU-T vendor-id. > > Comments? > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 17:15:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttQY-00083B-Fp; Mon, 11 Dec 2006 17:15:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GttQX-00082w-6k for dime@ietf.org; Mon, 11 Dec 2006 17:15:13 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GttQV-0003bM-OK for dime@ietf.org; Mon, 11 Dec 2006 17:15:13 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBBMF6H21579; Mon, 11 Dec 2006 17:15:07 -0500 (EST) Received: from [47.130.16.151] ([47.130.16.151] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 17:15:16 -0500 Message-ID: <457DD858.4060102@nortel.com> Date: Mon, 11 Dec 2006 17:14:48 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2006 22:15:16.0687 (UTC) FILETIME=[D64785F0:01C71D71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I see two paths for the ITU-T at this point. One is to conform fully with the word, though perhaps not the spirit, of RFC 3588 by specifying that all of the commands it uses are vendor-specific experimental commands which just happen to have the same numbers, same names, and almost the same content as their original counterparts. The other possibility might conform more to the spirit underlying RFC 3588 by using Auth-Application-Id to convey the application identifier (like Gq and the RFCs), keeping all the mandatory AVPs, but specifying default contents for those mandatory AVPs of no interest to the application. I need to decide which way to go within the next day -- last call comments are due to the ITU-T on Wednesday. Are there opinions out there? Tolga Asveren wrote: > Hi Tom, > > Considering that application Id namespace is flat, it seems that it doesn't > matter much whether Auth-App-Id or Vendor-Specific-App-Id is used. Actually > I even don't know why both the Application-Id in the message header and the > X-App-Id AVPs are used. They have to have the same value, so probably > X-App-Id AVPs are redundant. > > I think for the Gq interface the idea why Auth-Application-Id was preserved > is that it is defined as a mandatory AVP for AAR/AAA in RFC4005. OTOH, Gq > does something inconsistent with this by dropping Auth-Request-Type AVP in > AAR/AAA, which is a mandatory AVP according to the command grammar(defined > in {} ). > > I believe, one important question to answer is how much freedom do new > applications have, when they are reusing commands defined by other > applications in terms of changing the grammar. For example, are they > allowed/supposed to drop some mandatory AVPs in the new grammar definition > of the command? It could be a good idea not to touch mandatory AVPs, which > are supposed to be vital from the commands semantics point of view. If there > is such a need, probably a new command could be justified. OTOH, this may > cause the number of new commands to explode. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Tom-PT Taylor [mailto:taylor@nortel.com] >> Sent: Monday, December 11, 2006 9:41 AM >> To: dime@ietf.org >> Subject: [Dime] Application Id for commands in Gq and similar >> applications >> >> >> I have been mulling over the use of application-ids in the new ITU-T Rs >> application, which builds on 3GPP Gq. It has introduced a stateless mode >> of operation which has caused us to reuse a couple of 3GPP Cx commands, >> Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is >> running in stateless mode. That means we have a new application, not Gq. >> >> To ensure that Rs messages are routed to the right application at the >> destination, the application-Id in the Diameter header has to be that of >> the Rs application rather than of the application (mostly base, but also >> NASREQ and Cx as I said) that originally defined the command. And the >> application-Id presented in the body of the command has to be consistent >> with the header. >> >> My conclusion is that Gq should not have preserved the mandatory >> Auth-Application-Id AVPs of the commands it took from base and RFC 4005, >> but should instead have accepted that it was an experimental >> vendor-specific application within the context of Diameter rules and >> replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs >> application should do the same, using its own application-id and the >> ITU-T vendor-id. >> >> Comments? >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 17:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gttui-0006Zp-QF; Mon, 11 Dec 2006 17:46:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gttuh-0006Zh-Pl for dime@ietf.org; Mon, 11 Dec 2006 17:46:23 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gttug-0000GM-BQ for dime@ietf.org; Mon, 11 Dec 2006 17:46:23 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 6A4B534962; Mon, 11 Dec 2006 17:46:17 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBBMkBVc021832; Mon, 11 Dec 2006 17:46:12 -0500 (EST) From: "Tolga Asveren" To: "Tom-PT Taylor" Subject: RE: [Dime] Application Id for commands in Gq and similar applications Date: Mon, 11 Dec 2006 17:43:14 -0500 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: <457DD858.4060102@nortel.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 IMHO, the second path you described seems a better approach. It reuses what is already defined and just extends it. The first approach would require some IANA action. There isn't any range in command code namespace, which is reserved for generic vendor specific use. Thanks, Tolga > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Monday, December 11, 2006 5:15 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] Application Id for commands in Gq and similar > applications > > > I see two paths for the ITU-T at this point. One is to conform fully > with the word, though perhaps not the spirit, of RFC 3588 by specifying > that all of the commands it uses are vendor-specific experimental > commands which just happen to have the same numbers, same names, and > almost the same content as their original counterparts. The other > possibility might conform more to the spirit underlying RFC 3588 by > using Auth-Application-Id to convey the application identifier (like Gq > and the RFCs), keeping all the mandatory AVPs, but specifying default > contents for those mandatory AVPs of no interest to the application. > > I need to decide which way to go within the next day -- last call > comments are due to the ITU-T on Wednesday. Are there opinions out there? > > Tolga Asveren wrote: > > Hi Tom, > > > > Considering that application Id namespace is flat, it seems > that it doesn't > > matter much whether Auth-App-Id or Vendor-Specific-App-Id is > used. Actually > > I even don't know why both the Application-Id in the message > header and the > > X-App-Id AVPs are used. They have to have the same value, so probably > > X-App-Id AVPs are redundant. > > > > I think for the Gq interface the idea why Auth-Application-Id > was preserved > > is that it is defined as a mandatory AVP for AAR/AAA in > RFC4005. OTOH, Gq > > does something inconsistent with this by dropping > Auth-Request-Type AVP in > > AAR/AAA, which is a mandatory AVP according to the command > grammar(defined > > in {} ). > > > > I believe, one important question to answer is how much freedom do new > > applications have, when they are reusing commands defined by other > > applications in terms of changing the grammar. For example, are they > > allowed/supposed to drop some mandatory AVPs in the new grammar > definition > > of the command? It could be a good idea not to touch mandatory > AVPs, which > > are supposed to be vital from the commands semantics point of > view. If there > > is such a need, probably a new command could be justified. > OTOH, this may > > cause the number of new commands to explode. > > > > Thanks, > > Tolga > > > > > >> -----Original Message----- > >> From: Tom-PT Taylor [mailto:taylor@nortel.com] > >> Sent: Monday, December 11, 2006 9:41 AM > >> To: dime@ietf.org > >> Subject: [Dime] Application Id for commands in Gq and similar > >> applications > >> > >> > >> I have been mulling over the use of application-ids in the new ITU-T Rs > >> application, which builds on 3GPP Gq. It has introduced a > stateless mode > >> of operation which has caused us to reuse a couple of 3GPP Cx commands, > >> Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is > >> running in stateless mode. That means we have a new > application, not Gq. > >> > >> To ensure that Rs messages are routed to the right application at the > >> destination, the application-Id in the Diameter header has to > be that of > >> the Rs application rather than of the application (mostly > base, but also > >> NASREQ and Cx as I said) that originally defined the command. And the > >> application-Id presented in the body of the command has to be > consistent > >> with the header. > >> > >> My conclusion is that Gq should not have preserved the mandatory > >> Auth-Application-Id AVPs of the commands it took from base and > RFC 4005, > >> but should instead have accepted that it was an experimental > >> vendor-specific application within the context of Diameter rules and > >> replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs > >> application should do the same, using its own application-id and the > >> ITU-T vendor-id. > >> > >> Comments? > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 21:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxHl-0001pH-27; Mon, 11 Dec 2006 21:22:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxHk-0001p9-7f for dime@ietf.org; Mon, 11 Dec 2006 21:22:24 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtxHi-0002Pk-Rd for dime@ietf.org; Mon, 11 Dec 2006 21:22:24 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBC2MK224395; Mon, 11 Dec 2006 21:22:20 -0500 (EST) Received: from [47.130.16.151] ([47.130.16.151] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 21:22:30 -0500 Message-ID: <457E1250.8030508@nortel.com> Date: Mon, 11 Dec 2006 21:22:08 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 02:22:30.0359 (UTC) FILETIME=[5FD63E70:01C71D94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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'm not sure the first approach does require IANA action. As long as the ITU-T itself coordinates the assignment of command codes within the spaces defined by ITU-T applications, there should be no conflict. We have already created an ITU-T vendor-specific AVP registry, and I see no difference in principle for commands. Tolga Asveren wrote: > IMHO, the second path you described seems a better approach. It reuses what > is already defined and just extends it. > > The first approach would require some IANA action. There isn't any range in > command code namespace, which is reserved for generic vendor specific use. > > Thanks, > Tolga > >> -----Original Message----- >> From: Tom-PT Taylor [mailto:taylor@nortel.com] >> Sent: Monday, December 11, 2006 5:15 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] Application Id for commands in Gq and similar >> applications >> >> >> I see two paths for the ITU-T at this point. One is to conform fully >> with the word, though perhaps not the spirit, of RFC 3588 by specifying >> that all of the commands it uses are vendor-specific experimental >> commands which just happen to have the same numbers, same names, and >> almost the same content as their original counterparts. The other >> possibility might conform more to the spirit underlying RFC 3588 by >> using Auth-Application-Id to convey the application identifier (like Gq >> and the RFCs), keeping all the mandatory AVPs, but specifying default >> contents for those mandatory AVPs of no interest to the application. >> >> I need to decide which way to go within the next day -- last call >> comments are due to the ITU-T on Wednesday. Are there opinions out there? >> >> Tolga Asveren wrote: >>> Hi Tom, >>> >>> Considering that application Id namespace is flat, it seems >> that it doesn't >>> matter much whether Auth-App-Id or Vendor-Specific-App-Id is >> used. Actually >>> I even don't know why both the Application-Id in the message >> header and the >>> X-App-Id AVPs are used. They have to have the same value, so probably >>> X-App-Id AVPs are redundant. >>> >>> I think for the Gq interface the idea why Auth-Application-Id >> was preserved >>> is that it is defined as a mandatory AVP for AAR/AAA in >> RFC4005. OTOH, Gq >>> does something inconsistent with this by dropping >> Auth-Request-Type AVP in >>> AAR/AAA, which is a mandatory AVP according to the command >> grammar(defined >>> in {} ). >>> >>> I believe, one important question to answer is how much freedom do new >>> applications have, when they are reusing commands defined by other >>> applications in terms of changing the grammar. For example, are they >>> allowed/supposed to drop some mandatory AVPs in the new grammar >> definition >>> of the command? It could be a good idea not to touch mandatory >> AVPs, which >>> are supposed to be vital from the commands semantics point of >> view. If there >>> is such a need, probably a new command could be justified. >> OTOH, this may >>> cause the number of new commands to explode. >>> >>> Thanks, >>> Tolga >>> >>> >>>> -----Original Message----- >>>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>>> Sent: Monday, December 11, 2006 9:41 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] Application Id for commands in Gq and similar >>>> applications >>>> >>>> >>>> I have been mulling over the use of application-ids in the new ITU-T Rs >>>> application, which builds on 3GPP Gq. It has introduced a >> stateless mode >>>> of operation which has caused us to reuse a couple of 3GPP Cx commands, >>>> Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is >>>> running in stateless mode. That means we have a new >> application, not Gq. >>>> To ensure that Rs messages are routed to the right application at the >>>> destination, the application-Id in the Diameter header has to >> be that of >>>> the Rs application rather than of the application (mostly >> base, but also >>>> NASREQ and Cx as I said) that originally defined the command. And the >>>> application-Id presented in the body of the command has to be >> consistent >>>> with the header. >>>> >>>> My conclusion is that Gq should not have preserved the mandatory >>>> Auth-Application-Id AVPs of the commands it took from base and >> RFC 4005, >>>> but should instead have accepted that it was an experimental >>>> vendor-specific application within the context of Diameter rules and >>>> replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs >>>> application should do the same, using its own application-id and the >>>> ITU-T vendor-id. >>>> >>>> Comments? >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 21:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxQa-0005vK-Od; Mon, 11 Dec 2006 21:31:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtxQa-0005vE-2F for dime@ietf.org; Mon, 11 Dec 2006 21:31:32 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtxQX-0003p3-Lk for dime@ietf.org; Mon, 11 Dec 2006 21:31:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBC2VRL13774; Mon, 11 Dec 2006 21:31:27 -0500 (EST) Received: from [47.130.16.151] ([47.130.16.151] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 21:31:36 -0500 Message-ID: <457E1471.9080709@nortel.com> Date: Mon, 11 Dec 2006 21:31:13 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 02:31:37.0031 (UTC) FILETIME=[A5ADC570:01C71D95] X-Spam-Score: 0.0 (/) 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 Despite what I just said, I'll go for the second approach for the sake of maximizing the possibility of interoperability. Tolga Asveren wrote: > IMHO, the second path you described seems a better approach. It reuses what > is already defined and just extends it. > > The first approach would require some IANA action. There isn't any range in > command code namespace, which is reserved for generic vendor specific use. > > Thanks, > Tolga > >> -----Original Message----- >> From: Tom-PT Taylor [mailto:taylor@nortel.com] >> Sent: Monday, December 11, 2006 5:15 PM >> To: Tolga Asveren >> Cc: dime@ietf.org >> Subject: Re: [Dime] Application Id for commands in Gq and similar >> applications >> >> >> I see two paths for the ITU-T at this point. One is to conform fully >> with the word, though perhaps not the spirit, of RFC 3588 by specifying >> that all of the commands it uses are vendor-specific experimental >> commands which just happen to have the same numbers, same names, and >> almost the same content as their original counterparts. The other >> possibility might conform more to the spirit underlying RFC 3588 by >> using Auth-Application-Id to convey the application identifier (like Gq >> and the RFCs), keeping all the mandatory AVPs, but specifying default >> contents for those mandatory AVPs of no interest to the application. >> >> I need to decide which way to go within the next day -- last call >> comments are due to the ITU-T on Wednesday. Are there opinions out there? >> >> Tolga Asveren wrote: >>> Hi Tom, >>> >>> Considering that application Id namespace is flat, it seems >> that it doesn't >>> matter much whether Auth-App-Id or Vendor-Specific-App-Id is >> used. Actually >>> I even don't know why both the Application-Id in the message >> header and the >>> X-App-Id AVPs are used. They have to have the same value, so probably >>> X-App-Id AVPs are redundant. >>> >>> I think for the Gq interface the idea why Auth-Application-Id >> was preserved >>> is that it is defined as a mandatory AVP for AAR/AAA in >> RFC4005. OTOH, Gq >>> does something inconsistent with this by dropping >> Auth-Request-Type AVP in >>> AAR/AAA, which is a mandatory AVP according to the command >> grammar(defined >>> in {} ). >>> >>> I believe, one important question to answer is how much freedom do new >>> applications have, when they are reusing commands defined by other >>> applications in terms of changing the grammar. For example, are they >>> allowed/supposed to drop some mandatory AVPs in the new grammar >> definition >>> of the command? It could be a good idea not to touch mandatory >> AVPs, which >>> are supposed to be vital from the commands semantics point of >> view. If there >>> is such a need, probably a new command could be justified. >> OTOH, this may >>> cause the number of new commands to explode. >>> >>> Thanks, >>> Tolga >>> >>> >>>> -----Original Message----- >>>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>>> Sent: Monday, December 11, 2006 9:41 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] Application Id for commands in Gq and similar >>>> applications >>>> >>>> >>>> I have been mulling over the use of application-ids in the new ITU-T Rs >>>> application, which builds on 3GPP Gq. It has introduced a >> stateless mode >>>> of operation which has caused us to reuse a couple of 3GPP Cx commands, >>>> Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is >>>> running in stateless mode. That means we have a new >> application, not Gq. >>>> To ensure that Rs messages are routed to the right application at the >>>> destination, the application-Id in the Diameter header has to >> be that of >>>> the Rs application rather than of the application (mostly >> base, but also >>>> NASREQ and Cx as I said) that originally defined the command. And the >>>> application-Id presented in the body of the command has to be >> consistent >>>> with the header. >>>> >>>> My conclusion is that Gq should not have preserved the mandatory >>>> Auth-Application-Id AVPs of the commands it took from base and >> RFC 4005, >>>> but should instead have accepted that it was an experimental >>>> vendor-specific application within the context of Diameter rules and >>>> replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs >>>> application should do the same, using its own application-id and the >>>> ITU-T vendor-id. >>>> >>>> Comments? >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime >>> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 11 22:41:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtyWO-0003Xi-0t; Mon, 11 Dec 2006 22:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtyWM-0003XO-Nd for dime@ietf.org; Mon, 11 Dec 2006 22:41:34 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtyWL-0002Zh-DB for dime@ietf.org; Mon, 11 Dec 2006 22:41:34 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBC3fV915496 for ; Mon, 11 Dec 2006 22:41:31 -0500 (EST) Received: from [47.130.16.191] ([47.130.16.191] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 22:41:41 -0500 Message-ID: <457E24DC.6070901@nortel.com> Date: Mon, 11 Dec 2006 22:41:16 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 03:41:41.0375 (UTC) FILETIME=[6FA9C0F0:01C71D9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] Relationship between application Id in the message header vs. Auth-Application-Id in the body 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 seems to me section 1.3 of RFC 4005 provides a clue to why application Ids appear both in the header and in an AVP in the body. The application Id in the header is intended for routing, no question about that. But could the one in the body indicate the specification from which the command is imported? That would suggest that section 3 of RFC 3588 should be changed to allow the header application Id to differ from the one in the body. Harking back to my conversation with Tolga, this would fit nicely with the "second approach", which properly reuses commands rather than creating vendor-defined variants. BTW I just reread the part that says there are only two command codes available for experimental use. Tom Taylor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 12 10:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9RJ-0002V4-6n; Tue, 12 Dec 2006 10:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9RH-0002Uw-69 for dime@ietf.org; Tue, 12 Dec 2006 10:21:03 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9RA-0003ei-Im for dime@ietf.org; Tue, 12 Dec 2006 10:21:03 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBCFKEf4045787; Tue, 12 Dec 2006 10:20:14 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <457EC8AE.7070509@tari.toshiba.com> Date: Tue, 12 Dec 2006 10:20:14 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: <457E1471.9080709@nortel.com> In-Reply-To: <457E1471.9080709@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Tom, > Despite what I just said, I'll go for the second approach for the sake > of maximizing the possibility of interoperability. Just trying to catch up on the discussion, does the "second approach" mean that the app id in the header does not match those in the app id avps ? If so, this is probably in conflict with the existing base and with the bis as well. My understanding is that if your just trying to reuse a command/message defined from another spec (pls correct me if I mis-understood the problem) then the "second approach" is preferred but you should define a consistent app id in both the header and app id avps. The app id of the spec that originally defined the command need not be represented when you use the command in your new application. regards, victor > > Tolga Asveren wrote: >> IMHO, the second path you described seems a better approach. It >> reuses what >> is already defined and just extends it. >> >> The first approach would require some IANA action. There isn't any >> range in >> command code namespace, which is reserved for generic vendor specific >> use. >> >> Thanks, >> Tolga >> >>> -----Original Message----- >>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>> Sent: Monday, December 11, 2006 5:15 PM >>> To: Tolga Asveren >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Application Id for commands in Gq and similar >>> applications >>> >>> >>> I see two paths for the ITU-T at this point. One is to conform fully >>> with the word, though perhaps not the spirit, of RFC 3588 by specifying >>> that all of the commands it uses are vendor-specific experimental >>> commands which just happen to have the same numbers, same names, and >>> almost the same content as their original counterparts. The other >>> possibility might conform more to the spirit underlying RFC 3588 by >>> using Auth-Application-Id to convey the application identifier (like Gq >>> and the RFCs), keeping all the mandatory AVPs, but specifying default >>> contents for those mandatory AVPs of no interest to the application. >>> >>> I need to decide which way to go within the next day -- last call >>> comments are due to the ITU-T on Wednesday. Are there opinions out >>> there? >>> >>> Tolga Asveren wrote: >>>> Hi Tom, >>>> >>>> Considering that application Id namespace is flat, it seems >>> that it doesn't >>>> matter much whether Auth-App-Id or Vendor-Specific-App-Id is >>> used. Actually >>>> I even don't know why both the Application-Id in the message >>> header and the >>>> X-App-Id AVPs are used. They have to have the same value, so probably >>>> X-App-Id AVPs are redundant. >>>> >>>> I think for the Gq interface the idea why Auth-Application-Id >>> was preserved >>>> is that it is defined as a mandatory AVP for AAR/AAA in >>> RFC4005. OTOH, Gq >>>> does something inconsistent with this by dropping >>> Auth-Request-Type AVP in >>>> AAR/AAA, which is a mandatory AVP according to the command >>> grammar(defined >>>> in {} ). >>>> >>>> I believe, one important question to answer is how much freedom do new >>>> applications have, when they are reusing commands defined by other >>>> applications in terms of changing the grammar. For example, are they >>>> allowed/supposed to drop some mandatory AVPs in the new grammar >>> definition >>>> of the command? It could be a good idea not to touch mandatory >>> AVPs, which >>>> are supposed to be vital from the commands semantics point of >>> view. If there >>>> is such a need, probably a new command could be justified. >>> OTOH, this may >>>> cause the number of new commands to explode. >>>> >>>> Thanks, >>>> Tolga >>>> >>>> >>>>> -----Original Message----- >>>>> From: Tom-PT Taylor [mailto:taylor@nortel.com] >>>>> Sent: Monday, December 11, 2006 9:41 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] Application Id for commands in Gq and similar >>>>> applications >>>>> >>>>> >>>>> I have been mulling over the use of application-ids in the new >>>>> ITU-T Rs >>>>> application, which builds on 3GPP Gq. It has introduced a >>> stateless mode >>>>> of operation which has caused us to reuse a couple of 3GPP Cx >>>>> commands, >>>>> Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is >>>>> running in stateless mode. That means we have a new >>> application, not Gq. >>>>> To ensure that Rs messages are routed to the right application at the >>>>> destination, the application-Id in the Diameter header has to >>> be that of >>>>> the Rs application rather than of the application (mostly >>> base, but also >>>>> NASREQ and Cx as I said) that originally defined the command. And the >>>>> application-Id presented in the body of the command has to be >>> consistent >>>>> with the header. >>>>> >>>>> My conclusion is that Gq should not have preserved the mandatory >>>>> Auth-Application-Id AVPs of the commands it took from base and >>> RFC 4005, >>>>> but should instead have accepted that it was an experimental >>>>> vendor-specific application within the context of Diameter rules and >>>>> replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs >>>>> application should do the same, using its own application-id and the >>>>> ITU-T vendor-id. >>>>> >>>>> Comments? >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/dime >>>> >> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 12 10:42:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9li-0001Bm-7h; Tue, 12 Dec 2006 10:42:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9lg-0001Bf-Eu for dime@ietf.org; Tue, 12 Dec 2006 10:42:08 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9le-0007wb-GX for dime@ietf.org; Tue, 12 Dec 2006 10:42:08 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBCFg0G11864; Tue, 12 Dec 2006 10:42:00 -0500 (EST) Received: from [47.130.19.81] ([47.130.19.81] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 10:41:59 -0500 Message-ID: <457ECDB2.4000402@nortel.com> Date: Tue, 12 Dec 2006 10:41:38 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: <457E1471.9080709@nortel.com> <457EC8AE.7070509@tari.toshiba.com> In-Reply-To: <457EC8AE.7070509@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 15:42:00.0015 (UTC) FILETIME=[0FFADDF0:01C71E04] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 snipped down to the description of the second approach. You saw my other note suggesting a change in the meaning of the application identifier in the body? I thought I would do some forensic tracking, and dug out a copy of draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my laptop. (We used it as a basis for IPDC, one of Megaco's predecessors.) Anyway, that was too far back -- the concept of applications wasn't present yet. Victor Fajardo wrote: > Hi Tom, >> Despite what I just said, I'll go for the second approach for the sake >> of maximizing the possibility of interoperability. > > Just trying to catch up on the discussion, does the "second approach" > mean that the app id in the header does not match those in the app id > avps ? If so, this is probably in conflict with the existing base and > with the bis as well. My understanding is that if your just trying to > reuse a command/message defined from another spec (pls correct me if I > mis-understood the problem) then the "second approach" is preferred but > you should define a consistent app id in both the header and app id > avps. The app id of the spec that originally defined the command need > not be represented when you use the command in your new application. > [snip] The other >>>> possibility might conform more to the spirit underlying RFC 3588 by >>>> using Auth-Application-Id to convey the application identifier (like Gq >>>> and the RFCs), keeping all the mandatory AVPs, but specifying default >>>> contents for those mandatory AVPs of no interest to the application. >>>> [snip] _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 12 12:09:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuB8e-0004zm-IN; Tue, 12 Dec 2006 12:09:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuB8d-0004zc-GQ for dime@ietf.org; Tue, 12 Dec 2006 12:09:55 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuB8a-00087B-Qo for dime@ietf.org; Tue, 12 Dec 2006 12:09:55 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBCH3mjj046279; Tue, 12 Dec 2006 12:03:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <457EE0F5.7000604@tari.toshiba.com> Date: Tue, 12 Dec 2006 12:03:49 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: himanshu bahl Subject: Re: [Dime] regarding test case in interop doc for same host on both sides References: <20061206051826.65458.qmail@web90410.mail.mud.yahoo.com> In-Reply-To: <20061206051826.65458.qmail@web90410.mail.mud.yahoo.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 kBCH3mjj046279 X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: dime@ietf.org, "'Tschofenig, Hannes'" 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, Sorry for the late reply. > hi all, > I have asked this before also. > please clarify me on this one. suppose we get the same > host id on both sides . i.e on both peers we have > host1.x.com for example. > then what kind of processing are we supposed to do ? > > 1. will there be election lost hence an error code of > 4003 ( Election lost) be returned on both sides.? > > 2. Will there be an error returned with code 5012=20 > (unable to comply ) ? > > 3. will the message be silently be discarded with no > answer messages and connection will be torn down ? > =20 Obviously this scenario is a mis-configuration. Are you proposing to add=20 this to the test document ? In general, I would prefer option (3) just to maintain interoperability.=20 Also, election is independent of this scenario and your implementation=20 can always check for this case and revert to (3) instead of going ahead=20 with the election. regards, victor > a fast reply will be help full. > > Sincerely, > Himanshu. > http://thebahls.blogspot.com > > > > --- Tony Zhang wrote: > > =20 >> Hi All >> I suggest add test cases: >> (1)Use DWR/DWA detect connection status. >> (2)Routing based on >> longest-match-from-the-right on the realm =20 >> rather than requiring an exact match. =20 >> (3)For Redirect,the loop maybe happen, should >> test it? >> (4)Routing should test default route entry? >> (5)For connection ,should test more Negative >> test?like no response.no CER etc? >> Thanks! >> Tony >> >> -----Original Message----- >> From: Tschofenig, Hannes >> [mailto:hannes.tschofenig@siemens.com]=20 >> Sent: Wednesday, December 06, 2006 12:03 AM >> To: Tom-PT Taylor; Hannes Tschofenig >> Cc: dime@ietf.org >> Subject: AW: [Dime] Re: Input for Diameter Test >> Cases >> >> Thanks Tom.=20 >> >> We are looking forward to inspect the input.=20 >> >> In the meanwhile we need to work on the test cases. >> Would you like to give us some feedback? Here is the >> current draft version:=20 >> >> =20 > http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suit= e-02.txt > =20 >> I have created a Wiki page to collect information.=20 >> >> Ciao >> Hannes=20 >> >> -----Urspr=FCngliche Nachricht----- >> Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >> Gesendet: Dienstag, 5. Dezember 2006 16:59 >> An: Hannes Tschofenig >> Cc: dime@ietf.org >> Betreff: [Dime] Re: Input for Diameter Test Cases >> >> The MultiService Forum (MSF) is working through >> their liaison process.=20 >> We should have the material to you in two to three >> weeks. >> >> Hannes Tschofenig wrote: >> =20 >>> Hi Tom, >>> >>> during the DIME meeting you mentioned that you >>> =20 >> could provide us with=20 >> =20 >>> some test cases (collected from another interop >>> =20 >> event). >> =20 >>> Ciao >>> Hannes >>> >>> =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 >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> =20 > > > > =20 > _______________________________________________________________________= _____________ > Any questions? Get answers on any topic at www.Answers.yahoo.com. Try = it now. > > _______________________________________________ > 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 Tue Dec 12 12:22:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBKP-0003Dn-Tm; Tue, 12 Dec 2006 12:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuBKP-0003DZ-2h for dime@ietf.org; Tue, 12 Dec 2006 12:22:05 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuBKM-0000yv-7e for dime@ietf.org; Tue, 12 Dec 2006 12:22:04 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBCHLvIh046369; Tue, 12 Dec 2006 12:21:57 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <457EE536.5040107@tari.toshiba.com> Date: Tue, 12 Dec 2006 12:21:58 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: <457E1471.9080709@nortel.com> <457EC8AE.7070509@tari.toshiba.com> <457ECDB2.4000402@nortel.com> In-Reply-To: <457ECDB2.4000402@nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.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 Tom, > > You saw my other note suggesting a change in the meaning of the > application identifier in the body? I see. My main concern was interoperability if this new "meaning" results in multiple different app ids within a message. It could generate issues. best regards, victor > I thought I would do some forensic tracking, and dug out a copy of > draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my > laptop. (We used it as a basis for IPDC, one of Megaco's > predecessors.) Anyway, that was too far back -- the concept of > applications wasn't present yet. > > Victor Fajardo wrote: >> Hi Tom, >>> Despite what I just said, I'll go for the second approach for the >>> sake of maximizing the possibility of interoperability. >> >> Just trying to catch up on the discussion, does the "second approach" >> mean that the app id in the header does not match those in the app id >> avps ? If so, this is probably in conflict with the existing base and >> with the bis as well. My understanding is that if your just trying to >> reuse a command/message defined from another spec (pls correct me if >> I mis-understood the problem) then the "second approach" is preferred >> but you should define a consistent app id in both the header and app >> id avps. The app id of the spec that originally defined the command >> need not be represented when you use the command in your new >> application. >> > [snip] > > The other >>>>> possibility might conform more to the spirit underlying RFC 3588 by >>>>> using Auth-Application-Id to convey the application identifier >>>>> (like Gq >>>>> and the RFCs), keeping all the mandatory AVPs, but specifying default >>>>> contents for those mandatory AVPs of no interest to the application. >>>>> > [snip] > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 12 15:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuE5D-0000uD-Kr; Tue, 12 Dec 2006 15:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuE5C-0000u7-GX for dime@ietf.org; Tue, 12 Dec 2006 15:18:34 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuE57-0007Lf-EA for dime@ietf.org; Tue, 12 Dec 2006 15:18:34 -0500 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kBCKKWOk002672 for ; Wed, 13 Dec 2006 01:50:32 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kBCKKTR3002626; Wed, 13 Dec 2006 01:50:30 +0530 In-Reply-To: <457EE0F5.7000604@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] regarding test case in interop doc for same host on both sides MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Himanshu Bahl Date: Wed, 13 Dec 2006 01:47:02 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 12/13/2006 01:48:21, Serialize complete at 12/13/2006 01:48:21 X-Spam-Score: 0.7 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: dime@ietf.org, "'Tschofenig, Hannes'" 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="===============1377189573==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1377189573== Content-Type: multipart/alternative; boundary="=_alternative 006F888865257242_=" This is a multipart message in MIME format. --=_alternative 006F888865257242_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20victor,=0D=0A=0D=0AI=20don`t=20think=20option=203=20will=20be=20such= =20a=20good=20one.=20As=20the=20peer=20might=20resend=20=0D=0Athe=20reque= st=20in=20case=20of=20silent=20discard.=20=0D=0AI=20think=20the=20most=20= viable=20solution=20would=20be=20either=20returning=20UNKNOW_HOST.=20=0D= =0AUNABLE=20TO=20COMPLY=20also=20seems=20a=20good=20solution=20since=20th= e=20receiving=20node=20is=20in=20=0D=0Afact=20in=20really=20unable=20to= =20process=20the=20request=20because=20the=20peer`s=20Identity=20=0D=0Aha= s=20turned=20out=20to=20be=20same.=0D=0A=0D=0ARegarding=20the=20test=20ca= se=20document=20I=20think=20this=20case=20is=20already=20present=20in=20= =0D=0Athe=20document.=20draft-fajardo-dime-interop-test-suite-01=20in=20s= ection=203.1.1.2=20=0D=0A,=20point=203.=0D=0A=0D=0A=0D=0ASincerely,=0D=0A= Himanshu.=0D=0AKnow=20Me=20=0D=0Ahttp://www.aricent.com=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0AVictor=20Fajardo=20=20=0D=0A12/12/= 2006=2010:33=20PM=0D=0A=0D=0A=0D=0ATo=0D=0Ahimanshu=20bahl=20=0D=0Acc=0D=0Adime@ietf.org,=20"'Tschofenig,=20Hannes'"=20=0D=0ASubject=0D=0ARe:=20[Dime]=20regarding=20test= =20case=20in=20interop=20doc=20for=20same=20host=20on=20=20bothsides=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AHi,=0D=0A=0D=0ASorry=20for=20the= =20late=20reply.=0D=0A>=20hi=20all,=0D=0A>=20I=20have=20asked=20this=20be= fore=20also.=0D=0A>=20please=20clarify=20me=20on=20this=20one.=20suppose= =20we=20get=20the=20same=0D=0A>=20host=20id=20on=20both=20sides=20.=20i.e= =20on=20both=20peers=20we=20have=0D=0A>=20host1.x.com=20for=20example.=0D= =0A>=20then=20what=20kind=20of=20processing=20are=20we=20supposed=20to=20= do=20?=0D=0A>=0D=0A>=201.=20will=20there=20be=20election=20lost=20hence= =20an=20error=20code=20of=0D=0A>=204003=20(=20Election=20lost)=20be=20ret= urned=20on=20both=20sides.?=0D=0A>=0D=0A>=202.=20Will=20there=20be=20an= =20error=20returned=20with=20code=205012=20=0D=0A>=20(unable=20to=20compl= y=20)=20?=0D=0A>=0D=0A>=203.=20will=20the=20message=20be=20silently=20be= =20discarded=20with=20no=0D=0A>=20answer=20messages=20and=20connection=20= will=20be=20torn=20down=20?=0D=0A>=20=0D=0AObviously=20this=20scenario=20= is=20a=20mis-configuration.=20Are=20you=20proposing=20to=20add=20=0D=0Ath= is=20to=20the=20test=20document=20?=0D=0A=0D=0AIn=20general,=20I=20would= =20prefer=20option=20(3)=20just=20to=20maintain=20interoperability.=20=0D= =0AAlso,=20election=20is=20independent=20of=20this=20scenario=20and=20you= r=20implementation=20=0D=0Acan=20always=20check=20for=20this=20case=20and= =20revert=20to=20(3)=20instead=20of=20going=20ahead=20=0D=0Awith=20the=20= election.=0D=0A=0D=0Aregards,=0D=0Avictor=0D=0A=0D=0A>=20a=20fast=20reply= =20will=20be=20help=20full.=0D=0A>=0D=0A>=20Sincerely,=0D=0A>=20Himanshu.= =0D=0A>=20http://thebahls.blogspot.com=0D=0A>=0D=0A>=0D=0A>=0D=0A>=20---= =20Tony=20Zhang=20=20wrote:=0D=0A>=0D=0A>=20=0D= =0A>>=20Hi=20All=0D=0A>>=20=20=20=20=20=20=20=20I=20suggest=20add=20test= =20cases:=0D=0A>>=20=20=20=20=20=20=20(1)Use=20DWR/DWA=20detect=20connect= ion=20status.=0D=0A>>=20=20=20=20=20=20=20(2)Routing=20based=20on=0D=0A>>= =20longest-match-from-the-right=20on=20the=20realm=20=0D=0A>>=20rather=20= than=20requiring=20an=20exact=20match.=20=0D=0A>>=20=20=20=20=20=20=20(3)= For=20Redirect,the=20loop=20maybe=20happen,=20should=0D=0A>>=20test=20it?= =0D=0A>>=20=20=20=20=20=20=20(4)Routing=20should=20test=20default=20route= =20entry?=0D=0A>>=20=20=20=20=20=20=20(5)For=20connection=20,should=20tes= t=20more=20Negative=0D=0A>>=20test?like=20no=20response.no=20CER=20etc?= =0D=0A>>=20Thanks!=0D=0A>>=20Tony=0D=0A>>=0D=0A>>=20-----Original=20Messa= ge-----=0D=0A>>=20From:=20Tschofenig,=20Hannes=0D=0A>>=20[mailto:hannes.t= schofenig@siemens.com]=20=0D=0A>>=20Sent:=20Wednesday,=20December=2006,= =202006=2012:03=20AM=0D=0A>>=20To:=20Tom-PT=20Taylor;=20Hannes=20Tschofen= ig=0D=0A>>=20Cc:=20dime@ietf.org=0D=0A>>=20Subject:=20AW:=20[Dime]=20Re:= =20Input=20for=20Diameter=20Test=0D=0A>>=20Cases=0D=0A>>=0D=0A>>=20Thanks= =20Tom.=20=0D=0A>>=0D=0A>>=20We=20are=20looking=20forward=20to=20inspect= =20the=20input.=20=0D=0A>>=0D=0A>>=20In=20the=20meanwhile=20we=20need=20t= o=20work=20on=20the=20test=20cases.=0D=0A>>=20Would=20you=20like=20to=20g= ive=20us=20some=20feedback?=20Here=20is=20the=0D=0A>>=20current=20draft= =20version:=20=0D=0A>>=0D=0A>>=20=0D=0A>=20=0D=0Ahttp://www.opendiameter.= org/public/draft-fajardo-dime-interop-test-suite-02.txt=0D=0A=0D=0A>=20= =0D=0A>>=20I=20have=20created=20a=20Wiki=20page=20to=20collect=20informat= ion.=20=0D=0A>>=0D=0A>>=20Ciao=0D=0A>>=20Hannes=20=0D=0A>>=0D=0A>>=20----= -Urspr=FCngliche=20Nachricht-----=0D=0A>>=20Von:=20Tom-PT=20Taylor=20[mai= lto:taylor@nortel.com]=20=0D=0A>>=20Gesendet:=20Dienstag,=205.=20Dezember= =202006=2016:59=0D=0A>>=20An:=20Hannes=20Tschofenig=0D=0A>>=20Cc:=20dime@= ietf.org=0D=0A>>=20Betreff:=20[Dime]=20Re:=20Input=20for=20Diameter=20Tes= t=20Cases=0D=0A>>=0D=0A>>=20The=20MultiService=20Forum=20(MSF)=20is=20wor= king=20through=0D=0A>>=20their=20liaison=20process.=20=0D=0A>>=20We=20sho= uld=20have=20the=20material=20to=20you=20in=20two=20to=20three=0D=0A>>=20= weeks.=0D=0A>>=0D=0A>>=20Hannes=20Tschofenig=20wrote:=0D=0A>>=20=0D=0A>>>= =20Hi=20Tom,=0D=0A>>>=0D=0A>>>=20during=20the=20DIME=20meeting=20you=20me= ntioned=20that=20you=0D=0A>>>=20=0D=0A>>=20could=20provide=20us=20with=20= =0D=0A>>=20=0D=0A>>>=20some=20test=20cases=20(collected=20from=20another= =20interop=0D=0A>>>=20=0D=0A>>=20event).=0D=0A>>=20=0D=0A>>>=20Ciao=0D=0A= >>>=20Hannes=0D=0A>>>=0D=0A>>>=20=0D=0A>>=20_____________________________= __________________=0D=0A>>=20DiME=20mailing=20list=0D=0A>>=20DiME@ietf.or= g=0D=0A>>=20https://www1.ietf.org/mailman/listinfo/dime=0D=0A>>=0D=0A>>= =20_______________________________________________=0D=0A>>=20DiME=20maili= ng=20list=0D=0A>>=20DiME@ietf.org=0D=0A>>=20https://www1.ietf.org/mailman= /listinfo/dime=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>=20________________________= _______________________=0D=0A>>=20DiME=20mailing=20list=0D=0A>>=20DiME@ie= tf.org=0D=0A>>=20https://www1.ietf.org/mailman/listinfo/dime=0D=0A>>=0D= =0A>>=20=0D=0A>=0D=0A>=0D=0A>=0D=0A>=20=0D=0A>=20=0D=0A__________________= __________________________________________________________________=0D=0A>= =20Any=20questions?=20Get=20answers=20on=20any=20topic=20at=20www.Answers= .yahoo.com.=20=20Try=20=0D=0Ait=20now.=0D=0A>=0D=0A>=20__________________= _____________________________=0D=0A>=20DiME=20mailing=20list=0D=0A>=20DiM= E@ietf.org=0D=0A>=20https://www1.ietf.org/mailman/listinfo/dime=0D=0A>=0D= =0A>=0D=0A>=20=0D=0A=0D=0A=0D=0A_________________________________________= ______=0D=0ADiME=20mailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.ie= tf.org/mailman/listinfo/dime=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A***************= ********=20=20Aricent-Private=20=20=20***********************=0D=0A"DISCL= AIMER:=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is= =20intended=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20= whom=20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20conf= idential=20information=20and=20should=20not=20be=20=0Acirculated=20or=20u= sed=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20intende= d.=20If=20you=20have=20received=20this=20message=20in=20error,=20=0Apleas= e=20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20the= =20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20stri= ctly=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosin= g=20the=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20resp= onsibility=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20o= f=20the=20information=20transmitted=20by=20this=20email=20including=20dam= age=20from=20virus."=0A --=_alternative 006F888865257242_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20victor,=0D= =0A
=0D=0A
I=20don`t=20think= =20option=203=20will=20be=20such=0D=0Aa=20good=20one.=20As=20the=20peer= =20might=20resend=20the=20request=20in=20case=20of=20silent=20discard.=0D= =0A=0D=0A
I=20think=20th= e=20most=20viable=20solution=20would=0D=0Abe=20either=20returning=20UNKNO= W_HOST.=20UNABLE=20TO=20COMPLY=20also=20seems=20a=20good=20solution=0D=0A= since=20the=20receiving=20node=20is=20in=20fact=20in=20really=20unable=20= to=20process=20the=20request=0D=0Abecause=20the=20peer`s=20Identity=20has= =20turned=20out=20to=20be=20same.=0D=0A
=0D=0A
Regarding=20the=20test=20case=20document=20I= =20think=0D=0Athis=20case=20is=20already=20present=20in=20the=20document.= =20draft-fajardo-dime-interop-test-suite-01=0D=0Ain=20section=203.1.1.2= =20,=20point=203.=0D=0A
=0D=0A
=0D=0A
Sincerely,=0D=0A
Himanshu.=0D=0A=0D=0A=0D=0A= Know=0D=0AMe=20=0D=0A=0D=0Ahttp://www= .aricent.com=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A= =0D=0A=0D=0AVictor=20Fajardo=20<vfajardo@t= ari.toshiba.com>=0D=0A=0D=0A

12/12/2006=2010:33=20PM=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ATo=0D=0Ahimanshu=20bahl=20<hb= ahl52@yahoo.com>=0D=0A=0D=0A=0D=0A= cc=0D=0Adime@ietf.org,=20"'Tsc= hofenig,=0D=0AHannes'"=20<hannes.tschofenig@siemens.com>=0D=0A=0D=0A=0D=0ASubject=0D=0ARe:=20[Dime]=20regarding=20test=0D=0Acase=20in= =20interop=20doc=20for=20same=20host=20on=20 =20 =20 =20&n= bsp;=20bothsides=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
= =0D=0A
Hi,
=0D=0A
=0D=0ASorry=20for=20the= =20late=20reply.
=0D=0A>=20hi=20all,
=0D=0A>=20I=20have=20ask= ed=20this=20before=20also.
=0D=0A>=20please=20clarify=20me=20on=20t= his=20one.=20suppose=20we=20get=20the=20same
=0D=0A>=20host=20id=20= on=20both=20sides=20.=20i.e=20on=20both=20peers=20we=20have
=0D=0A>= =20host1.x.com=20for=20example.
=0D=0A>=20then=20what=20kind=20of= =20processing=20are=20we=20supposed=20to=20do=20?
=0D=0A>
=0D=0A= >=201.=20will=20there=20be=20election=20lost=20hence=20an=20error=20co= de=20of
=0D=0A>=204003=20(=20Election=20lost)=20be=20returned=20on= =20both=20sides.?
=0D=0A>
=0D=0A>=202.=20Will=20there=20be=20= an=20error=20returned=20with=20code=205012=20
=0D=0A>=20(unable=20t= o=20comply=20)=20?
=0D=0A>
=0D=0A>=203.=20will=20the=20messag= e=20be=20silently=20be=20discarded=20with=20no
=0D=0A>=20answer=20m= essages=20and=20connection=20will=20be=20torn=20down=20?
=0D=0A>=20=  =20
=0D=0AObviously=20this=20scenario=20is=20a=20mis-configurati= on.=20Are=20you=20proposing=20to=20add=0D=0A
=0D=0Athis=20to=20the=20t= est=20document=20?
=0D=0A
=0D=0AIn=20general,=20I=20would=20prefer= =20option=20(3)=20just=20to=20maintain=20interoperability.=0D=0A
=0D= =0AAlso,=20election=20is=20independent=20of=20this=20scenario=20and=20you= r=20implementation=0D=0A
=0D=0Acan=20always=20check=20for=20this=20cas= e=20and=20revert=20to=20(3)=20instead=20of=20going=20ahead=0D=0A
=0D= =0Awith=20the=20election.
=0D=0A
=0D=0Aregards,
=0D=0Avictor
= =0D=0A
=0D=0A>=20a=20fast=20reply=20will=20be=20help=20full.
=0D= =0A>
=0D=0A>=20Sincerely,
=0D=0A>=20Himanshu.
=0D=0A>= ;=20http://thebahls.blogspot.com
=0D=0A>
=0D=0A>
=0D=0A>= ;
=0D=0A>=20---=20Tony=20Zhang=20<zhangtao_hw@huawei.com>=20w= rote:
=0D=0A>
=0D=0A>=20 =20
=0D=0A>>=20Hi=20Al= l
=0D=0A>>=20 =20 =20 =20 I=20suggest=20add= =20test=20cases:
=0D=0A>>=20 =20 =20 =20(1)Use=20= DWR/DWA=20detect=20connection=20status.
=0D=0A>>=20 =20&nbs= p;=20 =20(2)Routing=20based=20on
=0D=0A>>=20longest-match-f= rom-the-right=20on=20the=20realm=20 =20 =20 
=0D=0A>= >=20rather=20than=20requiring=20an=20exact=20match.=20 =20 = =20 
=0D=0A>>=20 =20 =20 =20(3)For=20Redirec= t,the=20loop=20maybe=20happen,=20should
=0D=0A>>=20test=20it?=0D=0A>>=20 =20 =20 =20(4)Routing=20should=20test= =20default=20route=20entry?
=0D=0A>>=20 =20 =20 = =20(5)For=20connection=20,should=20test=20more=20Negative
=0D=0A>&g= t;=20test?like=20no=20response.no=20CER=20etc?
=0D=0A>>=20Thanks= !
=0D=0A>>=20Tony
=0D=0A>>
=0D=0A>>=20-----Ori= ginal=20Message-----
=0D=0A>>=20From:=20Tschofenig,=20Hannes
= =0D=0A>>=20[mailto:hannes.tschofenig@siemens.com]=20
=0D=0A>&= gt;=20Sent:=20Wednesday,=20December=2006,=202006=2012:03=20AM
=0D=0A&g= t;>=20To:=20Tom-PT=20Taylor;=20Hannes=20Tschofenig
=0D=0A>>= =20Cc:=20dime@ietf.org
=0D=0A>>=20Subject:=20AW:=20[Dime]=20Re:= =20Input=20for=20Diameter=20Test
=0D=0A>>=20Cases
=0D=0A>&= gt;
=0D=0A>>=20Thanks=20Tom.=20
=0D=0A>>
=0D=0A>&= gt;=20We=20are=20looking=20forward=20to=20inspect=20the=20input.=20
= =0D=0A>>
=0D=0A>>=20In=20the=20meanwhile=20we=20need=20to= =20work=20on=20the=20test=20cases.
=0D=0A>>=20Would=20you=20like= =20to=20give=20us=20some=20feedback?=20Here=20is=20the
=0D=0A>>= =20current=20draft=20version:=20
=0D=0A>>
=0D=0A>>=20&n= bsp;=20 =20
=0D=0A>=20http://www.opendiameter.org/public/draft= -fajardo-dime-interop-test-suite-02.txt
=0D=0A>=20 =20
=0D= =0A>>=20I=20have=20created=20a=20Wiki=20page=20to=20collect=20infor= mation.=20
=0D=0A>>
=0D=0A>>=20Ciao
=0D=0A>>= =20Hannes=20
=0D=0A>>
=0D=0A>>=20-----Urspr=FCngliche= =20Nachricht-----
=0D=0A>>=20Von:=20Tom-PT=20Taylor=20[mailto:ta= ylor@nortel.com]=20
=0D=0A>>=20Gesendet:=20Dienstag,=205.=20Deze= mber=202006=2016:59
=0D=0A>>=20An:=20Hannes=20Tschofenig
=0D= =0A>>=20Cc:=20dime@ietf.org
=0D=0A>>=20Betreff:=20[Dime]= =20Re:=20Input=20for=20Diameter=20Test=20Cases
=0D=0A>>
=0D= =0A>>=20The=20MultiService=20Forum=20(MSF)=20is=20working=20through=
=0D=0A>>=20their=20liaison=20process.=20
=0D=0A>>=20We= =20should=20have=20the=20material=20to=20you=20in=20two=20to=20three
= =0D=0A>>=20weeks.
=0D=0A>>
=0D=0A>>=20Hannes=20Ts= chofenig=20wrote:
=0D=0A>>=20 =20 =20
=0D=0A>>= ;>=20Hi=20Tom,
=0D=0A>>>
=0D=0A>>>=20during=20= the=20DIME=20meeting=20you=20mentioned=20that=20you
=0D=0A>>>= =20 =20 =20 =20
=0D=0A>>=20could=20provide=20us= =20with=20
=0D=0A>>=20 =20 =20
=0D=0A>>>= =20some=20test=20cases=20(collected=20from=20another=20interop
=0D=0A&= gt;>>=20 =20 =20 =20
=0D=0A>>=20event).
= =0D=0A>>=20 =20 =20
=0D=0A>>>=20Ciao
=0D= =0A>>>=20Hannes
=0D=0A>>>
=0D=0A>>>=20&n= bsp;=20 =20 =20
=0D=0A>>=20___________________________= ____________________
=0D=0A>>=20DiME=20mailing=20list
=0D=0A&= gt;>=20DiME@ietf.org
=0D=0A>>=20https://www1.ietf.org/mailman= /listinfo/dime
=0D=0A>>
=0D=0A>>=20____________________= ___________________________
=0D=0A>>=20DiME=20mailing=20list
= =0D=0A>>=20DiME@ietf.org
=0D=0A>>=20https://www1.ietf.org/= mailman/listinfo/dime
=0D=0A>>
=0D=0A>>
=0D=0A>&g= t;
=0D=0A>>=20_______________________________________________=0D=0A>>=20DiME=20mailing=20list
=0D=0A>>=20DiME@ietf.org=
=0D=0A>>=20https://www1.ietf.org/mailman/listinfo/dime
=0D= =0A>>
=0D=0A>>=20 =20 =20
=0D=0A>
=0D= =0A>
=0D=0A>
=0D=0A>=20 
=0D=0A>=20____________= ________________________________________________________________________<= br>=0D=0A>=20Any=20questions?=20Get=20answers=20on=20any=20topic=20at= =20www.Answers.yahoo.com.=0D=0A Try=20it=20now.
=0D=0A>
=0D= =0A>=20_______________________________________________
=0D=0A>= =20DiME=20mailing=20list
=0D=0A>=20DiME@ietf.org
=0D=0A>=20ht= tps://www1.ietf.org/mailman/listinfo/dime
=0D=0A>
=0D=0A>
= =0D=0A>=20 =20
=0D=0A
=0D=0A
=0D=0A_____________________= __________________________
=0D=0ADiME=20mailing=20list
=0D=0ADiME@i= etf.org
=0D=0Ahttps://www1.ietf.org/mailman/listinfo/dime
=0D=0A=0D=0A=0D=0A

= =0D=0A
=0D=0A***********************=20 Aricent-Private=20 = =20***********************=0D=0A
"DISCLAIMER:=20This=20message=20is=20propri=
etary=20to=20Aricent=20=20and=20is=20intended=20solely=20for=20the=20use=
=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=
=20contain=20privileged=20or=20confidential=20information=20and=20should=
=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20t=
han=20for=20what=20it=20is=20intended.=20If=20you=20have=20received=20thi=
s=20message=20in=20error,=20=0Aplease=20notify=20the=20originator=20immed=
iately.=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=
=20notified=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20=
copying,=20altering,=20or=20disclosing=20the=20contents=20of=20this=20mes=
sage.=20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20da=
mage=20arising=20from=20the=20use=20of=20the=20information=20transmitted=
=20by=20this=20email=20including=20damage=20from=20virus."=0A
--=_alternative 006F888865257242_=-- --===============1377189573== 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 --===============1377189573==-- From dime-bounces@ietf.org Tue Dec 12 15:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEal-0006Yo-MC; Tue, 12 Dec 2006 15:51:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuEak-0006Yg-Va; Tue, 12 Dec 2006 15:51:11 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuEai-0001x8-Kn; Tue, 12 Dec 2006 15:51:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5BF93176C1; Tue, 12 Dec 2006 20:50:38 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GuEa5-00085H-Gc; Tue, 12 Dec 2006 15:50:31 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Dec 2006 15:50:29 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, J. Loughney Filename : draft-ietf-dime-rfc3588bis-00.txt Pages : 166 Date : 2006-12-12 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-12140407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-12140407.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Dec 12 16:38:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFKL-00069P-En; Tue, 12 Dec 2006 16:38:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFKK-00068l-2A for dime@ietf.org; Tue, 12 Dec 2006 16:38:16 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuFKI-00016x-Qa for dime@ietf.org; Tue, 12 Dec 2006 16:38:16 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 78F41FF22D; Tue, 12 Dec 2006 16:38:12 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBCLc1pE012365; Tue, 12 Dec 2006 16:38:05 -0500 (EST) From: "Tolga Asveren" To: "Victor Fajardo" , "Tom-PT Taylor" Subject: RE: [Dime] Application Id for commands in Gq and similar applications Date: Tue, 12 Dec 2006 16:34:57 -0500 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: <457EE536.5040107@tari.toshiba.com> Received-SPF: none X-Spam-Score: 0.0 (/) 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 I share Victor's concerns on this one. I believe it may be safer not to touch the meaning of Application-Id AVPs and they have always the same values as the Application-Id in the message header. My understanding of approach two was that Auth-App-Id (together with App-Id in the header) is populated with the identifier of the corresponding application, e.g. Gq. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, December 12, 2006 12:22 PM > To: Tom-PT Taylor > Cc: Tolga Asveren; dime@ietf.org > Subject: Re: [Dime] Application Id for commands in Gq and similar > applications > > > Hi Tom, > > > > You saw my other note suggesting a change in the meaning of the > > application identifier in the body? > > I see. My main concern was interoperability if this new "meaning" > results in multiple different app ids within a message. It could > generate issues. > > best regards, > victor > > > I thought I would do some forensic tracking, and dug out a copy of > > draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my > > laptop. (We used it as a basis for IPDC, one of Megaco's > > predecessors.) Anyway, that was too far back -- the concept of > > applications wasn't present yet. > > > > Victor Fajardo wrote: > >> Hi Tom, > >>> Despite what I just said, I'll go for the second approach for the > >>> sake of maximizing the possibility of interoperability. > >> > >> Just trying to catch up on the discussion, does the "second approach" > >> mean that the app id in the header does not match those in the app id > >> avps ? If so, this is probably in conflict with the existing base and > >> with the bis as well. My understanding is that if your just trying to > >> reuse a command/message defined from another spec (pls correct me if > >> I mis-understood the problem) then the "second approach" is preferred > >> but you should define a consistent app id in both the header and app > >> id avps. The app id of the spec that originally defined the command > >> need not be represented when you use the command in your new > >> application. > >> > > [snip] > > > > The other > >>>>> possibility might conform more to the spirit underlying RFC 3588 by > >>>>> using Auth-Application-Id to convey the application identifier > >>>>> (like Gq > >>>>> and the RFCs), keeping all the mandatory AVPs, but > specifying default > >>>>> contents for those mandatory AVPs of no interest to the application. > >>>>> > > [snip] > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 12 16:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFWx-0006QF-LP; Tue, 12 Dec 2006 16:51:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuFWw-0006Nr-B1 for dime@ietf.org; Tue, 12 Dec 2006 16:51:18 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuFWu-0003Ps-Td for dime@ietf.org; Tue, 12 Dec 2006 16:51:18 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kBCLhvK00049; Tue, 12 Dec 2006 16:43:58 -0500 (EST) Received: from [47.130.16.48] ([47.130.16.48] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 16:51:17 -0500 Message-ID: <457F243E.4090405@nortel.com> Date: Tue, 12 Dec 2006 16:50:54 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Application Id for commands in Gq and similar applications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2006 21:51:18.0078 (UTC) FILETIME=[A736F5E0:01C71E37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 That is, indeed, what I recommended for Q.3301.1 (the Rs application). Tolga Asveren wrote: > I share Victor's concerns on this one. I believe it may be safer not to > touch the meaning of Application-Id AVPs and they have always the same > values as the Application-Id in the message header. > > My understanding of approach two was that Auth-App-Id (together with App-Id > in the header) is populated with the identifier of the corresponding > application, e.g. Gq. > > Thanks, > Tolga > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Tuesday, December 12, 2006 12:22 PM >> To: Tom-PT Taylor >> Cc: Tolga Asveren; dime@ietf.org >> Subject: Re: [Dime] Application Id for commands in Gq and similar >> applications >> >> >> Hi Tom, >>> You saw my other note suggesting a change in the meaning of the >>> application identifier in the body? >> I see. My main concern was interoperability if this new "meaning" >> results in multiple different app ids within a message. It could >> generate issues. >> >> best regards, >> victor >> >>> I thought I would do some forensic tracking, and dug out a copy of >>> draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my >>> laptop. (We used it as a basis for IPDC, one of Megaco's >>> predecessors.) Anyway, that was too far back -- the concept of >>> applications wasn't present yet. >>> >>> Victor Fajardo wrote: >>>> Hi Tom, >>>>> Despite what I just said, I'll go for the second approach for the >>>>> sake of maximizing the possibility of interoperability. >>>> Just trying to catch up on the discussion, does the "second approach" >>>> mean that the app id in the header does not match those in the app id >>>> avps ? If so, this is probably in conflict with the existing base and >>>> with the bis as well. My understanding is that if your just trying to >>>> reuse a command/message defined from another spec (pls correct me if >>>> I mis-understood the problem) then the "second approach" is preferred >>>> but you should define a consistent app id in both the header and app >>>> id avps. The app id of the spec that originally defined the command >>>> need not be represented when you use the command in your new >>>> application. >>>> >>> [snip] >>> >>> The other >>>>>>> possibility might conform more to the spirit underlying RFC 3588 by >>>>>>> using Auth-Application-Id to convey the application identifier >>>>>>> (like Gq >>>>>>> and the RFCs), keeping all the mandatory AVPs, but >> specifying default >>>>>>> contents for those mandatory AVPs of no interest to the application. >>>>>>> >>> [snip] >>> >>> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 13 09:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuUiw-0006iG-9A; Wed, 13 Dec 2006 09:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuUiv-0006i9-3e for dime@ietf.org; Wed, 13 Dec 2006 09:04:41 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuUit-0001rD-Iw for dime@ietf.org; Wed, 13 Dec 2006 09:04:41 -0500 Received: (qmail 65638 invoked by uid 0); 13 Dec 2006 14:04:27 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 13 Dec 2006 14:04:27 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Dec 2006 15:04:27 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB5357@lulex02.ad.operax.com> In-Reply-To: <4576AA74.7070404@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Auditing & ETSI TISPAN Thread-Index: AccZKlUiUtvDQ1RwScSNYV8CxUPn4wFlKJAw From: "Ulf Bodin" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: steve.norreys@bt.com, avri@ltu.se, dime@ietf.org Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN 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,=20 Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN has now agreed to send an LS and the draft LS will hence be forwarded to the TC of TISPAN for the final decition (at least this is how I understand the procedure :-).=20 Best regards,=20 Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 6 december 2006 12:33 To: Ulf Bodin Cc: avri@ltu.se; dime@ietf.org Subject: Re: Diameter Auditing & ETSI TISPAN Hi Ulf, thanks for the quick response. Please keep us up-to-date with regard to the outcome of the discussion next week. Ciao Hannes Ulf Bodin wrote: > Hi Hannes, > > I've submitted a draft LS for the meeting next week jointly signed by=20 > myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition=20 > will be taken next week on sending the LS to IETF. > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 6 december 2006 11:44 > To: Ulf Bodin; avri@ltu.se > Cc: dime@ietf.org > Subject: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Avri, > > what is the status of the liaison between ETSI TISPAN and the IETF=20 > DIME working group regarding the Diameter Auditing work? > > Ciao > Hannes & John > > PS: We encourage you to continue your work on the Diameter Auditing=20 > requirements draft and also to start your work on the solution document. > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 13 13:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZ9i-0007oG-2K; Wed, 13 Dec 2006 13:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZ9g-0007mw-SF for dime@ietf.org; Wed, 13 Dec 2006 13:48:36 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuZ9Y-0000pO-G5 for dime@ietf.org; Wed, 13 Dec 2006 13:48:36 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA8000S96WQCQ@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 13 Dec 2006 18:48:26 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.117.61]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA800GQQ6WPR6@lhrga01-in.huawei.com> for dime@ietf.org; Wed, 13 Dec 2006 18:48:26 +0000 (GMT) Date: Wed, 13 Dec 2006 19:48:21 +0100 From: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN To: Hannes Tschofenig , Ulf Bodin Message-id: <001501c71ee7$4383d3a0$3d75a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <33656995C5C5094A983DE84DA649A924CB5357@lulex02.ad.operax.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: steve.norreys@bt.com, avri@ltu.se, 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 And ETSI TISPAN also pointed out that there are no requirements about audit written in the active standard documents or drafts. People proposed, but they were removed, this is why there are no requirements about audit written in the active standard documents or drafts. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: "Hannes Tschofenig" Cc: ; ; Sent: Wednesday, December 13, 2006 3:04 PM Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes, Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN has now agreed to send an LS and the draft LS will hence be forwarded to the TC of TISPAN for the final decition (at least this is how I understand the procedure :-). Best regards, Ulf -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: den 6 december 2006 12:33 To: Ulf Bodin Cc: avri@ltu.se; dime@ietf.org Subject: Re: Diameter Auditing & ETSI TISPAN Hi Ulf, thanks for the quick response. Please keep us up-to-date with regard to the outcome of the discussion next week. Ciao Hannes Ulf Bodin wrote: > Hi Hannes, > > I've submitted a draft LS for the meeting next week jointly signed by > myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition > will be taken next week on sending the LS to IETF. > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 6 december 2006 11:44 > To: Ulf Bodin; avri@ltu.se > Cc: dime@ietf.org > Subject: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Avri, > > what is the status of the liaison between ETSI TISPAN and the IETF > DIME working group regarding the Diameter Auditing work? > > Ciao > Hannes & John > > PS: We encourage you to continue your work on the Diameter Auditing > requirements draft and also to start your work on the solution document. > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 13 16:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gubu5-0002Zz-1t; Wed, 13 Dec 2006 16:44:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gubu3-0002ZG-G4 for dime@ietf.org; Wed, 13 Dec 2006 16:44:39 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gubu1-00044d-Vl for dime@ietf.org; Wed, 13 Dec 2006 16:44:39 -0500 Received: (qmail 10237 invoked by uid 0); 13 Dec 2006 21:44:36 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 13 Dec 2006 21:44:36 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Wed, 13 Dec 2006 22:44:35 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB540E@lulex02.ad.operax.com> In-Reply-To: <001501c71ee7$4383d3a0$3d75a7d9@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: Acce506P4NSWEPSlQ3yF3qWL5vII5AAF7slQ From: "Ulf Bodin" To: "Tina TSOU" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: steve.norreys@bt.com, avri@ltu.se, 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 Yes, that's absolutely right. The reason for removing the requirements was that the protocol selected for the reference points in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements on auditing were removed since they were not possible to meet. We hope that by having a mechnism for auditing defined by the IETF the deletion of the auditing requirements can be reconsidered by ETSI TISPAN for coming releases.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: den 13 december 2006 19:48 To: Hannes Tschofenig; Ulf Bodin Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN And ETSI TISPAN also pointed out that there are no requirements about audit written in the active standard documents or drafts. People proposed, but they were removed, this is why there are no requirements about audit written in the active standard documents or drafts. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: "Hannes Tschofenig" Cc: ; ; Sent: Wednesday, December 13, 2006 3:04 PM Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes, Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN has now agreed to send an LS and the draft LS will hence be forwarded to the TC of TISPAN for the final decition (at least this is how I understand the procedure :-). Best regards, Ulf -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: den 6 december 2006 12:33 To: Ulf Bodin Cc: avri@ltu.se; dime@ietf.org Subject: Re: Diameter Auditing & ETSI TISPAN Hi Ulf, thanks for the quick response. Please keep us up-to-date with regard to the outcome of the discussion next week. Ciao Hannes Ulf Bodin wrote: > Hi Hannes, > > I've submitted a draft LS for the meeting next week jointly signed by > myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the decition > will be taken next week on sending the LS to IETF. > > Best regards, > Ulf > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 6 december 2006 11:44 > To: Ulf Bodin; avri@ltu.se > Cc: dime@ietf.org > Subject: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Avri, > > what is the status of the liaison between ETSI TISPAN and the IETF > DIME working group regarding the Diameter Auditing work? > > Ciao > Hannes & John > > PS: We encourage you to continue your work on the Diameter Auditing > requirements draft and also to start your work on the solution document. > _______________________________________________ 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 Dec 13 16:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gubzj-0004xv-Ny; Wed, 13 Dec 2006 16:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gubzi-0004xg-K0 for dime@ietf.org; Wed, 13 Dec 2006 16:50:30 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gubzh-00053M-2n for dime@ietf.org; Wed, 13 Dec 2006 16:50:30 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBDLngRS005240; Wed, 13 Dec 2006 23:49:45 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 23:50:11 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 23:50:11 +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: [Dime] RE: Diameter Auditing & ETSI TISPAN Date: Wed, 13 Dec 2006 23:49:39 +0200 Message-ID: In-Reply-To: <33656995C5C5094A983DE84DA649A924CB540E@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: Acce506P4NSWEPSlQ3yF3qWL5vII5AAF7slQAABdyGA= From: To: , , X-OriginalArrivalTime: 13 Dec 2006 21:50:11.0758 (UTC) FILETIME=[AA1914E0:01C71F00] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to discuss this with TISPAN? John=20 >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com]=20 >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the=20 >requirements was that the protocol selected for the reference=20 >points in questions (i.e. DIAMETER) doesn't (yet) support=20 >auditing. Hence, the requirements on auditing were removed=20 >since they were not possible to meet. We hope that by having a=20 >mechnism for auditing defined by the IETF the deletion of the=20 >auditing requirements can be reconsidered by ETSI TISPAN for=20 >coming releases.=20 > >Best regards, >Ulf=20 > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no=20 >requirements about audit written in the active standard=20 >documents or drafts. >People proposed, but they were removed, this is why there are=20 >no requirements about audit written in the active standard=20 >documents or drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of=20 >ETSI TISPAN has now agreed to send an LS and the draft LS will=20 >hence be forwarded to the TC of TISPAN for the final decition=20 >(at least this is how I understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with=20 >regard to the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly=20 >signed by=20 >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the=20 >decition=20 >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF=20 >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing=20 >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >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 Wed Dec 13 17:03:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GucCO-0002dB-Rj; Wed, 13 Dec 2006 17:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GucCO-0002d6-Ft for dime@ietf.org; Wed, 13 Dec 2006 17:03:36 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GucCM-00071t-Sn for dime@ietf.org; Wed, 13 Dec 2006 17:03:36 -0500 Received: (qmail 48995 invoked by uid 0); 13 Dec 2006 22:03:34 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 13 Dec 2006 22:03:34 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Wed, 13 Dec 2006 23:03:33 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB540F@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: Acce506P4NSWEPSlQ3yF3qWL5vII5AAF7slQAABdyGAAAB1vAA== From: "Ulf Bodin" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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,=20 Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. It is written by the authors with the intent of reflecting needs related to coming releases of the ETSI TISPAN architecture (and hopefully similar architectures as those defined by 3GPP and ITU-T). This IETF draft was referred to when discussing the LS today and the requirements listed therein ware considered useful from an ETSI TISPAN perspective.=20 The intention is further to submitt contributions to ETSI TISPAN aiming at again include sufficient requirements on auditing into the release 2 of the ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings.=20 Best regards,=20 Ulf=20 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to discuss this with TISPAN? John=20 >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requirements=20 >was that the protocol selected for the reference points in questions=20 >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements >on auditing were removed since they were not possible to meet. We hope=20 >that by having a mechnism for auditing defined by the IETF the deletion >of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements about=20 >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no=20 >requirements about audit written in the active standard documents or=20 >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN >has now agreed to send an LS and the draft LS will hence be forwarded=20 >to the TC of TISPAN for the final decition (at least this is how I=20 >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF=20 >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing=20 >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 05:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCx-0000Mf-PB; Thu, 14 Dec 2006 05:52:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCx-0000MY-Hh for dime@ietf.org; Thu, 14 Dec 2006 05:52:59 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoCu-0003EP-OE for dime@ietf.org; Thu, 14 Dec 2006 05:52:59 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA9005RGFK5MQ@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 10:52:53 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.117.61]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA900LHVFK4ZC@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 10:52:53 +0000 (GMT) Date: Thu, 14 Dec 2006 11:52:47 +0100 From: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN To: Hannes.Tschofenig@gmx.net, john.loughney@nokia.com, Ulf Bodin Message-id: <001901c71f6d$fea570e0$3d75a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <33656995C5C5094A983DE84DA649A924CB540F@lulex02.ad.operax.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: steve.norreys@bt.com, avri@ltu.se, 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 ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface protocol (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 and other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the capability to support synchronization and audit of the resource control session status in support of recovery and operational information statistics and auditing. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: ; ; Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. It is written by the authors with the intent of reflecting needs related to coming releases of the ETSI TISPAN architecture (and hopefully similar architectures as those defined by 3GPP and ITU-T). This IETF draft was referred to when discussing the LS today and the requirements listed therein ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aiming at again include sufficient requirements on auditing into the release 2 of the ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to discuss this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requirements >was that the protocol selected for the reference points in questions >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements >on auditing were removed since they were not possible to meet. We hope >that by having a mechnism for auditing defined by the IETF the deletion >of the auditing requirements can be reconsidered by ETSI TISPAN for >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements about >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no >requirements about audit written in the active standard documents or >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN >has now agreed to send an LS and the draft LS will hence be forwarded >to the TC of TISPAN for the final decition (at least this is how I >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 06:22:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guofl-00058a-6L; Thu, 14 Dec 2006 06:22:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guofk-00058S-9I for dime@ietf.org; Thu, 14 Dec 2006 06:22:44 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guofi-0008NA-Ok for dime@ietf.org; Thu, 14 Dec 2006 06:22:44 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 12:22:00 +0100 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 12:22:01 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE04C696FF@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: Accfbh1AGmY+SKBuT2WQz5/iyeEGJQAA007A From: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" , , , "Ulf Bodin" X-OriginalArrivalTime: 14 Dec 2006 11:22:00.0729 (UTC) FILETIME=[12E83890:01C71F72] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 mechanism defined in Q.3301 enables querying the status of a = particular session (i.e. almost like a keep-alive mechanism). It does = not provide a solution that fulfil all the requirements described in = draft-bodin-dime-auditing-reqs-01.txt=20 BC -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com]=20 Envoy=E9 : jeudi 14 d=E9cembre 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : Re: [Dime] RE: Diameter Auditing & ETSI TISPAN ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface protocol = (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 and = other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the = capability to support synchronization and audit of the resource control = session status in support of recovery and operational information = statistics and auditing. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: ; ; = Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. It is written by the authors with the intent of reflecting needs related = to coming releases of the ETSI TISPAN architecture (and hopefully = similar architectures as those defined by 3GPP and ITU-T). This IETF = draft was referred to when discussing the LS today and the requirements = listed therein ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aiming = at again include sufficient requirements on auditing into the release 2 = of the ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to = discuss this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requirements=20 >was that the protocol selected for the reference points in questions=20 >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements >on auditing were removed since they were not possible to meet. We hope=20 >that by having a mechnism for auditing defined by the IETF the deletion >of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements about=20 >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no=20 >requirements about audit written in the active standard documents or=20 >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN >has now agreed to send an LS and the draft LS will hence be forwarded=20 >to the TC of TISPAN for the final decition (at least this is how I=20 >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF=20 >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing=20 >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 06:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guoga-0005IH-OY; Thu, 14 Dec 2006 06:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuogZ-0005I9-VJ for dime@ietf.org; Thu, 14 Dec 2006 06:23:35 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuogY-0008VZ-Mi for dime@ietf.org; Thu, 14 Dec 2006 06:23:35 -0500 Received: (qmail 96998 invoked by uid 0); 14 Dec 2006 11:23:33 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 14 Dec 2006 11:23:33 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 12:23:30 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB547E@lulex02.ad.operax.com> In-Reply-To: <001901c71f6d$fea570e0$3d75a7d9@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfbgmIjRFhTWeoT9yaDjYc/lcJqgAAUXdg From: "Ulf Bodin" To: "Tina TSOU" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: steve.norreys@bt.com, avri@ltu.se, 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 To my undertanding the audit mechanism in Q.3301 of ITU-T defined although a quite general requirement a limited mechanism not fully meeting the requirements of draft-bodin-dime-auditing-reqs-01.txt. In my view there is an oppurtunity of the IETF DIME WG to accept developing a specification on DIAMETER auditing that meet all requirements deemed desired, or to advice ETSI TISPAN to develop their own extensions to the DIAMETER base protocol. Peronally I beleve the latter alternative to be unfortunate since we then face the risk of ending up with a number of different extensions whereof each one solves a limited auditing problem related to a specific usage of the DIAMETER protocol.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: den 14 december 2006 11:53 To: Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface protocol (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 and other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the capability to support synchronization and audit of the resource control session status in support of recovery and operational information statistics and auditing. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: ; ; Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. It is written by the authors with the intent of reflecting needs related to coming releases of the ETSI TISPAN architecture (and hopefully similar architectures as those defined by 3GPP and ITU-T). This IETF draft was referred to when discussing the LS today and the requirements listed therein ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aiming at again include sufficient requirements on auditing into the release 2 of the ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to discuss this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requirements=20 >was that the protocol selected for the reference points in questions=20 >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements >on auditing were removed since they were not possible to meet. We hope=20 >that by having a mechnism for auditing defined by the IETF the deletion >of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements about=20 >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no=20 >requirements about audit written in the active standard documents or=20 >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN >has now agreed to send an LS and the draft LS will hence be forwarded=20 >to the TC of TISPAN for the final decition (at least this is how I=20 >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF=20 >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing=20 >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 06:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guosm-0001rx-09; Thu, 14 Dec 2006 06:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guosk-0001rl-Ni for dime@ietf.org; Thu, 14 Dec 2006 06:36:10 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guosi-00023M-OA for dime@ietf.org; Thu, 14 Dec 2006 06:36:10 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA9005CCHK7MQ@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 11:36:07 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.117.61]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA900HZ2HK5KY@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 11:36:07 +0000 (GMT) Date: Thu, 14 Dec 2006 12:35:59 +0100 From: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN To: Ulf Bodin , john.loughney@nokia.com, Hannes.Tschofenig@gmx.net, CHATRAS Bruno RD-CORE-ISS Message-id: <003c01c71f74$08d654c0$3d75a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=original; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <2AF8FF7D89242541B12E7A47F6ECB4BE04C696FF@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: steve.norreys@bt.com, avri@ltu.se, 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, Q.3301 only needs to comply with the requirements within its requirem= ents=20 document Y.2111. draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements= =20 documents. We should notice the difference between synchronization and audit. Wh= at=20 Q.3301 specifies is audit rather than synchronization. If people need our DIME WG meet ETSI TISPAN requirements, it is more= =20 appropriate show requirements in ETSI TISPAN requirements documents (= e.g.=20 RACS R1, RACS R2). If ETSI TISPAN officially says that draft-bodin-dime-auditing-reqs-01= .txt is=20 ETSI TISPAN official audit requirements, that's fine. B. R. Tina ----- Original Message -----=20 =46rom: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" ; ;=20 ; "Ulf Bodin" Cc: ; ; Sent: Thursday, December 14, 2006 12:22 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN The mechanism defined in Q.3301 enables querying the status of a part= icular=20 session (i.e. almost like a keep-alive mechanism). It does not provid= e a=20 solution that fulfil all the requirements described in=20 draft-bodin-dime-auditing-reqs-01.txt BC -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : Re: [Dime] RE: Diameter Auditing & ETSI TISPAN ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface proto= col=20 (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 a= nd=20 other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the= =20 capability to support synchronization and audit of the resource contr= ol=20 session status in support of recovery and operational information sta= tistics=20 and auditing. B. R. Tina ----- Original Message ----- =46rom: "Ulf Bodin" To: ; ;=20 Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this documen= t. It is written by the authors with the intent of reflecting needs rela= ted to=20 coming releases of the ETSI TISPAN architecture (and hopefully simila= r=20 architectures as those defined by 3GPP and ITU-T). This IETF draft wa= s=20 referred to when discussing the LS today and the requirements listed = therein=20 ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aimi= ng at=20 again include sufficient requirements on auditing into the release 2 = of the=20 ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- =46rom: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditin= g. We can review that on the mailing list. Is it possible for you to di= scuss=20 this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requiremen= ts >was that the protocol selected for the reference points in questions >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requireme= nts >on auditing were removed since they were not possible to meet. We ho= pe >that by having a mechnism for auditing defined by the IETF the delet= ion >of the auditing requirements can be reconsidered by ETSI TISPAN for >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements abou= t >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no >requirements about audit written in the active standard documents or >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TIS= PAN >has now agreed to send an LS and the draft LS will hence be forwarde= d >to the TC of TISPAN for the final decition (at least this is how I >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard= to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditin= g >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 06:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gup6d-0007a3-Dv; Thu, 14 Dec 2006 06:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gup6c-0007Zr-7r for dime@ietf.org; Thu, 14 Dec 2006 06:50:30 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gup6a-0003u2-LV for dime@ietf.org; Thu, 14 Dec 2006 06:50:30 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 12:50:20 +0100 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 12:50:02 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE04C6974F@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfdA34/w7wLzsTRZmVoh0ICM01WgAAUguw From: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" , "Ulf Bodin" , , X-OriginalArrivalTime: 14 Dec 2006 11:50:20.0619 (UTC) FILETIME=[081ED9B0:01C71F76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: steve.norreys@bt.com, avri@ltu.se, 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 =20 -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com]=20 Envoy=E9 : jeudi 14 d=E9cembre 2006 12:36 =C0 : Ulf Bodin; john.loughney@nokia.com; Hannes.Tschofenig@gmx.net; = CHATRAS Bruno RD-CORE-ISS Cc : dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Objet : Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi all, Q.3301 only needs to comply with the requirements within its = requirements document Y.2111. draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements = documents. We should notice the difference between synchronization and audit. What Q.3301 specifies is audit rather than synchronization. =3D=3D> BC: To be even more precise, we could also notice that Q.3301 = specifies auditing of the session status only rather than auditing of = reservation contexts in general. If people need our DIME WG meet ETSI TISPAN requirements, it is more = appropriate show requirements in ETSI TISPAN requirements documents = (e.g.=20 RACS R1, RACS R2). If ETSI TISPAN officially says that = draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit = requirements, that's fine. B. R. Tina ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" ; ; = ; "Ulf Bodin" Cc: ; ; Sent: Thursday, December 14, 2006 12:22 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN The mechanism defined in Q.3301 enables querying the status of a = particular session (i.e. almost like a keep-alive mechanism). It does = not provide a solution that fulfil all the requirements described in = draft-bodin-dime-auditing-reqs-01.txt BC -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin Cc : = steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : Re: [Dime] RE: = Diameter Auditing & ETSI TISPAN ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface protocol = (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 and = other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the = capability to support synchronization and audit of the resource control = session status in support of recovery and operational information = statistics and auditing. B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: ; ; = Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. It is written by the authors with the intent of reflecting needs related = to=20 coming releases of the ETSI TISPAN architecture (and hopefully similar=20 architectures as those defined by 3GPP and ITU-T). This IETF draft was=20 referred to when discussing the LS today and the requirements listed = therein=20 ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aiming = at=20 again include sufficient requirements on auditing into the release 2 of = the=20 ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditing. We can review that on the mailing list. Is it possible for you to = discuss=20 this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requirements >was that the protocol selected for the reference points in questions >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements >on auditing were removed since they were not possible to meet. We hope >that by having a mechnism for auditing defined by the IETF the deletion >of the auditing requirements can be reconsidered by ETSI TISPAN for >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements about >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no >requirements about audit written in the active standard documents or >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN >has now agreed to send an LS and the draft LS will hence be forwarded >to the TC of TISPAN for the final decition (at least this is how I >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditing >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 07:40:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gupsc-0003pQ-Gp; Thu, 14 Dec 2006 07:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gupsa-0003oF-VW for dime@ietf.org; Thu, 14 Dec 2006 07:40:04 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GupsZ-0003Yv-8K for dime@ietf.org; Thu, 14 Dec 2006 07:40:04 -0500 Received: (qmail invoked by alias); 14 Dec 2006 12:40:02 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp033) with SMTP; 14 Dec 2006 13:40:02 +0100 X-Authenticated: #29516787 Message-ID: <45814620.204@gmx.net> Date: Thu, 14 Dec 2006 13:40:00 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN References: <33656995C5C5094A983DE84DA649A924CB540F@lulex02.ad.operax.com> <001901c71f6d$fea570e0$3d75a7d9@IBM4307EA0CEF3> In-Reply-To: <001901c71f6d$fea570e0$3d75a7d9@IBM4307EA0CEF3> 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: avri@ltu.se, Ulf Bodin , dime@ietf.org, steve.norreys@bt.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 Good to see that ITU-T is also interested in this work. I am sure Ulf, Avri and the other draft authors are going to consider additional requirements. Ciao Hannes Tina TSOU wrote: > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the > capability to support synchronization and audit of the resource > control session status in support of recovery and operational > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- From: "Ulf Bodin" > To: ; ; > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs related > to coming releases of the ETSI TISPAN architecture (and hopefully > similar architectures as those defined by 3GPP and ITU-T). This IETF > draft was referred to when discussing the LS today and the requirements > listed therein ware considered useful from an ETSI TISPAN perspective. > > The intention is further to submitt contributions to ETSI TISPAN aiming > at again include sufficient requirements on auditing into the release 2 > of the ETSI TISPAN NGN architecture (and releases beyond release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the requirements >> was that the protocol selected for the reference points in questions >> (i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements > >> on auditing were removed since they were not possible to meet. We hope >> that by having a mechnism for auditing defined by the IETF the deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no >> requirements about audit written in the active standard documents or >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 08:09:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqLT-00080J-ED; Thu, 14 Dec 2006 08:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqLR-0007yb-HF for dime@ietf.org; Thu, 14 Dec 2006 08:09:53 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuqK4-0007NW-JL for dime@ietf.org; Thu, 14 Dec 2006 08:08:31 -0500 Received: (qmail invoked by alias); 14 Dec 2006 13:08:27 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 14 Dec 2006 14:08:27 +0100 X-Authenticated: #29516787 Message-ID: <45814CC8.9050708@gmx.net> Date: Thu, 14 Dec 2006 14:08:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN References: <2AF8FF7D89242541B12E7A47F6ECB4BE04C696FF@ftrdmel3.rd.francetelecom.fr> <003c01c71f74$08d654c0$3d75a7d9@IBM4307EA0CEF3> In-Reply-To: <003c01c71f74$08d654c0$3d75a7d9@IBM4307EA0CEF3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: avri@ltu.se, dime@ietf.org, Ulf Bodin , steve.norreys@bt.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 Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements > documents. > > We should notice the difference between synchronization and audit. > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is more > appropriate show requirements in ETSI TISPAN requirements documents > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" > > To: "Tina TSOU" ; ; > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a > particular session (i.e. almost like a keep-alive mechanism). It does > not provide a solution that fulfil all the requirements described in > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] > Envoyé : jeudi 14 décembre 2006 11:53 > À : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin > Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Objet : Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the > capability to support synchronization and audit of the resource > control session status in support of recovery and operational > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ; > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs > related to coming releases of the ETSI TISPAN architecture (and > hopefully similar architectures as those defined by 3GPP and ITU-T). > This IETF draft was referred to when discussing the LS today and the > requirements listed therein ware considered useful from an ETSI TISPAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN > aiming at again include sufficient requirements on auditing into the > release 2 of the ETSI TISPAN NGN architecture (and releases beyond > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the requirements >> was that the protocol selected for the reference points in questions >> (i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requirements > >> on auditing were removed since they were not possible to meet. We hope >> that by having a mechnism for auditing defined by the IETF the deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no >> requirements about audit written in the active standard documents or >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 08:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gur08-0001rI-VE; Thu, 14 Dec 2006 08:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gur06-0001kU-Pf for dime@ietf.org; Thu, 14 Dec 2006 08:51:55 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gur03-0005uF-Su for dime@ietf.org; Thu, 14 Dec 2006 08:51:54 -0500 Received: (qmail 1041 invoked by uid 0); 14 Dec 2006 13:51:50 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 14 Dec 2006 13:51:50 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 14:51:48 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB54CF@lulex02.ad.operax.com> In-Reply-To: <45814CC8.9050708@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfgPm3PSAW8gKlRKqONIptVj4XCAAAV8+w From: "Ulf Bodin" To: "Hannes Tschofenig" , "Tina TSOU" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: avri@ltu.se, dime@ietf.org, steve.norreys@bt.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 Hannes,=20 In addition to being a requirements document draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover scenarios. Although I'm not sure a new requirement needs to be added to this draft but I do believe the specific use case addressed by Q.3301 is missing (i.e. auditing of the session status only). Hence, my answer to question 1 is; maybe but not sure, and my answer to question 2 is; I don't think so (in case we do it's a modification rather than a deletion of existing requirements).=20 In my view the best way forward is to start the work on the foreseen auditing mechanisms based on the earlier work of Calhoun (i.e. the expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case of Q.3301. All requirements need in my view to appear in the document specifying the mechnism, but maybe it's better to keep use cases in a separate document. I'm not sure the use case document now more or less being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC though.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 14 december 2006 14:08 To: Tina TSOU Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its=20 > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 > documents. > > We should notice the difference between synchronization and audit.=20 > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 > appropriate show requirements in ETSI TISPAN requirements documents=20 > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS"=20 > > To: "Tina TSOU" ; ;=20 > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a=20 > particular session (i.e. almost like a keep-alive mechanism). It does=20 > not provide a solution that fulfil all the requirements described in=20 > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre = > 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = Ulf > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet :=20 > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the=20 > capability to support synchronization and audit of the resource=20 > control session status in support of recovery and operational=20 > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ;=20 > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs=20 > related to coming releases of the ETSI TISPAN architecture (and=20 > hopefully similar architectures as those defined by 3GPP and ITU-T). > This IETF draft was referred to when discussing the LS today and the=20 > requirements listed therein ware considered useful from an ETSI TISPAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN=20 > aiming at again include sufficient requirements on auditing into the=20 > release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to=20 > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the=20 >> requirements was that the protocol selected for the reference points=20 >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >> the requirements > >> on auditing were removed since they were not possible to meet. We=20 >> hope that by having a mechnism for auditing defined by the IETF the=20 >> deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no=20 >> requirements about audit written in the active standard documents or=20 >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >> TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I=20 >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard=20 >> to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing=20 >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 08:56:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gur4R-0003ds-M8; Thu, 14 Dec 2006 08:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gur4Q-0003di-K6 for dime@ietf.org; Thu, 14 Dec 2006 08:56:22 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gur4P-0006T7-QF for dime@ietf.org; Thu, 14 Dec 2006 08:56:22 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id kBEDuBr7024121; Thu, 14 Dec 2006 14:56:11 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id kBEDu9NK014591; Thu, 14 Dec 2006 14:56:10 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 14:55:41 +0100 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: AW: [Dime] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 14:55:41 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC0240F184@MCHP7R6A.ww002.siemens.net> In-Reply-To: <33656995C5C5094A983DE84DA649A924CB54CF@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfgPm3PSAW8gKlRKqONIptVj4XCAAAV8+wAAE2IEA= From: "Tschofenig, Hannes" To: "Ulf Bodin" , "Hannes Tschofenig" , "Tina TSOU" X-OriginalArrivalTime: 14 Dec 2006 13:55:41.0689 (UTC) FILETIME=[8B070E90:01C71F87] X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 Ulf,=20 I like strawman proposals since then I have something detailed to look = at. Hence, I suggest to take draft-calhoun-diameter-res-mgmt-08.txt and = to modify it so that it fits the mentioned requirements.=20 We don't necessarily need to push a requirements draft to RFC. For = example, with the QoS document we have incorporated the most important = requirements into a section of the draft.=20 Ciao Hannes -----Urspr=FCngliche Nachricht----- Von: Ulf Bodin [mailto:Ulf.Bodin@operax.com]=20 Gesendet: Donnerstag, 14. Dezember 2006 14:52 An: Hannes Tschofenig; Tina TSOU Cc: avri@ltu.se; dime@ietf.org; steve.norreys@bt.com Betreff: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes,=20 In addition to being a requirements document draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover scenarios. Although I'm not sure a new requirement needs to be added to this draft but I do believe the specific use case addressed by Q.3301 is missing (i.e. auditing of the session status only). Hence, my answer to question 1 is; maybe but not sure, and my answer to question 2 is; I don't think so (in case we do it's a modification rather than a deletion of existing requirements).=20 In my view the best way forward is to start the work on the foreseen auditing mechanisms based on the earlier work of Calhoun (i.e. the expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case of Q.3301. All requirements need in my view to appear in the document specifying the mechnism, but maybe it's better to keep use cases in a separate document. I'm not sure the use case document now more or less being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC though.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 14 december 2006 14:08 To: Tina TSOU Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its=20 > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 > documents. > > We should notice the difference between synchronization and audit.=20 > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 > appropriate show requirements in ETSI TISPAN requirements documents=20 > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS"=20 > > To: "Tina TSOU" ; ;=20 > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a=20 > particular session (i.e. almost like a keep-alive mechanism). It does=20 > not provide a solution that fulfil all the requirements described in=20 > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre = > 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = Ulf > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet :=20 > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the=20 > capability to support synchronization and audit of the resource=20 > control session status in support of recovery and operational=20 > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ;=20 > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs=20 > related to coming releases of the ETSI TISPAN architecture (and=20 > hopefully similar architectures as those defined by 3GPP and ITU-T). > This IETF draft was referred to when discussing the LS today and the=20 > requirements listed therein ware considered useful from an ETSI TISPAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN=20 > aiming at again include sufficient requirements on auditing into the=20 > release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to=20 > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the=20 >> requirements was that the protocol selected for the reference points=20 >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >> the requirements > >> on auditing were removed since they were not possible to meet. We=20 >> hope that by having a mechnism for auditing defined by the IETF the=20 >> deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no=20 >> requirements about audit written in the active standard documents or=20 >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >> TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I=20 >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard=20 >> to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing=20 >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> 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 Thu Dec 14 09:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurCk-0004mT-RB; Thu, 14 Dec 2006 09:04:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurCj-0004m2-6p for dime@ietf.org; Thu, 14 Dec 2006 09:04:57 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GurCh-0007RP-5K for dime@ietf.org; Thu, 14 Dec 2006 09:04:56 -0500 Received: (qmail 63010 invoked by uid 0); 14 Dec 2006 14:04:52 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 14 Dec 2006 14:04:52 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 15:04:47 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB54D0@lulex02.ad.operax.com> In-Reply-To: <6F0CB04509C11D46A54232E852E390AC0240F184@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfgPm3PSAW8gKlRKqONIptVj4XCAAAV8+wAAE2IEAAAESmMA== From: "Ulf Bodin" To: "Tschofenig, Hannes" , "Hannes Tschofenig" , "Tina TSOU" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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,=20 this is exacly my view as well (i.e. I completely agree to what you're saying). Hence we will be happy to present a draft in which we modify draft-calhoun-diameter-res-mgmt-08.txt to fit the identified requirements.=20 Best regards,=20 Ulf =20 -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: den 14 december 2006 14:56 To: Ulf Bodin; Hannes Tschofenig; Tina TSOU Cc: avri@ltu.se; dime@ietf.org; steve.norreys@bt.com Subject: AW: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf,=20 I like strawman proposals since then I have something detailed to look at. Hence, I suggest to take draft-calhoun-diameter-res-mgmt-08.txt and to modify it so that it fits the mentioned requirements.=20 We don't necessarily need to push a requirements draft to RFC. For example, with the QoS document we have incorporated the most important requirements into a section of the draft.=20 Ciao Hannes -----Urspr=FCngliche Nachricht----- Von: Ulf Bodin [mailto:Ulf.Bodin@operax.com] Gesendet: Donnerstag, 14. Dezember 2006 14:52 An: Hannes Tschofenig; Tina TSOU Cc: avri@ltu.se; dime@ietf.org; steve.norreys@bt.com Betreff: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes,=20 In addition to being a requirements document draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover scenarios. Although I'm not sure a new requirement needs to be added to this draft but I do believe the specific use case addressed by Q.3301 is missing (i.e. auditing of the session status only). Hence, my answer to question 1 is; maybe but not sure, and my answer to question 2 is; I don't think so (in case we do it's a modification rather than a deletion of existing requirements).=20 In my view the best way forward is to start the work on the foreseen auditing mechanisms based on the earlier work of Calhoun (i.e. the expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case of Q.3301. All requirements need in my view to appear in the document specifying the mechnism, but maybe it's better to keep use cases in a separate document. I'm not sure the use case document now more or less being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC though.=20 Best regards, Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 14 december 2006 14:08 To: Tina TSOU Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its=20 > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 > documents. > > We should notice the difference between synchronization and audit.=20 > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 > appropriate show requirements in ETSI TISPAN requirements documents=20 > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS"=20 > > To: "Tina TSOU" ; ;=20 > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a=20 > particular session (i.e. almost like a keep-alive mechanism). It does=20 > not provide a solution that fulfil all the requirements described in=20 > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre = > 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = Ulf > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet :=20 > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the=20 > capability to support synchronization and audit of the resource=20 > control session status in support of recovery and operational=20 > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ;=20 > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs=20 > related to coming releases of the ETSI TISPAN architecture (and=20 > hopefully similar architectures as those defined by 3GPP and ITU-T). > This IETF draft was referred to when discussing the LS today and the=20 > requirements listed therein ware considered useful from an ETSI TISPAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN=20 > aiming at again include sufficient requirements on auditing into the=20 > release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to=20 > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the=20 >> requirements was that the protocol selected for the reference points=20 >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >> the requirements > >> on auditing were removed since they were not possible to meet. We=20 >> hope that by having a mechnism for auditing defined by the IETF the=20 >> deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no=20 >> requirements about audit written in the active standard documents or=20 >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >> TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I=20 >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard=20 >> to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing=20 >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> 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 Thu Dec 14 09:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurIW-0006QU-E8; Thu, 14 Dec 2006 09:10:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurIW-0006QP-6f for dime@ietf.org; Thu, 14 Dec 2006 09:10:56 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurIU-000843-KR for dime@ietf.org; Thu, 14 Dec 2006 09:10:56 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 2AEF896BB6; Thu, 14 Dec 2006 09:10:50 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBEEAl3l014048; Thu, 14 Dec 2006 09:10:48 -0500 (EST) From: "Tolga Asveren" To: "Tschofenig, Hannes" , "Ulf Bodin" , "Hannes Tschofenig" , "Tina TSOU" Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 09:07:31 -0500 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: <6F0CB04509C11D46A54232E852E390AC0240F184@MCHP7R6A.ww002.siemens.net> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: steve.norreys@bt.com, avri@ltu.se, 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 hope first we can have an evaluation of the requirements/proposals. For that purpose, which document do we need to read? I guess it should be draft-bodin-dime-auditing-reqs-01.txt. draft-calhoun-diameter-res-mgmt-08.txt is already assuming a specific way of meeting the requirements. The problem described in draft-bodin-dime-auditing-reqs-01.txt does not lead necessarily to an obvious solution. It could be an idea to gather first some feedback before focusing on details of a specific solution for the described problems. Thanks, Tolga > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, December 14, 2006 8:56 AM > To: Ulf Bodin; Hannes Tschofenig; Tina TSOU > Cc: steve.norreys@bt.com; dime@ietf.org; avri@ltu.se > Subject: AW: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi Ulf, > > I like strawman proposals since then I have something detailed to > look at. Hence, I suggest to take > draft-calhoun-diameter-res-mgmt-08.txt and to modify it so that > it fits the mentioned requirements. > > We don't necessarily need to push a requirements draft to RFC. > For example, with the QoS document we have incorporated the most > important requirements into a section of the draft. > > Ciao > Hannes > > -----Ursprüngliche Nachricht----- > Von: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Gesendet: Donnerstag, 14. Dezember 2006 14:52 > An: Hannes Tschofenig; Tina TSOU > Cc: avri@ltu.se; dime@ietf.org; steve.norreys@bt.com > Betreff: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Hannes, > > In addition to being a requirements document > draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover > scenarios. Although I'm not sure a new requirement needs to be added to > this draft but I do believe the specific use case addressed by Q.3301 is > missing (i.e. auditing of the session status only). Hence, my answer to > question 1 is; maybe but not sure, and my answer to question 2 is; I > don't think so (in case we do it's a modification rather than a deletion > of existing requirements). > > In my view the best way forward is to start the work on the foreseen > auditing mechanisms based on the earlier work of Calhoun (i.e. the > expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel > make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case > of Q.3301. All requirements need in my view to appear in the document > specifying the mechnism, but maybe it's better to keep use cases in a > separate document. I'm not sure the use case document now more or less > being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC > though. > > Best regards, > Ulf > > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 14 december 2006 14:08 > To: Tina TSOU > Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; > dime@ietf.org; avri@ltu.se; steve.norreys@bt.com > Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > Hi Tina, > > I am confused with this discussion. Can someone decrypt the > conversation? > We care about the following aspects: > * Are there new requirements somewhere out there? > * Should we modify or delete existing requirements? > > Is there anything in the mentioned documents that could contribute to > these two items? > > Ciao > Hannes > > Tina TSOU wrote: > > Hi all, > > Q.3301 only needs to comply with the requirements within its > > requirements document Y.2111. > > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements > > documents. > > > > We should notice the difference between synchronization and audit. > > What Q.3301 specifies is audit rather than synchronization. > > > > If people need our DIME WG meet ETSI TISPAN requirements, it is more > > appropriate show requirements in ETSI TISPAN requirements documents > > (e.g. RACS R1, RACS R2). > > If ETSI TISPAN officially says that > > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit > > requirements, that's fine. > > > > B. R. > > Tina > > > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" > > > > To: "Tina TSOU" ; ; > > ; "Ulf Bodin" > > Cc: ; ; > > Sent: Thursday, December 14, 2006 12:22 PM > > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > > > > The mechanism defined in Q.3301 enables querying the status of a > > particular session (i.e. almost like a keep-alive mechanism). It does > > not provide a solution that fulfil all the requirements described in > > draft-bodin-dime-auditing-reqs-01.txt > > BC > > > > -----Message d'origine----- > > De : Tina TSOU [mailto:tena@huawei.com] Envoyé : jeudi 14 décembre > > 2006 11:53 À : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf > > > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : > > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface > > protocol (Tom is the editor), not extending Diameter base protocol. > > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 > > and other Q.rcp series Recommendations (ITU-T standards)) are: > > Synchronization and audit: The Rs reference point shall provide the > > capability to support synchronization and audit of the resource > > control session status in support of recovery and operational > > information statistics and auditing. > > > > > > B. R. > > Tina > > > > ----- Original Message ----- > > From: "Ulf Bodin" > > To: ; ; > > > > Cc: ; ; > > Sent: Wednesday, December 13, 2006 11:03 PM > > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > > > > Hi John, > > > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this > document. > > It is written by the authors with the intent of reflecting needs > > related to coming releases of the ETSI TISPAN architecture (and > > hopefully similar architectures as those defined by 3GPP and ITU-T). > > This IETF draft was referred to when discussing the LS today and the > > requirements listed therein ware considered useful from an ETSI TISPAN > > > perspective. > > > > The intention is further to submitt contributions to ETSI TISPAN > > aiming at again include sufficient requirements on auditing into the > > release 2 of the ETSI TISPAN NGN architecture (and releases beyond > > release 2). > > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > > > Best regards, > > Ulf > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: den 13 december 2006 22:50 > > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > > Hi Ulf, > > > > That is good if we can have a short requirements document for > auditing. > > We can review that on the mailing list. Is it possible for you to > > discuss this with TISPAN? > > > > John > > > >> -----Original Message----- > >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] > >> Sent: 13 December, 2006 13:45 > >> To: Tina TSOU; Hannes Tschofenig > >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >> > >> Yes, that's absolutely right. The reason for removing the > >> requirements was that the protocol selected for the reference points > >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence, > >> the requirements > > > >> on auditing were removed since they were not possible to meet. We > >> hope that by having a mechnism for auditing defined by the IETF the > >> deletion > > > >> of the auditing requirements can be reconsidered by ETSI TISPAN for > >> coming releases. > >> > >> Best regards, > >> Ulf > >> > >> -----Original Message----- > >> From: Tina TSOU [mailto:tena@huawei.com] > >> Sent: den 13 december 2006 19:48 > >> To: Hannes Tschofenig; Ulf Bodin > >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com > >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >> > >> And ETSI TISPAN also pointed out that there are no requirements about > > >> audit written in the active standard documents or drafts. > >> People proposed, but they were removed, this is why there are no > >> requirements about audit written in the active standard documents or > >> drafts. > >> > >> B. R. > >> Tina > >> > >> ----- Original Message ----- > >> From: "Ulf Bodin" > >> To: "Hannes Tschofenig" > > > >> Cc: ; ; > >> Sent: Wednesday, December 13, 2006 3:04 PM > >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > >> > >> > >> Hi Hannes, > >> > >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI > >> TISPAN > > > >> has now agreed to send an LS and the draft LS will hence be forwarded > > >> to the TC of TISPAN for the final decition (at least this is how I > >> understand the procedure :-). > >> > >> Best regards, > >> Ulf > >> > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: den 6 december 2006 12:33 > >> To: Ulf Bodin > >> Cc: avri@ltu.se; dime@ietf.org > >> Subject: Re: Diameter Auditing & ETSI TISPAN > >> > >> Hi Ulf, > >> > >> thanks for the quick response. Please keep us up-to-date with regard > >> to > > > >> the outcome of the discussion next week. > >> > >> Ciao > >> Hannes > >> > >> Ulf Bodin wrote: > >>> Hi Hannes, > >>> > >>> I've submitted a draft LS for the meeting next week jointly > >> signed by > >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the > >> decition > >>> will be taken next week on sending the LS to IETF. > >>> > >>> Best regards, > >>> Ulf > >>> > >>> -----Original Message----- > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>> Sent: den 6 december 2006 11:44 > >>> To: Ulf Bodin; avri@ltu.se > >>> Cc: dime@ietf.org > >>> Subject: Diameter Auditing & ETSI TISPAN > >>> > >>> Hi Ulf, > >>> Hi Avri, > >>> > >>> what is the status of the liaison between ETSI TISPAN and the IETF > >>> DIME working group regarding the Diameter Auditing work? > >>> > >>> Ciao > >>> Hannes & John > >>> > >>> PS: We encourage you to continue your work on the Diameter Auditing > >>> requirements draft and also to start your work on the solution > >> document. > >>> > >> > >> > >> _______________________________________________ > >> 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 Thu Dec 14 09:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurPs-0005tB-St; Thu, 14 Dec 2006 09:18:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurPr-0005qT-Eq for dime@ietf.org; Thu, 14 Dec 2006 09:18:31 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GurPq-0000SW-KQ for dime@ietf.org; Thu, 14 Dec 2006 09:18:31 -0500 Received: (qmail invoked by alias); 14 Dec 2006 14:18:29 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 14 Dec 2006 15:18:29 +0100 X-Authenticated: #29516787 Message-ID: <45815D34.3070705@gmx.net> Date: Thu, 14 Dec 2006 15:18:28 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: steve.norreys@bt.com, "Tschofenig, Hannes" , avri@ltu.se, dime@ietf.org, Ulf Bodin 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, you might want to read draft-bodin-dime-auditing-reqs-01.txt and to consider draft-calhoun-diameter-res-mgmt-08.txt as one of the strawman proposals. Ulf will compile another one based on draft-calhoun-diameter-res-mgmt-08.txt and everyone else can come up with their flavor. Writing IETF drafts is not a bad thing (tm). Ciao Hannes Tolga Asveren wrote: > Hi All, > > I hope first we can have an evaluation of the requirements/proposals. For > that purpose, which document do we need to read? I guess it should be > draft-bodin-dime-auditing-reqs-01.txt. > draft-calhoun-diameter-res-mgmt-08.txt is already assuming a specific way of > meeting the requirements. > > The problem described in draft-bodin-dime-auditing-reqs-01.txt does not lead > necessarily to an obvious solution. It could be an idea to gather first some > feedback before focusing on details of a specific solution for the described > problems. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> Sent: Thursday, December 14, 2006 8:56 AM >> To: Ulf Bodin; Hannes Tschofenig; Tina TSOU >> Cc: steve.norreys@bt.com; dime@ietf.org; avri@ltu.se >> Subject: AW: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Ulf, >> >> I like strawman proposals since then I have something detailed to >> look at. Hence, I suggest to take >> draft-calhoun-diameter-res-mgmt-08.txt and to modify it so that >> it fits the mentioned requirements. >> >> We don't necessarily need to push a requirements draft to RFC. >> For example, with the QoS document we have incorporated the most >> important requirements into a section of the draft. >> >> Ciao >> Hannes >> >> -----Ursprüngliche Nachricht----- >> Von: Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Gesendet: Donnerstag, 14. Dezember 2006 14:52 >> An: Hannes Tschofenig; Tina TSOU >> Cc: avri@ltu.se; dime@ietf.org; steve.norreys@bt.com >> Betreff: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Hi Hannes, >> >> In addition to being a requirements document >> draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover >> scenarios. Although I'm not sure a new requirement needs to be added to >> this draft but I do believe the specific use case addressed by Q.3301 is >> missing (i.e. auditing of the session status only). Hence, my answer to >> question 1 is; maybe but not sure, and my answer to question 2 is; I >> don't think so (in case we do it's a modification rather than a deletion >> of existing requirements). >> >> In my view the best way forward is to start the work on the foreseen >> auditing mechanisms based on the earlier work of Calhoun (i.e. the >> expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel >> make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case >> of Q.3301. All requirements need in my view to appear in the document >> specifying the mechnism, but maybe it's better to keep use cases in a >> separate document. I'm not sure the use case document now more or less >> being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC >> though. >> >> Best regards, >> Ulf >> >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 14 december 2006 14:08 >> To: Tina TSOU >> Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; >> dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Tina, >> >> I am confused with this discussion. Can someone decrypt the >> conversation? >> We care about the following aspects: >> * Are there new requirements somewhere out there? >> * Should we modify or delete existing requirements? >> >> Is there anything in the mentioned documents that could contribute to >> these two items? >> >> Ciao >> Hannes >> >> Tina TSOU wrote: >> >>> Hi all, >>> Q.3301 only needs to comply with the requirements within its >>> requirements document Y.2111. >>> draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements >>> documents. >>> >>> We should notice the difference between synchronization and audit. >>> What Q.3301 specifies is audit rather than synchronization. >>> >>> If people need our DIME WG meet ETSI TISPAN requirements, it is more >>> appropriate show requirements in ETSI TISPAN requirements documents >>> (e.g. RACS R1, RACS R2). >>> If ETSI TISPAN officially says that >>> draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit >>> requirements, that's fine. >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" >>> >>> To: "Tina TSOU" ; ; >>> ; "Ulf Bodin" >>> Cc: ; ; >>> Sent: Thursday, December 14, 2006 12:22 PM >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> The mechanism defined in Q.3301 enables querying the status of a >>> particular session (i.e. almost like a keep-alive mechanism). It does >>> not provide a solution that fulfil all the requirements described in >>> draft-bodin-dime-auditing-reqs-01.txt >>> BC >>> >>> -----Message d'origine----- >>> De : Tina TSOU [mailto:tena@huawei.com] Envoyé : jeudi 14 décembre >>> 2006 11:53 À : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf >>> >>> Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : >>> Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface >>> protocol (Tom is the editor), not extending Diameter base protocol. >>> The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 >>> and other Q.rcp series Recommendations (ITU-T standards)) are: >>> Synchronization and audit: The Rs reference point shall provide the >>> capability to support synchronization and audit of the resource >>> control session status in support of recovery and operational >>> information statistics and auditing. >>> >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- >>> From: "Ulf Bodin" >>> To: ; ; >>> >>> Cc: ; ; >>> Sent: Wednesday, December 13, 2006 11:03 PM >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> Hi John, >>> >>> Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this >>> >> document. >> >>> It is written by the authors with the intent of reflecting needs >>> related to coming releases of the ETSI TISPAN architecture (and >>> hopefully similar architectures as those defined by 3GPP and ITU-T). >>> This IETF draft was referred to when discussing the LS today and the >>> requirements listed therein ware considered useful from an ETSI TISPAN >>> >>> perspective. >>> >>> The intention is further to submitt contributions to ETSI TISPAN >>> aiming at again include sufficient requirements on auditing into the >>> release 2 of the ETSI TISPAN NGN architecture (and releases beyond >>> release 2). >>> Thereby auditing will be discussed at coming ETSI TISPAN meetings. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Sent: den 13 december 2006 22:50 >>> To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net >>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> >>> That is good if we can have a short requirements document for >>> >> auditing. >> >>> We can review that on the mailing list. Is it possible for you to >>> discuss this with TISPAN? >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >>>> Sent: 13 December, 2006 13:45 >>>> To: Tina TSOU; Hannes Tschofenig >>>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> Yes, that's absolutely right. The reason for removing the >>>> requirements was that the protocol selected for the reference points >>>> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence, >>>> the requirements >>>> >>>> on auditing were removed since they were not possible to meet. We >>>> hope that by having a mechnism for auditing defined by the IETF the >>>> deletion >>>> >>>> of the auditing requirements can be reconsidered by ETSI TISPAN for >>>> coming releases. >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Tina TSOU [mailto:tena@huawei.com] >>>> Sent: den 13 december 2006 19:48 >>>> To: Hannes Tschofenig; Ulf Bodin >>>> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >>>> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> And ETSI TISPAN also pointed out that there are no requirements about >>>> >>>> audit written in the active standard documents or drafts. >>>> People proposed, but they were removed, this is why there are no >>>> requirements about audit written in the active standard documents or >>>> drafts. >>>> >>>> B. R. >>>> Tina >>>> >>>> ----- Original Message ----- >>>> From: "Ulf Bodin" >>>> To: "Hannes Tschofenig" >>>> >>>> Cc: ; ; >>>> Sent: Wednesday, December 13, 2006 3:04 PM >>>> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> >>>> Hi Hannes, >>>> >>>> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI >>>> TISPAN >>>> >>>> has now agreed to send an LS and the draft LS will hence be forwarded >>>> >>>> to the TC of TISPAN for the final decition (at least this is how I >>>> understand the procedure :-). >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: den 6 december 2006 12:33 >>>> To: Ulf Bodin >>>> Cc: avri@ltu.se; dime@ietf.org >>>> Subject: Re: Diameter Auditing & ETSI TISPAN >>>> >>>> Hi Ulf, >>>> >>>> thanks for the quick response. Please keep us up-to-date with regard >>>> to >>>> >>>> the outcome of the discussion next week. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Ulf Bodin wrote: >>>> >>>>> Hi Hannes, >>>>> >>>>> I've submitted a draft LS for the meeting next week jointly >>>>> >>>> signed by >>>> >>>>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >>>>> >>>> decition >>>> >>>>> will be taken next week on sending the LS to IETF. >>>>> >>>>> Best regards, >>>>> Ulf >>>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: den 6 december 2006 11:44 >>>>> To: Ulf Bodin; avri@ltu.se >>>>> Cc: dime@ietf.org >>>>> Subject: Diameter Auditing & ETSI TISPAN >>>>> >>>>> Hi Ulf, >>>>> Hi Avri, >>>>> >>>>> what is the status of the liaison between ETSI TISPAN and the IETF >>>>> DIME working group regarding the Diameter Auditing work? >>>>> >>>>> Ciao >>>>> Hannes & John >>>>> >>>>> PS: We encourage you to continue your work on the Diameter Auditing >>>>> requirements draft and also to start your work on the solution >>>>> >>>> document. >>>> >>>> _______________________________________________ >>>> 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 Thu Dec 14 09:20:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurRP-0006S7-Nz; Thu, 14 Dec 2006 09:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurRO-0006Rx-Rh for dime@ietf.org; Thu, 14 Dec 2006 09:20:06 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurRL-0000eX-3i for dime@ietf.org; Thu, 14 Dec 2006 09:20:06 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA9004QZP4ZOI@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 14:19:49 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.117.61]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA900HL2P4XKY@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 14:19:47 +0000 (GMT) Date: Thu, 14 Dec 2006 15:19:39 +0100 From: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN To: Hannes.Tschofenig@gmx.net, john.loughney@nokia.com, Ulf Bodin , CHATRAS Bruno RD-CORE-ISS Message-id: <001d01c71f8a$e56ad440$3d75a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=original; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <2AF8FF7D89242541B12E7A47F6ECB4BE04C6974F@ftrdmel3.rd.francetelecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 -----=20 =46rom: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" ; "Ulf Bodin" = ;=20 ; Cc: ; ; Sent: Thursday, December 14, 2006 12:50 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre 2006 12:36 =C0 : Ulf Bodin; john.loughney@nokia.com; Hannes.Tschofenig@gmx.net; = CHATRAS=20 Bruno RD-CORE-ISS Cc : dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Objet : Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi all, Q.3301 only needs to comply with the requirements within its requirem= ents=20 document Y.2111. draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements= =20 documents. We should notice the difference between synchronization and audit. Wh= at Q.3301 specifies is audit rather than synchronization. =3D=3D> BC: To be even more precise, we could also notice that Q.3301= specifies=20 auditing of the session status only rather than auditing of reservati= on=20 contexts in general. [Tina says: Y.2111 (requirements document of Q.3301) only require "audit of the r= esource=20 control session status". Y.2111 does not require auditing of reservat= ion=20 contexts. So, Q.3301 does not need to "audit of reservation contexts". ] If people need our DIME WG meet ETSI TISPAN requirements, it is more= =20 appropriate show requirements in ETSI TISPAN requirements documents (= e.g. RACS R1, RACS R2). If ETSI TISPAN officially says that draft-bodin-dime-auditing-reqs-01= .txt is=20 ETSI TISPAN official audit requirements, that's fine. B. R. Tina ----- Original Message ----- =46rom: "CHATRAS Bruno RD-CORE-ISS" To: "Tina TSOU" ; ;=20 ; "Ulf Bodin" Cc: ; ; Sent: Thursday, December 14, 2006 12:22 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN The mechanism defined in Q.3301 enables querying the status of a part= icular=20 session (i.e. almost like a keep-alive mechanism). It does not provid= e a=20 solution that fulfil all the requirements described in=20 draft-bodin-dime-auditing-reqs-01.txt BC -----Message d'origine----- De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; Ulf Bodin C= c :=20 steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : Re: [Dime] R= E:=20 Diameter Auditing & ETSI TISPAN ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface proto= col=20 (Tom is the editor), not extending Diameter base protocol. The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 a= nd=20 other Q.rcp series Recommendations (ITU-T standards)) are: Synchronization and audit: The Rs reference point shall provide the= =20 capability to support synchronization and audit of the resource contr= ol=20 session status in support of recovery and operational information sta= tistics=20 and auditing. B. R. Tina ----- Original Message ----- =46rom: "Ulf Bodin" To: ; ;=20 Cc: ; ; Sent: Wednesday, December 13, 2006 11:03 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi John, Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this documen= t. It is written by the authors with the intent of reflecting needs rela= ted to coming releases of the ETSI TISPAN architecture (and hopefully simila= r architectures as those defined by 3GPP and ITU-T). This IETF draft wa= s referred to when discussing the LS today and the requirements listed = therein ware considered useful from an ETSI TISPAN perspective. The intention is further to submitt contributions to ETSI TISPAN aimi= ng at again include sufficient requirements on auditing into the release 2 = of the ETSI TISPAN NGN architecture (and releases beyond release 2). Thereby auditing will be discussed at coming ETSI TISPAN meetings. Best regards, Ulf -----Original Message----- =46rom: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: den 13 december 2006 22:50 To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, That is good if we can have a short requirements document for auditin= g. We can review that on the mailing list. Is it possible for you to di= scuss this with TISPAN? John >-----Original Message----- >From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >Sent: 13 December, 2006 13:45 >To: Tina TSOU; Hannes Tschofenig >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > >Yes, that's absolutely right. The reason for removing the requiremen= ts >was that the protocol selected for the reference points in questions >(i.e. DIAMETER) doesn't (yet) support auditing. Hence, the requireme= nts >on auditing were removed since they were not possible to meet. We ho= pe >that by having a mechnism for auditing defined by the IETF the delet= ion >of the auditing requirements can be reconsidered by ETSI TISPAN for >coming releases. > >Best regards, >Ulf > >-----Original Message----- >From: Tina TSOU [mailto:tena@huawei.com] >Sent: den 13 december 2006 19:48 >To: Hannes Tschofenig; Ulf Bodin >Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >And ETSI TISPAN also pointed out that there are no requirements abou= t >audit written in the active standard documents or drafts. >People proposed, but they were removed, this is why there are no >requirements about audit written in the active standard documents or >drafts. > >B. R. >Tina > >----- Original Message ----- >From: "Ulf Bodin" >To: "Hannes Tschofenig" >Cc: ; ; >Sent: Wednesday, December 13, 2006 3:04 PM >Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN > > >Hi Hannes, > >Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI TIS= PAN >has now agreed to send an LS and the draft LS will hence be forwarde= d >to the TC of TISPAN for the final decition (at least this is how I >understand the procedure :-). > >Best regards, >Ulf > >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: den 6 december 2006 12:33 >To: Ulf Bodin >Cc: avri@ltu.se; dime@ietf.org >Subject: Re: Diameter Auditing & ETSI TISPAN > >Hi Ulf, > >thanks for the quick response. Please keep us up-to-date with regard= to >the outcome of the discussion next week. > >Ciao >Hannes > >Ulf Bodin wrote: >> Hi Hannes, >> >> I've submitted a draft LS for the meeting next week jointly >signed by >> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >decition >> will be taken next week on sending the LS to IETF. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 11:44 >> To: Ulf Bodin; avri@ltu.se >> Cc: dime@ietf.org >> Subject: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> Hi Avri, >> >> what is the status of the liaison between ETSI TISPAN and the IETF >> DIME working group regarding the Diameter Auditing work? >> >> Ciao >> Hannes & John >> >> PS: We encourage you to continue your work on the Diameter Auditin= g >> requirements draft and also to start your work on the solution >document. >> > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 09:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurZf-00088j-GA; Thu, 14 Dec 2006 09:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurZe-00088J-Av for dime@ietf.org; Thu, 14 Dec 2006 09:28:38 -0500 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurZd-0001Tm-MS for dime@ietf.org; Thu, 14 Dec 2006 09:28:38 -0500 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JA9004DCPJOOI@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 14:28:37 +0000 (GMT) Received: from IBM4307EA0CEF3 ([217.167.117.61]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JA900H7PPJNKY@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 14 Dec 2006 14:28:36 +0000 (GMT) Date: Thu, 14 Dec 2006 15:28:30 +0100 From: Tina TSOU Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN To: Hannes Tschofenig , Ulf Bodin Message-id: <002201c71f8c$21526940$3d75a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=original; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <33656995C5C5094A983DE84DA649A924CB54CF@lulex02.ad.operax.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 [Tina says: Y.2111 (requirements document of Q.3301) only require "audit of the r= esource=20 control session status". Y.2111 does not require auditing of reservat= ion=20 contexts. So, Q.3301 does not need to "audit of reservation contexts". There is no extending to Diameter base protocol in Q.3301. The audit = has=20 been fulfilled in the profile level rather than Diameter common appli= cation=20 level or base protocol level. Namely, in the current situation, ITU-T has no requirement to ask WG = DIME to=20 extend what RFC3588 specified. I am not allowed to say as ITU-T Q.5/11 rapporteur here. I say here a= s a=20 DIME member. ] ----- Original Message -----=20 =46rom: "Ulf Bodin" To: "Hannes Tschofenig" ; "Tina TSOU"=20 Cc: ; "CHATRAS Bruno RD-CORE-ISS"=20 ; ; ;= =20 Sent: Thursday, December 14, 2006 2:51 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes, In addition to being a requirements document draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover scenarios. Although I'm not sure a new requirement needs to be added = to this draft but I do believe the specific use case addressed by Q.3301= is missing (i.e. auditing of the session status only). Hence, my answer = to question 1 is; maybe but not sure, and my answer to question 2 is; I don't think so (in case we do it's a modification rather than a delet= ion of existing requirements). In my view the best way forward is to start the work on the foreseen auditing mechanisms based on the earlier work of Calhoun (i.e. the expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use ca= se of Q.3301. All requirements need in my view to appear in the document specifying the mechnism, but maybe it's better to keep use cases in a separate document. I'm not sure the use case document now more or les= s being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC though. Best regards, Ulf -----Original Message----- =46rom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: den 14 december 2006 14:08 To: Tina TSOU Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements > documents. > > We should notice the difference between synchronization and audit. > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is mor= e > appropriate show requirements in ETSI TISPAN requirements documents > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" > > To: "Tina TSOU" ; ; > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a > particular session (i.e. almost like a keep-alive mechanism). It do= es > not provide a solution that fulfil all the requirements described i= n > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cem= bre > 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com= ; Ulf > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the > capability to support synchronization and audit of the resource > control session status in support of recovery and operational > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ; > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs > related to coming releases of the ETSI TISPAN architecture (and > hopefully similar architectures as those defined by 3GPP and ITU-T)= . > This IETF draft was referred to when discussing the LS today and th= e > requirements listed therein ware considered useful from an ETSI TIS= PAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN > aiming at again include sufficient requirements on auditing into th= e > release 2 of the ETSI TISPAN NGN architecture (and releases beyond > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the >> requirements was that the protocol selected for the reference poin= ts >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence= , >> the requirements > >> on auditing were removed since they were not possible to meet. We >> hope that by having a mechnism for auditing defined by the IETF th= e >> deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN fo= r >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements ab= out >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no >> requirements about audit written in the active standard documents = or >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI >> TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwar= ded >> to the TC of TISPAN for the final decition (at least this is how I >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with rega= rd >> to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IET= F >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditi= ng >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 09:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurpb-0008Rf-R4; Thu, 14 Dec 2006 09:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurpa-0008RV-8O for dime@ietf.org; Thu, 14 Dec 2006 09:45:06 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GurpX-0002z6-Bd for dime@ietf.org; Thu, 14 Dec 2006 09:45:06 -0500 Received: (qmail 87816 invoked by uid 0); 14 Dec 2006 14:45:01 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 14 Dec 2006 14:45:01 -0000 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] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 15:45:01 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB54ED@lulex02.ad.operax.com> In-Reply-To: <002201c71f8c$21526940$3d75a7d9@IBM4307EA0CEF3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfjCzia7JU5QFyQrWH/KNm7orLngAATaqg From: "Ulf Bodin" To: "Tina TSOU" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 Yes, I understand that ITU-T already are working on a solution and that consequently don't need to ask DIME to specify a mechism meeting the corresponding requirement. In my view it would still make sence to explore the possibility to meet this corresponding requirement to avoid that spcific profile level mechanisms meeting the requirement are specified by differenmt SDOs for each interface to which the requirement apply and that use DIAMETER. Again, as I see it it's better to have all DIMAETER profiles specified by different SDOs use the same mechanism for auditing specified by the IETF.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: den 14 december 2006 15:29 To: Hannes Tschofenig; Ulf Bodin Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org; CHATRAS Bruno RD-CORE-ISS; john.loughney@nokia.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN [Tina says: Y.2111 (requirements document of Q.3301) only require "audit of the resource control session status". Y.2111 does not require auditing of reservation contexts. So, Q.3301 does not need to "audit of reservation contexts". There is no extending to Diameter base protocol in Q.3301. The audit has been fulfilled in the profile level rather than Diameter common application level or base protocol level. Namely, in the current situation, ITU-T has no requirement to ask WG DIME to extend what RFC3588 specified. I am not allowed to say as ITU-T Q.5/11 rapporteur here. I say here as a DIME member. ] ----- Original Message ----- From: "Ulf Bodin" To: "Hannes Tschofenig" ; "Tina TSOU"=20 Cc: ; "CHATRAS Bruno RD-CORE-ISS"=20 ; ; ; Sent: Thursday, December 14, 2006 2:51 PM Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Hannes, In addition to being a requirements document draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover scenarios. Although I'm not sure a new requirement needs to be added to this draft but I do believe the specific use case addressed by Q.3301 is missing (i.e. auditing of the session status only). Hence, my answer to question 1 is; maybe but not sure, and my answer to question 2 is; I don't think so (in case we do it's a modification rather than a deletion of existing requirements). In my view the best way forward is to start the work on the foreseen auditing mechanisms based on the earlier work of Calhoun (i.e. the expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case of Q.3301. All requirements need in my view to appear in the document specifying the mechnism, but maybe it's better to keep use cases in a separate document. I'm not sure the use case document now more or less being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC though. Best regards, Ulf -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: den 14 december 2006 14:08 To: Tina TSOU Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; dime@ietf.org; avri@ltu.se; steve.norreys@bt.com Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN Hi Ulf, Hi Tina, I am confused with this discussion. Can someone decrypt the conversation? We care about the following aspects: * Are there new requirements somewhere out there? * Should we modify or delete existing requirements? Is there anything in the mentioned documents that could contribute to these two items? Ciao Hannes Tina TSOU wrote: > Hi all, > Q.3301 only needs to comply with the requirements within its=20 > requirements document Y.2111. > draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 > documents. > > We should notice the difference between synchronization and audit. > What Q.3301 specifies is audit rather than synchronization. > > If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 > appropriate show requirements in ETSI TISPAN requirements documents=20 > (e.g. RACS R1, RACS R2). > If ETSI TISPAN officially says that > draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 > requirements, that's fine. > > B. R. > Tina > > ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" > > To: "Tina TSOU" ; ;=20 > ; "Ulf Bodin" > Cc: ; ; > Sent: Thursday, December 14, 2006 12:22 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > The mechanism defined in Q.3301 enables querying the status of a=20 > particular session (i.e. almost like a keep-alive mechanism). It does=20 > not provide a solution that fulfil all the requirements described in=20 > draft-bodin-dime-auditing-reqs-01.txt > BC > > -----Message d'origine----- > De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre > 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = Ulf > Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : > Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > > ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 > protocol (Tom is the editor), not extending Diameter base protocol. > The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 > and other Q.rcp series Recommendations (ITU-T standards)) are: > Synchronization and audit: The Rs reference point shall provide the=20 > capability to support synchronization and audit of the resource=20 > control session status in support of recovery and operational=20 > information statistics and auditing. > > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: ; ;=20 > > Cc: ; ; > Sent: Wednesday, December 13, 2006 11:03 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > > Hi John, > > Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this document. > It is written by the authors with the intent of reflecting needs=20 > related to coming releases of the ETSI TISPAN architecture (and=20 > hopefully similar architectures as those defined by 3GPP and ITU-T). > This IETF draft was referred to when discussing the LS today and the=20 > requirements listed therein ware considered useful from an ETSI TISPAN > perspective. > > The intention is further to submitt contributions to ETSI TISPAN=20 > aiming at again include sufficient requirements on auditing into the=20 > release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 > release 2). > Thereby auditing will be discussed at coming ETSI TISPAN meetings. > > Best regards, > Ulf > > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: den 13 december 2006 22:50 > To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN > > Hi Ulf, > > That is good if we can have a short requirements document for auditing. > We can review that on the mailing list. Is it possible for you to=20 > discuss this with TISPAN? > > John > >> -----Original Message----- >> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >> Sent: 13 December, 2006 13:45 >> To: Tina TSOU; Hannes Tschofenig >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Yes, that's absolutely right. The reason for removing the=20 >> requirements was that the protocol selected for the reference points=20 >> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >> the requirements > >> on auditing were removed since they were not possible to meet. We=20 >> hope that by having a mechnism for auditing defined by the IETF the=20 >> deletion > >> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >> coming releases. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 13 december 2006 19:48 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> And ETSI TISPAN also pointed out that there are no requirements about >> audit written in the active standard documents or drafts. >> People proposed, but they were removed, this is why there are no=20 >> requirements about audit written in the active standard documents or=20 >> drafts. >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" > >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 3:04 PM >> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi Hannes, >> >> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >> TISPAN > >> has now agreed to send an LS and the draft LS will hence be forwarded >> to the TC of TISPAN for the final decition (at least this is how I=20 >> understand the procedure :-). >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 6 december 2006 12:33 >> To: Ulf Bodin >> Cc: avri@ltu.se; dime@ietf.org >> Subject: Re: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> thanks for the quick response. Please keep us up-to-date with regard=20 >> to > >> the outcome of the discussion next week. >> >> Ciao >> Hannes >> >> Ulf Bodin wrote: >>> Hi Hannes, >>> >>> I've submitted a draft LS for the meeting next week jointly >> signed by >>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >> decition >>> will be taken next week on sending the LS to IETF. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 11:44 >>> To: Ulf Bodin; avri@ltu.se >>> Cc: dime@ietf.org >>> Subject: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> Hi Avri, >>> >>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>> DIME working group regarding the Diameter Auditing work? >>> >>> Ciao >>> Hannes & John >>> >>> PS: We encourage you to continue your work on the Diameter Auditing=20 >>> requirements draft and also to start your work on the solution >> document. >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 10:01:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gus5V-0006nZ-O6; Thu, 14 Dec 2006 10:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gus5U-0006mp-Az for dime@ietf.org; Thu, 14 Dec 2006 10:01:32 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gus5S-0004U9-AO for dime@ietf.org; Thu, 14 Dec 2006 10:01:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBEF1Ax06673; Thu, 14 Dec 2006 10:01:10 -0500 (EST) Received: from [47.130.18.52] ([47.130.18.52] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 10:01:16 -0500 Message-ID: <45816725.6090009@nortel.com> Date: Thu, 14 Dec 2006 10:00:53 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ulf Bodin Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN References: <33656995C5C5094A983DE84DA649A924CB54ED@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A924CB54ED@lulex02.ad.operax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 14 Dec 2006 15:01:16.0843 (UTC) FILETIME=[B48FE7B0:01C71F90] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps0kn.nortel.com id kBEF1Ax06673 X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: steve.norreys@bt.com, avri@ltu.se, 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 This sounds like an ideal, but what troubles me, both for this and for=20 the QoS work, is how the IETF-defined capabilities would be worked into=20 specifications developed by the other SDOs and already deployed. Would=20 there be an update of Gq, Gq', Q.3301.1? (The latter, of course, is not=20 deployed yet, but is almost out the door.) I know the IETF can't answer=20 this question, but I do want people to consider whether the effort might=20 be wasted. Ulf Bodin wrote: > Yes, I understand that ITU-T already are working on a solution and that > consequently don't need to ask DIME to specify a mechism meeting the > corresponding requirement. In my view it would still make sence to > explore the possibility to meet this corresponding requirement to avoid > that spcific profile level mechanisms meeting the requirement are > specified by differenmt SDOs for each interface to which the requiremen= t > apply and that use DIAMETER. Again, as I see it it's better to have all > DIMAETER profiles specified by different SDOs use the same mechanism fo= r > auditing specified by the IETF.=20 >=20 > Best regards,=20 > Ulf=20 >=20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com]=20 > Sent: den 14 december 2006 15:29 > To: Hannes Tschofenig; Ulf Bodin > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org; CHATRAS Bruno > RD-CORE-ISS; john.loughney@nokia.com > Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 > [Tina says: > Y.2111 (requirements document of Q.3301) only require "audit of the > resource control session status". Y.2111 does not require auditing of > reservation contexts. > So, Q.3301 does not need to "audit of reservation contexts". >=20 > There is no extending to Diameter base protocol in Q.3301. The audit ha= s > been fulfilled in the profile level rather than Diameter common > application level or base protocol level. > Namely, in the current situation, ITU-T has no requirement to ask WG > DIME to extend what RFC3588 specified. >=20 > I am not allowed to say as ITU-T Q.5/11 rapporteur here. I say here as = a > DIME member. > ] >=20 > ----- Original Message ----- > From: "Ulf Bodin" > To: "Hannes Tschofenig" ; "Tina TSOU"=20 > > Cc: ; "CHATRAS Bruno RD-CORE-ISS"=20 > ; ; ; > > Sent: Thursday, December 14, 2006 2:51 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 >=20 > Hi Hannes, >=20 > In addition to being a requirements document > draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover > scenarios. Although I'm not sure a new requirement needs to be added to > this draft but I do believe the specific use case addressed by Q.3301 i= s > missing (i.e. auditing of the session status only). Hence, my answer to > question 1 is; maybe but not sure, and my answer to question 2 is; I > don't think so (in case we do it's a modification rather than a deletio= n > of existing requirements). >=20 > In my view the best way forward is to start the work on the foreseen > auditing mechanisms based on the earlier work of Calhoun (i.e. the > expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel > make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use case > of Q.3301. All requirements need in my view to appear in the document > specifying the mechnism, but maybe it's better to keep use cases in a > separate document. I'm not sure the use case document now more or less > being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC > though. >=20 > Best regards, > Ulf >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 14 december 2006 14:08 > To: Tina TSOU > Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; > dime@ietf.org; avri@ltu.se; steve.norreys@bt.com > Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 > Hi Ulf, > Hi Tina, >=20 > I am confused with this discussion. Can someone decrypt the > conversation? > We care about the following aspects: > * Are there new requirements somewhere out there? > * Should we modify or delete existing requirements? >=20 > Is there anything in the mentioned documents that could contribute to > these two items? >=20 > Ciao > Hannes >=20 > Tina TSOU wrote: >> Hi all, >> Q.3301 only needs to comply with the requirements within its=20 >> requirements document Y.2111. >> draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 >> documents. >> >> We should notice the difference between synchronization and audit. >> What Q.3301 specifies is audit rather than synchronization. >> >> If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 >> appropriate show requirements in ETSI TISPAN requirements documents=20 >> (e.g. RACS R1, RACS R2). >> If ETSI TISPAN officially says that >> draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 >> requirements, that's fine. >> >> B. R. >> Tina >> >> ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" >> >> To: "Tina TSOU" ; ;=20 >> ; "Ulf Bodin" >> Cc: ; ; >> Sent: Thursday, December 14, 2006 12:22 PM >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> The mechanism defined in Q.3301 enables querying the status of a=20 >> particular session (i.e. almost like a keep-alive mechanism). It does=20 >> not provide a solution that fulfil all the requirements described in=20 >> draft-bodin-dime-auditing-reqs-01.txt >> BC >> >> -----Message d'origine----- >> De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 d=E9cembre >> 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; U= lf >=20 >> Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : >> Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 >> protocol (Tom is the editor), not extending Diameter base protocol. >> The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 >> and other Q.rcp series Recommendations (ITU-T standards)) are: >> Synchronization and audit: The Rs reference point shall provide the=20 >> capability to support synchronization and audit of the resource=20 >> control session status in support of recovery and operational=20 >> information statistics and auditing. >> >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: ; ;=20 >> >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 11:03 PM >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi John, >> >> Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this > document. >> It is written by the authors with the intent of reflecting needs=20 >> related to coming releases of the ETSI TISPAN architecture (and=20 >> hopefully similar architectures as those defined by 3GPP and ITU-T). >> This IETF draft was referred to when discussing the LS today and the=20 >> requirements listed therein ware considered useful from an ETSI TISPAN >=20 >> perspective. >> >> The intention is further to submitt contributions to ETSI TISPAN=20 >> aiming at again include sufficient requirements on auditing into the=20 >> release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 >> release 2). >> Thereby auditing will be discussed at coming ETSI TISPAN meetings. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: den 13 december 2006 22:50 >> To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> That is good if we can have a short requirements document for > auditing. >> We can review that on the mailing list. Is it possible for you to=20 >> discuss this with TISPAN? >> >> John >> >>> -----Original Message----- >>> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >>> Sent: 13 December, 2006 13:45 >>> To: Tina TSOU; Hannes Tschofenig >>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> Yes, that's absolutely right. The reason for removing the=20 >>> requirements was that the protocol selected for the reference points=20 >>> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >>> the requirements >>> on auditing were removed since they were not possible to meet. We=20 >>> hope that by having a mechnism for auditing defined by the IETF the=20 >>> deletion >>> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >>> coming releases. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Tina TSOU [mailto:tena@huawei.com] >>> Sent: den 13 december 2006 19:48 >>> To: Hannes Tschofenig; Ulf Bodin >>> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >>> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> And ETSI TISPAN also pointed out that there are no requirements about >=20 >>> audit written in the active standard documents or drafts. >>> People proposed, but they were removed, this is why there are no=20 >>> requirements about audit written in the active standard documents or=20 >>> drafts. >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- >>> From: "Ulf Bodin" >>> To: "Hannes Tschofenig" >>> Cc: ; ; >>> Sent: Wednesday, December 13, 2006 3:04 PM >>> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> Hi Hannes, >>> >>> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >>> TISPAN >>> has now agreed to send an LS and the draft LS will hence be forwarded >=20 >>> to the TC of TISPAN for the final decition (at least this is how I=20 >>> understand the procedure :-). >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 12:33 >>> To: Ulf Bodin >>> Cc: avri@ltu.se; dime@ietf.org >>> Subject: Re: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> >>> thanks for the quick response. Please keep us up-to-date with regard=20 >>> to >>> the outcome of the discussion next week. >>> >>> Ciao >>> Hannes >>> >>> Ulf Bodin wrote: >>>> Hi Hannes, >>>> >>>> I've submitted a draft LS for the meeting next week jointly >>> signed by >>>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >>> decition >>>> will be taken next week on sending the LS to IETF. >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: den 6 december 2006 11:44 >>>> To: Ulf Bodin; avri@ltu.se >>>> Cc: dime@ietf.org >>>> Subject: Diameter Auditing & ETSI TISPAN >>>> >>>> Hi Ulf, >>>> Hi Avri, >>>> >>>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>>> DIME working group regarding the Diameter Auditing work? >>>> >>>> Ciao >>>> Hannes & John >>>> >>>> PS: We encourage you to continue your work on the Diameter Auditing=20 >>>> requirements draft and also to start your work on the solution >>> document. >>> >>> _______________________________________________ >>> 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 >=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 Thu Dec 14 10:05:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gus8y-0008Jg-OT; Thu, 14 Dec 2006 10:05:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gus8x-0008Jb-Lt for dime@ietf.org; Thu, 14 Dec 2006 10:05:07 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gus8u-0004oT-Pf for dime@ietf.org; Thu, 14 Dec 2006 10:05:07 -0500 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kBEF5105014331; Thu, 14 Dec 2006 16:05:01 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id kBEF51Jv031898; Thu, 14 Dec 2006 16:05:01 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:05:00 +0100 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: AW: [Dime] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 16:05:00 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC0240F20C@MCHP7R6A.ww002.siemens.net> In-Reply-To: <45816725.6090009@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfkNcZRpBj2XOqS7er4yRBJ/uflwAACBog From: "Tschofenig, Hannes" To: "Tom-PT Taylor" , "Ulf Bodin" X-OriginalArrivalTime: 14 Dec 2006 15:05:00.0952 (UTC) FILETIME=[3A243980:01C71F91] X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 Tom,=20 You raise interesting questions. I personally see the QoS side a bit = different since our work addresses different usage scenarios (driven by = the other work being done).=20 Ciao Hannes -----Urspr=FCngliche Nachricht----- Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 Gesendet: Donnerstag, 14. Dezember 2006 16:01 An: Ulf Bodin Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Betreff: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN This sounds like an ideal, but what troubles me, both for this and for=20 the QoS work, is how the IETF-defined capabilities would be worked into=20 specifications developed by the other SDOs and already deployed. Would=20 there be an update of Gq, Gq', Q.3301.1? (The latter, of course, is not=20 deployed yet, but is almost out the door.) I know the IETF can't answer=20 this question, but I do want people to consider whether the effort might = be wasted. Ulf Bodin wrote: > Yes, I understand that ITU-T already are working on a solution and = that > consequently don't need to ask DIME to specify a mechism meeting the > corresponding requirement. In my view it would still make sence to > explore the possibility to meet this corresponding requirement to = avoid > that spcific profile level mechanisms meeting the requirement are > specified by differenmt SDOs for each interface to which the = requirement > apply and that use DIAMETER. Again, as I see it it's better to have = all > DIMAETER profiles specified by different SDOs use the same mechanism = for > auditing specified by the IETF.=20 >=20 > Best regards,=20 > Ulf=20 >=20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com]=20 > Sent: den 14 december 2006 15:29 > To: Hannes Tschofenig; Ulf Bodin > Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org; CHATRAS Bruno > RD-CORE-ISS; john.loughney@nokia.com > Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 > [Tina says: > Y.2111 (requirements document of Q.3301) only require "audit of the > resource control session status". Y.2111 does not require auditing of > reservation contexts. > So, Q.3301 does not need to "audit of reservation contexts". >=20 > There is no extending to Diameter base protocol in Q.3301. The audit = has > been fulfilled in the profile level rather than Diameter common > application level or base protocol level. > Namely, in the current situation, ITU-T has no requirement to ask WG > DIME to extend what RFC3588 specified. >=20 > I am not allowed to say as ITU-T Q.5/11 rapporteur here. I say here as = a > DIME member. > ] >=20 > ----- Original Message ----- > From: "Ulf Bodin" > To: "Hannes Tschofenig" ; "Tina TSOU"=20 > > Cc: ; "CHATRAS Bruno RD-CORE-ISS"=20 > ; ; ; > > Sent: Thursday, December 14, 2006 2:51 PM > Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 >=20 > Hi Hannes, >=20 > In addition to being a requirements document > draft-bodin-dime-auditing-reqs-01.txt provides use cases for failover > scenarios. Although I'm not sure a new requirement needs to be added = to > this draft but I do believe the specific use case addressed by Q.3301 = is > missing (i.e. auditing of the session status only). Hence, my answer = to > question 1 is; maybe but not sure, and my answer to question 2 is; I > don't think so (in case we do it's a modification rather than a = deletion > of existing requirements). >=20 > In my view the best way forward is to start the work on the foreseen > auditing mechanisms based on the earlier work of Calhoun (i.e. the > expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in parallel > make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use = case > of Q.3301. All requirements need in my view to appear in the document > specifying the mechnism, but maybe it's better to keep use cases in a > separate document. I'm not sure the use case document now more or less > being draft-bodin-dime-auditing-reqs-01.txt must be proceed to an RFC > though. >=20 > Best regards, > Ulf >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: den 14 december 2006 14:08 > To: Tina TSOU > Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS; > dime@ietf.org; avri@ltu.se; steve.norreys@bt.com > Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >=20 > Hi Ulf, > Hi Tina, >=20 > I am confused with this discussion. Can someone decrypt the > conversation? > We care about the following aspects: > * Are there new requirements somewhere out there? > * Should we modify or delete existing requirements? >=20 > Is there anything in the mentioned documents that could contribute to > these two items? >=20 > Ciao > Hannes >=20 > Tina TSOU wrote: >> Hi all, >> Q.3301 only needs to comply with the requirements within its=20 >> requirements document Y.2111. >> draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 >> documents. >> >> We should notice the difference between synchronization and audit. >> What Q.3301 specifies is audit rather than synchronization. >> >> If people need our DIME WG meet ETSI TISPAN requirements, it is more=20 >> appropriate show requirements in ETSI TISPAN requirements documents=20 >> (e.g. RACS R1, RACS R2). >> If ETSI TISPAN officially says that >> draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 >> requirements, that's fine. >> >> B. R. >> Tina >> >> ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" >> >> To: "Tina TSOU" ; ;=20 >> ; "Ulf Bodin" >> Cc: ; ; >> Sent: Thursday, December 14, 2006 12:22 PM >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> The mechanism defined in Q.3301 enables querying the status of a=20 >> particular session (i.e. almost like a keep-alive mechanism). It does = >> not provide a solution that fulfil all the requirements described in=20 >> draft-bodin-dime-auditing-reqs-01.txt >> BC >> >> -----Message d'origine----- >> De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 = d=E9cembre >> 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = Ulf >=20 >> Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : >> Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 >> protocol (Tom is the editor), not extending Diameter base protocol. >> The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 >> and other Q.rcp series Recommendations (ITU-T standards)) are: >> Synchronization and audit: The Rs reference point shall provide the=20 >> capability to support synchronization and audit of the resource=20 >> control session status in support of recovery and operational=20 >> information statistics and auditing. >> >> >> B. R. >> Tina >> >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: ; ;=20 >> >> Cc: ; ; >> Sent: Wednesday, December 13, 2006 11:03 PM >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> >> Hi John, >> >> Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this > document. >> It is written by the authors with the intent of reflecting needs=20 >> related to coming releases of the ETSI TISPAN architecture (and=20 >> hopefully similar architectures as those defined by 3GPP and ITU-T). >> This IETF draft was referred to when discussing the LS today and the=20 >> requirements listed therein ware considered useful from an ETSI = TISPAN >=20 >> perspective. >> >> The intention is further to submitt contributions to ETSI TISPAN=20 >> aiming at again include sufficient requirements on auditing into the=20 >> release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 >> release 2). >> Thereby auditing will be discussed at coming ETSI TISPAN meetings. >> >> Best regards, >> Ulf >> >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: den 13 december 2006 22:50 >> To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >> >> Hi Ulf, >> >> That is good if we can have a short requirements document for > auditing. >> We can review that on the mailing list. Is it possible for you to=20 >> discuss this with TISPAN? >> >> John >> >>> -----Original Message----- >>> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >>> Sent: 13 December, 2006 13:45 >>> To: Tina TSOU; Hannes Tschofenig >>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> Yes, that's absolutely right. The reason for removing the=20 >>> requirements was that the protocol selected for the reference points = >>> in questions (i.e. DIAMETER) doesn't (yet) support auditing. Hence,=20 >>> the requirements >>> on auditing were removed since they were not possible to meet. We=20 >>> hope that by having a mechnism for auditing defined by the IETF the=20 >>> deletion >>> of the auditing requirements can be reconsidered by ETSI TISPAN for=20 >>> coming releases. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Tina TSOU [mailto:tena@huawei.com] >>> Sent: den 13 december 2006 19:48 >>> To: Hannes Tschofenig; Ulf Bodin >>> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >>> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> And ETSI TISPAN also pointed out that there are no requirements = about >=20 >>> audit written in the active standard documents or drafts. >>> People proposed, but they were removed, this is why there are no=20 >>> requirements about audit written in the active standard documents or = >>> drafts. >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- >>> From: "Ulf Bodin" >>> To: "Hannes Tschofenig" >>> Cc: ; ; >>> Sent: Wednesday, December 13, 2006 3:04 PM >>> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> Hi Hannes, >>> >>> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >>> TISPAN >>> has now agreed to send an LS and the draft LS will hence be = forwarded >=20 >>> to the TC of TISPAN for the final decition (at least this is how I=20 >>> understand the procedure :-). >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: den 6 december 2006 12:33 >>> To: Ulf Bodin >>> Cc: avri@ltu.se; dime@ietf.org >>> Subject: Re: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> >>> thanks for the quick response. Please keep us up-to-date with regard = >>> to >>> the outcome of the discussion next week. >>> >>> Ciao >>> Hannes >>> >>> Ulf Bodin wrote: >>>> Hi Hannes, >>>> >>>> I've submitted a draft LS for the meeting next week jointly >>> signed by >>>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >>> decition >>>> will be taken next week on sending the LS to IETF. >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: den 6 december 2006 11:44 >>>> To: Ulf Bodin; avri@ltu.se >>>> Cc: dime@ietf.org >>>> Subject: Diameter Auditing & ETSI TISPAN >>>> >>>> Hi Ulf, >>>> Hi Avri, >>>> >>>> what is the status of the liaison between ETSI TISPAN and the IETF=20 >>>> DIME working group regarding the Diameter Auditing work? >>>> >>>> Ciao >>>> Hannes & John >>>> >>>> PS: We encourage you to continue your work on the Diameter Auditing = >>>> requirements draft and also to start your work on the solution >>> document. >>> >>> _______________________________________________ >>> 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 >=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 Thu Dec 14 12:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gutzn-00010U-ME; Thu, 14 Dec 2006 12:03:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gutzl-00010I-SL for dime@ietf.org; Thu, 14 Dec 2006 12:03:45 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gutzk-0001fg-Rh for dime@ietf.org; Thu, 14 Dec 2006 12:03:45 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBEH2sSU010306; Thu, 14 Dec 2006 19:03:03 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 19:03:39 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 19:03:39 +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: [Dime] RE: Diameter Auditing & ETSI TISPAN Date: Thu, 14 Dec 2006 19:03:30 +0200 Message-ID: In-Reply-To: <45816725.6090009@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Diameter Auditing & ETSI TISPAN Thread-Index: AccfmwD9d42bAOmuRZSuSsu2sDuLmgABn8Bg From: To: , X-OriginalArrivalTime: 14 Dec 2006 17:03:39.0129 (UTC) FILETIME=[CCE7D690:01C71FA1] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: steve.norreys@bt.com, dime@ietf.org, avri@ltu.se 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 Tom,=20 You know that this thing happens all of the time. I can cite examples, but that is probably not necessary. I don't think the IETF wants to change what other groups are doing, but I see benefit for solutions that are applicable for other networks than just ITU-T, for example. The engineering part is figuring out what the generic solution is and how to interwork with existing deployments. John=20 >-----Original Message----- >From: ext Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: 14 December, 2006 07:01 >To: Ulf Bodin >Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN > >This sounds like an ideal, but what troubles me, both for this=20 >and for the QoS work, is how the IETF-defined capabilities=20 >would be worked into specifications developed by the other=20 >SDOs and already deployed. Would there be an update of Gq,=20 >Gq', Q.3301.1? (The latter, of course, is not deployed yet,=20 >but is almost out the door.) I know the IETF can't answer this=20 >question, but I do want people to consider whether the effort=20 >might be wasted. > >Ulf Bodin wrote: >> Yes, I understand that ITU-T already are working on a solution and=20 >> that consequently don't need to ask DIME to specify a=20 >mechism meeting=20 >> the corresponding requirement. In my view it would still=20 >make sence to=20 >> explore the possibility to meet this corresponding requirement to=20 >> avoid that spcific profile level mechanisms meeting the requirement=20 >> are specified by differenmt SDOs for each interface to which the=20 >> requirement apply and that use DIAMETER. Again, as I see it it's=20 >> better to have all DIMAETER profiles specified by different SDOs use=20 >> the same mechanism for auditing specified by the IETF. >>=20 >> Best regards, >> Ulf >>=20 >> -----Original Message----- >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: den 14 december 2006 15:29 >> To: Hannes Tschofenig; Ulf Bodin >> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org; CHATRAS Bruno=20 >> RD-CORE-ISS; john.loughney@nokia.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>=20 >> [Tina says: >> Y.2111 (requirements document of Q.3301) only require "audit of the=20 >> resource control session status". Y.2111 does not require=20 >auditing of=20 >> reservation contexts. >> So, Q.3301 does not need to "audit of reservation contexts". >>=20 >> There is no extending to Diameter base protocol in Q.3301. The audit=20 >> has been fulfilled in the profile level rather than Diameter common=20 >> application level or base protocol level. >> Namely, in the current situation, ITU-T has no requirement to ask WG=20 >> DIME to extend what RFC3588 specified. >>=20 >> I am not allowed to say as ITU-T Q.5/11 rapporteur here. I=20 >say here as=20 >> a DIME member. >> ] >>=20 >> ----- Original Message ----- >> From: "Ulf Bodin" >> To: "Hannes Tschofenig" ; "Tina TSOU"=20 >> >> Cc: ; "CHATRAS Bruno RD-CORE-ISS"=20 >> ; ; ;=20 >> >> Sent: Thursday, December 14, 2006 2:51 PM >> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>=20 >>=20 >> Hi Hannes, >>=20 >> In addition to being a requirements document=20 >> draft-bodin-dime-auditing-reqs-01.txt provides use cases for=20 >failover=20 >> scenarios. Although I'm not sure a new requirement needs to be added=20 >> to this draft but I do believe the specific use case addressed by=20 >> Q.3301 is missing (i.e. auditing of the session status only). Hence,=20 >> my answer to question 1 is; maybe but not sure, and my answer to=20 >> question 2 is; I don't think so (in case we do it's a modification=20 >> rather than a deletion of existing requirements). >>=20 >> In my view the best way forward is to start the work on the foreseen=20 >> auditing mechanisms based on the earlier work of Calhoun (i.e. the=20 >> expired draft draft-calhoun-diameter-res-mgmt-08.txt) and in=20 >parallel=20 >> make an 02 of draft-bodin-dime-auditing-reqs-01.txt to add the use=20 >> case of Q.3301. All requirements need in my view to appear in the=20 >> document specifying the mechnism, but maybe it's better to keep use=20 >> cases in a separate document. I'm not sure the use case document now=20 >> more or less being draft-bodin-dime-auditing-reqs-01.txt must be=20 >> proceed to an RFC though. >>=20 >> Best regards, >> Ulf >>=20 >>=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: den 14 december 2006 14:08 >> To: Tina TSOU >> Cc: Ulf Bodin; john.loughney@nokia.com; CHATRAS Bruno RD-CORE-ISS;=20 >> dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>=20 >> Hi Ulf, >> Hi Tina, >>=20 >> I am confused with this discussion. Can someone decrypt the=20 >> conversation? >> We care about the following aspects: >> * Are there new requirements somewhere out there? >> * Should we modify or delete existing requirements? >>=20 >> Is there anything in the mentioned documents that could=20 >contribute to=20 >> these two items? >>=20 >> Ciao >> Hannes >>=20 >> Tina TSOU wrote: >>> Hi all, >>> Q.3301 only needs to comply with the requirements within its=20 >>> requirements document Y.2111. >>> draft-bodin-dime-auditing-reqs-01.txt is not Q.3301's requirements=20 >>> documents. >>> >>> We should notice the difference between synchronization and audit. >>> What Q.3301 specifies is audit rather than synchronization. >>> >>> If people need our DIME WG meet ETSI TISPAN requirements,=20 >it is more=20 >>> appropriate show requirements in ETSI TISPAN requirements documents=20 >>> (e.g. RACS R1, RACS R2). >>> If ETSI TISPAN officially says that >>> draft-bodin-dime-auditing-reqs-01.txt is ETSI TISPAN official audit=20 >>> requirements, that's fine. >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- From: "CHATRAS Bruno RD-CORE-ISS" >>> >>> To: "Tina TSOU" ; ;=20 >>> ; "Ulf Bodin" >>> Cc: ; ; >>> Sent: Thursday, December 14, 2006 12:22 PM >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> The mechanism defined in Q.3301 enables querying the status of a=20 >>> particular session (i.e. almost like a keep-alive=20 >mechanism). It does=20 >>> not provide a solution that fulfil all the requirements=20 >described in=20 >>> draft-bodin-dime-auditing-reqs-01.txt >>> BC >>> >>> -----Message d'origine----- >>> De : Tina TSOU [mailto:tena@huawei.com] Envoy=E9 : jeudi 14 = d=E9cembre >>> 2006 11:53 =C0 : Hannes.Tschofenig@gmx.net; john.loughney@nokia.com; = >>> Ulf >>=20 >>> Bodin Cc : steve.norreys@bt.com; avri@ltu.se; dime@ietf.org Objet : >>> Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> ITU-T has audit mechanism in Q.3301 Diameter-based Rs interface=20 >>> protocol (Tom is the editor), not extending Diameter base protocol. >>> The audit requirements in ITU-T Y.2111 (the architecture for Q.3301=20 >>> and other Q.rcp series Recommendations (ITU-T standards)) are: >>> Synchronization and audit: The Rs reference point shall provide the=20 >>> capability to support synchronization and audit of the resource=20 >>> control session status in support of recovery and operational=20 >>> information statistics and auditing. >>> >>> >>> B. R. >>> Tina >>> >>> ----- Original Message ----- >>> From: "Ulf Bodin" >>> To: ; ;=20 >>> >>> Cc: ; ; >>> Sent: Wednesday, December 13, 2006 11:03 PM >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> >>> Hi John, >>> >>> Actually draft-bodin-dime-auditing-reqs-01.txt is exacly this >> document. >>> It is written by the authors with the intent of reflecting needs=20 >>> related to coming releases of the ETSI TISPAN architecture (and=20 >>> hopefully similar architectures as those defined by 3GPP and ITU-T). >>> This IETF draft was referred to when discussing the LS=20 >today and the=20 >>> requirements listed therein ware considered useful from an ETSI=20 >>> TISPAN >>=20 >>> perspective. >>> >>> The intention is further to submitt contributions to ETSI TISPAN=20 >>> aiming at again include sufficient requirements on auditing=20 >into the=20 >>> release 2 of the ETSI TISPAN NGN architecture (and releases beyond=20 >>> release 2). >>> Thereby auditing will be discussed at coming ETSI TISPAN meetings. >>> >>> Best regards, >>> Ulf >>> >>> -----Original Message----- >>> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>> Sent: den 13 december 2006 22:50 >>> To: Ulf Bodin; tena@huawei.com; Hannes.Tschofenig@gmx.net >>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>> >>> Hi Ulf, >>> >>> That is good if we can have a short requirements document for >> auditing. >>> We can review that on the mailing list. Is it possible for you to=20 >>> discuss this with TISPAN? >>> >>> John >>> >>>> -----Original Message----- >>>> From: ext Ulf Bodin [mailto:Ulf.Bodin@operax.com] >>>> Sent: 13 December, 2006 13:45 >>>> To: Tina TSOU; Hannes Tschofenig >>>> Cc: steve.norreys@bt.com; avri@ltu.se; dime@ietf.org >>>> Subject: RE: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> Yes, that's absolutely right. The reason for removing the=20 >>>> requirements was that the protocol selected for the=20 >reference points=20 >>>> in questions (i.e. DIAMETER) doesn't (yet) support=20 >auditing. Hence,=20 >>>> the requirements on auditing were removed since they were not=20 >>>> possible to meet. We hope that by having a mechnism for auditing=20 >>>> defined by the IETF the deletion of the auditing=20 >requirements can be=20 >>>> reconsidered by ETSI TISPAN for coming releases. >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Tina TSOU [mailto:tena@huawei.com] >>>> Sent: den 13 december 2006 19:48 >>>> To: Hannes Tschofenig; Ulf Bodin >>>> Cc: dime@ietf.org; avri@ltu.se; steve.norreys@bt.com >>>> Subject: Re: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> And ETSI TISPAN also pointed out that there are no requirements=20 >>>> about >>=20 >>>> audit written in the active standard documents or drafts. >>>> People proposed, but they were removed, this is why there are no=20 >>>> requirements about audit written in the active standard=20 >documents or=20 >>>> drafts. >>>> >>>> B. R. >>>> Tina >>>> >>>> ----- Original Message ----- >>>> From: "Ulf Bodin" >>>> To: "Hannes Tschofenig" >>>> Cc: ; ; >>>> Sent: Wednesday, December 13, 2006 3:04 PM >>>> Subject: [Dime] RE: Diameter Auditing & ETSI TISPAN >>>> >>>> >>>> Hi Hannes, >>>> >>>> Just a quick update on the LS from ETSI to the IETF. WG3 of ETSI=20 >>>> TISPAN has now agreed to send an LS and the draft LS will hence be=20 >>>> forwarded >>=20 >>>> to the TC of TISPAN for the final decition (at least this is how I=20 >>>> understand the procedure :-). >>>> >>>> Best regards, >>>> Ulf >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: den 6 december 2006 12:33 >>>> To: Ulf Bodin >>>> Cc: avri@ltu.se; dime@ietf.org >>>> Subject: Re: Diameter Auditing & ETSI TISPAN >>>> >>>> Hi Ulf, >>>> >>>> thanks for the quick response. Please keep us up-to-date=20 >with regard=20 >>>> to the outcome of the discussion next week. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Ulf Bodin wrote: >>>>> Hi Hannes, >>>>> >>>>> I've submitted a draft LS for the meeting next week jointly >>>> signed by >>>>> myself, Bruno Chatras (FT) and Steve Norries (BT). Hence the >>>> decition >>>>> will be taken next week on sending the LS to IETF. >>>>> >>>>> Best regards, >>>>> Ulf >>>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: den 6 december 2006 11:44 >>>>> To: Ulf Bodin; avri@ltu.se >>>>> Cc: dime@ietf.org >>>>> Subject: Diameter Auditing & ETSI TISPAN >>>>> >>>>> Hi Ulf, >>>>> Hi Avri, >>>>> >>>>> what is the status of the liaison between ETSI TISPAN and=20 >the IETF=20 >>>>> DIME working group regarding the Diameter Auditing work? >>>>> >>>>> Ciao >>>>> Hannes & John >>>>> >>>>> PS: We encourage you to continue your work on the=20 >Diameter Auditing=20 >>>>> requirements draft and also to start your work on the solution >>>> document. >>>> >>>> _______________________________________________ >>>> 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 >>=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 Thu Dec 14 13:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guuwk-0000sT-4Y; Thu, 14 Dec 2006 13:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guuwi-0000sN-Fl for dime@ietf.org; Thu, 14 Dec 2006 13:04:40 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guuwh-0007xw-Ur for dime@ietf.org; Thu, 14 Dec 2006 13:04:40 -0500 Received: by nf-out-0910.google.com with SMTP id h2so898466nfe for ; Thu, 14 Dec 2006 10:04:39 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=CBZSYT3ctgnQzlGZGxvhSuDapKZNnO/+RDIYPkVbC1w4yg9O/IRz/TFgNKlpFXrhzyA+nBn2WpI6EteAFPTSU0I/QZyyYYmCrJBd0IIpdl90nvwrGgzXm6BCGQrDPr3DlOomDd18JYtGKWOlsYn/FU8ubYZGR+G8yQBa4X+mIaw= Received: by 10.48.210.16 with SMTP id i16mr1166989nfg.1166119478987; Thu, 14 Dec 2006 10:04:38 -0800 (PST) Received: by 10.48.213.18 with HTTP; Thu, 14 Dec 2006 10:04:38 -0800 (PST) Message-ID: <5e2406980612141004p3af2c09el9e657eedb693d00f@mail.gmail.com> Date: Thu, 14 Dec 2006 19:04:38 +0100 From: "Julien Bournelle" To: "Ahmad Muhanna" Subject: Re: [Dime] Expert Reviewers Nominated In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371119947E6@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455515A0.9050106@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA4371119947E6@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: lionel.morand@francetelecom.com, dime@ietf.org, "Glen Zorn \(gwz\)" , mamuhanna@nortel.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 Ahmad, Thanks for your review. Comments inline.. On 11/22/06, Ahmad Muhanna wrote: > > Hi all, > Please find below my technical comments after reviewing this draft. > > The following is the type of comments I have: > > 1. Editorial comments > > 1.1. Comment 1: > Abstract > > ................................. This document also specifies the > role of the Home Agent as part of the AAA infrastructure supporting > the Diameter Mobile IPv6 Authorization Application. > > I am not sure what we mean by the HA part of the AAA infrastructure. May > be we can say "..... The Home Agent as a Diameter MIP6 Authorization > client." ok. > > 1.2. Comment 2: > Introduction > " > With the Mobile IPv6 protocol [1], a Mobile Node (MN) is assigned a > Home Agent which is in charge of relaying IPv6 packets destined to > MN's Home Address to the MN's current address. > " > Can we reword this sentence as follows: > > "A Mobile Node (MN) that support Mobile IPv6 protocol [1] is assigned a > Home Agent to register its Mobile IPv6 session in order facilitate its > reachability and mobility at all time when it is a way from home." ok > > 1.3. Comment 3: > " > ....................For this reason, it is important for the Home > Agent to act as part of the service provider's AAA infrastructure." > > Can we replace it with the following: > > "....................For this reason, it is important for the Home > Agent to act as Diameter MIP6 Authorization client." yes > > > 1.4. Comment 4: > Under section 3.0, > "When the verification of user authorization to receive Mobile IPv6 > service is complete, the Home Agent..............................." > > Can we replace it with the following: > > "When the user Mobile IPv6 service authorization process is successful, > the Home Agent..............................." yes > > > 1.5. Comment 5: > Under section 4: > "...................................................... As EAP is > considered as a strong choice in performing authentication, this > document explains the use of Diameter EAP application in cases where > the prior authentication between MN and HA is done through use of > EAP. Therefore, the HA performs AAA operations for Mobile IPv6 by > using two Diameter Applications, namely: Diameter EAP[6] and Diameter > Mobile IPv6 (specified by this document)." > > Can we reword this one, may be as follows: > > "...................................................... As EAP is > very possibly the choice for performing user authentication, this I would prefer "considered as a strong choice" > document explains the use of Diameter EAP application when the MN > and HA use it for their authentication. Therefore HA performs user > authentication using Diameter EAP [6] and Mobile IPv6 service > authorization using Diameter Mobile IPv6 as specified in this > document" ok > > > > 2. Non Completed sections comments > > All non completed section need to be updated and completed. we'll do our best :) > > 3. Proposed New functionality comments > > Under section 4.3 Accounting, it reads: > " ........................................................ However, due > to routing optimization techniques introduced with Mobile IPv6 the HA > does not see the entire traffic exchanged between the MN and the CN." > > Proposed Functionality: > I would propose that it become part of this application the > authorization for > the user route optimization. This means that AAAH-MIP6 server will > indicate > to the HA if route optimization is allowed for this user or not using an > AVP, like: > MIP6-Route-Optimization-Capabilities. This will give the MSA more power > over the > their billing modulation and offering. This probably requires some > change to allow the HA to communicate to MN that route optimization > authorization status. i agree with you. We planned to add this in the MAA message. I guess how the HA communicates to the MN is however out of scope of our document. > > > 4. The main technical issue, AAAH-EAP and AAAH-MIP6 servers are > Different. > (IMO) this needs to be addressed depending on the bootstrapping and > authentication Model, as described below: > > 4.1. Integrated Bootstrapping > In this case, I do not see any need for the AAAH-EAP and AAAH-MIP6 to be > the same. Both the Diameter Client and Diameter server belong to the > same operator and there SHOULD be an existing trust relationship. In > this case, the Diameter server AAAH-MIP6 does not need to verify or know > that the user has been authenticated or NOT. It ONLY needs to verify if > the user is authorized to receive Mobile IPv6 service or not. (Also the > proposed idea below can be adopted here) I tend to agree. As I said to madjid, it would be good to get opinions from others. I'll start a new thread on this. > > 4.2. Split Bootstrapping: > In this case, I believe there are two different scenarios: (4.2.1. HA in > the Home Network, 4.2.2. HA in the visited network) > > 4.2.1. HA in the Home Network > This case is similar to 4.1. > > 4.2.2. HA in the Visited Network > Although communication to the AAAH-EAP and AAAH-MIP6 servers is through > some kind of SLA, there is still a need for the AAAH-MIP6 to be assured > that the authorization request is for an authenticated user. Please see > some thoughts about a possible idea for a solution below. Even if the HA is in the Visited Network, AAAH-EAP and AAAH-MIP6 belongs to the MSA. I don't see how it is different. > > 4.3. Using RFC4285 > I think this RFC should be considered for this Diameter MIP6 > Authorization application. I'll start another thread on this. Thanks again, I'll incorporate your review and will provide an intermediate draft ASAP. Julien > > > Proposed solutions: > I will use the other thread for it. > > Many Thanks. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, November 10, 2006 6:13 PM > > To: dime@ietf.org > > Cc: lionel.morand@francetelecom.com; mamuhanna@nortel.com; > > Glen Zorn (gwz) > > Subject: [Dime] Expert Reviewers Nominated > > > > Hi all, > > > > during the DIME meeting we selected expert reviewers for the > > HA<->AAAH document > > > (http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt): > > > > * Glen Zorn > > * Lionel Morand > > * Ahmad Muhanna > > > > Since a number of issues have been raised during the meeting > > I would suggest to also jump into the discussions. I will > > send a separate mail with a description of the raised aspects. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 13:55:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guvk8-0005CX-K8; Thu, 14 Dec 2006 13:55:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guvk6-0005CN-QX for dime@ietf.org; Thu, 14 Dec 2006 13:55:42 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guvk5-0004Ng-A1 for dime@ietf.org; Thu, 14 Dec 2006 13:55:42 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id DE7624E36F for ; Thu, 14 Dec 2006 13:55:36 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBEItZZP010664 for ; Thu, 14 Dec 2006 13:55:35 -0500 (EST) From: "Tolga Asveren" To: Date: Thu, 14 Dec 2006 13:52:18 -0500 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: 0a7aa2e6e558383d84476dc338324fab Subject: [Dime] trying to understand auditing problem X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here are some questions I came up with, while I was trying to understand the concept of auditing as described in draft-bodin-dime-auditing-reqs-01.txt: 1) I think the goal is not (and IMO should not be) to prevent session leaking. For example, if server or client is down, IMO application layer timers on the other side are supposed to take care of lack of requests/responses and delete session accordingly. The application layer protocol needs to be designed properly to take care of this type of situation. 2) Is the goal to allow restarting nodes to gather enough information to process subsequent incoming requests? I would think carrying relevant information in the requests to allow them to be processed by backup instances could be a more handy approach, i.e. basically allowing servers to be stateless (at least from protocol processing point of view). 3) AFAICS, the third issue is, how does a backup client knows, which sessions were alive, what data was associated with them etc..., so that it can continue to manage the service provided to the customer. I know the exact approach could be dependent on the service we are talking about but I will use DCCA/prepaid call as an example: +---+ +--------+ | | | | | S |::::|DCCA | +--------+ | e | |Client-1+----------+ | | r | +--------+ | | | v | | DCCA | | i | | Server | | c | +--------+ | | | e | | +----------+ | | |::::|DCCA | +--------+ | L | |Client-2| | o | +--------+ | g | | i | | c | +---+ Let's say there are 3 calls, which are using prepaid service. Credit control for Call-1 and Call-2 are handled by DCCA Client-1 and for Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to handle Call-1 and Call-2 as well. The first thing Client-2 needs to do is to determine which calls were handled by Client-1. I guess, this can be done in a straightforward way via communication between Client-2 and Service Logic component (assuming that this data is not synchronized between Client-1 and Client-2). Now, Client-2 can start a new session for these calls and perform credit control operation. The sessions on DCCA server, which were opened by requests from client-1 will be cleaned up after Tcc expires. Overall, it seems to me that with careful protocol design, it is possible to addres 3) as well without a need of a special mechanism. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 15:23:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gux7C-00070G-Ef; Thu, 14 Dec 2006 15:23:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gux7A-0006yY-Vw for dime@ietf.org; Thu, 14 Dec 2006 15:23:36 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gux79-0005vS-LD for dime@ietf.org; Thu, 14 Dec 2006 15:23:36 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBEKNW310825; Thu, 14 Dec 2006 15:23:32 -0500 (EST) 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] Expert Reviewers Nominated Date: Thu, 14 Dec 2006 14:23:29 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111EE5D64@zrc2hxm2.corp.nortel.com> In-Reply-To: <5e2406980612141004p3af2c09el9e657eedb693d00f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Expert Reviewers Nominated Thread-Index: AccfqlbEIwWnlXMETT6J2tqpOA3yIAADok2w From: "Ahmad Muhanna" To: "Julien Bournelle" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: lionel.morand@francetelecom.com, dime@ietf.org, "Glen Zorn \(gwz\)" , mamuhanna@nortel.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 Julien, please see comments inline. Regards, Ahmad =20 > Subject: Re: [Dime] Expert Reviewers Nominated >=20 > > > > > > 1.5. Comment 5: > > Under section 4: > > "...................................................... As EAP is > > considered as a strong choice in performing authentication, this > > document explains the use of Diameter EAP application in=20 > cases where > > the prior authentication between MN and HA is done through use of > > EAP. Therefore, the HA performs AAA operations for Mobile IPv6 by > > using two Diameter Applications, namely: Diameter EAP[6]=20 > and Diameter > > Mobile IPv6 (specified by this document)." > > > > Can we reword this one, may be as follows: > > > > "...................................................... As EAP is > > very possibly the choice for performing user authentication, this >=20 > I would prefer "considered as a strong choice" [Ahmad] That's fine. > > > > 2. Non Completed sections comments > > > > All non completed section need to be updated and completed. >=20 > we'll do our best :) >=20 > > > > 3. Proposed New functionality comments > > > > Under section 4.3 Accounting, it reads: > > " ........................................................=20 > However, due > > to routing optimization techniques introduced with=20 > Mobile IPv6 the HA > > does not see the entire traffic exchanged between the MN=20 > and the CN." > > > > Proposed Functionality: > > I would propose that it become part of this application the=20 > > authorization for the user route optimization. This means that=20 > > AAAH-MIP6 server will indicate to the HA if route optimization is=20 > > allowed for this user or not using an AVP, like: > > MIP6-Route-Optimization-Capabilities. This will give the MSA more=20 > > power over the their billing modulation and offering. This probably=20 > > requires some change to allow the HA to communicate to MN=20 > that route=20 > > optimization authorization status. >=20 > i agree with you. We planned to add this in the MAA message. >=20 > I guess how the HA communicates to the MN is however out of=20 > scope of our document. [Ahmad] Agree. >=20 > > > > 4.2. Split Bootstrapping: > > In this case, I believe there are two different scenarios:=20 > (4.2.1. HA=20 > > in the Home Network, 4.2.2. HA in the visited network) > > > > 4.2.1. HA in the Home Network > > This case is similar to 4.1. > > > > 4.2.2. HA in the Visited Network > > Although communication to the AAAH-EAP and AAAH-MIP6 servers is=20 > > through some kind of SLA, there is still a need for the=20 > AAAH-MIP6 to=20 > > be assured that the authorization request is for an authenticated=20 > > user. Please see some thoughts about a possible idea for a=20 > solution below. >=20 > Even if the HA is in the Visited Network, AAAH-EAP and=20 > AAAH-MIP6 belongs to the MSA. I don't see how it is different. [Ahmad] Since HA and AAAH-MIP6 belong to two different operators, in case the HA is compromised or acting inappropriately, MSA always will have a record that the MIP service which was offered to a specific session was always delivered to an authenticated user based on information directly received from the Home Agent itself. i.e. Since we are talking about separate servers for authentication and authorization, HA always certifies that the user was properly authenticated. I hope I am making sense here. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 14 15:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuxRN-0005fT-8l; Thu, 14 Dec 2006 15:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuxRM-0005ek-7B for dime@ietf.org; Thu, 14 Dec 2006 15:44:28 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuxRK-0007uM-KR for dime@ietf.org; Thu, 14 Dec 2006 15:44:28 -0500 Received: (qmail 14645 invoked by uid 0); 14 Dec 2006 20:44:25 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 14 Dec 2006 20:44:25 -0000 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] trying to understand auditing problem Date: Thu, 14 Dec 2006 21:41:36 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB5559@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] trying to understand auditing problem Thread-Index: AccfsZO+jwAAx8nmQHmz9Yh4U25hiwACvigg From: "Ulf Bodin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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,=20 Pls find my replies below.=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 14 december 2006 19:52 To: dime@ietf.org Subject: [Dime] trying to understand auditing problem Here are some questions I came up with, while I was trying to understand the concept of auditing as described in draft-bodin-dime-auditing-reqs-01.txt: 1) I think the goal is not (and IMO should not be) to prevent session leaking. For example, if server or client is down, IMO application layer timers on the other side are supposed to take care of lack of requests/responses and delete session accordingly. The application layer protocol needs to be designed properly to take care of this type of situation. Ulf: I'm not sure how this can be handled in case of hard-state. I.e. without any messages updating timers for sessions remaining valid/active. In case long timers would be used to approach a hard-state behaviour this would also increase the period of inconsistency (which depending on the application can be costy and even incopatible with the service offered).=20 2) Is the goal to allow restarting nodes to gather enough information to process subsequent incoming requests? I would think carrying relevant information in the requests to allow them to be processed by backup instances could be a more handy approach, i.e. basically allowing servers to be stateless (at least from protocol processing point of view). Ulf: A failover to a cold standby basically corresponds to having the server stateless. For this particular scenario I think we just need a mechanism triggering clients to actuall resubmit their previously issued requests with all relevant information. These resubmitted requests must however be separated from new requests. I.e. since the server wont recognize any session IDs it must be given another indication of which sessions are new and which ones that a just re-established.=20 3) AFAICS, the third issue is, how does a backup client knows, which sessions were alive, what data was associated with them etc..., so that it can continue to manage the service provided to the customer. I know the exact approach could be dependent on the service we are talking about but I will use DCCA/prepaid call as an example: +---+ +--------+ | | | | | S |::::|DCCA | +--------+ | e | |Client-1+----------+ | | r | +--------+ | | | v | | DCCA | | i | | Server | | c | +--------+ | | | e | | +----------+ | | |::::|DCCA | +--------+ | L | |Client-2| | o | +--------+ | g | | i | | c | +---+ Let's say there are 3 calls, which are using prepaid service. Credit control for Call-1 and Call-2 are handled by DCCA Client-1 and for Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to handle Call-1 and Call-2 as well. The first thing Client-2 needs to do is to determine which calls were handled by Client-1. I guess, this can be done in a straightforward way via communication between Client-2 and Service Logic component (assuming that this data is not synchronized between Client-1 and Client-2). Now, Client-2 can start a new session for these calls and perform credit control operation. The sessions on DCCA server, which were opened by requests from client-1 will be cleaned up after Tcc expires. Ulf: If I understand this scenario correctly I believe it's similar to the second one. I.e. a trigger from Client 2 to the service logic making it re-submit requests for active sessions and tag them as re-establish requests rather than new requests would probably be enough.=20 Overall, it seems to me that with careful protocol design, it is possible to addres 3) as well without a need of a special mechanism. 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 Dec 14 16:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyBA-0007zF-0Q; Thu, 14 Dec 2006 16:31:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyB8-0007xN-6t for dime@ietf.org; Thu, 14 Dec 2006 16:31:46 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuyB5-0004n1-Eh for dime@ietf.org; Thu, 14 Dec 2006 16:31:46 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 36F569A7BC for ; Thu, 14 Dec 2006 16:31:38 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBELVXo1023453 for ; Thu, 14 Dec 2006 16:31:37 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] trying to understand auditing problem Date: Thu, 14 Dec 2006 16:28:15 -0500 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: <33656995C5C5094A983DE84DA649A924CB5559@lulex02.ad.operax.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 Ulf, Please see below for some more questions/comments. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Thursday, December 14, 2006 3:42 PM > To: dime@ietf.org > Subject: RE: [Dime] trying to understand auditing problem > > > Hi Tolga, > > Pls find my replies below. > > Best regards, > Ulf > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 14 december 2006 19:52 > To: dime@ietf.org > Subject: [Dime] trying to understand auditing problem > > Here are some questions I came up with, while I was trying to understand > the concept of auditing as described in > draft-bodin-dime-auditing-reqs-01.txt: > > > 1) I think the goal is not (and IMO should not be) to prevent session > leaking. For example, if server or client is down, IMO application layer > timers on the other side are supposed to take care of lack of > requests/responses and delete session accordingly. The application layer > protocol needs to be designed properly to take care of this type of > situation. > > Ulf: I'm not sure how this can be handled in case of hard-state. I.e. > without any messages updating timers for sessions remaining > valid/active. In case long timers would be used to approach a hard-state > behaviour this would also increase the period of inconsistency (which > depending on the application can be costy and even incopatible with the > service offered). [TOLGA] O.K., now it is more clear to me. AFAICS, using timers translates to a soft-state scenario. For example for DCCA : a)For event based scenario, there is no issue, it is just a single transaction. b)For session based scenario, client needs periodically to send new requests. This maximum value for this period is communciated from server and server is running Tcc timer. If Tcc expires and no new request is received yet, the session is freed. Similarly client uses Tx timer while waiting for replies. Overall, hard-state approach seems a risky strategy to me, for example what happens if client dies and there is no backup server? Will the sessions on the server stay there forever? IMHO, use of timers at both client and server side makes life really easy. > > 2) Is the goal to allow restarting nodes to gather enough information to > process subsequent incoming requests? I would think carrying relevant > information in the requests to allow them to be processed by backup > instances could be a more handy approach, i.e. basically allowing > servers to be stateless (at least from protocol processing point of > view). > > Ulf: A failover to a cold standby basically corresponds to having the > server stateless. For this particular scenario I think we just need a > mechanism triggering clients to actuall resubmit their previously issued > requests with all relevant information. These resubmitted requests must > however be separated from new requests. I.e. since the server wont > recognize any session IDs it must be given another indication of which > sessions are new and which ones that a just re-established. [TOLGA]If the clients are sending new requests periodically and if the requests contain enough information for proper processing even if they are sent to a cold standby this probably should work. If the sessions for the reqeusts are not known by the cold standby instance yet, this shouldn't be a problem. It just will create a new session and perform processing according to the contents of the received request. It seems this item is again closely related whether a timer is running on the client side. > > 3) AFAICS, the third issue is, how does a backup client knows, which > sessions were alive, what data was associated with them etc..., so that > it can continue to manage the service provided to the customer. I know > the exact approach could be dependent on the service we are talking > about but I will use DCCA/prepaid call as an example: > > +---+ +--------+ > | | | | > | S |::::|DCCA | +--------+ > | e | |Client-1+----------+ | > | r | +--------+ | | > | v | | DCCA | > | i | | Server | > | c | +--------+ | | > | e | | +----------+ | > | |::::|DCCA | +--------+ > | L | |Client-2| > | o | +--------+ > | g | > | i | > | c | > +---+ > > Let's say there are 3 calls, which are using prepaid service. Credit > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to handle > Call-1 and Call-2 as well. > > The first thing Client-2 needs to do is to determine which calls were > handled by Client-1. I guess, this can be done in a straightforward way > via communication between Client-2 and Service Logic component (assuming > that this data is not synchronized between Client-1 and Client-2). Now, > Client-2 can start a new session for these calls and perform credit > control operation. The sessions on DCCA server, which were opened by > requests from > client-1 will be cleaned up after Tcc expires. > > Ulf: If I understand this scenario correctly I believe it's similar to > the second one. I.e. a trigger from Client 2 to the service logic making > it re-submit requests for active sessions and tag them as re-establish > requests rather than new requests would probably be enough. [TOLGA]On this item, I tried to evaluate the situation from client point of view (you are right, this is the same scenario as 2, this time from client perspective). Basically how Client-2 determines calls which were served by Client-1 is really implementation dependent. It definetly can be done though, the calls (or any resource in that sense) is controlled by some service logic, which has the information about what is currently provided to the users. What Client-2 needs to do is just to create new sessions for these service instances. "Old" sessions on the DCCA server will expire upon expiry of Tcc. > > Overall, it seems to me that with careful protocol design, it is > possible to addres 3) as well without a need of a special mechanism. > > 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 Fri Dec 15 12:31:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGts-0005Sd-Px; Fri, 15 Dec 2006 12:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGtr-0005SX-Ta for dime@ietf.org; Fri, 15 Dec 2006 12:31:11 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GvGtr-0005lX-3p for dime@ietf.org; Fri, 15 Dec 2006 12:31:11 -0500 Received: (qmail 93870 invoked by uid 0); 15 Dec 2006 17:31:07 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 15 Dec 2006 17:31:07 -0000 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] trying to understand auditing problem Date: Fri, 15 Dec 2006 18:31:06 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB56E7@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] trying to understand auditing problem Thread-Index: Accfx2jIvlKrPAzmQES+mHHpy4YJBwAg/0Mw From: "Ulf Bodin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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,=20 Further replies below.=20 Best regards,=20 Ulf=20 > > Here are some questions I came up with, while I was trying to=20 > understand the concept of auditing as described in > draft-bodin-dime-auditing-reqs-01.txt: > > > 1) I think the goal is not (and IMO should not be) to prevent session=20 > leaking. For example, if server or client is down, IMO application=20 > layer timers on the other side are supposed to take care of lack of=20 > requests/responses and delete session accordingly. The application=20 > layer protocol needs to be designed properly to take care of this type > of situation. > > Ulf: I'm not sure how this can be handled in case of hard-state. I.e. > without any messages updating timers for sessions remaining=20 > valid/active. In case long timers would be used to approach a=20 > hard-state behaviour this would also increase the period of=20 > inconsistency (which depending on the application can be costy and=20 > even incopatible with the service offered). [TOLGA] O.K., now it is more clear to me. AFAICS, using timers translates to a soft-state scenario. For example for DCCA : a)For event based scenario, there is no issue, it is just a single transaction. b)For session based scenario, client needs periodically to send new requests. This maximum value for this period is communciated from server and server is running Tcc timer. If Tcc expires and no new request is received yet, the session is freed. Similarly client uses Tx timer while waiting for replies. Overall, hard-state approach seems a risky strategy to me, for example what happens if client dies and there is no backup server? Will the sessions on the server stay there forever? IMHO, use of timers at both client and server side makes life really easy. Ulf2: I assume you refer to a dead client without any backup client. Then, if a client dies the server certainly needs a strategy for how to handle hard states established by a confirmed dead client (i.e. if there is no backup client these states need to be terminated). If instead there is a backup client taking over a (short) while, it should be able to ensure that it's in sync with the server.=20 > > 2) Is the goal to allow restarting nodes to gather enough information=20 > to process subsequent incoming requests? I would think carrying=20 > relevant information in the requests to allow them to be processed by=20 > backup instances could be a more handy approach, i.e. basically=20 > allowing servers to be stateless (at least from protocol processing=20 > point of view). > > Ulf: A failover to a cold standby basically corresponds to having the=20 > server stateless. For this particular scenario I think we just need a=20 > mechanism triggering clients to actuall resubmit their previously=20 > issued requests with all relevant information. These resubmitted=20 > requests must however be separated from new requests. I.e. since the=20 > server wont recognize any session IDs it must be given another=20 > indication of which sessions are new and which ones that a just re-established. [TOLGA]If the clients are sending new requests periodically and if the requests contain enough information for proper processing even if they are sent to a cold standby this probably should work. If the sessions for the reqeusts are not known by the cold standby instance yet, this shouldn't be a problem. It just will create a new session and perform processing according to the contents of the received request. It seems this item is again closely related whether a timer is running on the client side. Ulf2: Yes, with the addition that a trigger to resubmit requests is needed and an indication of that the resubmitted requests are for lost session states and not for new sessions (i.e. the server may need to differentiate between these two types of session requests to provide its service properly).=20 > > 3) AFAICS, the third issue is, how does a backup client knows, which=20 > sessions were alive, what data was associated with them etc..., so=20 > that it can continue to manage the service provided to the customer. I > know the exact approach could be dependent on the service we are=20 > talking about but I will use DCCA/prepaid call as an example: > > +---+ +--------+ > | | | | > | S |::::|DCCA | +--------+ > | e | |Client-1+----------+ | > | r | +--------+ | | > | v | | DCCA | > | i | | Server | > | c | +--------+ | | > | e | | +----------+ | > | |::::|DCCA | +--------+ > | L | |Client-2| > | o | +--------+ > | g | > | i | > | c | > +---+ > > Let's say there are 3 calls, which are using prepaid service. Credit=20 > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to handle > Call-1 and Call-2 as well. > > The first thing Client-2 needs to do is to determine which calls were=20 > handled by Client-1. I guess, this can be done in a straightforward=20 > way via communication between Client-2 and Service Logic component=20 > (assuming that this data is not synchronized between Client-1 and=20 > Client-2). Now, > Client-2 can start a new session for these calls and perform credit=20 > control operation. The sessions on DCCA server, which were opened by=20 > requests from > client-1 will be cleaned up after Tcc expires. > > Ulf: If I understand this scenario correctly I believe it's similar to > the second one. I.e. a trigger from Client 2 to the service logic=20 > making it re-submit requests for active sessions and tag them as=20 > re-establish requests rather than new requests would probably be enough. [TOLGA]On this item, I tried to evaluate the situation from client point of view (you are right, this is the same scenario as 2, this time from client perspective). Basically how Client-2 determines calls which were served by Client-1 is really implementation dependent. It definetly can be done though, the calls (or any resource in that sense) is controlled by some service logic, which has the information about what is currently provided to the users. What Client-2 needs to do is just to create new sessions for these service instances. "Old" sessions on the DCCA server will expire upon expiry of Tcc. Ulf2: Yes, I agree. For this scenario the service logic provides the trigger to Client 2 and since the server hasn't done a failover it should recognize the session ID of Call 1 and Call 2 as existing ones. If instead the server would have done a failover such indication would IMHO be needed.=20 > > Overall, it seems to me that with careful protocol design, it is=20 > possible to addres 3) as well without a need of a special mechanism. > > 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 Dec 15 15:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJKq-0007kx-DB; Fri, 15 Dec 2006 15:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvJKo-0007kl-7p for dime@ietf.org; Fri, 15 Dec 2006 15:07:10 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvJKm-0001Gt-S2 for dime@ietf.org; Fri, 15 Dec 2006 15:07:10 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 32EAF9F213 for ; Fri, 15 Dec 2006 15:07:04 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBFK73Fx009169 for ; Fri, 15 Dec 2006 15:07:03 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] trying to understand auditing problem Date: Fri, 15 Dec 2006 15:03:39 -0500 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: <33656995C5C5094A983DE84DA649A924CB56E7@lulex02.ad.operax.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 Ulf, Please see below for more comments/questions. Thanks, Tolga [..snip..] > Overall, hard-state approach seems a risky strategy to me, for example > what happens if client dies and there is no backup server? Will the > sessions on the server stay there forever? IMHO, use of timers at both > client and server side makes life really easy. > > Ulf2: I assume you refer to a dead client without any backup client. > Then, if a client dies the server certainly needs a strategy for how to > handle hard states established by a confirmed dead client (i.e. if there > is no backup client these states need to be terminated). If instead > there is a backup client taking over a (short) while, it should be able > to ensure that it's in sync with the server. [TOLGA]Yes, sorry for the typo, the scenario was a dead client with no backup client. I guess confirming (or better said believing with a very high probability) that the client is dead will require a timer on server side anyhow, transforming the scenario to a soft-state case. [..snip..] > [TOLGA]If the clients are sending new requests periodically and if the > requests contain enough information for proper processing even if they > are sent to a cold standby this probably should work. If the sessions > for the reqeusts are not known by the cold standby instance yet, this > shouldn't be a problem. It just will create a new session and perform > processing according to the contents of the received request. It seems > this item is again closely related whether a timer is running on the > client side. > > Ulf2: Yes, with the addition that a trigger to resubmit requests is > needed and an indication of that the resubmitted requests are for lost > session states and not for new sessions (i.e. the server may need to > differentiate between these two types of session requests to provide its > service properly). [TOLGA]I guess with careful protocol design one can avoid the need to indicate that resubmitted requests are for lost session states. For example in DCCA, if a client dies, a backup instance takes over and starts new sessions for the service instances it took over. I guess no harm would be done even for session based scenario, except service provider not being able to charge for the last service period at a maximum, which really shouldn't be a big amount. Old sessions in the server just will expire upon timer expiry. > > > > 3) AFAICS, the third issue is, how does a backup client knows, which > > sessions were alive, what data was associated with them etc..., so > > that it can continue to manage the service provided to the customer. I > > > know the exact approach could be dependent on the service we are > > talking about but I will use DCCA/prepaid call as an example: > > > > +---+ +--------+ > > | | | | > > | S |::::|DCCA | +--------+ > > | e | |Client-1+----------+ | > > | r | +--------+ | | > > | v | | DCCA | > > | i | | Server | > > | c | +--------+ | | > > | e | | +----------+ | > > | |::::|DCCA | +--------+ > > | L | |Client-2| > > | o | +--------+ > > | g | > > | i | > > | c | > > +---+ > > > > Let's say there are 3 calls, which are using prepaid service. Credit > > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to handle > > Call-1 and Call-2 as well. > > > > The first thing Client-2 needs to do is to determine which calls were > > handled by Client-1. I guess, this can be done in a straightforward > > way via communication between Client-2 and Service Logic component > > (assuming that this data is not synchronized between Client-1 and > > Client-2). Now, > > Client-2 can start a new session for these calls and perform credit > > control operation. The sessions on DCCA server, which were opened by > > requests from > > client-1 will be cleaned up after Tcc expires. > > > > Ulf: If I understand this scenario correctly I believe it's similar to > > > the second one. I.e. a trigger from Client 2 to the service logic > > making it re-submit requests for active sessions and tag them as > > re-establish requests rather than new requests would probably be > enough. > [TOLGA]On this item, I tried to evaluate the situation from client point > of view (you are right, this is the same scenario as 2, this time from > client perspective). Basically how Client-2 determines calls which were > served by > Client-1 is really implementation dependent. It definetly can be done > though, the calls (or any resource in that sense) is controlled by some > service logic, which has the information about what is currently > provided to the users. What Client-2 needs to do is just to create new > sessions for these service instances. "Old" sessions on the DCCA server > will expire upon expiry of Tcc. > Ulf2: Yes, I agree. For this scenario the service logic provides the > trigger to Client 2 and since the server hasn't done a failover it > should recognize the session ID of Call 1 and Call 2 as existing ones. > If instead the server would have done a failover such indication would > IMHO be needed. [TOLGA]Will there be any cases where Service Logic won't be controlling the service resources? I guess the answer is negative because otherwise Service Logic wouldn't be able to release resources allocated for a specific user upon a negative answer from DCCA server. So, I assume Service Logic can always provide a trigger for a backup client taking over responsibilites of a failed one. I think it is possible that the server does not need to know anything about whether the sessions are a replacement for existing sessions. Old ones just will expire if a timer is utilized. Again it depends on the design of the application layer protocol. Actually, in general IMHO proper application layer protocol design is important to deal with issues audit mechanism talks about and could provide a satisfactory solution for most of the cases. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 18 04:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFFs-0005VT-7m; Mon, 18 Dec 2006 04:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFFq-0005VO-9A for dime@ietf.org; Mon, 18 Dec 2006 04:57:54 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwFFo-0001ck-Vb for dime@ietf.org; Mon, 18 Dec 2006 04:57:54 -0500 X-VirusChecked: Checked X-Env-Sender: in1236c@motorola.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1166435863!10796121!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 14874 invoked from network); 18 Dec 2006 09:57:43 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-4.tower-119.messagelabs.com with SMTP; 18 Dec 2006 09:57:43 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kBI9vgut013346 for ; Mon, 18 Dec 2006 02:57:42 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kBI9vfAl023699 for ; Mon, 18 Dec 2006 03:57:42 -0600 (CST) Received: from [10.232.35.38] ([10.232.35.38]) by ZMY16EXM67.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Mon, 18 Dec 2006 17:57:34 +0800 From: Satendra To: Victor Fajardo , john.loughney@nokia.com, "Tschofenig, Hannes" Content-Type: text/plain Date: Mon, 18 Dec 2006 15:23:23 +0530 Message-Id: <1166435603.10153.116.camel@A21224-01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2006 09:57:34.0290 (UTC) FILETIME=[F0B9FB20:01C7228A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org Subject: [Dime] Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, We went through your test case draft, following are our observations. 1) Application id in common messages: As the doubts about application id value in common messages have been clarified we can test for its compliance. Following text can be added to section 4.1.1.1.1. bullet 3 & 4, section 4.3.1.5 bullet 3 ,4. "Verify application id value in STR/STA message as that of the target application." Note: We would like to have the same comment applied to section 4.7.1 bullets 2 and 4. But looks like RFC 4004 explicitly states app id 0 for STR/STA. 2) Capabilities Negotiation for relay application: Following test case can be added to section 3.1.1.1 o Positive test for establishment of connection with test pairs of which one of them is advertising support for only relay app and no other app is in common. o Positive test for establishment of connection advertising the relay app in auth app id, acct app id & VSA. o Negative test case for TLS handshake failure. The connection is disconnected by both the peers. Intentionally configure vendor A to send wrong certificate after Inband-Security-AVP with value 1 (TLS). TLS handshake should fail. Optional test cases: o Positive test for establishment of connection with inter and intra domain peers advertising support for use of TLS (for inter-domain) and IPSec (for intra-domain). Vendor A is an edge node which has peers intra-domain and inter-domain. Vendor A advertises inband Security AVP with TLS with the inter-domain peer (vendor B). Vendor A does not advertise inband security avp with TLS with the intra-domain peer(vendor C). Connection is established with both peers. 3) Positive test case can be for v6 connectivity to section 3.1.1 4) Section 3.1.1.3 para 1 "Determination must be made within 30 seconds of the event." The detection time will depend on watchdog timer and can't be 30 seconds with all configurations 5) Section 3.1.1.3: We can use the text in errata draft to specify the peer behaviour when a DPR is received. 6) Section 3.1.1.2: a) The two test cases can be combined to one test case. "Positive test for establishment of connection between two peers, one having higher identity than the other. Vendor A having a higher identity than vendor B. Vendor A and vendor B initiate connection, verify that vendor A initiated connected is closed at both the ends." b) One more test case can be added to verify the behaviour of TLS in the election scenario. "Positive test for establishment of connection with TLS between two peers,with election scenario, as mentioned above. vendor B will initiate TLS handshake on vendor B initiated transport connection." 7) Section 3.1.1.3 para 3: "Implementation should also attempt re-connection with lost peer before resetting the connection." Does RFC suggests such a behavior ? 8) Section 3.1.1.5 bullet 4: Need to specify that link3 is down.Also a mention that vendor B and vendor D are advertising only relay application. 9) Section 3.1.2: Need to specify vendor A2 and vendor B1 should be relays. 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": A2 should be relay, otherwise A1 will not send the request to it, since neither the dest host or the realm matches. Note that this message has dest host avp. Hence A1 cannot do realm routing. Also, B1 should also be a relay. 11) Section 3.1.2.2: A2 and B1 should be relay in this case too. Otherwise, - the message is routed to them because they support the app. - they will locally consume this message, because there is no dest host avp. Regards, Satendra Motorola _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 18 08:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwItE-0006a2-5b; Mon, 18 Dec 2006 08:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwItD-0006Zw-E1 for dime@ietf.org; Mon, 18 Dec 2006 08:50:47 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwItC-0007jf-JC for dime@ietf.org; Mon, 18 Dec 2006 08:50:47 -0500 Received: (qmail 97642 invoked by uid 0); 18 Dec 2006 13:50:42 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 18 Dec 2006 13:50:42 -0000 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] trying to understand auditing problem Date: Mon, 18 Dec 2006 14:50:42 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB5835@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] trying to understand auditing problem Thread-Index: AccghMJfzdzBEEVBTW+cEq4UPnImuwCF2TNg From: "Ulf Bodin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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,=20 Clearly it's quite easy to find examples in which Diameter clients and their server can rely on soft-state to ensure that they after timer expiration return to the same view on the set of sessions being active. In my view soft-state without auditing is preferable over soft-state with auditing for synchronization or hard-state in many cases for several reasons.=20 For example, for high-volume and short holding-time applications/sessions it would be troublesome to audit high volumes of states while serving new session requests in parallel. That is, auditing will consume resources and take time. Consequently, many audited session states are likely to have been terminated by the application before being audited. Also, for applications that can accept periods of client/server inconstency, soft-state without auditing for synchronization is most likely the way to go.=20 On the other hand, lower-volume and longer-holding time applications/sessions auditing can allow for more precise services offered by Dimeter server systems. Also, to some extent, auditing can relax requirements on state replication at both clients and server. An example of such a scenario is when an instance of RACS (Resource and Admisison Control Subsystem as defined by ETSI TISPAN) is to handle resource reservations for leased-line services.=20 For simplicitly, say that only two leased-line service nodes and two RACS nodes exist, one active and one backup node of each kind. The active leased-line service Diameter client node establishes a session with the active RACS Diameter server node. This corresponding session state in RACS must not be lost for any reason (e.g. the contractual agreement for the leased-line service makes it very costly to lose resource reservation states for this service). Hence, to protect against state loss or at least periods of state inconsistency, replication is required at the client side, at the server side, or both. Through auditing, states need not be replicated at both client and server and/or replication can be asyncronous.=20 In case of hard-state, I agree that states must be terminated in case the backup instance can't be activated. In my view this fact does however not transform the hard-state to a soft-state. For example, failing to activate a hot-standby backup client or server should indeed result in states being terminated either explicitly by a management operation or automatically through a timeout. However, in case the backup is activated successfully, auditing is useful to ensure synchronisation without waiting for timer expiration.=20 The problem of state synchronization may be possible to engineer around, but it's my firm belief that that an auditing capability in Diameter would be useful and allow for more attractive overall solutions compared to such engineering approaches. Again, I don't believe auditing to the best approach for all applications, but rather for particular applications with specific needs (e.g. such as RACS resource reservations for leased-lines).=20 Best regards,=20 Ulf=20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 15 december 2006 21:04 To: dime@ietf.org Subject: RE: [Dime] trying to understand auditing problem Hi Ulf, Please see below for more comments/questions. Thanks, Tolga [..snip..] > Overall, hard-state approach seems a risky strategy to me, for example > what happens if client dies and there is no backup server? Will the=20 > sessions on the server stay there forever? IMHO, use of timers at both > client and server side makes life really easy. > > Ulf2: I assume you refer to a dead client without any backup client. > Then, if a client dies the server certainly needs a strategy for how=20 > to handle hard states established by a confirmed dead client (i.e. if=20 > there is no backup client these states need to be terminated). If=20 > instead there is a backup client taking over a (short) while, it=20 > should be able to ensure that it's in sync with the server. [TOLGA]Yes, sorry for the typo, the scenario was a dead client with no backup client. I guess confirming (or better said believing with a very high probability) that the client is dead will require a timer on server side anyhow, transforming the scenario to a soft-state case. [..snip..] > [TOLGA]If the clients are sending new requests periodically and if the > requests contain enough information for proper processing even if they > are sent to a cold standby this probably should work. If the sessions=20 > for the reqeusts are not known by the cold standby instance yet, this=20 > shouldn't be a problem. It just will create a new session and perform=20 > processing according to the contents of the received request. It seems > this item is again closely related whether a timer is running on the=20 > client side. > > Ulf2: Yes, with the addition that a trigger to resubmit requests is=20 > needed and an indication of that the resubmitted requests are for lost > session states and not for new sessions (i.e. the server may need to=20 > differentiate between these two types of session requests to provide=20 > its service properly). [TOLGA]I guess with careful protocol design one can avoid the need to indicate that resubmitted requests are for lost session states. For example in DCCA, if a client dies, a backup instance takes over and starts new sessions for the service instances it took over. I guess no harm would be done even for session based scenario, except service provider not being able to charge for the last service period at a maximum, which really shouldn't be a big amount. Old sessions in the server just will expire upon timer expiry. > > > > 3) AFAICS, the third issue is, how does a backup client knows,=20 > > which sessions were alive, what data was associated with them=20 > > etc..., so that it can continue to manage the service provided to=20 > > the customer. I > > > know the exact approach could be dependent on the service we are=20 > > talking about but I will use DCCA/prepaid call as an example: > > > > +---+ +--------+ > > | | | | > > | S |::::|DCCA | +--------+ > > | e | |Client-1+----------+ | > > | r | +--------+ | | > > | v | | DCCA | > > | i | | Server | > > | c | +--------+ | | > > | e | | +----------+ | > > | |::::|DCCA | +--------+ > > | L | |Client-2| > > | o | +--------+ > > | g | > > | i | > > | c | > > +---+ > > > > Let's say there are 3 calls, which are using prepaid service. Credit > > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to=20 > > handle > > Call-1 and Call-2 as well. > > > > The first thing Client-2 needs to do is to determine which calls=20 > > were handled by Client-1. I guess, this can be done in a=20 > > straightforward way via communication between Client-2 and Service=20 > > Logic component (assuming that this data is not synchronized between > > Client-1 and Client-2). Now, > > Client-2 can start a new session for these calls and perform credit=20 > > control operation. The sessions on DCCA server, which were opened by > > requests from > > client-1 will be cleaned up after Tcc expires. > > > > Ulf: If I understand this scenario correctly I believe it's similar=20 > > to > > > the second one. I.e. a trigger from Client 2 to the service logic=20 > > making it re-submit requests for active sessions and tag them as=20 > > re-establish requests rather than new requests would probably be > enough. > [TOLGA]On this item, I tried to evaluate the situation from client=20 > point of view (you are right, this is the same scenario as 2, this=20 > time from client perspective). Basically how Client-2 determines calls > which were served by > Client-1 is really implementation dependent. It definetly can be done=20 > though, the calls (or any resource in that sense) is controlled by=20 > some service logic, which has the information about what is currently=20 > provided to the users. What Client-2 needs to do is just to create new > sessions for these service instances. "Old" sessions on the DCCA=20 > server will expire upon expiry of Tcc. > Ulf2: Yes, I agree. For this scenario the service logic provides the=20 > trigger to Client 2 and since the server hasn't done a failover it=20 > should recognize the session ID of Call 1 and Call 2 as existing ones. > If instead the server would have done a failover such indication would > IMHO be needed. [TOLGA]Will there be any cases where Service Logic won't be controlling the service resources? I guess the answer is negative because otherwise Service Logic wouldn't be able to release resources allocated for a specific user upon a negative answer from DCCA server. So, I assume Service Logic can always provide a trigger for a backup client taking over responsibilites of a failed one. I think it is possible that the server does not need to know anything about whether the sessions are a replacement for existing sessions. Old ones just will expire if a timer is utilized. Again it depends on the design of the application layer protocol. Actually, in general IMHO proper application layer protocol design is important to deal with issues audit mechanism talks about and could provide a satisfactory solution for most of the cases. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 18 09:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJoH-0000EY-Hl; Mon, 18 Dec 2006 09:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJoG-0000EF-1i for dime@ietf.org; Mon, 18 Dec 2006 09:49:44 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJoB-0001iU-17 for dime@ietf.org; Mon, 18 Dec 2006 09:49:44 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBIEmrX4073946; Mon, 18 Dec 2006 09:48:53 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4586AA56.1090409@tari.toshiba.com> Date: Mon, 18 Dec 2006 09:48:54 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Satendra References: <1166435603.10153.116.camel@A21224-01> In-Reply-To: <1166435603.10153.116.camel@A21224-01> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: dime@ietf.org, "Tschofenig, Hannes" Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Satendra, Thanks. Comments inline: > We went through your test case draft, following are our observations. > > 1) Application id in common messages: > As the doubts about application id value in common messages have been > clarified we can test for its compliance. Following text can be added to > section 4.1.1.1.1. bullet 3 & 4, section 4.3.1.5 bullet 3 ,4. > "Verify application id value in STR/STA message as that of the target > application." > > Note: We would like to have the same comment applied to section 4.7.1 > bullets 2 and 4. But looks like RFC 4004 explicitly states app id 0 for > STR/STA. > ok. > 2) Capabilities Negotiation for relay application: > Following test case can be added to section 3.1.1.1 > > o Positive test for establishment of connection with test pairs of which > one of them is advertising support for only relay app and no other app > is in common. > ok. > o Positive test for establishment of connection advertising the relay > app in auth app id, acct app id & VSA. > is'nt this already covered ? > o Negative test case for TLS handshake failure. The connection is > disconnected by both the peers. > Intentionally configure vendor A to send wrong certificate after > Inband-Security-AVP with value 1 (TLS). TLS handshake should fail. > this maybe covered as well. my current thought is try not to be very detailed in the test cases so the document won't be so large that it becomes cumbersome to follow. in the specific case you mentioned above, there are probably multiple ways of making TLS handshake fail so it maybe best to leave it up to the participants to simulate a failure that is most convinient for them. Especially since we only have a few days to test. > Optional test cases: > > o Positive test for establishment of connection with inter and intra > domain peers advertising support for use of TLS (for inter-domain) and > IPSec (for intra-domain). Vendor A is an edge node which has peers > intra-domain and inter-domain. Vendor A advertises inband Security AVP > with TLS with the inter-domain peer (vendor B). Vendor A does not > advertise inband security avp with TLS with the intra-domain peer(vendor > C). Connection is established with both peers. > Maybe this is a very specific deployment test instead of a general test case ? > 3) Positive test case can be for v6 connectivity to section 3.1.1 > > 4) Section 3.1.1.3 para 1 "Determination must be made within 30 seconds > of the event." The detection time will depend on watchdog timer and > can't be 30 seconds with all configurations > ok. > 5) Section 3.1.1.3: We can use the text in errata draft to specify the > peer behaviour when a DPR is received. > Since the errata is still a draft ... I'm not sure if most existing implementation already follows it. > 6) Section 3.1.1.2: > a) The two test cases can be combined to one > test case. > "Positive test for establishment of connection between > two peers, one having higher identity than the other. > Vendor A having a higher identity than vendor B. > Vendor A and vendor B initiate connection, verify that > vendor A initiated connected is closed at both the ends." > > b) One more test case can be added to verify the behaviour > of TLS in the election scenario. > "Positive test for establishment of connection with TLS between > two peers,with election scenario, as mentioned above. > vendor B will initiate TLS handshake on vendor B initiated > transport connection." > not sure what you mean. My understanding is TLS handshake is independent of election ... is there a specific need to integrate the test ? > 7) Section 3.1.1.3 para 3: > "Implementation should also attempt re-connection with lost peer before > resetting the connection." > Does RFC suggests such a behavior ? > We can remove that sentence. > 8) Section 3.1.1.5 bullet 4: > Need to specify that link3 is down. ok. > Also a mention that vendor B and > vendor D are advertising only relay application. > mmm... they don't have to be relays. what if other participants B and D wants to have a symmetric test similar to A and C. > 9) Section 3.1.2: > Need to specify vendor A2 and vendor B1 should be relays. > same as above. > 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": > A2 should be relay, otherwise A1 will not send the request to it, since > neither the dest host or the realm matches. Note that this message has > dest host avp. Hence A1 cannot do realm routing. > Also, B1 should also be a relay. > mmm... we have two(2) items here. 1. A2 does not necessarily need to be a relay. We can add either A2 and B1 are relay or has a realm route to B2. We need to give participants flexibility since they might want to test routing functionality that is interesting to them. Mandating one configuration over another may not be helpful. 2. Having a dest-host does not automatically preclude that your not going to do realm routing. > 11) Section 3.1.2.2: A2 and B1 should be relay in this case too. > Otherwise, > - the message is routed to them because they support the app. > - they will locally consume this message, because there is no dest host > avp. > Again, I advocate flexibility .... A2 and B1 can always have realms routes to B2 .... regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Dec 18 17:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwR8q-0006kx-TV; Mon, 18 Dec 2006 17:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwR8p-0006fa-Ji for dime@ietf.org; Mon, 18 Dec 2006 17:39:27 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwR8p-0000lr-3G for dime@ietf.org; Mon, 18 Dec 2006 17:39:27 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 17B832A711 for ; Mon, 18 Dec 2006 17:39:20 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBIMdECf020199 for ; Mon, 18 Dec 2006 17:39:19 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] trying to understand auditing problem Date: Mon, 18 Dec 2006 17:35:28 -0500 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: <33656995C5C5094A983DE84DA649A924CB5835@lulex02.ad.operax.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 Ulf, I agree with you on most of the issues with slight disagreement on applicability of certain mechanisms for different types of applications. IMHO a) The effect of application level timers and the role they play to prevent session leaking/failure handling should be documented. I think "Diameter Application Design Guidelines Document" which is an item in the charter is a good place for it. Basically what has been discussed in this thread would be useful material for anybody designing a new Diameter application. b) The audit document may provide a bit more information about other possible mechanisms to deal with the problems it tries to address. A few short paragraphs and a reference to the relevant section in the Application Design Guidelines document could be a good idea. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Monday, December 18, 2006 8:51 AM > To: dime@ietf.org > Subject: RE: [Dime] trying to understand auditing problem > > > Hi Tolga, > > Clearly it's quite easy to find examples in which Diameter clients and > their server can rely on soft-state to ensure that they after timer > expiration return to the same view on the set of sessions being active. > In my view soft-state without auditing is preferable over soft-state > with auditing for synchronization or hard-state in many cases for > several reasons. > > For example, for high-volume and short holding-time > applications/sessions it would be troublesome to audit high volumes of > states while serving new session requests in parallel. That is, auditing > will consume resources and take time. Consequently, many audited session > states are likely to have been terminated by the application before > being audited. Also, for applications that can accept periods of > client/server inconstency, soft-state without auditing for > synchronization is most likely the way to go. > > On the other hand, lower-volume and longer-holding time > applications/sessions auditing can allow for more precise services > offered by Dimeter server systems. Also, to some extent, auditing can > relax requirements on state replication at both clients and server. An > example of such a scenario is when an instance of RACS (Resource and > Admisison Control Subsystem as defined by ETSI TISPAN) is to handle > resource reservations for leased-line services. > > For simplicitly, say that only two leased-line service nodes and two > RACS nodes exist, one active and one backup node of each kind. The > active leased-line service Diameter client node establishes a session > with the active RACS Diameter server node. This corresponding session > state in RACS must not be lost for any reason (e.g. the contractual > agreement for the leased-line service makes it very costly to lose > resource reservation states for this service). Hence, to protect against > state loss or at least periods of state inconsistency, replication is > required at the client side, at the server side, or both. Through > auditing, states need not be replicated at both client and server and/or > replication can be asyncronous. > > In case of hard-state, I agree that states must be terminated in case > the backup instance can't be activated. In my view this fact does > however not transform the hard-state to a soft-state. For example, > failing to activate a hot-standby backup client or server should indeed > result in states being terminated either explicitly by a management > operation or automatically through a timeout. However, in case the > backup is activated successfully, auditing is useful to ensure > synchronisation without waiting for timer expiration. > > The problem of state synchronization may be possible to engineer around, > but it's my firm belief that that an auditing capability in Diameter > would be useful and allow for more attractive overall solutions compared > to such engineering approaches. Again, I don't believe auditing to the > best approach for all applications, but rather for particular > applications with specific needs (e.g. such as RACS resource > reservations for leased-lines). > > Best regards, > Ulf > > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 15 december 2006 21:04 > To: dime@ietf.org > Subject: RE: [Dime] trying to understand auditing problem > > Hi Ulf, > > Please see below for more comments/questions. > > Thanks, > Tolga > > [..snip..] > > Overall, hard-state approach seems a risky strategy to me, for example > > > what happens if client dies and there is no backup server? Will the > > sessions on the server stay there forever? IMHO, use of timers at both > > > client and server side makes life really easy. > > > > Ulf2: I assume you refer to a dead client without any backup client. > > Then, if a client dies the server certainly needs a strategy for how > > to handle hard states established by a confirmed dead client (i.e. if > > there is no backup client these states need to be terminated). If > > instead there is a backup client taking over a (short) while, it > > should be able to ensure that it's in sync with the server. > [TOLGA]Yes, sorry for the typo, the scenario was a dead client with no > backup client. I guess confirming (or better said believing with a very > high probability) that the client is dead will require a timer on server > side anyhow, transforming the scenario to a soft-state case. > > > > [..snip..] > > [TOLGA]If the clients are sending new requests periodically and if the > > > requests contain enough information for proper processing even if they > > > are sent to a cold standby this probably should work. If the sessions > > for the reqeusts are not known by the cold standby instance yet, this > > shouldn't be a problem. It just will create a new session and perform > > processing according to the contents of the received request. It seems > > > this item is again closely related whether a timer is running on the > > client side. > > > > Ulf2: Yes, with the addition that a trigger to resubmit requests is > > needed and an indication of that the resubmitted requests are for lost > > > session states and not for new sessions (i.e. the server may need to > > differentiate between these two types of session requests to provide > > its service properly). > [TOLGA]I guess with careful protocol design one can avoid the need to > indicate that resubmitted requests are for lost session states. For > example in DCCA, if a client dies, a backup instance takes over and > starts new sessions for the service instances it took over. I guess no > harm would be done even for session based scenario, except service > provider not being able to charge for the last service period at a > maximum, which really shouldn't be a big amount. Old sessions in the > server just will expire upon timer expiry. > > > > > > > > 3) AFAICS, the third issue is, how does a backup client knows, > > > which sessions were alive, what data was associated with them > > > etc..., so that it can continue to manage the service provided to > > > the customer. I > > > > > know the exact approach could be dependent on the service we are > > > talking about but I will use DCCA/prepaid call as an example: > > > > > > +---+ +--------+ > > > | | | | > > > | S |::::|DCCA | +--------+ > > > | e | |Client-1+----------+ | > > > | r | +--------+ | | > > > | v | | DCCA | > > > | i | | Server | > > > | c | +--------+ | | > > > | e | | +----------+ | > > > | |::::|DCCA | +--------+ > > > | L | |Client-2| > > > | o | +--------+ > > > | g | > > > | i | > > > | c | > > > +---+ > > > > > > Let's say there are 3 calls, which are using prepaid service. Credit > > > > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > > > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to > > > handle > > > Call-1 and Call-2 as well. > > > > > > The first thing Client-2 needs to do is to determine which calls > > > were handled by Client-1. I guess, this can be done in a > > > straightforward way via communication between Client-2 and Service > > > Logic component (assuming that this data is not synchronized between > > > > Client-1 and Client-2). Now, > > > Client-2 can start a new session for these calls and perform credit > > > control operation. The sessions on DCCA server, which were opened by > > > > requests from > > > client-1 will be cleaned up after Tcc expires. > > > > > > Ulf: If I understand this scenario correctly I believe it's similar > > > to > > > > > the second one. I.e. a trigger from Client 2 to the service logic > > > making it re-submit requests for active sessions and tag them as > > > re-establish requests rather than new requests would probably be > > enough. > > [TOLGA]On this item, I tried to evaluate the situation from client > > point of view (you are right, this is the same scenario as 2, this > > time from client perspective). Basically how Client-2 determines calls > > > which were served by > > Client-1 is really implementation dependent. It definetly can be done > > though, the calls (or any resource in that sense) is controlled by > > some service logic, which has the information about what is currently > > provided to the users. What Client-2 needs to do is just to create new > > > sessions for these service instances. "Old" sessions on the DCCA > > server will expire upon expiry of Tcc. > > Ulf2: Yes, I agree. For this scenario the service logic provides the > > trigger to Client 2 and since the server hasn't done a failover it > > should recognize the session ID of Call 1 and Call 2 as existing ones. > > If instead the server would have done a failover such indication would > > > IMHO be needed. > [TOLGA]Will there be any cases where Service Logic won't be controlling > the service resources? I guess the answer is negative because otherwise > Service Logic wouldn't be able to release resources allocated for a > specific user upon a negative answer from DCCA server. So, I assume > Service Logic can always provide a trigger for a backup client taking > over responsibilites of a failed one. > > I think it is possible that the server does not need to know anything > about whether the sessions are a replacement for existing sessions. Old > ones just will expire if a timer is utilized. Again it depends on the > design of the application layer protocol. Actually, in general IMHO > proper application layer protocol design is important to deal with > issues audit mechanism talks about and could provide a satisfactory > solution for most of the cases. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 19 01:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwY2A-0000z6-HD; Tue, 19 Dec 2006 01:01:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwY29-0000yt-EE for dime@ietf.org; Tue, 19 Dec 2006 01:01:01 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwY28-00007t-2X for dime@ietf.org; Tue, 19 Dec 2006 01:01:01 -0500 X-VirusChecked: Checked X-Env-Sender: in1236c@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1166508058!16821210!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 19809 invoked from network); 19 Dec 2006 06:00:58 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-15.tower-119.messagelabs.com with SMTP; 19 Dec 2006 06:00:58 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id kBJ60vuA013175 for ; Mon, 18 Dec 2006 23:00:57 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id kBJ60utH021882 for ; Tue, 19 Dec 2006 00:00:57 -0600 (CST) Received: from [10.232.35.38] ([10.232.35.38]) by ZMY16EXM67.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Tue, 19 Dec 2006 14:00:52 +0800 From: Satendra To: Victor Fajardo Content-Type: text/plain Date: Tue, 19 Dec 2006 11:26:36 +0530 Message-Id: <1166507796.10153.141.camel@A21224-01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2006 06:00:52.0485 (UTC) FILETIME=[0A344350:01C72333] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: dime@ietf.org Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Follow-up comments in line. Regards, Satendra -------- Original Message -------- From: Victor Fajardo To: Satendra Cc: john.loughney@nokia.com, Tschofenig, Hannes , dime@ietf.org, G Nadaf Liyaqatali-a21917 Subject: Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt Date: Mon, 18 Dec 2006 09:48:54 -0500 Hi Satendra, Thanks. Comments inline: > We went through your test case draft, following are our observations. > > 1) Application id in common messages: > As the doubts about application id value in common messages have been > clarified we can test for its compliance. Following text can be added to > section 4.1.1.1.1. bullet 3 & 4, section 4.3.1.5 bullet 3 ,4. > "Verify application id value in STR/STA message as that of the target > application." > > Note: We would like to have the same comment applied to section 4.7.1 > bullets 2 and 4. But looks like RFC 4004 explicitly states app id 0 for > STR/STA. > ok. > 2) Capabilities Negotiation for relay application: > Following test case can be added to section 3.1.1.1 > > o Positive test for establishment of connection with test pairs of which > one of them is advertising support for only relay app and no other app > is in common. > ok. > o Positive test for establishment of connection advertising the relay > app in auth app id, acct app id & VSA. > is'nt this already covered ? Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted. > o Negative test case for TLS handshake failure. The connection is > disconnected by both the peers. > Intentionally configure vendor A to send wrong certificate after > Inband-Security-AVP with value 1 (TLS). TLS handshake should fail. > this maybe covered as well. my current thought is try not to be very detailed in the test cases so the document won't be so large that it becomes cumbersome to follow. in the specific case you mentioned above, there are probably multiple ways of making TLS handshake fail so it maybe best to leave it up to the participants to simulate a failure that is most convinient for them. Especially since we only have a few days to test. Satendra>> Ok > Optional test cases: > > o Positive test for establishment of connection with inter and intra > domain peers advertising support for use of TLS (for inter-domain) and > IPSec (for intra-domain). Vendor A is an edge node which has peers > intra-domain and inter-domain. Vendor A advertises inband Security AVP > with TLS with the inter-domain peer (vendor B). Vendor A does not > advertise inband security avp with TLS with the intra-domain peer(vendor > C). Connection is established with both peers. > Maybe this is a very specific deployment test instead of a general test case ? Satendra>> If you feel that this is too specific we can leave the case out. > 3) Positive test case can be for v6 connectivity to section 3.1.1 > > 4) Section 3.1.1.3 para 1 "Determination must be made within 30 seconds > of the event." The detection time will depend on watchdog timer and > can't be 30 seconds with all configurations > ok. > 5) Section 3.1.1.3: We can use the text in errata draft to specify the > peer behaviour when a DPR is received. > Since the errata is still a draft ... I'm not sure if most existing implementation already follows it. Satendra>> I believe the text in the errata draft is just a clarification and the behavior can be tested. > 6) Section 3.1.1.2: > a) The two test cases can be combined to one > test case. > "Positive test for establishment of connection between > two peers, one having higher identity than the other. > Vendor A having a higher identity than vendor B. > Vendor A and vendor B initiate connection, verify that > vendor A initiated connected is closed at both the ends." > > b) One more test case can be added to verify the behaviour > of TLS in the election scenario. > "Positive test for establishment of connection with TLS between > two peers,with election scenario, as mentioned above. > vendor B will initiate TLS handshake on vendor B initiated > transport connection." > not sure what you mean. My understanding is TLS handshake is independent of election ... is there a specific need to integrate the test ? Satendra>> The intent was to test who initiates the hand shake, anyway this case can be left out. > 7) Section 3.1.1.3 para 3: > "Implementation should also attempt re-connection with lost peer before > resetting the connection." > Does RFC suggests such a behavior ? > We can remove that sentence. > 8) Section 3.1.1.5 bullet 4: > Need to specify that link3 is down. ok. > Also a mention that vendor B and > vendor D are advertising only relay application. > mmm... they don't have to be relays. what if other participants B and D wants to have a symmetric test similar to A and C. > 9) Section 3.1.2: > Need to specify vendor A2 and vendor B1 should be relays. > same as above. > 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": > A2 should be relay, otherwise A1 will not send the request to it, since > neither the dest host or the realm matches. Note that this message has > dest host avp. Hence A1 cannot do realm routing. > Also, B1 should also be a relay. > mmm... we have two(2) items here. 1. A2 does not necessarily need to be a relay. We can add either A2 and B1 are relay or has a realm route to B2. We need to give participants flexibility since they might want to test routing functionality that is interesting to them. Mandating one configuration over another may not be helpful. 2. Having a dest-host does not automatically preclude that your not going to do realm routing. Satendra>> Why should peer A1 send out message to A2 when destination is realm B , and A2 has not advertised itself as a relay ? Does it mean that originator will send out message to any connected peer ? > 11) Section 3.1.2.2: A2 and B1 should be relay in this case too. > Otherwise, > - the message is routed to them because they support the app. > - they will locally consume this message, because there is no dest host > avp. > Again, I advocate flexibility .... A2 and B1 can always have realms routes to B2 .... regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 19 05:03:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwboO-00055C-SK; Tue, 19 Dec 2006 05:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwboO-00054s-8K for dime@ietf.org; Tue, 19 Dec 2006 05:03:04 -0500 Received: from net-internal.operax.com ([213.50.74.197] helo=smtp.operax.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwboM-0006uT-Ab for dime@ietf.org; Tue, 19 Dec 2006 05:03:03 -0500 Received: (qmail 41588 invoked by uid 0); 19 Dec 2006 10:02:56 -0000 Received: from lulex02.ad.operax.com (192.168.2.13) by treo.operax.com with SMTP; 19 Dec 2006 10:02:56 -0000 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] trying to understand auditing problem Date: Tue, 19 Dec 2006 11:02:55 +0100 Message-ID: <33656995C5C5094A983DE84DA649A924CB593E@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] trying to understand auditing problem Thread-Index: Acci9XhD6Y+0ZX39SYq7rZyyMNI7xgAU+49Q From: "Ulf Bodin" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b 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,=20 I completely agree to documenting different alternatives to prevent session leaking and inconsistency related to resilience and failovers. My first understanding (from quickly reading the charter) was that the "Diameter Application Design Guidelines Document" is as defined in the charter not targeted to cover these kind of issues (more or less implicitly said though), but I do believe it should.=20 I also agree to having a few paragraphs on alternative approaches to auditing in the auditing requirements document with reference to the application design guide. Eventually, assuming we do a specification on Diameter auditing, the reference to the application design guide should be brought into that specification.=20 The approach I believe we should now follow is to make an .03 of the auditing requirements draft and a first version of an auditing solutions document (draft) based on the expired draft-calhoun-diameter-res-mgmt-08.txt. I would also be interested to be involved in putting together the application design guide document.=20 QUESTION (maybe to the chairs): what are the current plans to progress this applications design document for Diameter (i.e. beyond what's said in the charter). Best regards,=20 Ulf =20 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 18 december 2006 23:35 To: dime@ietf.org Subject: RE: [Dime] trying to understand auditing problem Hi Ulf, I agree with you on most of the issues with slight disagreement on applicability of certain mechanisms for different types of applications. IMHO a) The effect of application level timers and the role they play to prevent session leaking/failure handling should be documented. I think "Diameter Application Design Guidelines Document" which is an item in the charter is a good place for it. Basically what has been discussed in this thread would be useful material for anybody designing a new Diameter application. b) The audit document may provide a bit more information about other possible mechanisms to deal with the problems it tries to address. A few short paragraphs and a reference to the relevant section in the Application Design Guidelines document could be a good idea. Thanks, Tolga > -----Original Message----- > From: Ulf Bodin [mailto:Ulf.Bodin@operax.com] > Sent: Monday, December 18, 2006 8:51 AM > To: dime@ietf.org > Subject: RE: [Dime] trying to understand auditing problem > > > Hi Tolga, > > Clearly it's quite easy to find examples in which Diameter clients and > their server can rely on soft-state to ensure that they after timer=20 > expiration return to the same view on the set of sessions being active. > In my view soft-state without auditing is preferable over soft-state=20 > with auditing for synchronization or hard-state in many cases for=20 > several reasons. > > For example, for high-volume and short holding-time=20 > applications/sessions it would be troublesome to audit high volumes of > states while serving new session requests in parallel. That is,=20 > auditing will consume resources and take time. Consequently, many=20 > audited session states are likely to have been terminated by the=20 > application before being audited. Also, for applications that can=20 > accept periods of client/server inconstency, soft-state without=20 > auditing for synchronization is most likely the way to go. > > On the other hand, lower-volume and longer-holding time=20 > applications/sessions auditing can allow for more precise services=20 > offered by Dimeter server systems. Also, to some extent, auditing can=20 > relax requirements on state replication at both clients and server. An > example of such a scenario is when an instance of RACS (Resource and=20 > Admisison Control Subsystem as defined by ETSI TISPAN) is to handle=20 > resource reservations for leased-line services. > > For simplicitly, say that only two leased-line service nodes and two=20 > RACS nodes exist, one active and one backup node of each kind. The=20 > active leased-line service Diameter client node establishes a session=20 > with the active RACS Diameter server node. This corresponding session=20 > state in RACS must not be lost for any reason (e.g. the contractual=20 > agreement for the leased-line service makes it very costly to lose=20 > resource reservation states for this service). Hence, to protect=20 > against state loss or at least periods of state inconsistency,=20 > replication is required at the client side, at the server side, or=20 > both. Through auditing, states need not be replicated at both client=20 > and server and/or replication can be asyncronous. > > In case of hard-state, I agree that states must be terminated in case=20 > the backup instance can't be activated. In my view this fact does=20 > however not transform the hard-state to a soft-state. For example,=20 > failing to activate a hot-standby backup client or server should=20 > indeed result in states being terminated either explicitly by a=20 > management operation or automatically through a timeout. However, in=20 > case the backup is activated successfully, auditing is useful to=20 > ensure synchronisation without waiting for timer expiration. > > The problem of state synchronization may be possible to engineer=20 > around, but it's my firm belief that that an auditing capability in=20 > Diameter would be useful and allow for more attractive overall=20 > solutions compared to such engineering approaches. Again, I don't=20 > believe auditing to the best approach for all applications, but rather > for particular applications with specific needs (e.g. such as RACS=20 > resource reservations for leased-lines). > > Best regards, > Ulf > > > > -----Original Message----- > From: Tolga Asveren [mailto:asveren@ulticom.com] > Sent: den 15 december 2006 21:04 > To: dime@ietf.org > Subject: RE: [Dime] trying to understand auditing problem > > Hi Ulf, > > Please see below for more comments/questions. > > Thanks, > Tolga > > [..snip..] > > Overall, hard-state approach seems a risky strategy to me, for=20 > > example > > > what happens if client dies and there is no backup server? Will the=20 > > sessions on the server stay there forever? IMHO, use of timers at=20 > > both > > > client and server side makes life really easy. > > > > Ulf2: I assume you refer to a dead client without any backup client. > > Then, if a client dies the server certainly needs a strategy for how > > to handle hard states established by a confirmed dead client (i.e.=20 > > if there is no backup client these states need to be terminated). If > > instead there is a backup client taking over a (short) while, it=20 > > should be able to ensure that it's in sync with the server. > [TOLGA]Yes, sorry for the typo, the scenario was a dead client with no > backup client. I guess confirming (or better said believing with a=20 > very high probability) that the client is dead will require a timer on > server side anyhow, transforming the scenario to a soft-state case. > > > > [..snip..] > > [TOLGA]If the clients are sending new requests periodically and if=20 > > the > > > requests contain enough information for proper processing even if=20 > > they > > > are sent to a cold standby this probably should work. If the=20 > > sessions for the reqeusts are not known by the cold standby instance > > yet, this shouldn't be a problem. It just will create a new session=20 > > and perform processing according to the contents of the received=20 > > request. It seems > > > this item is again closely related whether a timer is running on the > > client side. > > > > Ulf2: Yes, with the addition that a trigger to resubmit requests is=20 > > needed and an indication of that the resubmitted requests are for=20 > > lost > > > session states and not for new sessions (i.e. the server may need to > > differentiate between these two types of session requests to provide > > its service properly). > [TOLGA]I guess with careful protocol design one can avoid the need to=20 > indicate that resubmitted requests are for lost session states. For=20 > example in DCCA, if a client dies, a backup instance takes over and=20 > starts new sessions for the service instances it took over. I guess no > harm would be done even for session based scenario, except service=20 > provider not being able to charge for the last service period at a=20 > maximum, which really shouldn't be a big amount. Old sessions in the=20 > server just will expire upon timer expiry. > > > > > > > > 3) AFAICS, the third issue is, how does a backup client knows,=20 > > > which sessions were alive, what data was associated with them=20 > > > etc..., so that it can continue to manage the service provided to=20 > > > the customer. I > > > > > know the exact approach could be dependent on the service we are=20 > > > talking about but I will use DCCA/prepaid call as an example: > > > > > > +---+ +--------+ > > > | | | | > > > | S |::::|DCCA | +--------+ > > > | e | |Client-1+----------+ | > > > | r | +--------+ | | > > > | v | | DCCA | > > > | i | | Server | > > > | c | +--------+ | | > > > | e | | +----------+ | > > > | |::::|DCCA | +--------+ > > > | L | |Client-2| > > > | o | +--------+ > > > | g | > > > | i | > > > | c | > > > +---+ > > > > > > Let's say there are 3 calls, which are using prepaid service.=20 > > > Credit > > > > control for Call-1 and Call-2 are handled by DCCA Client-1 and for > > > Call-3 by DCCA Client-2. Now, Client1-fails, Client-2 needs to=20 > > > handle > > > Call-1 and Call-2 as well. > > > > > > The first thing Client-2 needs to do is to determine which calls=20 > > > were handled by Client-1. I guess, this can be done in a=20 > > > straightforward way via communication between Client-2 and Service > > > Logic component (assuming that this data is not synchronized=20 > > > between > > > > Client-1 and Client-2). Now, > > > Client-2 can start a new session for these calls and perform=20 > > > credit control operation. The sessions on DCCA server, which were=20 > > > opened by > > > > requests from > > > client-1 will be cleaned up after Tcc expires. > > > > > > Ulf: If I understand this scenario correctly I believe it's=20 > > > similar to > > > > > the second one. I.e. a trigger from Client 2 to the service logic=20 > > > making it re-submit requests for active sessions and tag them as=20 > > > re-establish requests rather than new requests would probably be > > enough. > > [TOLGA]On this item, I tried to evaluate the situation from client=20 > > point of view (you are right, this is the same scenario as 2, this=20 > > time from client perspective). Basically how Client-2 determines=20 > > calls > > > which were served by > > Client-1 is really implementation dependent. It definetly can be=20 > > done though, the calls (or any resource in that sense) is controlled > > by some service logic, which has the information about what is=20 > > currently provided to the users. What Client-2 needs to do is just=20 > > to create new > > > sessions for these service instances. "Old" sessions on the DCCA=20 > > server will expire upon expiry of Tcc. > > Ulf2: Yes, I agree. For this scenario the service logic provides the > > trigger to Client 2 and since the server hasn't done a failover it=20 > > should recognize the session ID of Call 1 and Call 2 as existing ones. > > If instead the server would have done a failover such indication=20 > > would > > > IMHO be needed. > [TOLGA]Will there be any cases where Service Logic won't be=20 > controlling the service resources? I guess the answer is negative=20 > because otherwise Service Logic wouldn't be able to release resources > allocated for a specific user upon a negative answer from DCCA server. > So, I assume Service Logic can always provide a trigger for a backup=20 > client taking over responsibilites of a failed one. > > I think it is possible that the server does not need to know anything=20 > about whether the sessions are a replacement for existing sessions.=20 > Old ones just will expire if a timer is utilized. Again it depends on=20 > the design of the application layer protocol. Actually, in general=20 > IMHO proper application layer protocol design is important to deal=20 > with issues audit mechanism talks about and could provide a=20 > satisfactory solution for most of the cases. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 19 10:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwh8S-00012k-5I; Tue, 19 Dec 2006 10:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwh8Q-00012V-Pd for dime@ietf.org; Tue, 19 Dec 2006 10:44:06 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwh8N-00029O-CA for dime@ietf.org; Tue, 19 Dec 2006 10:44:06 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBJFhBDD084583; Tue, 19 Dec 2006 10:43:15 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45880891.2040205@tari.toshiba.com> Date: Tue, 19 Dec 2006 10:43:13 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Satendra References: <1166507796.10153.141.camel@A21224-01> In-Reply-To: <1166507796.10153.141.camel@A21224-01> 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 Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Satendra, Comments inline: >> o Positive test for establishment of connection advertising the relay >> app in auth app id, acct app id & VSA. >> >> > > is'nt this already covered ? > > Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted. > ok. > >> 5) Section 3.1.1.3: We can use the text in errata draft to specify the >> peer behaviour when a DPR is received. >> >> > > Since the errata is still a draft ... I'm not sure if most existing > implementation already follows it. > > Satendra>> I believe the text in the errata draft is just a clarification > and the behavior can be tested. > ... in this specific case, it may not be just a clarification since it pertains to re-connection behavior. since it's still a draft we may want to be careful on what we mandate. > >> 6) Section 3.1.1.2: >> a) The two test cases can be combined to one >> test case. >> "Positive test for establishment of connection between >> two peers, one having higher identity than the other. >> Vendor A having a higher identity than vendor B. >> Vendor A and vendor B initiate connection, verify that >> vendor A initiated connected is closed at both the ends." >> >> b) One more test case can be added to verify the behaviour >> of TLS in the election scenario. >> "Positive test for establishment of connection with TLS between >> two peers,with election scenario, as mentioned above. >> vendor B will initiate TLS handshake on vendor B initiated >> transport connection." >> >> > > not sure what you mean. My understanding is TLS handshake is independent > of election ... is there a specific need to integrate the test ? > > Satendra>> The intent was to test who initiates the hand shake, anyway > this case can be left out. > I was thinking that instead of tying it to election, we can simply revive your original proposal on capabilities negotiation but in a more general tone. i.e. add: "Negative test case for TLS handshake failure. In the case where the negotiated Inband-Security involves subsequent TLS negotiation, participants can simulate a TLS handshake failure (i.e. via invalid certificates, TLS/SSL version mis-match etc) that must result in the peers being disconnected." what do you think ? > >> 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": >> A2 should be relay, otherwise A1 will not send the request to it, since >> neither the dest host or the realm matches. Note that this message has >> dest host avp. Hence A1 cannot do realm routing. >> Also, B1 should also be a relay. >> >> > > mmm... we have two(2) items here. > > 1. A2 does not necessarily need to be a relay. We can add either A2 and > B1 are relay or has a realm route to B2. We need to give participants > flexibility since they might want to test routing functionality that is > interesting to them. Mandating one configuration over another may not be > helpful. > 2. Having a dest-host does not automatically preclude that your not > going to do realm routing. > > Satendra>> Why should peer A1 send out message to A2 when destination is realm B , > and A2 has not advertised itself as a relay ? > Because A2 can advertise that it supports the same application as B2 and has a realm route to B2 ... example is a proxy. We can add a sentence to that effect if it clarifies this. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 20 09:12:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Aw-0004ar-Fn; Wed, 20 Dec 2006 09:12:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Av-0004VQ-3e for dime@ietf.org; Wed, 20 Dec 2006 09:12:05 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gx2At-0006rS-QN for dime@ietf.org; Wed, 20 Dec 2006 09:12:05 -0500 X-VirusChecked: Checked X-Env-Sender: in1236c@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1166621731!13930788!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16043 invoked from network); 20 Dec 2006 13:35:31 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 20 Dec 2006 13:35:31 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kBKDZURO000693 for ; Wed, 20 Dec 2006 06:35:30 -0700 (MST) Received: from ZMY16EXM67.ds.mot.com (zmy16exm67.ap.mot.com [10.179.4.27]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kBKDZS0C010809 for ; Wed, 20 Dec 2006 07:35:29 -0600 (CST) Received: from [10.232.35.38] ([10.232.35.38]) by ZMY16EXM67.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 20 Dec 2006 21:35:27 +0800 From: Satendra To: Victor Fajardo Content-Type: text/plain Date: Wed, 20 Dec 2006 19:01:08 +0530 Message-Id: <1166621468.10153.165.camel@A21224-01> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 13:35:27.0563 (UTC) FILETIME=[B5D4A1B0:01C7243B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: dime@ietf.org Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, 1) "Because A2 can advertise that it supports the same application as B2 and has a realm route to B2 ... example is a proxy. We can add a sentence to that effect if it clarifies this." A1 from the advertisement can just find out that A2 supports the said application but can't figure out that A2 is a proxy. Does this mean that A1 should sent out the message to any peer supporting that application hoping that it is a proxy ? 2) I am ok with the idea adding a negative test case for TLS. Regards, Satendra -------- Original Message -------- From: Victor Fajardo To: Satendra Cc: dime@ietf.org, G Nadaf Liyaqatali-a21917 Subject: Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt Date: Tue, 19 Dec 2006 10:43:13 -0500 Hi Satendra, Comments inline: >> o Positive test for establishment of connection advertising the relay >> app in auth app id, acct app id & VSA. >> >> > > is'nt this already covered ? > > Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted. > ok. > >> 5) Section 3.1.1.3: We can use the text in errata draft to specify the >> peer behaviour when a DPR is received. >> >> > > Since the errata is still a draft ... I'm not sure if most existing > implementation already follows it. > > Satendra>> I believe the text in the errata draft is just a clarification > and the behavior can be tested. > ... in this specific case, it may not be just a clarification since it pertains to re-connection behavior. since it's still a draft we may want to be careful on what we mandate. > >> 6) Section 3.1.1.2: >> a) The two test cases can be combined to one >> test case. >> "Positive test for establishment of connection between >> two peers, one having higher identity than the other. >> Vendor A having a higher identity than vendor B. >> Vendor A and vendor B initiate connection, verify that >> vendor A initiated connected is closed at both the ends." >> >> b) One more test case can be added to verify the behaviour >> of TLS in the election scenario. >> "Positive test for establishment of connection with TLS between >> two peers,with election scenario, as mentioned above. >> vendor B will initiate TLS handshake on vendor B initiated >> transport connection." >> >> > > not sure what you mean. My understanding is TLS handshake is independent > of election ... is there a specific need to integrate the test ? > > Satendra>> The intent was to test who initiates the hand shake, anyway > this case can be left out. > I was thinking that instead of tying it to election, we can simply revive your original proposal on capabilities negotiation but in a more general tone. i.e. add: "Negative test case for TLS handshake failure. In the case where the negotiated Inband-Security involves subsequent TLS negotiation, participants can simulate a TLS handshake failure (i.e. via invalid certificates, TLS/SSL version mis-match etc) that must result in the peers being disconnected." what do you think ? > >> 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": >> A2 should be relay, otherwise A1 will not send the request to it, since >> neither the dest host or the realm matches. Note that this message has >> dest host avp. Hence A1 cannot do realm routing. >> Also, B1 should also be a relay. >> >> > > mmm... we have two(2) items here. > > 1. A2 does not necessarily need to be a relay. We can add either A2 and > B1 are relay or has a realm route to B2. We need to give participants > flexibility since they might want to test routing functionality that is > interesting to them. Mandating one configuration over another may not be > helpful. > 2. Having a dest-host does not automatically preclude that your not > going to do realm routing. > > Satendra>> Why should peer A1 send out message to A2 when destination is realm B , > and A2 has not advertised itself as a relay ? > Because A2 can advertise that it supports the same application as B2 and has a realm route to B2 ... example is a proxy. We can add a sentence to that effect if it clarifies this. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 20 09:37:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2ZF-0001AQ-AG; Wed, 20 Dec 2006 09:37:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2ZE-00018r-Pa for dime@ietf.org; Wed, 20 Dec 2006 09:37:12 -0500 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gx2ZD-00084a-Bv for dime@ietf.org; Wed, 20 Dec 2006 09:37:12 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBKEVsnt089226; Wed, 20 Dec 2006 09:31:54 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4589495B.6070206@tari.toshiba.com> Date: Wed, 20 Dec 2006 09:31:55 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Satendra References: <1166621468.10153.165.camel@A21224-01> In-Reply-To: <1166621468.10153.165.camel@A21224-01> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: dime@ietf.org Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Satendra, > Hi Victor, > > 1) "Because A2 can advertise that it supports the same application as B2 > and has a realm route to B2 ... example is a proxy. We can add a > sentence to that effect if it clarifies this." > > A1 from the advertisement can just find out that A2 supports the said > application but can't figure out that A2 is a proxy. Does this mean that > A1 should sent out the message to any peer supporting that application > hoping that it is a proxy ? > A1 does'nt care whether A2 is a proxy or not but obviously the originator of the message (A1) should have a realm route to realm B via A2 :) ... otherwise realm routing would not work even if A2 was advertising itself as a relay. > 2) I am ok with the idea adding a negative test case for TLS. > ok regards, victor > Regards, > Satendra > > -------- Original Message -------- > From: Victor Fajardo > To: Satendra > Cc: dime@ietf.org, G Nadaf Liyaqatali-a21917 > Subject: Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt > Date: Tue, 19 Dec 2006 10:43:13 -0500 > > Hi Satendra, > > Comments inline: > > >>> o Positive test for establishment of connection advertising the relay >>> app in auth app id, acct app id & VSA. >>> >>> >>> >> is'nt this already covered ? >> >> Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted. >> >> > > ok. > > >> >> >>> 5) Section 3.1.1.3: We can use the text in errata draft to specify the >>> peer behaviour when a DPR is received. >>> >>> >>> >> Since the errata is still a draft ... I'm not sure if most existing >> implementation already follows it. >> >> Satendra>> I believe the text in the errata draft is just a clarification >> and the behavior can be tested. >> >> > > ... in this specific case, it may not be just a clarification since it > pertains to re-connection behavior. since it's still a draft we may want > to be careful on what we mandate. > > >> >> >>> 6) Section 3.1.1.2: >>> a) The two test cases can be combined to one >>> test case. >>> "Positive test for establishment of connection between >>> two peers, one having higher identity than the other. >>> Vendor A having a higher identity than vendor B. >>> Vendor A and vendor B initiate connection, verify that >>> vendor A initiated connected is closed at both the ends." >>> >>> b) One more test case can be added to verify the behaviour >>> of TLS in the election scenario. >>> "Positive test for establishment of connection with TLS between >>> two peers,with election scenario, as mentioned above. >>> vendor B will initiate TLS handshake on vendor B initiated >>> transport connection." >>> >>> >>> >> not sure what you mean. My understanding is TLS handshake is independent >> of election ... is there a specific need to integrate the test ? >> >> Satendra>> The intent was to test who initiates the hand shake, anyway >> this case can be left out. >> >> > > I was thinking that instead of tying it to election, we can simply > revive your original proposal on capabilities negotiation but in a more > general tone. i.e. add: > > "Negative test case for TLS handshake failure. In the case where the > negotiated Inband-Security involves subsequent TLS negotiation, participants > can simulate a TLS handshake failure (i.e. via invalid certificates, > TLS/SSL > version mis-match etc) that must result in the peers being disconnected." > > what do you think ? > > >> >> >>> 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": >>> A2 should be relay, otherwise A1 will not send the request to it, since >>> neither the dest host or the realm matches. Note that this message has >>> dest host avp. Hence A1 cannot do realm routing. >>> Also, B1 should also be a relay. >>> >>> >>> >> mmm... we have two(2) items here. >> >> 1. A2 does not necessarily need to be a relay. We can add either A2 and >> B1 are relay or has a realm route to B2. We need to give participants >> flexibility since they might want to test routing functionality that is >> interesting to them. Mandating one configuration over another may not be >> helpful. >> 2. Having a dest-host does not automatically preclude that your not >> going to do realm routing. >> >> Satendra>> Why should peer A1 send out message to A2 when destination is realm B , >> and A2 has not advertised itself as a relay ? >> >> > > Because A2 can advertise that it supports the same application as B2 and > has a realm route to B2 ... example is a proxy. We can add a sentence to > that effect if it clarifies this. > > regards, > victor > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 20 18:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAuA-0000yz-Sa; Wed, 20 Dec 2006 18:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAsc-0008Uc-EM for dime@ietf.org; Wed, 20 Dec 2006 18:29:46 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAp1-000651-93 for dime@ietf.org; Wed, 20 Dec 2006 18:26:06 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAL0075XGFE7Y@usaga01-in.huawei.com> for dime@ietf.org; Wed, 20 Dec 2006 14:42:51 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAL00KYDGFEYR@usaga01-in.huawei.com> for dime@ietf.org; Wed, 20 Dec 2006 14:42:50 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JAL00889GWIYU@usaml03-in.huawei.com> for dime@ietf.org; Wed, 20 Dec 2006 14:53:10 -0800 (PST) Date: Wed, 20 Dec 2006 14:42:47 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <5e2406980612110511x67d58099k277d8ffe07e1d949@mail.gmail.com> To: 'Julien Bournelle' Message-id: <000101c72488$2caf32e0$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccdJdZRwzV0hhYkRtmqMKEItNpqUwHYfrKg 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 Hi Julien, A compromised HA will of course contact AAA-MIP6 to steal service or Denial of service attacks. I am not sure what kind of proof you are providing? Otherwise why would we care about HA compromise?:) Madjid > > Things > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > Is this really a problem if the authorization server trust the HA ? > > Madjid>>well, define trust? > Just because HA as a AAA client shares a key > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. sure. > The AAA_EAP may authenticate somebody, while HA tries to get authorization > for somebody else! So basically the HA can help the MN steal service. The assumption that the HA could be compromised is the reason why we are talking about this. One question is if this assumption doesn't bring concerns more important. As an example, if the HA is compromised, why should it contact the AAA_MIP6 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 21 03:38:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxJR8-0003ku-A8; Thu, 21 Dec 2006 03:37:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxJR6-0003kK-PK for dime@ietf.org; Thu, 21 Dec 2006 03:37:56 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxJR5-0003qV-FQ for dime@ietf.org; Thu, 21 Dec 2006 03:37:56 -0500 Received: by nf-out-0910.google.com with SMTP id l36so681418nfa for ; Thu, 21 Dec 2006 00:37:54 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=BOc8920TR6k8GloYEXJv7kXQuZ0M3hFPZsAXOpTzyzFbB38PPqr+s6opBfx4sKZwu90cAD6aLlvsZ8W6nSp1QhEub3XM5myGTY09f3EBLupXdgLrZrrs3XLw964MZSPXI/udlAeOy/rBk9Yl1x3i96wYFjJ+obSMEYEwFkicuv0= Received: by 10.49.41.12 with SMTP id t12mr10346240nfj.1166690274640; Thu, 21 Dec 2006 00:37:54 -0800 (PST) Received: by 10.48.213.18 with HTTP; Thu, 21 Dec 2006 00:37:54 -0800 (PST) Message-ID: <5e2406980612210037i113fb36n14ce8c000bfdfb79@mail.gmail.com> Date: Thu, 21 Dec 2006 09:37:54 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-Reply-To: <000101c72488$2caf32e0$02fda8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980612110511x67d58099k277d8ffe07e1d949@mail.gmail.com> <000101c72488$2caf32e0$02fda8c0@china.huawei.com> 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 madjid, On 12/20/06, Madjid Nakhjiri wrote: > > Hi Julien, > > > A compromised HA will of course contact AAA-MIP6 to steal service or Denial > of service attacks. I am not sure what kind of proof you are providing? If you can compromise the HA to steal the service, why would you contact the AAA-MIP6 to get an authorization ? Julien > Otherwise why would we care about HA compromise?:) > > Madjid > > > > > > Things > > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > > > Is this really a problem if the authorization server trust the HA ? > > > > Madjid>>well, define trust? > > Just because HA as a AAA client shares a key > > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. > > sure. > > > The AAA_EAP may authenticate somebody, while HA tries to get authorization > > for somebody else! So basically the HA can help the MN steal service. > > The assumption that the HA could be compromised is the reason why we > are talking about this. One question is if this assumption doesn't > bring concerns more important. > > As an example, if the HA is compromised, why should it contact the AAA_MIP6 > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 21 08:45:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOEN-00037w-5m; Thu, 21 Dec 2006 08:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxOEM-00037l-7d for dime@ietf.org; Thu, 21 Dec 2006 08:45:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxOEJ-0001gS-RJ for dime@ietf.org; Thu, 21 Dec 2006 08:45:06 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 21 Dec 2006 05:45:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kBLDj30B002206 for ; Thu, 21 Dec 2006 05:45:03 -0800 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 kBLDj3A6001434 for ; Thu, 21 Dec 2006 05:45:03 -0800 (PST) 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.1830); Thu, 21 Dec 2006 05:45:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Dec 2006 05:38:48 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250325CA6E@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Acct-Application-Id value for NASREQ Thread-Index: AcclBVgdmGIsZ9vpRQuEdQAn6VOhmg== From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 21 Dec 2006 13:45:03.0067 (UTC) FILETIME=[374552B0:01C72506] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2704; t=1166708703; x=1167572703; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20Acct-Application-Id=20value=20for=20NASREQ |Sender:=20; bh=dYzw+RbOju6EUfLU5ajjqb+DK5GRpi0orEaWYZfu1Sg=; b=Z03v1b1ey8pexiX4r8+JoAYuyWDAs68sO7+vutYOwO2JL04BYU7xyo1uDCofuaoRYGjk6K5H 1Q32bc5nYQE+AGOpl8tWT0Xs15tK5RuLd+CLF+kfLjwo+arjt0YroLkJ; Authentication-Results: sj-dkim-7; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "Glen Zorn \(gwz\)" Subject: [Dime] Acct-Application-Id value for NASREQ 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="===============1338365200==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1338365200== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72505.59F8290A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72505.59F8290A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just noticed that RFC 4005 doesn't appear to actually specify the value of Acct-Application-Id for NASREQ accounting messages; I suspect that what is intended is that the value be '3' for Diameter base accounting. This seems to me to be problematic for a couple of reasons * it makes it difficult to determine what application actually generated the accounting record (assuming that two or more applications use unmodified base accounting on the same server) * It seems to make it impossible to separate accounting servers by application (again assuming that two or more applications use base accounting w/o modification) because all those servers would advertise the same accounting application. It does seem possible to separate generic accounting servers from others by advertising just base accounting and no other applications, but that doesn't seem quite good enough. Comments? ------_=_NextPart_001_01C72505.59F8290A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acct-Application-Id value for NASREQ

Just noticed that RFC 4005 doesn't = appear to actually specify the value of Acct-Application-Id for NASREQ = accounting messages; I suspect that what is intended is that the value = be '3' for Diameter base accounting.  This seems to me to be = problematic for a couple of reasons

  • it makes it difficult to determine = what application actually generated the accounting record (assuming that = two or more applications use unmodified base accounting on the same = server)
  • It seems to make it impossible to = separate accounting servers by application (again assuming that two or = more applications use base accounting w/o modification) because all = those servers would advertise the same accounting = application.

It does seem possible to separate = generic accounting servers from others by advertising just base = accounting and no other applications, but that doesn't seem quite good = enough.  Comments?

------_=_NextPart_001_01C72505.59F8290A-- --===============1338365200== 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 --===============1338365200==-- From dime-bounces@ietf.org Thu Dec 21 17:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWem-0000cq-4m; Thu, 21 Dec 2006 17:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxWek-0000ah-Qd for dime@ietf.org; Thu, 21 Dec 2006 17:44:54 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxWej-000458-J5 for dime@ietf.org; Thu, 21 Dec 2006 17:44:54 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 369E4AA7A7 for ; Thu, 21 Dec 2006 17:44:47 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBLMikZp022507 for ; Thu, 21 Dec 2006 17:44:46 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Acct-Application-Id value for NASREQ Date: Thu, 21 Dec 2006 17:41:39 -0500 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: <4C0FAAC489C8B74F96BEAD85EAEB26250325CA6E@xmb-sjc-215.amer.cisco.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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, Based on my understanding of the "Which App-Id to use in the message header for base protocol messages" discussion in the last IETF, I would say that to use the application identifier for NASREQ, i.e. "1", for all messages exchanged for a NASREQ session makes sense. I guess there was already consensus to follow that approach for base protocol messages like STR, ASR. IMHO, extending that strategy to other messages could be useful to guarantee successful routing of these messages in all types of configurations and also to prevent confusions you listed. BTW, if one reads RFC4005 literally, one can interpret it in a way where use of app_id=0 is indicated for ACR and ACA as well based on the following passage: 1.3 Advertising Application Support .... All other messages are defined by [BASE] and use the Base application id value. ACR/ACA belongs to other messages and base application id value is 0. Nonetheless, I guess the real intention was to use App-Id=3 for ACR/ACA like you stated. Thanks, Tolga -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: Thursday, December 21, 2006 8:39 AM To: dime@ietf.org Cc: Glen Zorn (gwz) Subject: [Dime] Acct-Application-Id value for NASREQ Just noticed that RFC 4005 doesn't appear to actually specify the value of Acct-Application-Id for NASREQ accounting messages; I suspect that what is intended is that the value be '3' for Diameter base accounting. This seems to me to be problematic for a couple of reasons it makes it difficult to determine what application actually generated the accounting record (assuming that two or more applications use unmodified base accounting on the same server) It seems to make it impossible to separate accounting servers by application (again assuming that two or more applications use base accounting w/o modification) because all those servers would advertise the same accounting application. It does seem possible to separate generic accounting servers from others by advertising just base accounting and no other applications, but that doesn't seem quite good enough. Comments? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 21 18:23:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxXG8-0003HA-2c; Thu, 21 Dec 2006 18:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxXG6-0003G6-87 for dime@ietf.org; Thu, 21 Dec 2006 18:23:30 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxXBH-0002Mo-2g for dime@ietf.org; Thu, 21 Dec 2006 18:18:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBLNIM905333; Thu, 21 Dec 2006 18:18:22 -0500 (EST) Received: from [47.130.25.121] ([47.130.25.121] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 18:18:37 -0500 Message-ID: <458B162C.5030702@nortel.com> Date: Thu, 21 Dec 2006 18:18:04 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Acct-Application-Id value for NASREQ References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Dec 2006 23:18:37.0515 (UTC) FILETIME=[57E159B0:01C72556] X-Spam-Score: 0.0 (/) 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 Am I right in thinking that you always use the base application Id "0" for CER/CEA? I'm thinking that before these messages are exchanged there is no basis for routing on application. Tolga Asveren wrote: > Glen, > > Based on my understanding of the "Which App-Id to use in the message header > for base protocol messages" discussion in the last IETF, I would say that to > use the application identifier for NASREQ, i.e. "1", for all messages > exchanged for a NASREQ session makes sense. > > I guess there was already consensus to follow that approach for base > protocol messages like STR, ASR. IMHO, extending that strategy to other > messages could be useful to guarantee successful routing of these messages > in all types of configurations and also to prevent confusions you listed. > > BTW, if one reads RFC4005 literally, one can interpret it in a way where use > of app_id=0 is indicated for ACR and ACA as well based on the following > passage: > 1.3 Advertising Application Support > .... > All other messages are defined by [BASE] and > use the Base application id value. > > ACR/ACA belongs to other messages and base application id value is 0. > Nonetheless, I guess the real intention was to use App-Id=3 for ACR/ACA like > you stated. > > Thanks, > Tolga > > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Thursday, December 21, 2006 8:39 AM > To: dime@ietf.org > Cc: Glen Zorn (gwz) > Subject: [Dime] Acct-Application-Id value for NASREQ > > > Just noticed that RFC 4005 doesn't appear to actually specify the value of > Acct-Application-Id for NASREQ accounting messages; I suspect that what is > intended is that the value be '3' for Diameter base accounting. This seems > to me to be problematic for a couple of reasons > it makes it difficult to determine what application actually generated the > accounting record (assuming that two or more applications use unmodified > base accounting on the same server) > It seems to make it impossible to separate accounting servers by application > (again assuming that two or more applications use base accounting w/o > modification) because all those servers would advertise the same accounting > application. > > It does seem possible to separate generic accounting servers from others by > advertising just base accounting and no other applications, but that doesn't > seem quite good enough. Comments? > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 21 23:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxc6B-0001nP-Aq; Thu, 21 Dec 2006 23:33:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxc6A-0001nK-Gw for dime@ietf.org; Thu, 21 Dec 2006 23:33:34 -0500 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxc69-0002qq-19 for dime@ietf.org; Thu, 21 Dec 2006 23:33:34 -0500 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Dec 2006 10:03:31 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Dec 2006 10:03:31 +0530 Message-ID: <434F1CE611459F45BBC351FEB5A83F4302C84920@kavithai.ctd.hcltech.com> Content-Transfer-Encoding: quoted-printable From: "Balamurugan T - TLS, Chennai." To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Fri, 22 Dec 2006 10:03:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Dec 2006 04:33:31.0154 (UTC) FILETIME=[555DDF20:01C72582] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Dime] Query regarding Diameter agents 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 Guys, I need a claification regarding diameter agent. IMS architecture = has comonents like AS,HSS,S-CSCF ,I-CSCF and P-CSCF. In IMS components the S-CSCF or P-CSCF can use the diameter clients = for their communication. What is the purpose of diamter=20 agents in IMS architecture and Which are components that act as diameter agents? Thanks in Advance. Thanks, Bala DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 22 03:17:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxfb7-0006UA-Hm; Fri, 22 Dec 2006 03:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxfb6-0006U0-06 for dime@ietf.org; Fri, 22 Dec 2006 03:17:44 -0500 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxfb4-0006tN-ES for dime@ietf.org; Fri, 22 Dec 2006 03:17:43 -0500 Content-Class: urn:content-classes:message X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Dec 2006 13:47:40 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Dec 2006 13:47:40 +0530 Message-ID: <434F1CE611459F45BBC351FEB5A83F4302C84F7F@kavithai.ctd.hcltech.com> From: "Balamurugan T - TLS, Chennai." Content-Transfer-Encoding: quoted-printable To: Date: Fri, 22 Dec 2006 13:47:34 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Dec 2006 08:17:40.0117 (UTC) FILETIME=[A592C450:01C725A1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Dime] Clarification needs on transaction state 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 folks , 1.Section 3.(End-to-End Identifier ) in RFC says "Duplicate requests SHOULD cause the same answer to be transmitted (modulo the hop-by-hop Identifier field and any routing AVPs that may be present), and MUST NOT affect any state that was set when the original request was processed. = The identifier MUST remain locally unique for a period of at least 4 = minutes, even across reboots." a. For what purpose, we have to keep the same value after reboots = also.? 2. According to RFC,only the outgoing requests should be stored in = the pending queue . The request has to be removed from the queue on arrival = of corresponding answer message.=20 a. Is it necessary to maintain the list of incoming requests in the transaction level?. b. If so, How long we need to maintain them?.=20 "If the incoming requests are not available in transaction state, = How to identify duplicate requests?" .It could be helpful if any of you explain the transaction state maintenance. Thanks in advance, Bala DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 22 03:41:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxfxb-0003Aa-Ik; Fri, 22 Dec 2006 03:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxfxa-0003AR-17 for dime@ietf.org; Fri, 22 Dec 2006 03:40:58 -0500 Received: from mailtest.keycab.com ([193.111.46.30]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GxfxY-0001sU-BI for dime@ietf.org; Fri, 22 Dec 2006 03:40:58 -0500 Received: (qmail 58609 invoked from network); 22 Dec 2006 08:37:51 -0000 Received: from unknown (HELO D25L042J) (10.1.25.60) by 0 with SMTP; 22 Dec 2006 08:37:50 -0000 From: "Marco Carusio" To: "'Balamurugan T - TLS, Chennai.'" , , Subject: R: [Dime] Query regarding Diameter agents Date: Fri, 22 Dec 2006 09:40:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcclgoPEqSAAz/M6RPOmXp/PiemBGgAIQJAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <434F1CE611459F45BBC351FEB5A83F4302C84920@kavithai.ctd.hcltech.com> X-keycab-SPA: scanned by network antivirus X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Message-Id: Hi Bala, the diameter inside the IMS architecture will have many purposes. As far as I know the Diameter is used inside I-CSCF and S-CSCF for accounting aims and it is, thus, interfaced to the Charging system. Concerning the P-CSCF the diameter is used to establish communication = with the PDF element in the IMS architecture. The Diameter is a protocol basically designed for authorization, so it is used in this scope to "authorize" the P-CSCF to use the resources, and in this authorization process it is the PDF to work as the "authentication Server": it checks whether the P-CSCF is authorized to use the available resources. Obviously Diameter has also many other purposes in the IMS architecture since its many reliable features. Regards, Marco. > -----Messaggio originale----- > Da: Balamurugan T - TLS, Chennai. [mailto:tbalamurugan@hcl.in] > Inviato: venerd=EC 22 dicembre 2006 5.33 > A: dime@ietf.org > Oggetto: [Dime] Query regarding Diameter agents >=20 > Hi Guys, >=20 > I need a claification regarding diameter agent. IMS architecture = has > comonents like AS,HSS,S-CSCF ,I-CSCF and P-CSCF. > In IMS components the S-CSCF or P-CSCF can use the diameter = clients > for > their communication. What is the purpose of diamter > agents in IMS architecture and Which are components that act as > diameter agents? >=20 > Thanks in Advance. >=20 > Thanks, > Bala >=20 > DISCLAIMER > The contents of this e-mail and any attachment(s) are confidential and > intended for the >=20 > named recipient(s) only. It shall not attach any liability on the > originator or HCL or its >=20 > affiliates. Any views or opinions presented in this email are solely = those > of the author and >=20 > may not necessarily reflect the opinions of HCL or its affiliates. Any > form of reproduction, >=20 > dissemination, copying, disclosure, modification, distribution and / = or > publication of this >=20 > message without the prior written consent of the author of this e-mail = is > strictly >=20 > prohibited. If you have received this email in error please delete it = and > notify the sender >=20 > immediately. Before opening any mail and attachments please check them = for > viruses and >=20 > defect. >=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 Dec 22 03:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxg6k-0007MR-W2; Fri, 22 Dec 2006 03:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxg6j-0007MM-Gs for dime@ietf.org; Fri, 22 Dec 2006 03:50:25 -0500 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxg6h-0003Ec-LL for dime@ietf.org; Fri, 22 Dec 2006 03:50:25 -0500 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kBM8qBed014725 for ; Fri, 22 Dec 2006 14:22:11 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id kBM8qACM014698 for ; Fri, 22 Dec 2006 14:22:11 +0530 In-Reply-To: To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Fri, 22 Dec 2006 14:21:48 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 22/12/2006 02:14:50 PM, Serialize complete at 22/12/2006 02:14:50 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] AVP code for 3GPP-charging Id 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: , Content-Type: multipart/mixed; boundary="===============0664397296==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0664397296== Content-Type: multipart/alternative; boundary="=_alternative 00308AA7E525724C_=" This is a multipart message in MIME format. --=_alternative 00308AA7E525724C_= Content-Type: text/plain; charset="US-ASCII" Hi ! Can someone tell me the AVP code for 3GPP-charging Id AVP. Also specification number in which it is mentioned Regards Preeti. *********************** Aricent-Unclassified *********************** --=_alternative 00308AA7E525724C_= Content-Type: text/html; charset="US-ASCII"
Hi !

Can someone tell me the AVP code for 3GPP-charging Id AVP. Also specification number in which it is mentioned

Regards
Preeti.

***********************  Aricent-Unclassified   *********************** --=_alternative 00308AA7E525724C_=-- --===============0664397296== 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 --===============0664397296==-- From dime-bounces@ietf.org Fri Dec 22 09:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxl7W-0000vQ-5Y; Fri, 22 Dec 2006 09:11:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxl7U-0000v9-Qz for dime@ietf.org; Fri, 22 Dec 2006 09:11:32 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxl7T-0005sU-H3 for dime@ietf.org; Fri, 22 Dec 2006 09:11:32 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id F5BD5F49E4; Fri, 22 Dec 2006 09:11:31 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBMEBTfe027515; Fri, 22 Dec 2006 09:11:30 -0500 (EST) From: "Tolga Asveren" To: "Tom-PT Taylor" Subject: RE: [Dime] Acct-Application-Id value for NASREQ Date: Fri, 22 Dec 2006 09:08:18 -0500 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: <458B162C.5030702@nortel.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Yes, CER/CEA is not exchanged for a particular application session and is also hop-to-hop, i.e. does not need to be routed. > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Thursday, December 21, 2006 6:18 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] Acct-Application-Id value for NASREQ > > > Am I right in thinking that you always use the base application Id "0" > for CER/CEA? I'm thinking that before these messages are exchanged there > is no basis for routing on application. > > Tolga Asveren wrote: > > Glen, > > > > Based on my understanding of the "Which App-Id to use in the > message header > > for base protocol messages" discussion in the last IETF, I > would say that to > > use the application identifier for NASREQ, i.e. "1", for all messages > > exchanged for a NASREQ session makes sense. > > > > I guess there was already consensus to follow that approach for base > > protocol messages like STR, ASR. IMHO, extending that strategy to other > > messages could be useful to guarantee successful routing of > these messages > > in all types of configurations and also to prevent confusions > you listed. > > > > BTW, if one reads RFC4005 literally, one can interpret it in a > way where use > > of app_id=0 is indicated for ACR and ACA as well based on the following > > passage: > > 1.3 Advertising Application Support > > .... > > All other messages are defined by [BASE] and > > use the Base application id value. > > > > ACR/ACA belongs to other messages and base application id value is 0. > > Nonetheless, I guess the real intention was to use App-Id=3 for > ACR/ACA like > > you stated. > > > > Thanks, > > Tolga > > > > -----Original Message----- > > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > > Sent: Thursday, December 21, 2006 8:39 AM > > To: dime@ietf.org > > Cc: Glen Zorn (gwz) > > Subject: [Dime] Acct-Application-Id value for NASREQ > > > > > > Just noticed that RFC 4005 doesn't appear to actually specify > the value of > > Acct-Application-Id for NASREQ accounting messages; I suspect > that what is > > intended is that the value be '3' for Diameter base accounting. > This seems > > to me to be problematic for a couple of reasons > > it makes it difficult to determine what application actually > generated the > > accounting record (assuming that two or more applications use unmodified > > base accounting on the same server) > > It seems to make it impossible to separate accounting servers > by application > > (again assuming that two or more applications use base accounting w/o > > modification) because all those servers would advertise the > same accounting > > application. > > > > It does seem possible to separate generic accounting servers > from others by > > advertising just base accounting and no other applications, but > that doesn't > > seem quite good enough. Comments? > > > > > > _______________________________________________ > > 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 Dec 22 10:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxmI7-0007cw-Ny; Fri, 22 Dec 2006 10:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxmI7-0007b8-8F for dime@ietf.org; Fri, 22 Dec 2006 10:26:35 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxmI5-0000h6-4L for dime@ietf.org; Fri, 22 Dec 2006 10:26:35 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id EB02AD6BAB for ; Fri, 22 Dec 2006 10:26:28 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBMFQRjS003867 for ; Fri, 22 Dec 2006 10:26:28 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Clarification needs on transaction state Date: Fri, 22 Dec 2006 10:23:16 -0500 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: <434F1CE611459F45BBC351FEB5A83F4302C84F7F@kavithai.ctd.hcltech.com> Received-SPF: none X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Bala, > -----Original Message----- > From: Balamurugan T - TLS, Chennai. [mailto:tbalamurugan@hcl.in] > Sent: Friday, December 22, 2006 3:18 AM > To: dime@ietf.org > Subject: [Dime] Clarification needs on transaction state > > > > Hi folks , > > 1.Section 3.(End-to-End Identifier ) in RFC says "Duplicate requests > SHOULD cause the same answer to be transmitted (modulo the hop-by-hop > Identifier field and any routing AVPs that may be present), and MUST NOT > affect any state that was set when the original request was > processed. The > identifier MUST remain locally unique for a period of at least 4 minutes, > even across reboots." > a. For what purpose, we have to keep the same value after > reboots also.? [TOLGA]I guess you are asking why the value MUST be locally unique even after a reboot for a period of 4 minutes (?). This is to prevent false duplicate detections. Otherwise a message sent after the reboot could have the same E2E-Id with a request sent before reboot, even if they are actaully different messages. > > 2. According to RFC,only the outgoing requests should be stored in the > pending queue . The request has to be removed from the queue on arrival of > corresponding answer message. > a. Is it necessary to maintain the list of incoming requests in the > transaction level?. [TOLGA]Probably it depends on implementation where to keep them, but information should be stored somewhere on the receiving node to perform duplicate detection. > b. If so, How long we need to maintain them?. [TOLGA]This is currently not specified. 4 minutes mentioned for the uniqueness of E2E-Id could be used as a guideline. It is important to synchronize the uniqueness period honored when assigning E2E-Ids and how long the requests are kept for duplicate detection. Otherwise false duplicate detections may occur or some actual duplicate requests may not have been identified as duplicates. > "If the incoming requests are not available in transaction > state, How to > identify duplicate requests?" .It could be helpful if any of you explain > the transaction state maintenance. > Thanks in advance, > Bala > > DISCLAIMER > The contents of this e-mail and any attachment(s) are > confidential and intended for the > > named recipient(s) only. It shall not attach any liability on the > originator or HCL or its > > affiliates. Any views or opinions presented in this email are > solely those of the author and > > may not necessarily reflect the opinions of HCL or its > affiliates. Any form of reproduction, > > dissemination, copying, disclosure, modification, distribution > and / or publication of this > > message without the prior written consent of the author of this > e-mail is strictly > > prohibited. If you have received this email in error please > delete it and notify the sender > > immediately. Before opening any mail and attachments please check > them for viruses and > > defect. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 22 12:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnsR-0002Hf-8o; Fri, 22 Dec 2006 12:08:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnsP-0002HL-UR for dime@ietf.org; Fri, 22 Dec 2006 12:08:09 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxnsO-0003D6-Fh for dime@ietf.org; Fri, 22 Dec 2006 12:08:09 -0500 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBMH84ka099875; Fri, 22 Dec 2006 12:08:04 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <458C10F5.2020208@tari.toshiba.com> Date: Fri, 22 Dec 2006 12:08:05 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Acct-Application-Id value for NASREQ 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: 3002fc2e661cd7f114cb6bae92fe88f1 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, There maybe several points that needs clarification here. My historical understanding is that there is a relationship between auth-app-id and acct-app-id where the acct-app-id represents the accounting application that the auth application (auth-app-id) is using. So if an application supports accounting it would include an acct-app-id specifying what accounting application it uses and that id would be different from the app-id in the message header. The proposals in Sec 2.12 of the errata draft somewhat attempted to clarify such app-id assignments (auth-id and acct-id avps) without considering this relationship. During the last IETF, there was a consensus that at least for Sec 2.12, we should just explain this relationship even though most existing applications do not use it. This does not really do any harm, i.e. routing problems, since that will still be based on the app id of the header. Note that this should not be confused with Sec 2.8 of the errata which deals with session level messages and their app-id assignments. And the proposal on that issue states the use of app id of the application for the noted session level messages. regards, victor > Glen, > > Based on my understanding of the "Which App-Id to use in the message header > for base protocol messages" discussion in the last IETF, I would say that to > use the application identifier for NASREQ, i.e. "1", for all messages > exchanged for a NASREQ session makes sense. > > I guess there was already consensus to follow that approach for base > protocol messages like STR, ASR. IMHO, extending that strategy to other > messages could be useful to guarantee successful routing of these messages > in all types of configurations and also to prevent confusions you listed. > > BTW, if one reads RFC4005 literally, one can interpret it in a way where use > of app_id=0 is indicated for ACR and ACA as well based on the following > passage: > 1.3 Advertising Application Support > .... > All other messages are defined by [BASE] and > use the Base application id value. > > ACR/ACA belongs to other messages and base application id value is 0. > Nonetheless, I guess the real intention was to use App-Id=3 for ACR/ACA like > you stated. > > Thanks, > Tolga > > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Thursday, December 21, 2006 8:39 AM > To: dime@ietf.org > Cc: Glen Zorn (gwz) > Subject: [Dime] Acct-Application-Id value for NASREQ > > > Just noticed that RFC 4005 doesn't appear to actually specify the value of > Acct-Application-Id for NASREQ accounting messages; I suspect that what is > intended is that the value be '3' for Diameter base accounting. This seems > to me to be problematic for a couple of reasons > it makes it difficult to determine what application actually generated the > accounting record (assuming that two or more applications use unmodified > base accounting on the same server) > It seems to make it impossible to separate accounting servers by application > (again assuming that two or more applications use base accounting w/o > modification) because all those servers would advertise the same accounting > application. > > It does seem possible to separate generic accounting servers from others by > advertising just base accounting and no other applications, but that doesn't > seem quite good enough. Comments? > > > _______________________________________________ > 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 Dec 22 16:04:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxrZA-0002Pf-Dh; Fri, 22 Dec 2006 16:04:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxrZ9-0002PH-Gd for dime@ietf.org; Fri, 22 Dec 2006 16:04:31 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxrZ8-00067M-2a for dime@ietf.org; Fri, 22 Dec 2006 16:04:31 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 300B8BC162 for ; Fri, 22 Dec 2006 16:04:27 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBML4QPw025743 for ; Fri, 22 Dec 2006 16:04:27 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Acct-Application-Id value for NASREQ Date: Fri, 22 Dec 2006 16:01:13 -0500 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: <458C10F5.2020208@tari.toshiba.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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, My understanding is that RFC3588 does not leave much room for interpretation in terms of the relationship between Application-Id in the message header and the AVPs which are carrying application-id information (based on definition of Application-ID in 3.Diameter Header in RFC3588). Like you mentioned, there is currently nothing changing this behavior in the errata draft either. It is of course possible to do so. It could be useful to discuss advantages/disadvantages based on a proposed text regarding this issue. Actually after thinking a bit more about the problem Glen mentioned: a) What I suggested won't work unless the authorization and accounting are done on the same node/application instance, because the message header would contain app-id of NASREQ causing the requests to be routed to the NASREQ application. OTOH, I am not sure whether this is already the intent. I don't know whether it is feasible to have a generic accounting application, which can handle accounting for different purposes. Each application will add service-specific AVPs to ACR for accounting purposes, the accounting application needs to know how to make use of the data present in those AVPs, which IMO would make a generic accounting server hard to implement. b) If different applications are used for authorization and accounting, indicating that the accounting is to be done for NASREQ could be useful. Using Acct-App-Id for this purpose could make sense. If the same application is used, I guess there is no point to use Acct-App-Id, because all messages for the session will go to the same application anyhow. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Friday, December 22, 2006 12:08 PM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: Re: [Dime] Acct-Application-Id value for NASREQ > > > Hi, > > There maybe several points that needs clarification here. My historical > understanding is that there is a relationship between auth-app-id and > acct-app-id where the acct-app-id represents the accounting application > that the auth application (auth-app-id) is using. So if an application > supports accounting it would include an acct-app-id specifying what > accounting application it uses and that id would be different from the > app-id in the message header. > > The proposals in Sec 2.12 of the errata draft somewhat attempted to > clarify such app-id assignments (auth-id and acct-id avps) without > considering this relationship. During the last IETF, there was a > consensus that at least for Sec 2.12, we should just explain this > relationship even though most existing applications do not use it. This > does not really do any harm, i.e. routing problems, since that will > still be based on the app id of the header. Note that this should not be > confused with Sec 2.8 of the errata which deals with session level > messages and their app-id assignments. And the proposal on that issue > states the use of app id of the application for the noted session level > messages. > > regards, > victor > > > Glen, > > > > Based on my understanding of the "Which App-Id to use in the > message header > > for base protocol messages" discussion in the last IETF, I > would say that to > > use the application identifier for NASREQ, i.e. "1", for all messages > > exchanged for a NASREQ session makes sense. > > > > I guess there was already consensus to follow that approach for base > > protocol messages like STR, ASR. IMHO, extending that strategy to other > > messages could be useful to guarantee successful routing of > these messages > > in all types of configurations and also to prevent confusions > you listed. > > > > BTW, if one reads RFC4005 literally, one can interpret it in a > way where use > > of app_id=0 is indicated for ACR and ACA as well based on the following > > passage: > > 1.3 Advertising Application Support > > .... > > All other messages are defined by [BASE] and > > use the Base application id value. > > > > ACR/ACA belongs to other messages and base application id value is 0. > > Nonetheless, I guess the real intention was to use App-Id=3 for > ACR/ACA like > > you stated. > > > > Thanks, > > Tolga > > > > -----Original Message----- > > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > > Sent: Thursday, December 21, 2006 8:39 AM > > To: dime@ietf.org > > Cc: Glen Zorn (gwz) > > Subject: [Dime] Acct-Application-Id value for NASREQ > > > > > > Just noticed that RFC 4005 doesn't appear to actually specify > the value of > > Acct-Application-Id for NASREQ accounting messages; I suspect > that what is > > intended is that the value be '3' for Diameter base accounting. > This seems > > to me to be problematic for a couple of reasons > > it makes it difficult to determine what application actually > generated the > > accounting record (assuming that two or more applications use unmodified > > base accounting on the same server) > > It seems to make it impossible to separate accounting servers > by application > > (again assuming that two or more applications use base accounting w/o > > modification) because all those servers would advertise the > same accounting > > application. > > > > It does seem possible to separate generic accounting servers > from others by > > advertising just base accounting and no other applications, but > that doesn't > > seem quite good enough. Comments? > > > > > > _______________________________________________ > > 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 Dec 22 23:19:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxyMM-00022y-4k; Fri, 22 Dec 2006 23:19:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxyML-00021j-FX for dime@ietf.org; Fri, 22 Dec 2006 23:19:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxyMK-0000IK-4M for dime@ietf.org; Fri, 22 Dec 2006 23:19:45 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Dec 2006 20:19:41 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBN4JfqR011352; Fri, 22 Dec 2006 20:19:41 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kBN4JfUH023056; Fri, 22 Dec 2006 20:19:41 -0800 (PST) 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.1830); Fri, 22 Dec 2006 20:19:41 -0800 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] Acct-Application-Id value for NASREQ Date: Fri, 22 Dec 2006 20:19:37 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250325D01A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Acct-Application-Id value for NASREQ Thread-Index: Accl6+cG0YdxnAa/Ts2cEj6mOtZnaAAWI6hg From: "Glen Zorn \(gwz\)" To: "Victor Fajardo" X-OriginalArrivalTime: 23 Dec 2006 04:19:41.0033 (UTC) FILETIME=[90FD3590:01C72649] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2575; t=1166847581; x=1167711581; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Acct-Application-Id=20value=20for=20NASREQ |Sender:=20; bh=YJNS9+Q2F1e/1kNv10nKxWhN+Sexyqy7osi/BAqI2Y8=; b=QXNET8le0u0dOA9o7acri24ZRVBeId3hlUgE0zHbGMcoOzDU7ufcN651MvTdgoJNsjo40+mK yffo+h+4CU21MtpQUPc3mh81CN2+EpjdMmCnRuxPJs9O5w5Y5LXVLsmF; Authentication-Results: sj-dkim-8; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 supposedly scribbled on Friday, December 22, 2006 9:08 AM: > Hi, >=20 > There maybe several points that needs clarification here. My > historical understanding is that there is a relationship between > auth-app-id and acct-app-id where the acct-app-id represents the > accounting application that the auth application (auth-app-id) is > using. So if an application supports accounting it would include an > acct-app-id specifying what accounting application it uses and that > id would be different from the app-id in the message header.=20 OK, but I'm not sure where this understanding comes from or why it's not reflected in the RFCs. In fact, section 1.2.4 of RFC 3588 seems to directly contradict this statement:=20 "If the base accounting is used without any mandatory AVPs, new commands or additional mechanisms (e.g., application defined state machine), then the base protocol defined standard accounting application Id (Section 2.4) MUST be used in ACR/ACA commands." Please note that I am neither denying the existence of such a historical understanding (I didn't pay any attention to Diameter after the first couple of years for reasons that needn't be attended to here) nor disagreeing that that is how it _should_ work. >=20 > The proposals in Sec 2.12 of the errata draft somewhat attempted to > clarify such app-id assignments (auth-id and acct-id avps) without > considering this relationship. During the last IETF, there was a > consensus that at least for Sec 2.12, we should just explain this > relationship even though most existing applications do not use it. > This does not really do any harm, i.e. routing problems, since that > will still be based on the app id of the header. Note that this > should not be confused with Sec 2.8 of the errata which deals with > session level messages and their app-id assignments. And the proposal > on that issue states the use of app id of the application for the > noted session level messages.=20 Actually, I believe that the best thing to do would be to separate the common application messages which are related to user sessions (ACR, ACA, STR, STA, etc.) from the actual base protocol which deals with peer-to-peer connections rather than user sessions, preferably in a new document. I think that that approach is much cleaner & more useful in the long run than a piecemeal approach. The drawback is that it would probably mean recycling 3588 at PS rather than advancing to Draft Standard. =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Dec 23 07:02:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy5aF-0000yb-T6; Sat, 23 Dec 2006 07:02:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy5aE-0000yP-4X for dime@ietf.org; Sat, 23 Dec 2006 07:02:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gy5aC-0003XL-R1 for dime@ietf.org; Sat, 23 Dec 2006 07:02:34 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 23 Dec 2006 04:02:32 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id kBNC2WoT022325; Sat, 23 Dec 2006 04:02:32 -0800 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 kBNC2RDi018495; Sat, 23 Dec 2006 04:02:27 -0800 (PST) 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.1830); Sat, 23 Dec 2006 04:02:27 -0800 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] Acct-Application-Id value for NASREQ Date: Sat, 23 Dec 2006 04:02:24 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250325D045@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Acct-Application-Id value for NASREQ Thread-Index: AccmDOH1N/CFwqI8RL+Stzgn4XFY4QAXFAzg From: "Glen Zorn \(gwz\)" To: "Tolga Asveren" X-OriginalArrivalTime: 23 Dec 2006 12:02:27.0632 (UTC) FILETIME=[372BFB00:01C7268A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1677; t=1166875352; x=1167739352; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Acct-Application-Id=20value=20for=20NASREQ |Sender:=20; bh=RT+S6vNYklwVRWIVyjFgTTqCX1Oe8ggwNGPdgNaFiR0=; b=N8sdLQW9/Q+C0KKSZPOrEPjgSz4Tw06V1vef9n+O6jYY4sQgPMgvjKjshF9TwV964O1IDrZn rCketS3ewLXaCN3OXVyvFJQoG+hZgEDxLb31j19FHR00Qnhh7yuhEFzL; Authentication-Results: sj-dkim-6; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim6002 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 Tolga Asveren supposedly scribbled on Friday, December 22, 2006 1:01 PM: ... > Actually after thinking a bit more about the problem Glen mentioned: > a) What I suggested won't work unless the authorization and > accounting are done on the same node/application instance, because > the message header would contain app-id of NASREQ causing the > requests to be routed to the NASREQ application.=20 I think that you are right, in order to route AA & Accounting servers with anything like efficiency the Acct-Application-Id & Application-Id would have to be distinct. > OTOH, I am not sure > whether this is already the intent. I don't know whether it is > feasible to have a generic accounting application, which can handle > accounting for different purposes. Each application will add > service-specific AVPs to ACR for accounting purposes, the accounting > application needs to know how to make use of the data present in > those AVPs, which IMO would make a generic accounting server hard to > implement. I think the idea is that accounting data would always just be written to a log. If that is the case, then the requirements for the understanding of AVPs should be minimal, right? Basically just the ability to parse AVPs, it seems. Since Diameter (unlike RADIUS) doesn't use accounting messages for things like error reporting that may require immediate action, this doesn't seem like an unrealistic assumption. However, this still leaves us unable to easily distinguish between the applications or services (e.g., NASREQ, MobileIP, etc.) that generated the accounting records.=20 =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Dec 23 09:44:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy86M-0001RY-9j; Sat, 23 Dec 2006 09:43:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gy86K-0001RT-IL for dime@ietf.org; Sat, 23 Dec 2006 09:43:52 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gy86H-0005BT-3h for dime@ietf.org; Sat, 23 Dec 2006 09:43:52 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBNEhBM6003145; Sat, 23 Dec 2006 09:43:12 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <458D40B7.4090206@tari.toshiba.com> Date: Sat, 23 Dec 2006 09:44:07 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] Acct-Application-Id value for NASREQ References: <4C0FAAC489C8B74F96BEAD85EAEB26250325D01A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250325D01A@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Glen, > > OK, but I'm not sure where this understanding comes from or why it's not > reflected in the RFCs. In fact, section 1.2.4 of RFC 3588 seems to > directly contradict this statement: > > "If the base accounting is used without any mandatory AVPs, new > commands or additional mechanisms (e.g., application defined state > machine), then the base protocol defined standard accounting > application Id (Section 2.4) MUST be used in ACR/ACA commands." > > Please note that I am neither denying the existence of such a historical > understanding (I didn't pay any attention to Diameter after the first > couple of years for reasons that needn't be attended to here) nor > disagreeing that that is how it _should_ work. Well ... most likely I may have mis-understood as well :) since I was basing it on the comments made during the last meeting, your probably the better person to clarify. Here's the meeting minutes snippet: - Issue 13 [Duplication of App id in the header and App Id avps] Lionel: The basic question is why do we need to have several app ids present in the message. John: Need clarify text on why its there. Glen: Fuzzy recollection on why there are two app ids present. The idea was that diameter applications would have accounting. So one of these ids where either accounting or nothing. John: Need to do some forensic digging. Victor: How will this affect routing Glen: It really would'nt John: Because you would be routing on the header and accounting would be in the body Glen: But nowadays, virtually no applications include accounting so we can remove this feature. John: What we can do is just put an explanation why we have to app ids. And as long as it does'nt do any harm then it should be ok. >> The proposals in Sec 2.12 of the errata draft somewhat attempted to >> clarify such app-id assignments (auth-id and acct-id avps) without >> considering this relationship. During the last IETF, there was a >> consensus that at least for Sec 2.12, we should just explain this >> relationship even though most existing applications do not use it. >> This does not really do any harm, i.e. routing problems, since that >> will still be based on the app id of the header. Note that this >> should not be confused with Sec 2.8 of the errata which deals with >> session level messages and their app-id assignments. And the proposal >> on that issue states the use of app id of the application for the >> noted session level messages. > > Actually, I believe that the best thing to do would be to separate the > common application messages which are related to user sessions (ACR, > ACA, STR, STA, etc.) from the actual base protocol which deals with > peer-to-peer connections rather than user sessions, preferably in a new > document. I think that that approach is much cleaner & more useful in > the long run than a piecemeal approach. The drawback is that it would > probably mean recycling 3588 at PS rather than advancing to Draft > Standard. > > ... > Ok. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Dec 24 02:32:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyNpr-0005zq-4A; Sun, 24 Dec 2006 02:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyNpq-0005zl-DY for DiME@ietf.org; Sun, 24 Dec 2006 02:31:54 -0500 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyNpp-0002LK-5I for DiME@ietf.org; Sun, 24 Dec 2006 02:31:54 -0500 Received: by wx-out-0506.google.com with SMTP id h27so3289096wxd for ; Sat, 23 Dec 2006 23:31:52 -0800 (PST) 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; b=LHggoq7Dkuy58EBF2Z/BCjH6q9h6VqOSTpav57RmfZkEgFhJnHn90/9yfe60Neq88DRX0dqMEWv3QaQ1gHQL95xqPuWoFUd6vi3f87IrBAwSYQjbgePhL9u1bY7Q1M5tiRR0p8WNmFk+pXZCb8cEi8VKZonMdS28ICjRMXD/ILU= Received: by 10.90.104.14 with SMTP id b14mr10145906agc.1166945512933; Sat, 23 Dec 2006 23:31:52 -0800 (PST) Received: by 10.90.91.14 with HTTP; Sat, 23 Dec 2006 23:31:52 -0800 (PST) Message-ID: Date: Sun, 24 Dec 2006 09:31:52 +0200 From: "Gil Shafran" To: DiME@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Dime] Mistakes in standards? 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="===============0696126648==" Errors-To: dime-bounces@ietf.org --===============0696126648== Content-Type: multipart/alternative; boundary="----=_Part_48176_16994344.1166945512909" ------=_Part_48176_16994344.1166945512909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I've found few mismatches of command and AVP definitions, both in base diameter and 3GPP standards. Two examples: - In rfc 3588, section 6.11 defines: ::= < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } This definition contradicts the definition of grouped AVP (section 4.4), since optional AVP comes before required AVPs. There also shouldn't be parenthesis around the grouped AVP name. - In 29229-740 section 6.1.1, optional AVPs come before required AVPs (Supported-Features AVP before Public-Identity AVP) as defined in rfc 3588 section 3.2. Can anyone tell me if these are mistakes? Regards, Gil ------=_Part_48176_16994344.1166945512909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I've found few mismatches of command and AVP definitions, both in base diameter and 3GPP standards. Two examples:
- In rfc 3588, section 6.11 defines:

   <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >

                                     1* [ Vendor-Id ]

                                     0*1{ Auth-Application-Id }

                                     0*1{ Acct-Application-Id }

This definition contradicts the definition of grouped AVP (section 4.4), since optional AVP comes before required AVPs. There also shouldn't be parenthesis around the grouped AVP name.

 

- In 29229-740 section 6.1.1, optional AVPs come before required AVPs (Supported-Features AVP before Public-Identity AVP) as defined in rfc 3588 section 3.2.

 

Can anyone tell me if these are mistakes?

 

Regards,

Gil

 

 

------=_Part_48176_16994344.1166945512909-- --===============0696126648== 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 --===============0696126648==-- From dime-bounces@ietf.org Sun Dec 24 05:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyQLp-0001bh-46; Sun, 24 Dec 2006 05:13:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyQLn-0001bZ-Ui for DiME@ietf.org; Sun, 24 Dec 2006 05:13:03 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyQLl-0004xF-Ce for DiME@ietf.org; Sun, 24 Dec 2006 05:13:03 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Dec 2006 02:13:00 -0800 X-IronPort-AV: i="4.12,208,1165219200"; d="scan'208,217"; a="94704625:sNHT135715014" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kBOAD0Wf008163; Sun, 24 Dec 2006 02:13:00 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBOAD0Pn003010; Sun, 24 Dec 2006 02:13:00 -0800 (PST) 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.1830); Sun, 24 Dec 2006 02:12:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Mistakes in standards? Date: Sun, 24 Dec 2006 02:12:48 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250325D094@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Mistakes in standards? Thread-Index: AccnLa0UqhNLuMe7Tw+Dt8BpUZdGzQADwV6A From: "Glen Zorn \(gwz\)" To: "Gil Shafran" X-OriginalArrivalTime: 24 Dec 2006 10:12:57.0919 (UTC) FILETIME=[15BB14F0:01C72744] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6740; t=1166955180; x=1167819180; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Mistakes=20in=20standards? |Sender:=20; bh=TnMq8S+ZeXJIxX1TM4iSALfczzdtvbw69/uCe++ft1Q=; b=ZlUxaXAVVN+mfWAMNaczaFZmBj4x8jEbnTEbg7T386FmWq+FyBPVFomuR4vKX/rJtsIuwqSW pJxSfoQHrKFsfsuPAR8eTA+LEdsBTVY0mZjvHwZcnAQjHY5QTIDMlFRV; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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="===============1464769101==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1464769101== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72744.157113E9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72744.157113E9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 I've found few mismatches of command and AVP definitions, both in base diameter and 3GPP standards. Two examples: - In rfc 3588, section 6.11 defines: ::=3D < AVP Header: 260 >=20 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } This definition contradicts the definition of grouped AVP (section 4.4), since optional AVP comes before required AVPs. =20 =20 I agree that the ABNF is wrong, but not in the same way. Although I'm hardly an ABNF expert, it seems to me that "1* [ Vendor-ID ]" and "{ Vendor-ID }" are semantically identical. OTOH, the ABNF seems to allow instances of both the Auth-Application-Id and Acct-Application-Id AVPs in the same Vendor-Specific-Application-Id AVP, but the textual description of the Vendor-Specific-Application-Id AVP seems to forbid this: "Exactly one of the Auth-Application-Id and Acct-Application-Id AVPs MAY be present." I say that it "seems to forbid" it because I find this sentence very difficult to parse. I'm guessing that it means either "Exactly one instance of either the Auth-Application-Id or Acct-Application-Id AVPs but not both MUST be present." or "Either the Auth-Application-Id or the Acct-Application-Id AVPs but not both MAY be present." The latter interpretation doesn't make a lot of sense, though, because you could end up with a Vendor-Specific-Application-Id AVP without an application ID! In any case, I think that the use of the alternative syntax (RFC 4234, section 3.2) would be much more appropriate here. ...=20 ------_=_NextPart_001_01C72744.157113E9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've found few mismatches of command and AVP definitions, both in = base=20 diameter and 3GPP standards. Two examples:
- In rfc 3588, section 6.11 defines:

  =20 <Vendor-Specific-Application-Id> ::=3D < AVP Header: 260 = >=20

           &n= bsp;           &nb= sp;           &nbs= p;=20 1* [ Vendor-Id ]

        =20            &n= bsp;           &nb= sp;    0*1{=20 Auth-Application-Id }

           &n= bsp;           &nb= sp;           &nbs= p;=20 0*1{ Acct-Application-Id }

This definition contradicts the = definition of=20 grouped AVP (section 4.4), since optional AVP comes before required = AVPs.  

 

I = agree that the=20 ABNF is wrong, but not in the same way.  Although I'm hardly an = ABNF=20 expert, it seems to me that "1* [ Vendor-ID ]" and "{ Vendor-ID }" are=20 semantically identical.  OTOH, the ABNF seems to allow instances of = both=20 the Auth-Application-Id and Acct-Application-Id AVPs in the same=20 Vendor-Specific-Application-Id AVP, but the textual description of the=20 Vendor-Specific-Application-Id AVP seems to forbid this: "Exactly one of = the=20 Auth-Application-Id and Acct-Application-Id AVPs MAY be present."  = I say=20 that it "seems to forbid" it because I find this sentence very difficult = to=20 parse.  I'm guessing that it means either "Exactly one instance of = either=20 the Auth-Application-Id or Acct-Application-Id AVPs but not both MUST be = present."  or "Either the Auth-Application-Id or the = Acct-Application-Id=20 AVPs but not both MAY be present."  The latter interpretation = doesn't make=20 a lot of sense, though, because you could end up with a=20 Vendor-Specific-Application-Id AVP without an application ID!  In = any case,=20 I think that the use of the alternative syntax (RFC 4234, section=20 3.2) would be much more appropriate = here.

... 

------_=_NextPart_001_01C72744.157113E9-- --===============1464769101== 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 --===============1464769101==-- From dime-bounces@ietf.org Sun Dec 24 23:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyhMo-0003UO-9h; Sun, 24 Dec 2006 23:23:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyhMn-0003UI-Dt for dime@ietf.org; Sun, 24 Dec 2006 23:23:13 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyhMh-0000Ge-FV for dime@ietf.org; Sun, 24 Dec 2006 23:23:13 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAT00HKGACHRC@usaga01-in.huawei.com> for dime@ietf.org; Sun, 24 Dec 2006 20:12:17 -0800 (PST) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JAT00CNFACGVP@usaga01-in.huawei.com> for dime@ietf.org; Sun, 24 Dec 2006 20:12:17 -0800 (PST) Received: from [172.24.1.24] (Forwarded-For: [10.164.5.37]) by szxmc03-in.huawei.com (mshttpd); Mon, 25 Dec 2006 12:12:19 +0800 Date: Mon, 25 Dec 2006 12:12:19 +0800 From: lijijun 41867 Subject: =?gb2312?B?u9i4tA==?=:R: [Dime] Query regarding Diameter agents To: Marco Carusio Message-id: <436266434123.434123436266@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Carusio, Thanks for your comment.But you did not answer: ^-^ What is the purpose of diamter agents in IMS architecture and Which are components that act as diameter agents? This is also my question? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 26 02:02:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz6Jv-00048X-GP; Tue, 26 Dec 2006 02:01:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz6Jt-00048L-Sk; Tue, 26 Dec 2006 02:01:53 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gz6Jq-0005Rr-RM; Tue, 26 Dec 2006 02:01:53 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 26122006 #240078; status: clean Received: from hemant ([172.16.12.212]) by ricky.india.internal.net (8.12.10/8.11.6) with SMTP id kBQ6n2ms024709; Tue, 26 Dec 2006 12:19:02 +0530 Message-ID: <005101c728bd$01742f70$d40c10ac@india.internal.net> From: "Hemant" To: , Date: Tue, 26 Dec 2006 12:40:58 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: imsdia@intellinet-india.com Subject: [Dime] Missing AVP Code and definition 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="===============1132110533==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1132110533== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C728EB.17A4CB50" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C728EB.17A4CB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, In RFC 4004 there are some AVPs which have reference in the = specification but are not declared formally with AVP code. Following are the AVP's: 1. MIP-HA-to-MN-SPI used in the Grouped AVP MIP-HA-to-MN-MSA. 2. MIP-MN-FA-SPI used in the Grouped AVP MIP-MN-to-FA-MSA. 3. MIP-MN-HA-SPI used in the Grouped AVP MIP-MN-to-HA-MSA. Are they defined in some other RFC or do we have to use internally = defined values for them? Thanks in Advance. Regards, Hemant Bhatnagar=20 Software Engineer IntelliNet Technologies India Pvt. Ltd. Accelerating Convergence hbhatnagar@intellinet-india.com 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2311 Off - Fax.......: + 91 80 25202947 ------=_NextPart_000_004C_01C728EB.17A4CB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
In RFC 4004 there are some = AVPs which=20 have reference in the specification = but are not=20 declared formally with AVP code.
 
Following are the AVP's:
1. MIP-HA-to-MN-SPI used in the Grouped = AVP=20 MIP-HA-to-MN-MSA.
2. MIP-MN-FA-SPI used in the Grouped AVP=20 MIP-MN-to-FA-MSA.
3. MIP-MN-HA-SPI used in the Grouped AVP=20 MIP-MN-to-HA-MSA.
 
Are they defined in some other RFC = or do=20 we have to use internally defined values for = them?
 
Thanks in Advance.
 
Regards,
Hemant Bhatnagar
Software = Engineer
IntelliNet Technologies India Pvt.=20 Ltd.
Accelerating Convergence
hbhatnagar@intellinet-ind= ia.com
413/4=20 Oxford Towers, 139 Airport Road,
Bangalore - 560 = 017
Off-Phone.....: + 91=20 80 51256018 Ext: 2311
Off - Fax.......: + 91 80=20 25202947
------=_NextPart_000_004C_01C728EB.17A4CB50-- --===============1132110533== 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 --===============1132110533==-- From dime-bounces@ietf.org Tue Dec 26 14:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzHs2-0006PB-QB; Tue, 26 Dec 2006 14:21:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzHs1-0006Ox-9M for dime@ietf.org; Tue, 26 Dec 2006 14:21:53 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzHrz-0005Xr-TU for dime@ietf.org; Tue, 26 Dec 2006 14:21:53 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kBQJEOa01150; Tue, 26 Dec 2006 14:14:24 -0500 (EST) Received: from [47.130.24.49] ([47.130.24.49] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Dec 2006 14:22:07 -0500 Message-ID: <4591763A.8000702@nortel.com> Date: Tue, 26 Dec 2006 14:21:30 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: lijijun 41867 Subject: Re: =?UTF-8?B?5Zue5aSNOlI6IFtEaW1lXSBRdWVyeSByZWdhcmRpbmcgRGlhbWU=?= =?UTF-8?B?dGVyIGFnZW50cw==?= References: <436266434123.434123436266@huawei.com> In-Reply-To: <436266434123.434123436266@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Dec 2006 19:22:07.0265 (UTC) FILETIME=[21E5C910:01C72923] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Agents do not appear explicitly in the IMS architecture. They are an implementation option: part of the operator's chosen Diameter routing infrastructure. So they would lie between the CSCF and the HSS, but their possible presence has not been documented in IMS specifications. lijijun 41867 wrote: > Hi Marco Carusio, > > Thanks for your comment.But you did not answer: ^-^ > What is the purpose of diamter agents in IMS architecture and Which are components that act as diameter agents? > This is also my question? > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 26 14:51:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzIKy-0007HX-4j; Tue, 26 Dec 2006 14:51:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzIKw-0007HR-W0 for dime@ietf.org; Tue, 26 Dec 2006 14:51:46 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzIKv-0005Xw-Oa for dime@ietf.org; Tue, 26 Dec 2006 14:51:46 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id BBF355A7EA; Tue, 26 Dec 2006 14:51:34 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBQJpSSp002446; Tue, 26 Dec 2006 14:51:28 -0500 (EST) From: "Tolga Asveren" To: "Glen Zorn (gwz)" Subject: RE: [Dime] Acct-Application-Id value for NASREQ Date: Tue, 26 Dec 2006 14:47:47 -0500 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: <4C0FAAC489C8B74F96BEAD85EAEB26250325D045@xmb-sjc-215.amer.cisco.com> Received-SPF: none X-Spam-Score: 0.0 (/) 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 With the assumption of a single generic accounting application, using Acct-Application-Id to identify the accounted application makes more sense to me now. This information could be used by some other entity, which needs to analyze the logs. Thanks, Tolga > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Saturday, December 23, 2006 7:02 AM > To: Tolga Asveren > Cc: dime@ietf.org > Subject: RE: [Dime] Acct-Application-Id value for NASREQ > > > Tolga Asveren supposedly scribbled on > Friday, December 22, 2006 1:01 PM: > > ... > > > Actually after thinking a bit more about the problem Glen mentioned: > > a) What I suggested won't work unless the authorization and > > accounting are done on the same node/application instance, because > > the message header would contain app-id of NASREQ causing the > > requests to be routed to the NASREQ application. > > I think that you are right, in order to route AA & Accounting servers > with anything like efficiency the Acct-Application-Id & Application-Id > would have to be distinct. > > > OTOH, I am not sure > > whether this is already the intent. I don't know whether it is > > feasible to have a generic accounting application, which can handle > > accounting for different purposes. Each application will add > > service-specific AVPs to ACR for accounting purposes, the accounting > > application needs to know how to make use of the data present in > > those AVPs, which IMO would make a generic accounting server hard to > > implement. > > I think the idea is that accounting data would always just be written to > a log. If that is the case, then the requirements for the understanding > of AVPs should be minimal, right? Basically just the ability to parse > AVPs, it seems. Since Diameter (unlike RADIUS) doesn't use accounting > messages for things like error reporting that may require immediate > action, this doesn't seem like an unrealistic assumption. However, this > still leaves us unable to easily distinguish between the applications or > services (e.g., NASREQ, MobileIP, etc.) that generated the accounting > records. > > ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Dec 26 16:12:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJbP-0006gm-Ma; Tue, 26 Dec 2006 16:12:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJbO-0006gZ-NE for DiME@ietf.org; Tue, 26 Dec 2006 16:12:50 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzJbL-0004aJ-BY for DiME@ietf.org; Tue, 26 Dec 2006 16:12:50 -0500 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kBQLC7Bp012961; Tue, 26 Dec 2006 16:12:07 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45919028.1090202@tari.toshiba.com> Date: Tue, 26 Dec 2006 16:12:08 -0500 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] Mistakes in standards? References: <4C0FAAC489C8B74F96BEAD85EAEB26250325D094@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250325D094@xmb-sjc-215.amer.cisco.com> 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 Glen, > Hi, > > I've found few mismatches of command and AVP definitions, both in base > diameter and 3GPP standards. Two examples: > - In rfc 3588, section 6.11 defines: > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > This definition contradicts the definition of grouped AVP (section > 4.4), since optional AVP comes before required AVPs. > > > > I agree that the ABNF is wrong, but not in the same way. Although I'm > hardly an ABNF expert, it seems to me that "1* [ Vendor-ID ]" and "{ > Vendor-ID }" are semantically identical. OTOH, the ABNF seems to > allow instances of both the Auth-Application-Id and > Acct-Application-Id AVPs in the same Vendor-Specific-Application-Id > AVP, but the textual description of the Vendor-Specific-Application-Id > AVP seems to forbid this: "Exactly one of the Auth-Application-Id and > Acct-Application-Id AVPs MAY be present." I say that it "seems to > forbid" it because I find this sentence very difficult to parse. I'm > guessing that it means either "Exactly one instance of either the > Auth-Application-Id or Acct-Application-Id AVPs but not both MUST be > present." or "Either the Auth-Application-Id or the > Acct-Application-Id AVPs but not both MAY be present." The latter > interpretation doesn't make a lot of sense, though, because you could > end up with a Vendor-Specific-Application-Id AVP without an > application ID! In any case, I think that the use of the alternative > syntax (RFC 4234, section 3.2) would be much more appropriate here. > > ... > I agree. I think we can expand the proposed solution in Sec 2.6 of the errata to include this suggestion. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 27 09:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzZLV-0002wK-4X; Wed, 27 Dec 2006 09:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzZLT-0002wF-LT for dime@ietf.org; Wed, 27 Dec 2006 09:01:27 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzZLQ-0001ZA-UD for dime@ietf.org; Wed, 27 Dec 2006 09:01:27 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 27122006 #240212; status: clean Received: from hemant ([172.16.12.212]) by ricky.india.internal.net (8.12.10/8.11.6) with SMTP id kBRDmqPX013278 for ; Wed, 27 Dec 2006 19:18:52 +0530 Message-ID: <004c01c729c0$d794eeb0$d40c10ac@india.internal.net> From: "Hemant" To: Date: Wed, 27 Dec 2006 19:40:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Dime] Fw: Missing AVP Code and definition 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 would appreciate if anybody can provide some inputs on this. Thanks, Hemant Bhatnagar --Original Message ----- From: Hemant To: dime@ietf.org ; dime-request@ietf.org Cc: imsdia@intellinet-india.com Sent: Tuesday, December 26, 2006 12:40 PM Subject: Missing AVP Code and definition Hi All, In RFC 4004 there are some AVPs which have reference in the specification but are not declared formally with AVP code. Following are the AVP's: 1. MIP-HA-to-MN-SPI used in the Grouped AVP MIP-HA-to-MN-MSA. 2. MIP-MN-FA-SPI used in the Grouped AVP MIP-MN-to-FA-MSA. 3. MIP-MN-HA-SPI used in the Grouped AVP MIP-MN-to-HA-MSA. Are they defined in some other RFC or do we have to use internally defined values for them? Thanks in Advance. Regards, Hemant Bhatnagar Software Engineer IntelliNet Technologies India Pvt. Ltd. Accelerating Convergence hbhatnagar@intellinet-india.com 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2311 Off - Fax.......: + 91 80 25202947 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Dec 27 09:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzZRO-0004kO-8X; Wed, 27 Dec 2006 09:07:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzZRM-0004kJ-8G for dime@ietf.org; Wed, 27 Dec 2006 09:07:32 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GzZRL-0002Yi-12 for dime@ietf.org; Wed, 27 Dec 2006 09:07:32 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1167228449!18029742!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2913 invoked from network); 27 Dec 2006 14:07:30 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-119.messagelabs.com with SMTP; 27 Dec 2006 14:07:30 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kBRE7TUi010762 for ; Wed, 27 Dec 2006 07:07:29 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id kBRE7RSN023752 for ; Wed, 27 Dec 2006 08:07:28 -0600 (CST) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Wed, 27 Dec 2006 22:07:25 +0800 Message-ID: <45927D5D.2090208@motorola.com> Date: Wed, 27 Dec 2006 19:34:13 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: vfajardo@tari.toshiba.com, dime@ietf.org X-OriginalArrivalTime: 27 Dec 2006 14:07:25.0631 (UTC) FILETIME=[55FAD4F0:01C729C0] X-Spam-Score: 1.8 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: hannes.tschofenig@siemens.com Subject: [Dime] Contradicting AVPs in 4006 ? 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="===============0189813997==" Errors-To: dime-bounces@ietf.org --===============0189813997== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi All,

I had a couple of questions about the command level AVP's and the Multiple-service-credit-control AVP.

Suppose a event based CCR, with CHECK_BALANCE as the value in Requested-Action AVP, is sent by the credit control client to the server, so, which of the following AVP combinations should be considered by the server to check the balance.
    -service-identifier AVP at the command level or
    -service-identifier AVP(s) in the Multiple-service-credit-control AVP or
    -both of the above AVPs

Similarly,  in the above scenario if the requested-action AVP had PRICE_ENQUIRY as the AVP value, then wouldn't the service-identifier AVP at the command level and
the Multiple-service-credit-control AVP be contradicting?

At a higher level, when should the command level AVPs in CCR gain priority than the Multiple-service-credit-control AVPs?

I would appreciate if anybody can provide some inputs on this.

-- 
Regards,
Liyaqatali G Nadaf
--===============0189813997== 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 --===============0189813997==-- From dime-bounces@ietf.org Wed Dec 27 10:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzaqc-0005AV-Ts; Wed, 27 Dec 2006 10:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzaqb-0005A6-NF for dime@ietf.org; Wed, 27 Dec 2006 10:37:41 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzaqZ-0000Wt-F3 for dime@ietf.org; Wed, 27 Dec 2006 10:37:41 -0500 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id A07A15D073 for ; Wed, 27 Dec 2006 10:37:39 -0500 (EST) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id kBRFbcXS002199 for ; Wed, 27 Dec 2006 10:37:38 -0500 (EST) From: "Tolga Asveren" To: Subject: RE: [Dime] Contradicting AVPs in 4006 ? Date: Wed, 27 Dec 2006 10:33:51 -0500 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: <45927D5D.2090208@motorola.com> Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Liyaqatali, I guess it makes sense to use the values present in Multiple-Services-Credit-Control AVP if there is a contradiction. I even would expect Service-Identifier AVP not to be present if multiple services are used. BTW, I am not sure whether event based scenarios for CHECK_BALANCE and PRICE_ENQUIRY can be used with multiple services. Multiple-Services-Credit-Control AVP does not have Cost-Information/Check-Balance-Result AVPs. There is of course the wildcard *[ AVP ], but I would expect these AVPs to be specifically mentioned, if there was an intention to use them. There are probably not many scenarios, where multiple parallel event based services are necessary to provide a "single service experience" from user point of view. Thanks, Tolga -----Original Message----- From: Liyaqatali [mailto:a21917@motorola.com] Sent: Wednesday, December 27, 2006 9:04 AM To: vfajardo@tari.toshiba.com; dime@ietf.org Cc: hannes.tschofenig@siemens.com Subject: [Dime] Contradicting AVPs in 4006 ? Hi All, I had a couple of questions about the command level AVP's and the Multiple-service-credit-control AVP. Suppose a event based CCR, with CHECK_BALANCE as the value in Requested-Action AVP, is sent by the credit control client to the server, so, which of the following AVP combinations should be considered by the server to check the balance. -service-identifier AVP at the command level or -service-identifier AVP(s) in the Multiple-service-credit-control AVP or -both of the above AVPs Similarly, in the above scenario if the requested-action AVP had PRICE_ENQUIRY as the AVP value, then wouldn't the service-identifier AVP at the command level and the Multiple-service-credit-control AVP be contradicting? At a higher level, when should the command level AVPs in CCR gain priority than the Multiple-service-credit-control AVPs? I would appreciate if anybody can provide some inputs on this. -- Regards, Liyaqatali G Nadaf _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Dec 28 07:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzu9A-0002tU-He; Thu, 28 Dec 2006 07:14:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzu98-0002tO-VA for dime@ietf.org; Thu, 28 Dec 2006 07:14:06 -0500 Received: from mail132.messagelabs.com ([216.82.241.3] helo=mail122.messagelabs.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gzu97-0003UB-LO for dime@ietf.org; Thu, 28 Dec 2006 07:14:06 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-2.tower-132.messagelabs.com!1167308038!38616609!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 7589 invoked from network); 28 Dec 2006 12:13:59 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-132.messagelabs.com with SMTP; 28 Dec 2006 12:13:59 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kBSCDwfY009085 for ; Thu, 28 Dec 2006 05:13:58 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id kBSCDsT4013309 for ; Thu, 28 Dec 2006 06:13:57 -0600 (CST) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM66.ds.mot.com with Microsoft SMTPSVC(6.0.3790.2709); Thu, 28 Dec 2006 20:13:52 +0800 Message-ID: <4593B43D.8090006@motorola.com> Date: Thu, 28 Dec 2006 17:40:37 +0530 From: Liyaqatali User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Contradicting AVPs in 4006 ? References: In-Reply-To: X-OriginalArrivalTime: 28 Dec 2006 12:13:52.0688 (UTC) FILETIME=[A38FFB00:01C72A79] X-Spam-Score: 2.2 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1823174826==" Errors-To: dime-bounces@ietf.org --===============1823174826== Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Hi Tolga,

Thanks for your response.
Well, I agree with you that Service-Identifier AVP should not be present, if multiple services are used, but apparently, this isn't mentioned in the RFC hence I was a bit confused. I also agree that there may not be many scenarios where multiple parallel event based services are necessary but the reason I considered event based services is because it clearly brings out the contradiction.
I also feel that conditional AVPs should be mentioned in the RFC like the way the presence of Subscription-Id AVP is mentioned in most of the sections of the RFC because these are optional AVPs at the command level.
I was wondering, Is there a reason why it isn't explicitly mentioned in the RFC?

Regards,
Liyaqatali G Nadaf

Tolga Asveren wrote: 
Hi Liyaqatali,

I guess it makes sense to use the values present in
Multiple-Services-Credit-Control AVP if there is a contradiction. I even
would expect Service-Identifier AVP not to be present if multiple services
are used.

BTW, I am not sure whether event based scenarios for CHECK_BALANCE and
PRICE_ENQUIRY can be used with multiple services.
Multiple-Services-Credit-Control AVP does not have
Cost-Information/Check-Balance-Result AVPs. There is of course the wildcard
*[ AVP ], but I would expect these AVPs to be specifically mentioned, if
there was an intention to use them. There are probably not many scenarios,
where multiple parallel event based services are necessary to provide a
"single service experience" from user point of view.

    Thanks,
    Tolga

-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Wednesday, December 27, 2006 9:04 AM
To: vfajardo@tari.toshiba.com; dime@ietf.org
Cc: hannes.tschofenig@siemens.com
Subject: [Dime] Contradicting AVPs in 4006 ?



Hi All,

I had a couple of questions about the command level AVP's and the
Multiple-service-credit-control AVP.

Suppose a event based CCR, with CHECK_BALANCE as the value in
Requested-Action AVP, is sent by the credit control client to the server,
so, which of the following AVP combinations should be considered by the
server to check the balance.
    -service-identifier AVP at the command level or
    -service-identifier AVP(s) in the Multiple-service-credit-control AVP or
    -both of the above AVPs

Similarly,  in the above scenario if the requested-action AVP had
PRICE_ENQUIRY as the AVP value, then wouldn't the service-identifier AVP at
the command level and
the Multiple-service-credit-control AVP be contradicting?

At a higher level, when should the command level AVPs in CCR gain priority
than the Multiple-service-credit-control AVPs?

I would appreciate if anybody can provide some inputs on this.

--

Regards,
Liyaqatali G Nadaf


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--===============1823174826== 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 --===============1823174826==-- From dime-bounces@ietf.org Fri Dec 29 03:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0D2V-0003hP-7q; Fri, 29 Dec 2006 03:24:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0D2T-0003hD-OW for dime@ietf.org; Fri, 29 Dec 2006 03:24:29 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0D2S-0007ot-Fg for dime@ietf.org; Fri, 29 Dec 2006 03:24:29 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB0003NQZG9ZO@usaga01-in.huawei.com> for dime@ietf.org; Thu, 28 Dec 2006 23:57:45 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB0005DDZG85P@usaga01-in.huawei.com> for dime@ietf.org; Thu, 28 Dec 2006 23:57:45 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JB0005UHZXLYX@usaml03-in.huawei.com> for dime@ietf.org; Fri, 29 Dec 2006 00:08:14 -0800 (PST) Date: Thu, 28 Dec 2006 23:57:44 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <5e2406980612210037i113fb36n14ce8c000bfdfb79@mail.gmail.com> To: 'Julien Bournelle' Message-id: <000f01c72b1f$06b25700$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acck21JE82s5ebWaT6auWUGZxJEB/QGQ2adw X-Spam-Score: 0.0 (/) 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 I think you are missing the point here. If you separate authentication and authorization without making sure identities are proven, You can get the HA to give a rouge node Mobile IP service, while another node gets charged for it. That is just one example for the problems ahead. Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Thursday, December 21, 2006 12:38 AM To: Madjid Nakhjiri Cc: Ahmad Muhanna; dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Hi madjid, On 12/20/06, Madjid Nakhjiri wrote: > > Hi Julien, > > > A compromised HA will of course contact AAA-MIP6 to steal service or Denial > of service attacks. I am not sure what kind of proof you are providing? If you can compromise the HA to steal the service, why would you contact the AAA-MIP6 to get an authorization ? Julien > Otherwise why would we care about HA compromise?:) > > Madjid > > > > > > Things > > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > > > Is this really a problem if the authorization server trust the HA ? > > > > Madjid>>well, define trust? > > Just because HA as a AAA client shares a key > > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. > > sure. > > > The AAA_EAP may authenticate somebody, while HA tries to get authorization > > for somebody else! So basically the HA can help the MN steal service. > > The assumption that the HA could be compromised is the reason why we > are talking about this. One question is if this assumption doesn't > bring concerns more important. > > As an example, if the HA is compromised, why should it contact the AAA_MIP6 > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 29 04:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Doy-0004Fl-4P; Fri, 29 Dec 2006 04:14:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dox-0004Fb-93; Fri, 29 Dec 2006 04:14:35 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Dou-0000nS-GZ; Fri, 29 Dec 2006 04:14:35 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 29122006 #240582; status: clean Received: from anaparthi ([172.16.17.13]) by ricky.india.internal.net (8.12.10/8.11.6) with SMTP id kBT91qPX022538; Fri, 29 Dec 2006 14:31:52 +0530 Message-ID: <004d01c72b2b$1d10d920$0d1110ac@india.internal.net> From: "Nanaparthi" To: , Date: Fri, 29 Dec 2006 14:54:16 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Dime] Missing AVP Code and definition 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="===============0253491517==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0253491517== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C72B59.3632A180" This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C72B59.3632A180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, In RFC 4005 (NASREQ) there are some AVPs which have reference in the = specification but are not declared formally with AVP code.=20 Following are the AVP's which given in Message format of RAR( = Re-Auth-Answer) & ASA (Abort-Session-Answer). But no where description = included. 1. Redirected-Host=20 2. Redirected-Host-Usage=20 3. Redirected-Host-Cache-Time=20 4. Redirected-Max-Cache-Time Are they defined in some other RFC or do we have to use internally = defined values for them? Thanks in Advance. Regards,=20 Naresh Babu A.=20 Software Engineer=20 IntelliNet Technologies India Pvt. Ltd. 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2304 Off - Fax.......: + 91 80 25202947 ------=_NextPart_000_004A_01C72B59.3632A180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
In RFC 4005 = (NASREQ) there are some AVPs which have = reference=20 in the specification but are not declared formally with AVP code. =
 
Following are the = AVP's which=20 given in Message format of RAR( Re-Auth-Answer) = & ASA=20 (Abort-Session-Answer). But no where description=20 included.
 
1. Redirected-Host=20
2. Redirected-Host-Usage=20
3. Redirected-Host-Cache-Time
4. Redirected-Max-Cache-Time
 
Are they defined in = some other RFC=20 or do we have to use internally defined values for=20 them?
 
Thanks in = Advance.
 
Regards, =
Naresh Babu A. =
Software Engineer =
IntelliNet Technologies India = Pvt.=20 Ltd.
413/4 Oxford Towers, 139 Airport = Road,
Bangalore - 560 017
Off-Phone.....: + 91 80 51256018 = Ext:=20 2304
Off - Fax.......: + 91 80=20 25202947
 
------=_NextPart_000_004A_01C72B59.3632A180-- --===============0253491517== 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 --===============0253491517==-- From dime-bounces@ietf.org Fri Dec 29 04:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dx0-0007Fp-N9; Fri, 29 Dec 2006 04:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dwx-0007CD-F7 for dime@ietf.org; Fri, 29 Dec 2006 04:22:52 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Dwv-0002iR-N8 for dime@ietf.org; Fri, 29 Dec 2006 04:22:51 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 29122006 #240582; status: clean Received: from anaparthi ([172.16.17.13]) by ricky.india.internal.net (8.12.10/8.11.6) with SMTP id kBT9ABPX023040 for ; Fri, 29 Dec 2006 14:40:12 +0530 Message-ID: <008f01c72b2c$45df83a0$0d1110ac@india.internal.net> From: "Nanaparthi" To: Date: Fri, 29 Dec 2006 15:02:34 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Dime] Missing AVP Code and definition 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="===============0571483820==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0571483820== Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C72B5A.5F019A20" This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C72B5A.5F019A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, In RFC 4005 (NASREQ) there are some AVPs which have reference in the = specification but are not declared formally with AVP code.=20 Following are the AVP's which given in Message format of RAR( = Re-Auth-Answer) & ASA (Abort-Session-Answer). But no where description = included. 1. Redirected-Host=20 2. Redirected-Host-Usage=20 3. Redirected-Host-Cache-Time=20 4. Redirected-Max-Cache-Time Are they defined in some other RFC or do we have to use internally = defined values for them? Thanks in Advance. Regards,=20 Naresh Babu A.=20 Software Engineer=20 IntelliNet Technologies India Pvt. Ltd. 413/4 Oxford Towers, 139 Airport Road, Bangalore - 560 017 Off-Phone.....: + 91 80 51256018 Ext: 2304 Off - Fax.......: + 91 80 25202947 ------=_NextPart_000_008C_01C72B5A.5F019A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
In RFC 4005 = (NASREQ) there are some AVPs which have = reference=20 in the specification but are not declared formally with AVP code. =
 
Following = are the AVP's=20 which given in Message format of RAR( Re-Auth-Answer) &=20 ASA (Abort-Session-Answer). But no where description=20 included.
 
1. Redirected-Host=20
2. Redirected-Host-Usage
3. Redirected-Host-Cache-Time
4. Redirected-Max-Cache-Time
 
Are they defined in = some other RFC=20 or do we have to use internally defined values for=20 them?
 
Thanks in = Advance.
 
Regards, =
Naresh Babu A. =
Software Engineer =
IntelliNet Technologies India = Pvt.=20 Ltd.
413/4 Oxford Towers, 139 Airport = Road,
Bangalore - 560 017
Off-Phone.....: + 91 80 51256018 = Ext:=20 2304
Off - Fax.......: + 91 80=20 25202947
 
------=_NextPart_000_008C_01C72B5A.5F019A20-- --===============0571483820== 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 --===============0571483820==-- From dime-bounces@ietf.org Fri Dec 29 04:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dzs-0007kC-PU; Fri, 29 Dec 2006 04:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Dzq-0007jw-Ve; Fri, 29 Dec 2006 04:25:51 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Dzo-0003KB-Tg; Fri, 29 Dec 2006 04:25:50 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kBT9Pkv24972; Fri, 29 Dec 2006 04:25:46 -0500 (EST) Received: from [47.130.24.117] ([47.130.24.117] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 04:25:50 -0500 Message-ID: <4594DEFC.8010609@nortel.com> Date: Fri, 29 Dec 2006 04:25:16 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Nanaparthi Subject: Re: [Dime] Missing AVP Code and definition References: <004d01c72b2b$1d10d920$0d1110ac@india.internal.net> In-Reply-To: <004d01c72b2b$1d10d920$0d1110ac@india.internal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Dec 2006 09:25:50.0609 (UTC) FILETIME=[54969010:01C72B2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dime-request@ietf.org, 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 They come from RFC 3588, along with the commands themselves. I tried to verify on this list that these AVPs are mutually exclusive to those that would be returned in an actual answer a few weeks back, but got no response. Nanaparthi wrote: > Hi All, > > In RFC 4005 (NASREQ) there are some AVPs which have reference in the specification but are not declared formally with AVP code. > > Following are the AVP's which given in Message format of RAR( Re-Auth-Answer) & ASA (Abort-Session-Answer). But no where description included. > > 1. Redirected-Host > 2. Redirected-Host-Usage > 3. Redirected-Host-Cache-Time > 4. Redirected-Max-Cache-Time > > Are they defined in some other RFC or do we have to use internally defined values for them? > > Thanks in Advance. > > Regards, > Naresh Babu A. > Software Engineer > IntelliNet Technologies India Pvt. Ltd. > 413/4 Oxford Towers, 139 Airport Road, > Bangalore - 560 017 > Off-Phone.....: + 91 80 51256018 Ext: 2304 > Off - Fax.......: + 91 80 25202947 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Dec 29 05:21:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ErZ-0001NV-TD; Fri, 29 Dec 2006 05:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ErY-0001NH-MD; Fri, 29 Dec 2006 05:21:20 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ErG-0007Aq-PM; Fri, 29 Dec 2006 05:21:20 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 29122006 #240582; status: clean Received: from anaparthi ([172.16.17.13]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id kBTA8JPX027838; Fri, 29 Dec 2006 15:38:20 +0530 Message-ID: <019701c72b34$653849f0$0d1110ac@india.internal.net> From: "Nanaparthi" To: "Tom-PT Taylor" References: <004d01c72b2b$1d10d920$0d1110ac@india.internal.net> <4594DEFC.8010609@nortel.com> Subject: Re: [Dime] Missing AVP Code and definition Date: Fri, 29 Dec 2006 15:19:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: dime-request@ietf.org, 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, I verified RFC 3588. But I was unable to find the those required AVPs . Thanks, Naresh Babu A. ----- Original Message ----- From: "Tom-PT Taylor" To: "Nanaparthi" Cc: ; Sent: Friday, December 29, 2006 2:55 PM Subject: Re: [Dime] Missing AVP Code and definition > They come from RFC 3588, along with the commands themselves. I tried to > verify on this list that these AVPs are mutually exclusive to those that > would be returned in an actual answer a few weeks back, but got no > response. > > Nanaparthi wrote: >> Hi All, >> >> In RFC 4005 (NASREQ) there are some AVPs which have reference in the >> specification but are not declared formally with AVP code. Following are >> the AVP's which given in Message format of RAR( Re-Auth-Answer) & ASA >> (Abort-Session-Answer). But no where description included. >> >> 1. Redirected-Host 2. Redirected-Host-Usage 3. Redirected-Host-Cache-Time >> 4. Redirected-Max-Cache-Time >> >> Are they defined in some other RFC or do we have to use internally >> defined values for them? >> >> Thanks in Advance. >> >> Regards, Naresh Babu A. Software Engineer IntelliNet Technologies India >> Pvt. Ltd. >> 413/4 Oxford Towers, 139 Airport Road, >> Bangalore - 560 017 >> Off-Phone.....: + 91 80 51256018 Ext: 2304 >> Off - Fax.......: + 91 80 25202947 >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Dec 29 05:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0F0K-0004aq-VX; Fri, 29 Dec 2006 05:30:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0F0H-0004ad-Sn; Fri, 29 Dec 2006 05:30:22 -0500 Received: from [59.145.147.70] (helo=ricky.india.internal.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0F01-0001NI-GG; Fri, 29 Dec 2006 05:30:21 -0500 X-Anti-Virus: Cyberoam Anti-Virus for SMTP; Kaspersky 5.5.3/RELEASE, bases: 29122006 #240582; status: clean Received: from anaparthi ([172.16.17.13]) by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id kBTAHKPX028710; Fri, 29 Dec 2006 15:47:26 +0530 Message-ID: <01bd01c72b35$aa9019a0$0d1110ac@india.internal.net> From: "Nanaparthi" To: "Nanaparthi" , "Tom-PT Taylor" Subject: Re: [Dime] Missing AVP Code and definition Date: Fri, 29 Dec 2006 16:09:43 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dime-request@ietf.org, 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, I verified RFC 3588. But I was unable to find the those required AVPs . It will be helpful if somebody come with solution. Thanks, Naresh Babu A. ----- Original Message ----- From: "Nanaparthi" To: "Tom-PT Taylor" Cc: ; Sent: Friday, December 29, 2006 3:19 PM Subject: Re: [Dime] Missing AVP Code and definition > Hi, > > I verified RFC 3588. But I was unable to find the those required AVPs . > > Thanks, > Naresh Babu A. > > ----- Original Message ----- > From: "Tom-PT Taylor" > To: "Nanaparthi" > Cc: ; > Sent: Friday, December 29, 2006 2:55 PM > Subject: Re: [Dime] Missing AVP Code and definition > > >> They come from RFC 3588, along with the commands themselves. I tried to >> verify on this list that these AVPs are mutually exclusive to those that >> would be returned in an actual answer a few weeks back, but got no >> response. >> >> Nanaparthi wrote: >>> Hi All, >>> >>> In RFC 4005 (NASREQ) there are some AVPs which have reference in the >>> specification but are not declared formally with AVP code. Following are >>> the AVP's which given in Message format of RAR( Re-Auth-Answer) & ASA >>> (Abort-Session-Answer). But no where description included. >>> >>> 1. Redirected-Host 2. Redirected-Host-Usage 3. >>> Redirected-Host-Cache-Time 4. Redirected-Max-Cache-Time >>> >>> Are they defined in some other RFC or do we have to use internally >>> defined values for them? >>> >>> Thanks in Advance. >>> >>> Regards, Naresh Babu A. Software Engineer IntelliNet Technologies India >>> Pvt. Ltd. >>> 413/4 Oxford Towers, 139 Airport Road, >>> Bangalore - 560 017 >>> Off-Phone.....: + 91 80 51256018 Ext: 2304 >>> Off - Fax.......: + 91 80 25202947 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 Dec 29 06:20:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FnC-0006Ga-5d; Fri, 29 Dec 2006 06:20:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0FnA-0006Dv-QB for dime@ietf.org; Fri, 29 Dec 2006 06:20:52 -0500 Received: from [2001:1560:bb0:768:20c:f1ff:fe9c:8c73] (helo=noir.netzwert.ag) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Fn8-0003TJ-Br for dime@ietf.org; Fri, 29 Dec 2006 06:20:52 -0500 Received: by noir.netzwert.ag (Postfix, from userid 531) id 4BAEC81736A; Fri, 29 Dec 2006 12:20:47 +0100 (CET) Date: Fri, 29 Dec 2006 12:20:47 +0100 From: Alexis Hildebrandt To: dime@ietf.org Subject: Re: [Dime] Missing AVP Code and definition Message-ID: <20061229112046.GA23673@noir.netzwert.ag> References: <004d01c72b2b$1d10d920$0d1110ac@india.internal.net> <4594DEFC.8010609@nortel.com> <019701c72b34$653849f0$0d1110ac@india.internal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <019701c72b34$653849f0$0d1110ac@india.internal.net> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 assume that this might just be a typographical error where 'Redirected' was written instead of 'Redirect' and that therefore: 1. Redirected-Host AVP is likely to actually be a reference to Redirect-Host AVP, which is defined in sect. 6.12 of RFC 3588 2. Redirected-Host-Usage AVP rather refers to the Redirect-Host-Usage AVP, which is specified in sect 6.13 of RFC 3588 3. Redirected-Host-Cache-Time again should probably read Redirect-Host-Cache-Time, which was also an error in RFC 3588 and in fact is Redirect-Max-Cache-Time. For details please search for the errata of RFC 3588 at: http://www.rfc-editor.org/errata.html 4. And Redirected-Max-Cache-Time AVP was presumably meant to be Redirect-Max-Cache-Time AVP, that is described in sect. 6.14 of RFC 3588 Maybe one of the authors of RFC 4005 can confirm this. Regards, A. Hildebrandt -- Alexis Hildebrandt, Software Development Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany Voice: +49.30.590080-1172, Fax: +49.30.5900800-700 http://www.netzwert.ag _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Dec 29 10:57:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0K7C-0008PH-OP; Fri, 29 Dec 2006 10:57:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0K7B-0008P9-QV for dime@ietf.org; Fri, 29 Dec 2006 10:57:49 -0500 Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0K78-0003Pt-4i for dime@ietf.org; Fri, 29 Dec 2006 10:57:49 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id kBTFvWvH002677; Sat, 30 Dec 2006 00:57:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id kBTFvXko026244; Sat, 30 Dec 2006 00:57:33 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with ESMTP id AAA26243; Sat, 30 Dec 2006 00:57:32 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id kBTFvW3L001243; Sat, 30 Dec 2006 00:57:32 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id kBTFvWSR019503; Sat, 30 Dec 2006 00:57:32 +0900 (JST) Received: from steelhead ([172.30.24.105]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0JB100JJPLNTG5HD@mail.po.toshiba.co.jp>; Sat, 30 Dec 2006 00:57:32 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.63) (envelope-from ) id 1H0K6r-0007R1-4G; Fri, 29 Dec 2006 07:57:29 -0800 Date: Fri, 29 Dec 2006 10:57:29 -0500 From: Yoshihiro Ohba Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <000f01c72b1f$06b25700$02fda8c0@china.huawei.com> To: Madjid Nakhjiri Message-id: <20061229155728.GB28309@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <5e2406980612210037i113fb36n14ce8c000bfdfb79@mail.gmail.com> <000f01c72b1f$06b25700$02fda8c0@china.huawei.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Madjid, How this problem is different from the problem that would arise from separating accounting and authentication/authorization? Yoshihiro Ohba On Thu, Dec 28, 2006 at 11:57:44PM -0800, Madjid Nakhjiri wrote: > I think you are missing the point here. If you separate authentication and > authorization without making sure identities are proven, You can get the HA > to give a rouge node Mobile IP service, while another node gets charged for > it. That is just one example for the problems ahead. > > Madjid > > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Thursday, December 21, 2006 12:38 AM > To: Madjid Nakhjiri > Cc: Ahmad Muhanna; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > Hi madjid, > > On 12/20/06, Madjid Nakhjiri wrote: > > > > Hi Julien, > > > > > > A compromised HA will of course contact AAA-MIP6 to steal service or > Denial > > of service attacks. I am not sure what kind of proof you are providing? > > If you can compromise the HA to steal the service, why would you > contact the AAA-MIP6 to get an authorization ? > > Julien > > > Otherwise why would we care about HA compromise?:) > > > > Madjid > > > > > > > > > > Things > > > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > > > > > Is this really a problem if the authorization server trust the HA ? > > > > > > Madjid>>well, define trust? > > > Just because HA as a AAA client shares a key > > > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. > > > > sure. > > > > > The AAA_EAP may authenticate somebody, while HA tries to get > authorization > > > for somebody else! So basically the HA can help the MN steal service. > > > > The assumption that the HA could be compromised is the reason why we > > are talking about this. One question is if this assumption doesn't > > bring concerns more important. > > > > As an example, if the HA is compromised, why should it contact the > AAA_MIP6 > > > > > > > > > > > > > > > > _______________________________________________ > 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 Dec 29 18:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0QtI-0000aQ-Vv; Fri, 29 Dec 2006 18:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0QtH-0000ZX-QT for dime@ietf.org; Fri, 29 Dec 2006 18:11:55 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0QtG-0007tE-Fl for dime@ietf.org; Fri, 29 Dec 2006 18:11:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB200IQN5RRVE@usaga01-in.huawei.com> for dime@ietf.org; Fri, 29 Dec 2006 15:11:51 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JB2006B85RQ7V@usaga01-in.huawei.com> for dime@ietf.org; Fri, 29 Dec 2006 15:11:51 -0800 (PST) Received: from N737011 (pool-71-112-126-182.sttlwa.dsl-w.verizon.net [71.112.126.182]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JB200KSJ694VY@usaml03-in.huawei.com> for dime@ietf.org; Fri, 29 Dec 2006 15:22:20 -0800 (PST) Date: Fri, 29 Dec 2006 15:11:50 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split In-reply-to: <20061229155728.GB28309@steelhead> To: 'Yoshihiro Ohba' Message-id: <008701c72b9e$b92befc0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccrYhRBgbg0/bmfSkyJSzLZWFE3kQAPFzmQ X-Spam-Score: 0.0 (/) 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 Not sure what the problem you are referring to, is, but there can be several problems if you just separate authentication from authz/accounting without taking proper precautions. I just brought one up directly related to Julien's question. Madjid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Friday, December 29, 2006 7:57 AM To: Madjid Nakhjiri Cc: 'Julien Bournelle'; dime@ietf.org Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split Madjid, How this problem is different from the problem that would arise from separating accounting and authentication/authorization? Yoshihiro Ohba On Thu, Dec 28, 2006 at 11:57:44PM -0800, Madjid Nakhjiri wrote: > I think you are missing the point here. If you separate authentication and > authorization without making sure identities are proven, You can get the HA > to give a rouge node Mobile IP service, while another node gets charged for > it. That is just one example for the problems ahead. > > Madjid > > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Thursday, December 21, 2006 12:38 AM > To: Madjid Nakhjiri > Cc: Ahmad Muhanna; dime@ietf.org > Subject: Re: [Dime] Diameter Mobile IPv6 HA-to-AAAH Support: Server Split > > Hi madjid, > > On 12/20/06, Madjid Nakhjiri wrote: > > > > Hi Julien, > > > > > > A compromised HA will of course contact AAA-MIP6 to steal service or > Denial > > of service attacks. I am not sure what kind of proof you are providing? > > If you can compromise the HA to steal the service, why would you > contact the AAA-MIP6 to get an authorization ? > > Julien > > > Otherwise why would we care about HA compromise?:) > > > > Madjid > > > > > > > > > > Things > > > > that cause problem are when the AAA-MIP is different from AAA_EAP, > > > > > > Is this really a problem if the authorization server trust the HA ? > > > > > > Madjid>>well, define trust? > > > Just because HA as a AAA client shares a key > > > with the AAA_MIP, it does not mean it cannot lie to the AAA_MIP. > > > > sure. > > > > > The AAA_EAP may authenticate somebody, while HA tries to get > authorization > > > for somebody else! So basically the HA can help the MN steal service. > > > > The assumption that the HA could be compromised is the reason why we > > are talking about this. One question is if this assumption doesn't > > bring concerns more important. > > > > As an example, if the HA is compromised, why should it contact the > AAA_MIP6 > > > > > > > > > > > > > > > > _______________________________________________ > 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