From dime-bounces@ietf.org Thu Nov 01 08:13:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InYuz-0007ms-Mh; Thu, 01 Nov 2007 08:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InYuy-0007ZM-Fs for dime@ietf.org; Thu, 01 Nov 2007 08:13:00 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InYuq-00079w-Cr for dime@ietf.org; Thu, 01 Nov 2007 08:12:53 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lA1CBtdM017744; Thu, 1 Nov 2007 07:11:55 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4729C27F.6050906@tari.toshiba.com> Date: Thu, 01 Nov 2007 08:11:43 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "Zeltsan, Zachary \(Zachary\)" Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> In-Reply-To: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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, > > I have noticed what appears to be an omission in > draft-ietf-dime-rfc3558bis. > Whereas RFC 3558 explicitly required IPsec for the client with an > option for TLS, now the TLS is mentioned as an OPTION, but nothing is > said about IPsec. Is IPsec still mandatory? If not, is it still an > option? I strongly believe that the text must be explicit. > From the discussion we had a few months ago, the conclusion was that extensive use case references to IPsec is not necessary because diameter has no deep protocol interaction/dependency with IPsec (unlike TLS); i.e. IPsec can be used independent of and transparent from diameter. (See http://www.tschofenig.priv.at:8080/diameter-interop/issue52). However, use of IPsec still remains as an option under security considerations in Sec 2.2 and Sec 13. What type of 'explicit text' do you have in mind ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 01 16:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IngkC-0008HD-EU; Thu, 01 Nov 2007 16:34:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IngkB-0008Gz-7h for dime@ietf.org; Thu, 01 Nov 2007 16:34:23 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ingk4-00014G-FH for dime@ietf.org; Thu, 01 Nov 2007 16:34:23 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lA1KY3WM018812; Thu, 1 Nov 2007 15:34:10 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.11]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 15:33:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Thu, 1 Nov 2007 15:33:46 -0500 Message-ID: <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> In-Reply-To: <4729C27F.6050906@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime]: A Potential Issue with the New Text for RFC 3558bis Thread-Index: AcgcgHTpGrtYIUeWRSqe5B6pm5tyUwARFgHw References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> From: "Zeltsan, Zachary \(Zachary\)" To: "Victor Fajardo" X-OriginalArrivalTime: 01 Nov 2007 20:33:48.0209 (UTC) FILETIME=[81844210:01C81CC6] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) 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 Victor, Do I understand it right then that what the current specification says is that the client=20 1) MAY use TLS , or=20 2) MAY use IPsec, or=20 3) Simply have no security whatsoever?=20 With thanks, Zachary > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: Thursday, November 01, 2007 8:12 AM > To: Zeltsan, Zachary (Zachary) > Cc: dime@ietf.org > Subject: Re: [Dime]: A Potential Issue with the New Text for=20 > RFC 3558bis >=20 > Hi, >=20 > > > > I have noticed what appears to be an omission in=20 > > draft-ietf-dime-rfc3558bis. > > Whereas RFC 3558 explicitly required IPsec for the client with an=20 > > option for TLS, now the TLS is mentioned as an OPTION, but=20 > nothing is=20 > > said about IPsec. Is IPsec still mandatory? If not, is it still an=20 > > option? I strongly believe that the text must be explicit. > > >=20 > From the discussion we had a few months ago, the conclusion=20 > was that extensive use case references to IPsec is not=20 > necessary because diameter has no deep protocol=20 > interaction/dependency with IPsec (unlike TLS); i.e. IPsec=20 > can be used independent of and transparent from diameter.=20 > (See=20 > http://www.tschofenig.priv.at:8080/diameter-interop/issue52).=20 > However, use of IPsec still remains as an option under=20 > security considerations in Sec 2.2 and Sec 13. What type of=20 > 'explicit text' do you have in mind ? >=20 > regards, > victor >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 01 16:45:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingu3-0008N2-Ol; Thu, 01 Nov 2007 16:44:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingu3-0008Mv-71 for dime@ietf.org; Thu, 01 Nov 2007 16:44:35 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ingu2-0006IA-Ur for dime@ietf.org; Thu, 01 Nov 2007 16:44:35 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lA1KiPNZ020153; Thu, 1 Nov 2007 15:44:25 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <472A3AA2.2090001@tari.toshiba.com> Date: Thu, 01 Nov 2007 16:44:18 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "Zeltsan, Zachary \(Zachary\)" Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> In-Reply-To: <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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. Though there is a strong recommendation in Sec 2.2 against option (3) below. regards, victor > Victor, > > Do I understand it right then that what the current specification says > is that the client > 1) MAY use TLS , or > 2) MAY use IPsec, or > 3) Simply have no security whatsoever? > > With thanks, > > Zachary > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 02 15:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2Ks-0006Qn-DB; Fri, 02 Nov 2007 15:37:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2Kr-0006QZ-GY for dime@ietf.org; Fri, 02 Nov 2007 15:37:41 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io2Kr-0003tK-52 for dime@ietf.org; Fri, 02 Nov 2007 15:37:41 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lA2Jbdcv024972; Fri, 2 Nov 2007 14:37:39 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.11]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 14:37:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Fri, 2 Nov 2007 14:37:38 -0500 Message-ID: <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> In-Reply-To: <472A3AA2.2090001@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime]: A Potential Issue with the New Text for RFC 3558bis Thread-Index: AcgcyAKmiekOAzU1S+CyDber6jCN1AAvQDGg References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> From: "Zeltsan, Zachary \(Zachary\)" To: "Victor Fajardo" X-OriginalArrivalTime: 02 Nov 2007 19:37:39.0116 (UTC) FILETIME=[D3CB36C0:01C81D87] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) 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 Then, in my opinion, it is a step back from the RFC3588 that has stronger security requirements (section 2.2): "Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec)." The draft 3588bis states only that "The Diameter protocol SHOULD NOT be used without any security mechanism." What is the reason for relaxing security? With thanks, Zachary > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: Thursday, November 01, 2007 4:44 PM > To: Zeltsan, Zachary (Zachary) > Cc: dime@ietf.org > Subject: Re: [Dime]: A Potential Issue with the New Text for=20 > RFC 3558bis >=20 > Yes. Though there is a strong recommendation in Sec 2.2 against option > (3) below. >=20 > regards, > victor >=20 > > Victor, > > > > Do I understand it right then that what the current=20 > specification says=20 > > is that the client > > 1) MAY use TLS , or > > 2) MAY use IPsec, or > > 3) Simply have no security whatsoever?=20 > > > > With thanks, > > > > Zachary > > =20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 02 17:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io488-0001Cd-5i; Fri, 02 Nov 2007 17:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io486-0001Aw-VV for dime@ietf.org; Fri, 02 Nov 2007 17:32:38 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io480-0000q6-PB for dime@ietf.org; Fri, 02 Nov 2007 17:32:38 -0400 Received: from [192.168.1.10] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (rwcrmhc11) with SMTP id <20071102213219m11004kijke>; Fri, 2 Nov 2007 21:32:19 +0000 Message-Id: <1A0BD078-D3C9-44E5-95D4-89B47DF8467F@g11.org.uk> From: ken carlberg To: Hannes Tschofenig In-Reply-To: <47247DBF.9090101@gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Fri, 2 Nov 2007 17:32:18 -0400 References: <471DA62B.9050706@gmx.net> <47220518.1020006@gmx.net> <8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk> <47247DBF.9090101@gmx.net> X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: dime@ietf.org Subject: [Dime] Re: RPH Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, First, my apologies for the very tardy response. And second, thanks for the extended thoughts below. It helps clarify the question you raised previously. Now, taking your example as is, I have no disagreement.....*within* the context of the scenario you describe. However, one can take a different approach and consider SIP operating in a walled garden, or even in a B2BUA with co-resident SBCs. In either of these cases, QoS is derived from a statistical estimate where one correlates a bandwidth range per call (which are congruent with data paths) and one traffic engineers the paths accordingly. In other words, there are efforts that *loosely* emulate some circuit switched designs that aren't reliant on direct references to QoS. They simply count calls and use a max count to minimize the chance of congestion. Thus, I can still have an interest to prioritize calls, but I may not have a need to articulate anything about QoS in my signaling or data packets. And again, I'm in agreement with your subsequent email where QoS profiles can be defined that only include the subset of QoS parameters that are needed. But, I go back to the email exchange I came across where someone didn't have an interest in your QoS parameters draft in order to support their need to respond to Priority parameters because they had no interest in QoS. In viewing the situation as a whole, I think it might be better to look into defining an optional AVP extension to rfc-4740 that correlates to the resource priority field of rfc-4412. cheers, -ken On Oct 28, 2007, at 8:17 AM, Hannes Tschofenig wrote: > Hi Ken, > > let me give you a concrete example. > > Let's assume a SIP proxy receives a RPH and wants to ask the AAA > server whether this user is authorized to use this specific RPH. > Here is how this could look like, assuming that Filter-Rules are not > important in this specific case (they are optional anyway). > > > AAA client -> AAA server: > ---------------------------- > > * QoS-ObjectType > > with the information that the provided QoS information is of type > "QoS-Desired". The semantic is > "Please authorize the indicated QoS" > > * RPH Priority Parameter (from Section 4.11 of > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt) > encapsulated > in the QoSBlob AVP (as the only QoS parameter in this example). > > These two AVPs are encapsulated in the QoSBlob-Group and contained > in the QoS-Resources AVP. This encapsulation is simply necessary > when you use grouped AVPs. Without using grouped AVPs one would have > to add additional fields to indicate how the individual AVPs relate > to each other. > > Note that the QoS-Profile AVP, which indicates the QoS profile, is > not necessary in this example since the RPH Priority refers to a > parameter from the base profile document. (This is not yet in the > draft since we haven't published the updated draft based on the > provided feedback yet). > > > > AAA client <- AAA server: > ---------------------------- > > Authorization successful or failed. No QoS information needs to be > repeated here in our example. > > > Now you tell me what should be further removed. Is this really > complicated or does the current document just look complicated? > > > Ciao > Hannes > > ken carlberg wrote: >> >> On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote: >> >>> Hi Ken, >>> >>> ken carlberg wrote: >>>> Hannes, >>>> >>>> What are your thoughts about defining a new AVP exclusively for >>>> priority? I don't have concerns about the inclusion of priority >>>> in the QoS parameters draft. However, I recently came across an >>>> email exchange related to IMS where one of the participants >>>> didn't want to consider using the QoS parameters draft for >>>> validating SIP R-P information because of the bundled QoS. >>> Can you more specific on how the desired approach would look like? >> >> at a very high level, an approach that strips out the QoS elements >> discussed in >> draft-ietf-dime-diameter-qos-01.txt >> draft-ietf-dime-qos-parameters-01.txt >> and focuses on the application of AAA of Priority values we may see >>> from protocols like SIP and its R-P header. And yes, this probably >> equates to thinner documents :-) >> >> -ken > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 02 21:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io7w8-00023V-P5; Fri, 02 Nov 2007 21:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io7w6-00022S-US for dime@ietf.org; Fri, 02 Nov 2007 21:36:31 -0400 Received: from alnrmhc15.comcast.net ([206.18.177.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io7vx-0004MB-AJ for dime@ietf.org; Fri, 02 Nov 2007 21:36:30 -0400 Received: from gwzpc (c-76-28-183-80.hsd1.wa.comcast.net[76.28.183.80]) by comcast.net (alnrmhc15) with SMTP id <20071103013605b1500p01t4e>; Sat, 3 Nov 2007 01:36:05 +0000 From: "Glen Zorn" To: "'Zeltsan, Zachary \(Zachary\)'" , "'Victor Fajardo'" References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> In-Reply-To: <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Fri, 2 Nov 2007 18:35:02 -0700 Message-ID: <00a301c81db9$c1baa8d0$452ffa70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgcyAKmiekOAzU1S+CyDber6jCN1AAvQDGgAA0cXGA= Content-Language: en-us x-cr-hashedpuzzle: Awac I6IC Jr2s JvH+ KRRc KydG PZcK P6vt S9Os X6j6 ZgFo aw6M fINs fhje gBUj hJZI; 3; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA7AHYAZgBhAGoAYQByAGQAbwBAAHQAYQByAGkALgB0AG8AcwBoAGkAYgBhAC4AYwBvAG0AOwB6AGUAbAB0AHMAYQBuAEAAYQBsAGMAYQB0AGUAbAAtAGwAdQBjAGUAbgB0AC4AYwBvAG0A; Sosha1_v1; 7; {0CC63AC9-B084-475C-9E83-DE5F912F88ED}; ZwBsAGUAbgB6AG8AcgBuAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0AA==; Sat, 03 Nov 2007 01:34:51 GMT; UgBFADoAIABbAEQAaQBtAGUAXQA6ACAAQQAgAFAAbwB0AGUAbgB0AGkAYQBsACAASQBzAHMAdQBlACAAdwBpAHQAaAAgAHQAaABlACAATgBlAHcAIABUAGUAeAB0ACAAZgBvAHIAIABSAEYAQwAgADMANQA1ADgAYgBpAHMA x-cr-puzzleid: {0CC63AC9-B084-475C-9E83-DE5F912F88ED} X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 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 Personally, I think that it would both simplify things & improve security considerably to simply make TLS a MUST & delete the mention of IPsec. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Nov 03 08:59:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoIYy-0005We-Ot; Sat, 03 Nov 2007 08:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoIYx-0005UU-Rn for dime@ietf.org; Sat, 03 Nov 2007 08:57:19 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IoIYo-0005RC-1v for dime@ietf.org; Sat, 03 Nov 2007 08:57:15 -0400 Received: by py-out-1112.google.com with SMTP id d32so3896581pye for ; Sat, 03 Nov 2007 05:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=iqByfOIJPWRHOulOMWlxH43nTg85xFhWubSM0GRswlY=; b=OQemAM2t5DwVYffMy2x4HkcTngd4Lu6JXEUzkgxiyHwiRU8YK7g6j/WDPYW3Xw4TpozUD7kQoXr6hXjm8EaGoZbRQaaxv8xfgh8t3B4mrCqITwDEsyIJIOfN+8s0b2+2cKxgb6d0yYH0e5sRMhwxyff2JV7rQvrPFJzECp+ZnuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tkl7hu+K2vLGETkzifUglFFEy8RYK00XpMEfcqOZ4XkXt5hZNalBh0jZTKzcYI0jy+cfPKDzkTYeVMIAk0m+E3aC7zYFJB43Gy+yWaJ/z4ESZq8x1Flr/kwwpnHAQLZQbGMShE/tQm2G90a0G3m7rjW9r2P94AkAkUMs/pgmlXk= Received: by 10.35.77.18 with SMTP id e18mr3407912pyl.1194094610695; Sat, 03 Nov 2007 05:56:50 -0700 (PDT) Received: by 10.35.68.15 with HTTP; Sat, 3 Nov 2007 05:56:50 -0700 (PDT) Message-ID: Date: Sat, 3 Nov 2007 13:56:50 +0100 From: "Thomas Lindgren" To: "Zeltsan, Zachary (Zachary)" Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis In-Reply-To: <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> MIME-Version: 1.0 References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543071329==" Errors-To: dime-bounces@ietf.org --===============1543071329== Content-Type: multipart/alternative; boundary="----=_Part_26132_36862.1194094610682" ------=_Part_26132_36862.1194094610682 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/2/07, Zeltsan, Zachary (Zachary) wrote: > > > Then, in my opinion, it is a step back from the RFC3588 that has > stronger security requirements (section 2.2): > > "Diameter clients, such as Network Access Servers (NASes) and Mobility > Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. > Diameter servers MUST support TLS and IPsec. The Diameter protocol > MUST NOT be used without any security mechanism (TLS or IPsec)." > > The draft 3588bis states only that "The Diameter protocol SHOULD NOT be > used without any security > mechanism." > > What is the reason for relaxing security? Zachary, While I certainly didn't write it, it does seem reasonable to me. First, requiring support for IPSec doesn't seem like an issue that needs to be addressed in the diameter protocol. Second, since diameter is a peer-to-peer protocol, the distinction of requiring TLS support in 'servers' but permitting its absence in other elements seems odd, or perhaps outdated. Third, perhaps we will want other solutions than IPSec or the base spec TLS usage. (How about an alternative simpler stunnel-style TLS, anyone?) So the MUST/MAY requirements in the first paragraph seem too strong and inflexible. Regarding the MUST NOT, I have in practice seen little demand for either IPSec or TLS so far, so requiring it seems like overkill (or an invitation to ignore full compliance). Thus, the second formulation seems fine to me. (Ideally, I'd instead prefer to see the detailed transport layer security issues moved into new RFCs instead.) Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_26132_36862.1194094610682 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/2/07, Zeltsan, Zachary (Zachary) <zeltsan@alcatel-lucent.com> wrote:

Then, in my opinion, it is a step back from the RFC3588 that has
stronger security requirements (section 2.2):

"Diameter clients, such as Network Access Servers (NASes) and Mobility
   Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS].
   Diameter servers MUST support TLS and IPsec.  The Diameter protocol
   MUST NOT be used without any security mechanism (TLS or IPsec)."

The draft 3588bis states only that "The Diameter protocol SHOULD NOT be
used without any security
   mechanism."

What is the reason for relaxing security?

Zachary,

While I certainly didn't write it, it does seem reasonable to me. First, requiring support for IPSec doesn't seem like an issue that needs to be addressed in the diameter protocol. Second, since diameter is a peer-to-peer protocol, the distinction of requiring TLS support in 'servers' but permitting its absence in other elements seems odd, or perhaps outdated. Third, perhaps we will want other solutions than IPSec or the base spec TLS usage. (How about an alternative simpler stunnel-style TLS, anyone?) So the MUST/MAY requirements in the first paragraph seem too strong and inflexible. Regarding the MUST NOT, I have in practice seen little demand for either IPSec or TLS so far, so requiring it seems like overkill (or an invitation to ignore full compliance). Thus, the second formulation seems fine to me.

(Ideally, I'd instead prefer to see the detailed transport layer security issues moved into new RFCs instead.)

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd


------=_Part_26132_36862.1194094610682-- --===============1543071329== 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 --===============1543071329==-- From dime-bounces@ietf.org Mon Nov 05 12:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5lt-0002Sk-0A; Mon, 05 Nov 2007 12:29:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5ls-0002Rr-8H for dime@ietf.org; Mon, 05 Nov 2007 12:29:56 -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 1Ip5lq-00045q-U3 for dime@ietf.org; Mon, 05 Nov 2007 12:29:56 -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 lA5HT6jl034911; Mon, 5 Nov 2007 12:29:06 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <472F52E1.7090604@tari.toshiba.com> Date: Mon, 05 Nov 2007 12:29:05 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Thomas Lindgren Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Thomas, > While I certainly didn't write it, it does seem reasonable to me. > First, requiring support for IPSec doesn't seem like an issue that > needs to be addressed in the diameter protocol. Second, since diameter > is a peer-to-peer protocol, the distinction of requiring TLS support > in 'servers' but permitting its absence in other elements seems odd, > or perhaps outdated. Third, perhaps we will want other solutions than > IPSec or the base spec TLS usage. (How about an alternative simpler > stunnel-style TLS, anyone?) So the MUST/MAY requirements in the first > paragraph seem too strong and inflexible. Regarding the MUST NOT, I > have in practice seen little demand for either IPSec or TLS so far, so > requiring it seems like overkill (or an invitation to ignore full > compliance). Thus, the second formulation seems fine to me. I generally agree with this assessment. This was also the general feeling among implementors during past interops. That's why the current text is the way it is. Regarding 'servers' requiring TLS support, that can probably needs cleaning up as well. > > (Ideally, I'd instead prefer to see the detailed transport layer > security issues moved into new RFCs instead.) regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 05 13:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6iD-0004RS-64; Mon, 05 Nov 2007 13:30:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6iC-0004RI-K9 for dime@ietf.org; Mon, 05 Nov 2007 13:30:12 -0500 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound1-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip6iB-0005ya-Ej for dime@ietf.org; Mon, 05 Nov 2007 13:30:12 -0500 Received: from outbound1-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-blu-R.bigfish.com (Postfix) with ESMTP id 497D85015F8; Mon, 5 Nov 2007 18:30:10 +0000 (UTC) Received: from mail17-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound1-blu.bigfish.com (Postfix) with ESMTP id C26C212E0059; Mon, 5 Nov 2007 18:30:09 +0000 (UTC) Received: from mail17-blu (localhost.localdomain [127.0.0.1]) by mail17-blu-R.bigfish.com (Postfix) with ESMTP id 868B34D8157; Mon, 5 Nov 2007 18:30:09 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail17-blu (MessageSwitch) id 1194287407684633_4997; Mon, 5 Nov 2007 18:30:07 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail17-blu.bigfish.com (Postfix) with ESMTP id 06A251010060; Mon, 5 Nov 2007 18:30:06 +0000 (UTC) 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]: A Potential Issue with the New Text for RFC 3558bis Date: Mon, 5 Nov 2007 18:29:48 -0000 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8019C4198@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime]: A Potential Issue with the New Text for RFC 3558bis Thread-Index: Acgf0YJ7YnwfcprpQbO52mC/0ryQYQAB1GPA From: "Dan Warren" To: "Victor Fajardo" , "Thomas Lindgren" X-Spam-Score: -4.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 Just an observation... Doesn't all of the below not countenance for the possibility of a Diameter implementation within a single domain (ie where security is actually not an issue)? So if I were take an example of an Accounting application between a device a charging system within a single network, do I need any form of security at all? Perhaps what is needed is a description of the context within which security is required - Diameter interactions without underlying or inherent security. I certainly see no need for a security mechanism for something like Diameter-SIP-Application when deployed in a single network, as an example. Dan > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] = > Sent: 05 November 2007 17:29 > To: Thomas Lindgren > Cc: dime@ietf.org > Subject: Re: [Dime]: A Potential Issue with the New Text for = > RFC 3558bis > = > Hi Thomas, > = > > While I certainly didn't write it, it does seem reasonable to me. = > > First, requiring support for IPSec doesn't seem like an issue that = > > needs to be addressed in the diameter protocol. Second, = > since diameter = > > is a peer-to-peer protocol, the distinction of requiring = > TLS support = > > in 'servers' but permitting its absence in other elements = > seems odd, = > > or perhaps outdated. Third, perhaps we will want other = > solutions than = > > IPSec or the base spec TLS usage. (How about an alternative simpler = > > stunnel-style TLS, anyone?) So the MUST/MAY requirements in = > the first = > > paragraph seem too strong and inflexible. Regarding the MUST NOT, I = > > have in practice seen little demand for either IPSec or TLS = > so far, so = > > requiring it seems like overkill (or an invitation to ignore full = > > compliance). Thus, the second formulation seems fine to me. > = > I generally agree with this assessment. This was also the = > general feeling among implementors during past interops. = > That's why the current text is the way it is. Regarding = > 'servers' requiring TLS support, that can probably needs = > cleaning up as well. > = > > > > (Ideally, I'd instead prefer to see the detailed transport layer = > > security issues moved into new RFCs instead.) > = > regards, > victor > = > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 05 15:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip92z-00089E-JN; Mon, 05 Nov 2007 15:59:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip92y-000893-DB for dime@ietf.org; Mon, 05 Nov 2007 15:59:48 -0500 Received: from qmta06.westchester.pa.mail.comcast.net ([76.96.62.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip92y-00033X-3H for dime@ietf.org; Mon, 05 Nov 2007 15:59:48 -0500 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with smtp id 98o81Y00217dt5G0000r00; Mon, 05 Nov 2007 20:59:47 +0000 Received: from gwzPC ([76.28.183.80]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 98zm1Y0031kVLSs0000000; Mon, 05 Nov 2007 20:59:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZviYZfGE2XM9vZffY_cA:9 a=j5cnqrK4jfBy47X45oQVAiehMj0A:4 a=3I_whO4B8K8A:10 From: "Glen Zorn" To: "'Dan Warren'" , "'Victor Fajardo'" , "'Thomas Lindgren'" References: <6918D1F7F8770C4FB182838A7BDFD6C8019C4198@GSMDUBEX02.GSM.TLD> In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8019C4198@GSMDUBEX02.GSM.TLD> Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Mon, 5 Nov 2007 12:58:26 -0800 Message-ID: <004901c81fee$9d2786f0$d77694d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgf0YJ7YnwfcprpQbO52mC/0ryQYQAB1GPAAAT+TYA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Just an observation... Doesn't all of the below not countenance for the possibility of a Diameter implementation within a single domain (ie where security is actually not an issue)? So if I were take an example of an Accounting application between a device a charging system within a single network, do I need any form of security at all? [gwz] Of course not! The service providers are our friends, totally dedicated only to supplying the highest possible quality of service & all of their employees are utterly trustworthy & incorruptible. [/gwz] Perhaps what is needed is a description of the context within which security is required - Diameter interactions without underlying or inherent security. I certainly see no need for a security mechanism for something like Diameter-SIP-Application when deployed in a single network, as an example. [gwz] See above; repeat as necessary until delusion is complete. [/gwz] ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 06 07:41:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNkW-0004Mj-Op; Tue, 06 Nov 2007 07:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNkU-0004H9-OV for dime@ietf.org; Tue, 06 Nov 2007 07:41:42 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpNkR-0001i0-AA for dime@ietf.org; Tue, 06 Nov 2007 07:41:42 -0500 Received: (qmail invoked by alias); 06 Nov 2007 12:41:37 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp043) with SMTP; 06 Nov 2007 13:41:37 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ywNZOlHnyYO7LGtLKUQI5gIRNdC1xNIPdlwN8kr mpiQTK1UTukGfA Message-ID: <47306101.7090907@gmx.net> Date: Tue, 06 Nov 2007 13:41:37 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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] Re-Chartering Discussion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 are currently completing a couple of our DIME WG items. Hence, we will be ready to start new work. Please let us know whether you would like to discuss your document. We need to prepare the agenda for the meeting. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 06 07:54:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNxE-0001Q8-5d; Tue, 06 Nov 2007 07:54:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNxC-0001Fx-Kp for dime@ietf.org; Tue, 06 Nov 2007 07:54:50 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpNx9-00028x-3N for dime@ietf.org; Tue, 06 Nov 2007 07:54:50 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 13:54:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re-Chartering Discussion Date: Tue, 6 Nov 2007 13:54:39 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9430@SEHAN021MB.tcad.telia.se> In-Reply-To: <47306101.7090907@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re-Chartering Discussion Thread-Index: Acggcm+whCdl9YdETg2BvqCvdjM41AAASAPg From: To: , X-OriginalArrivalTime: 06 Nov 2007 12:54:45.0582 (UTC) FILETIME=[34E5A6E0:01C82074] X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Hannes, I would like to present (again) the Proxy Mobile IPv6 Diameter document that was surfaces in the last meeting. A revision is on its way soon. Imho that could be a potential item for a new work. Cheers, Jouni =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 6. marraskuuta 2007 14:42 > To: dime@ietf.org > Subject: [Dime] Re-Chartering Discussion >=20 >=20 > Hi all, >=20 > we are currently completing a couple of our DIME WG items.=20 > Hence, we will be ready to start new work. > Please let us know whether you would like to discuss your document. > We need to prepare the agenda for the meeting. >=20 > Ciao > Hannes >=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 Tue Nov 06 08:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOM8-00028E-8x; Tue, 06 Nov 2007 08:20:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOM7-00027M-FG for dime@ietf.org; Tue, 06 Nov 2007 08:20:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpOM7-0006fL-6X for dime@ietf.org; Tue, 06 Nov 2007 08:20:35 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 1CA532ACEE; Tue, 6 Nov 2007 13:20:05 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IpOLc-0005qr-SO; Tue, 06 Nov 2007 08:20:04 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: jouni.korhonen@teliasonera.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 06 Nov 2007 08:20:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Hannes.Tschofenig@nsn.com, charliep@nsn.com, dime@ietf.org, julien.bournelle@orange-ftgroup.com Subject: [Dime] New Version Notification for draft-ietf-dime-mip6-integrated-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 new version of I-D, draft-ietf-dime-mip6-integrated-06.txt has been successfuly submitted by Jouni Korhonen and posted to the IETF repository. Filename: draft-ietf-dime-mip6-integrated Revision: 06 Title: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Creation_date: 2007-11-06 WG ID: dime Number_of_pages: 20 Abstract: A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 06 08:30:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOVI-0004OA-Pe; Tue, 06 Nov 2007 08:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOVI-0004NP-8z; Tue, 06 Nov 2007 08:30:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpOVG-0002zE-2F; Tue, 06 Nov 2007 08:30:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 08C73328DA; Tue, 6 Nov 2007 13:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IpOVF-0008SE-UR; Tue, 06 Nov 2007 08:30:01 -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, 06 Nov 2007 08:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-06.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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-06.txt Pages : 20 Date : 2007-11-06 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-06.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-mip6-integrated-06.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-mip6-integrated-06.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: <2007-11-06082002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-06082002.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 Nov 06 10:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQFW-0000fb-Hj; Tue, 06 Nov 2007 10:21:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQFV-0000f1-PS for dime@ietf.org; Tue, 06 Nov 2007 10:21:53 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpQFV-0002AA-Bf for dime@ietf.org; Tue, 06 Nov 2007 10:21:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re-Chartering Discussion Date: Tue, 6 Nov 2007 10:21:51 -0500 Message-ID: In-Reply-To: <47306101.7090907@gmx.net> References: <47306101.7090907@gmx.net> From: "Avi Lior" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Hannes, =20 I would like to have the Classifier document to be considered as a work item that we can complete fairly quickly.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: November 6, 2007 7:42 AM > To: dime@ietf.org > Subject: [Dime] Re-Chartering Discussion >=20 > Hi all, >=20 > we are currently completing a couple of our DIME WG items.=20 > Hence, we will be ready to start new work. > Please let us know whether you would like to discuss your document. > We need to prepare the agenda for the meeting. >=20 > Ciao > Hannes >=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 Tue Nov 06 10:50:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQgk-0004SG-7S; Tue, 06 Nov 2007 10:50:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQgi-0004Rr-RD for dime@ietf.org; Tue, 06 Nov 2007 10:50:00 -0500 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpQgh-0002nt-T6 for dime@ietf.org; Tue, 06 Nov 2007 10:50:00 -0500 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id lA6FnuMj002243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Nov 2007 16:49:56 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id lA6Fnri5022883; Tue, 6 Nov 2007 16:49:55 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 16:49:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] Re: RPH Example Date: Tue, 6 Nov 2007 16:49:53 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB0555F0@DEMUEXC012.nsn-intra.net> In-Reply-To: <1A0BD078-D3C9-44E5-95D4-89B47DF8467F@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re: RPH Example Thread-Index: AcgdmL5iKy4NP4p5QFOsy/bkz9sS8wC75olA References: <471DA62B.9050706@gmx.net><47220518.1020006@gmx.net><8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk><47247DBF.9090101@gmx.net> <1A0BD078-D3C9-44E5-95D4-89B47DF8467F@g11.org.uk> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext ken carlberg" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Nov 2007 15:49:54.0064 (UTC) FILETIME=[AC70C100:01C8208C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 Ken,=20 > Hannes, >=20 > First, my apologies for the very tardy response. And second, thanks =20 > for the extended thoughts below. It helps clarify the question you =20 > raised previously. Don't worry. >=20 > Now, taking your example as is, I have no disagreement.....*within* =20 > the context of the scenario you describe. However, one can take a =20 > different approach and consider SIP operating in a walled garden, or =20 > even in a B2BUA with co-resident SBCs. In either of these=20 > cases, QoS =20 > is derived from a statistical estimate where one correlates a =20 > bandwidth range per call (which are congruent with data=20 > paths) and one =20 > traffic engineers the paths accordingly. In other words, there are =20 > efforts that *loosely* emulate some circuit switched designs that =20 > aren't reliant on direct references to QoS. They simply=20 > count calls =20 > and use a max count to minimize the chance of congestion. Thus, I =20 > can still have an interest to prioritize calls, but I may not have a =20 > need to articulate anything about QoS in my signaling or data packets. I fully understand this usage scenario.=20 >=20 > And again, I'm in agreement with your subsequent email where QoS =20 > profiles can be defined that only include the subset of QoS=20 > parameters =20 > that are needed. But, I go back to the email exchange I came across =20 > where someone didn't have an interest in your QoS parameters=20 > draft in =20 > order to support their need to respond to Priority parameters=20 > because =20 > they had no interest in QoS. That's fine as well.=20 In that particular organization where this work is done they would just register a new profile that only indicates what type of priority values would be used.=20 As a consequence, there wouldn't be a single "QoS attribute" (note that I believe that priority values are also QoS values) flying between the Diameter Client and the Diameter server. =20 > In viewing the situation as a whole, I think it might be better to =20 > look into defining an optional AVP extension to rfc-4740 that =20 > correlates to the resource priority field of rfc-4412. My above suggestion would essentially do what you have in mind.=20 Ciao Hannes >=20 > cheers, >=20 > -ken >=20 >=20 > On Oct 28, 2007, at 8:17 AM, Hannes Tschofenig wrote: >=20 > > Hi Ken, > > > > let me give you a concrete example. > > > > Let's assume a SIP proxy receives a RPH and wants to ask the AAA =20 > > server whether this user is authorized to use this specific RPH. > > Here is how this could look like, assuming that=20 > Filter-Rules are not =20 > > important in this specific case (they are optional anyway). > > > > > > AAA client -> AAA server: > > ---------------------------- > > > > * QoS-ObjectType > > > > with the information that the provided QoS information is of type =20 > > "QoS-Desired". The semantic is > > "Please authorize the indicated QoS" > > > > * RPH Priority Parameter (from Section 4.11 of > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parame ters-01.txt)=20 > > encapsulated > > in the QoSBlob AVP (as the only QoS parameter in this example). > > > > These two AVPs are encapsulated in the QoSBlob-Group and contained =20 > > in the QoS-Resources AVP. This encapsulation is simply necessary =20 > > when you use grouped AVPs. Without using grouped AVPs one=20 > would have =20 > > to add additional fields to indicate how the individual=20 > AVPs relate =20 > > to each other. > > > > Note that the QoS-Profile AVP, which indicates the QoS profile, is =20 > > not necessary in this example since the RPH Priority refers to a =20 > > parameter from the base profile document. (This is not yet in the =20 > > draft since we haven't published the updated draft based on the =20 > > provided feedback yet). > > > > > > > > AAA client <- AAA server: > > ---------------------------- > > > > Authorization successful or failed. No QoS information needs to be =20 > > repeated here in our example. > > > > > > Now you tell me what should be further removed. Is this really =20 > > complicated or does the current document just look complicated? > > > > > > Ciao > > Hannes > > > > ken carlberg wrote: > >> > >> On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote: > >> > >>> Hi Ken, > >>> > >>> ken carlberg wrote: > >>>> Hannes, > >>>> > >>>> What are your thoughts about defining a new AVP exclusively for =20 > >>>> priority? I don't have concerns about the inclusion of=20 > priority =20 > >>>> in the QoS parameters draft. However, I recently came=20 > across an =20 > >>>> email exchange related to IMS where one of the participants =20 > >>>> didn't want to consider using the QoS parameters draft for =20 > >>>> validating SIP R-P information because of the bundled QoS. > >>> Can you more specific on how the desired approach would look like? > >> > >> at a very high level, an approach that strips out the QoS=20 > elements =20 > >> discussed in > >> draft-ietf-dime-diameter-qos-01.txt > >> draft-ietf-dime-qos-parameters-01.txt > >> and focuses on the application of AAA of Priority values we may see > >>> from protocols like SIP and its R-P header. And yes,=20 > this probably > >> equates to thinner documents :-) > >> > >> -ken > > >=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 Tue Nov 06 11:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpROI-0000d3-31; Tue, 06 Nov 2007 11:35:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpROG-0000cu-GQ for dime@ietf.org; Tue, 06 Nov 2007 11:35:00 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound10-sin-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpROF-0003uN-DL for dime@ietf.org; Tue, 06 Nov 2007 11:35:00 -0500 Received: from outbound10-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound10-sin-R.bigfish.com (Postfix) with ESMTP id AE4081BA8D90; Tue, 6 Nov 2007 16:34:48 +0000 (UTC) Received: from mail76-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound10-sin.bigfish.com (Postfix) with ESMTP id 3A9232C005A; Tue, 6 Nov 2007 16:34:48 +0000 (UTC) Received: from mail76-sin (localhost.localdomain [127.0.0.1]) by mail76-sin-R.bigfish.com (Postfix) with ESMTP id EABC798815F; Tue, 6 Nov 2007 16:34:33 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail76-sin (MessageSwitch) id 1194366873945241_12304; Tue, 6 Nov 2007 16:34:33 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail76-sin.bigfish.com (Postfix) with ESMTP id 0FA7B1AA004C; Tue, 6 Nov 2007 16:34:32 +0000 (UTC) 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]: A Potential Issue with the New Text for RFC 3558bis Date: Tue, 6 Nov 2007 16:34:53 -0000 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C801A2BAE0@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime]: A Potential Issue with the New Text for RFC 3558bis Thread-Index: Acgf0YJ7YnwfcprpQbO52mC/0ryQYQAB1GPAAAT+TYAAKVkfcA== From: "Dan Warren" To: "Glen Zorn" , "Victor Fajardo" , "Thomas Lindgren" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Hmmmm I sense you may have been mocking me :-) On the flip side though, if you don't live in this delusional state, who do you ever trust? Within a single operator, if I have to deploy IPSec or TLS to protect against one of my own employees corrupting my network, that is a pretty sorry state (albeit delusional). And then who says you trust the guy configuring the IPSec or TLS? Does the CEO wander round with a gun to the Network Management operatives head? It smacks slightly of paranoia, which I guess was my point in the first place. I am talking about a totally contained Diameter implementation... To mandate IPSec and/or TLS as a pre-requisite just puts in place a requirement that is going to get ignored by a whole bunch of implementations, so why not deal with reality in the document rather than your 'non-delusional' view point...? Dan > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@comcast.net] = > Sent: 05 November 2007 20:58 > To: Dan Warren; 'Victor Fajardo'; 'Thomas Lindgren' > Cc: dime@ietf.org > Subject: RE: [Dime]: A Potential Issue with the New Text for = > RFC 3558bis > = > Just an observation... > = > Doesn't all of the below not countenance for the possibility = > of a Diameter implementation within a single domain (ie where = > security is actually not an issue)? So if I were take an = > example of an Accounting application between a device a = > charging system within a single network, do I need any form = > of security at all? > [gwz] > Of course not! The service providers are our friends, = > totally dedicated only to supplying the highest possible = > quality of service & all of their employees are utterly = > trustworthy & incorruptible. > [/gwz] > = > Perhaps what is needed is a description of the context within = > which security is required - Diameter interactions without = > underlying or inherent security. I certainly see no need for = > a security mechanism for something like = > Diameter-SIP-Application when deployed in a single network, = > as an example. > [gwz] > See above; repeat as necessary until delusion is complete. > [/gwz] > ... > = > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 06 11:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRY6-0003io-ND; Tue, 06 Nov 2007 11:45:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRY5-0003iU-Fk for dime@ietf.org; Tue, 06 Nov 2007 11:45:09 -0500 Received: from web84103.mail.mud.yahoo.com ([68.142.206.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpRY3-0000WV-1A for dime@ietf.org; Tue, 06 Nov 2007 11:45:09 -0500 Received: (qmail 59570 invoked by uid 60001); 6 Nov 2007 16:45:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=OBJo4pGLGDgSw3O0FkYqbkDaXMWFFUvZXFqijMtkYFwnXCzybttXXulaW2pHa5LpKC9Ecr23O8RJZbqIe3UfhodpYvjbY9WeRMSy+LRE+TPSMSxT0NSOdkh1pY6+oNzRDtbx/OyTmF+E3PPXKTZOCwh95YphVW+m+EDFX9OkSkc=; X-YMail-OSG: grRWJVUVM1lzXANY7IjOYAbHRI8EkqMpXPg0xLwv8QSWkU4M35E_OesOKtxvLrlrCvUiHuY_mzjLQB8hlhc9tEu75aSYoPqBRCDqCuOU8pbBmQg- Received: from [206.16.17.212] by web84103.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 08:45:06 PST X-Mailer: YahooMailRC/814.06 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 08:45:06 -0800 (PST) From: Behcet Sarikaya Subject: Re: [Dime] Re-Chartering Discussion To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <482378.59034.qm@web84103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1483276478==" Errors-To: dime-bounces@ietf.org --===============1483276478== Content-Type: multipart/alternative; boundary="0-1298915652-1194367506=:59034" --0-1298915652-1194367506=:59034 Content-Type: text/plain; charset=us-ascii Hi all, We have submitted a draft which is at: http://www.ietf.org/internet-drafts/draft-sarikaya-dime-prefix-delegation-ps-00.txt entitled: Problem Statement: Diameter Prefix Delegation Application and we would like this work considered as part of re-chartering. Comments are welcome. Regards, Behcet ----- Original Message ---- From: Hannes Tschofenig To: dime@ietf.org Sent: Tuesday, November 6, 2007 6:41:37 AM Subject: [Dime] Re-Chartering Discussion Hi all, we are currently completing a couple of our DIME WG items. Hence, we will be ready to start new work. Please let us know whether you would like to discuss your document. We need to prepare the agenda for the meeting. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --0-1298915652-1194367506=:59034 Content-Type: text/html; charset=us-ascii
Hi all,
  We have submitted a draft which is at:
http://www.ietf.org/internet-drafts/draft-sarikaya-dime-prefix-delegation-ps-00.txt
entitled: Problem Statement: Diameter Prefix Delegation Application

and we would like this work considered as part of re-chartering.

  Comments are welcome.

Regards,

Behcet
----- Original Message ----
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: dime@ietf.org
Sent: Tuesday, November 6, 2007 6:41:37 AM
Subject: [Dime] Re-Chartering Discussion

Hi all,

we are currently completing a couple of our DIME WG items. Hence, we
will be ready to start new work.
Please let us know whether you would like to discuss your document.
We need to prepare the agenda for the meeting.

Ciao
Hannes


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

--0-1298915652-1194367506=:59034-- --===============1483276478== 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 --===============1483276478==-- From dime-bounces@ietf.org Tue Nov 06 18:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYIj-0002Km-Tb; Tue, 06 Nov 2007 18:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYIi-0002Jl-UZ for dime@ietf.org; Tue, 06 Nov 2007 18:57:44 -0500 Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpYIf-0005m6-2u for dime@ietf.org; Tue, 06 Nov 2007 18:57:44 -0500 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA03.westchester.pa.mail.comcast.net with smtp id 9WcC1Y0090SCNGk000P700; Tue, 06 Nov 2007 23:57:40 +0000 Received: from gwzPC ([76.28.183.80]) by OMTA09.westchester.pa.mail.comcast.net with comcast id 9bxg1Y0021kVLSs0000000; Tue, 06 Nov 2007 23:57:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=eNYDvfp58NENiYgIfN0A:9 a=lqM8hIn6UpdD71LaaAW8Y9BKmZ8A:4 a=2uiCRmbCp6AA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <47306101.7090907@gmx.net> In-Reply-To: Subject: RE: [Dime] Re-Chartering Discussion Date: Tue, 6 Nov 2007 15:56:07 -0800 Message-ID: <006a01c820d0$999b3030$ccd19090$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AcggiMQ8T3HCMN6iSHa7xE0MkJAE7gAR69Qg X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, I would like to have the Classifier document to be considered as a work item that we can complete fairly quickly. [gwz] I'll second that. [/gwz] _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 07 09:34:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iplz5-00036J-4M; Wed, 07 Nov 2007 09:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iplz3-00031f-Dy for dime@ietf.org; Wed, 07 Nov 2007 09:34:21 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iplz0-0002v5-GU for dime@ietf.org; Wed, 07 Nov 2007 09:34:20 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lA7EY4EY031825; Wed, 7 Nov 2007 09:34:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re-Chartering Discussion Date: Wed, 7 Nov 2007 09:34:07 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E750955F@sonusmail04.sonusnet.com> In-Reply-To: <47306101.7090907@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re-Chartering Discussion Thread-Index: AcggcmzErJbkMifvSES5KSHcORyhvwA0vr5w References: <47306101.7090907@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 I propose to have the following in the charter: - Diameter extensions to base protocol facilitating development of redundant applications, handling overload situations and improving existing reliability procedures. There were drafts submitted for all these three areas but I guess now all of them are expired. In a nutshell: Facilitating development of redundant applications: During interop there were informal talks about the possibility of passing an opaque per-session token. This really can ease a lot to provide redundancy for a lot of cases. I submitted a draft long time ago, there were a few comments but not the draft is long expired. Handling overload situations: This is mainly to address overload prevention/overload handling. I presented a draft during the last meeting but we didn't have much opportunity to discuss. I think we don't know what the right approach is -for now- but I guess some WG-level work is definitely useful. Improving existing reliability procedures: Current duplicate detection mechanism has -IMHO- some problems. I submitted a draft discussing these. Maybe what we need to do is just to tell people a bit more in detail about possible shortcomings and how they would need to use duplicate detection mechanism (or to have an extension to make it more practical to develop). Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, November 06, 2007 7:42 AM > To: dime@ietf.org > Subject: [Dime] Re-Chartering Discussion >=20 > Hi all, >=20 > we are currently completing a couple of our DIME WG items. Hence, we > will be ready to start new work. > Please let us know whether you would like to discuss your document. > We need to prepare the agenda for the meeting. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 07 10:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpmkZ-00037w-78; Wed, 07 Nov 2007 10:23:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpmkY-00036X-9e for dime@ietf.org; Wed, 07 Nov 2007 10:23:26 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpmkX-00041j-R7 for dime@ietf.org; Wed, 07 Nov 2007 10:23:26 -0500 MIME-Version: 1.0 Subject: RE: [Dime] Re-Chartering Discussion Date: Wed, 7 Nov 2007 10:23:24 -0500 Message-ID: References: <47306101.7090907@gmx.net> <006a01c820d0$999b3030$ccd19090$@net> From: "Mark Jones" To: "Hannes Tschofenig" X-Spam-Score: 1.8 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0306459980==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0306459980== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82152.239DD194" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82152.239DD194 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hannes,=20 =20 I'd also like to see the Classifier draft adopted as a DIME work item. =20 Regards Mark ________________________________ From: Glen Zorn [mailto:glenzorn@comcast.net] Sent: Wed 11/7/2007 12:56 AM To: 'Hannes Tschofenig' Cc: dime@ietf.org Subject: RE: [Dime] Re-Chartering Discussion Hannes, I would like to have the Classifier document to be considered as a work item that we can complete fairly quickly. [gwz] I'll second that. [/gwz] _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C82152.239DD194 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] Re-Chartering Discussion=0A= =0A= =0A= =0A=
=0A=
Hannes, =
=0A=
 
=0A=
I'd also like = to see the Classifier draft adopted as a DIME work item.
=0A=
 
=0A=
Regards
=0A=
Mark
=0A=

=0A=
=0A= From: Glen Zorn = [mailto:glenzorn@comcast.net]
Sent: Wed 11/7/2007 12:56 = AM
To: 'Hannes Tschofenig'
Cc: = dime@ietf.org
Subject: RE: [Dime] Re-Chartering = Discussion

=0A=
=0A=

Hannes,

I would like to have the Classifier = document to be considered as a work
item that we can complete fairly = quickly.

[gwz]
I'll second = that.
[/gwz]


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

------_=_NextPart_001_01C82152.239DD194-- --===============0306459980== 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 --===============0306459980==-- From dime-bounces@ietf.org Fri Nov 09 22:01:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqgas-0004w8-NQ; Fri, 09 Nov 2007 22:01:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqgar-0004vx-Ay for dime@ietf.org; Fri, 09 Nov 2007 22:01:09 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqgaq-0008EW-Jj for dime@ietf.org; Fri, 09 Nov 2007 22:01:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A441210804E for ; Fri, 9 Nov 2007 22:01:01 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21098-11 for ; Fri, 9 Nov 2007 22:00:57 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 9 Nov 2007 22:00:57 -0500 (EST) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 21:59:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re-Chartering Discussion Date: Fri, 9 Nov 2007 22:00:57 -0500 Message-ID: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re-Chartering Discussion Thread-Index: Acggcm+whCdl9YdETg2BvqCvdjM41AAASAPgALR3PeA= From: "Chowdhury, Kuntal" To: , X-OriginalArrivalTime: 10 Nov 2007 02:59:58.0435 (UTC) FILETIME=[C75A2B30:01C82345] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Hannes, We should include the Diameter PMIP6 work item in the new charter. PMIP6 will be used by many SDOs and an AAA interface spec to support PMIP6 should be defined. BR, Kuntal > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Tuesday, November 06, 2007 6:55 AM > To: Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: RE: [Dime] Re-Chartering Discussion >=20 > Hi Hannes, >=20 > I would like to present (again) the Proxy Mobile IPv6 Diameter > document that was surfaces in the last meeting. A revision is > on its way soon. Imho that could be a potential item for a new > work. >=20 > Cheers, > Jouni >=20 >=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: 6. marraskuuta 2007 14:42 > > To: dime@ietf.org > > Subject: [Dime] Re-Chartering Discussion > > > > > > Hi all, > > > > we are currently completing a couple of our DIME WG items. > > Hence, we will be ready to start new work. > > Please let us know whether you would like to discuss your document. > > We need to prepare the agenda for the meeting. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 11 21:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOdj-0007E6-3C; Sun, 11 Nov 2007 21:03:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOdh-000701-8a; Sun, 11 Nov 2007 21:03:01 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrOdg-00039U-6w; Sun, 11 Nov 2007 21:03:01 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2914737bc0d; Mon, 12 Nov 2007 10:12:00 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm7e47308698; Tue, 06 Nov 2007 22:02:29 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 06 Nov 2007 22:02:29 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOVK-0004Ok-7K; Tue, 06 Nov 2007 08:30:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOVI-0004NP-8z; Tue, 06 Nov 2007 08:30:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpOVG-0002zE-2F; Tue, 06 Nov 2007 08:30:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 08C73328DA; Tue, 6 Nov 2007 13:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IpOVF-0008SE-UR; Tue, 06 Nov 2007 08:30:01 -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, 06 Nov 2007 08:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-06.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org 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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-06.txt Pages : 20 Date : 2007-11-06 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-06.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-mip6-integrated-06.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-mip6-integrated-06.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: <2007-11-06082002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-06082002.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sun Nov 11 22:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQ5f-0005nc-CL; Sun, 11 Nov 2007 22:35:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQ5d-0005nO-PU for dime@ietf.org; Sun, 11 Nov 2007 22:35:57 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrQ5Z-0005NV-Qs for dime@ietf.org; Sun, 11 Nov 2007 22:35:57 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD001ZJJBJFM@szxga01-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 11:35:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD007MRJBJXJ@szxga01-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 11:35:43 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRD00HKEJBJYV@szxml04-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 11:35:43 +0800 (CST) Date: Mon, 12 Nov 2007 11:35:43 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <007501c824dd$1aa5b960$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Dime] Next step of "Diameter explicit routing" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336499973==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1336499973== Content-type: multipart/alternative; boundary="Boundary_(ID_9jyDSX/A7Q6wf+H1Uub6Hg)" This is a multi-part message in MIME format. --Boundary_(ID_9jyDSX/A7Q6wf+H1Uub6Hg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Dear all, Wrt Next step of "Diameter explicit routing" http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03, should we propose it as an informal RFC? 3GPP has paid attention to it for its usefulness. B. R. Tina --Boundary_(ID_9jyDSX/A7Q6wf+H1Uub6Hg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Dear all,
Wrt Next step of "Diameter explicit routing" http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03, should we propose it as an informal RFC? 3GPP has paid attention to it for its usefulness.
 
B. R.
Tina
 
 
--Boundary_(ID_9jyDSX/A7Q6wf+H1Uub6Hg)-- --===============1336499973== 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 --===============1336499973==-- From dime-bounces@ietf.org Mon Nov 12 06:54:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXrp-0001l7-Ot; Mon, 12 Nov 2007 06:54:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXro-0001kg-SD for dime@ietf.org; Mon, 12 Nov 2007 06:54:12 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrXro-0002jR-DA for dime@ietf.org; Mon, 12 Nov 2007 06:54:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Re-Chartering Discussion Date: Mon, 12 Nov 2007 06:54:07 -0500 Message-ID: In-Reply-To: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> References: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, I also feel that this must be included as a work item in the new DIME charter. Regards Mark > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: November 10, 2007 04:01 > To: Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: RE: [Dime] Re-Chartering Discussion >=20 > Hi Hannes, >=20 > We should include the Diameter PMIP6 work item in the new=20 > charter. PMIP6 > will be used by many SDOs and an AAA interface spec to support PMIP6 > should be defined. >=20 > BR, > Kuntal >=20 >=20 > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Tuesday, November 06, 2007 6:55 AM > > To: Hannes.Tschofenig@gmx.net; dime@ietf.org > > Subject: RE: [Dime] Re-Chartering Discussion > >=20 > > Hi Hannes, > >=20 > > I would like to present (again) the Proxy Mobile IPv6 Diameter > > document that was surfaces in the last meeting. A revision is > > on its way soon. Imho that could be a potential item for a new > > work. > >=20 > > Cheers, > > Jouni > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: 6. marraskuuta 2007 14:42 > > > To: dime@ietf.org > > > Subject: [Dime] Re-Chartering Discussion > > > > > > > > > Hi all, > > > > > > we are currently completing a couple of our DIME WG items. > > > Hence, we will be ready to start new work. > > > Please let us know whether you would like to discuss your=20 > document. > > > We need to prepare the agenda for the meeting. > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 12 07:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYcy-0007LP-4D; Mon, 12 Nov 2007 07:42:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYcw-0007I3-Up for dime@ietf.org; Mon, 12 Nov 2007 07:42:54 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYcw-0004kk-EB for dime@ietf.org; Mon, 12 Nov 2007 07:42:54 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id lACCgkcq075365 for ; Mon, 12 Nov 2007 13:42:46 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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-Chartering Discussion Date: Mon, 12 Nov 2007 13:42:46 +0100 Message-ID: <33656995C5C5094A983DE84DA649A9240208F5A9@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re-Chartering Discussion thread-index: AcglIsmR7s6YiqJcTrig7ziIo64Q9AABi54w References: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Mon, 12 Nov 2007 13:42:47 +0100 (CET) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/4752/Mon Nov 12 09:00:52 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 We would like to discuss making state recovery an WG work item. Such work item could target a specification for protocol mechanisms enabling protocol aided state recovery.=20 Rgs Ulf =20 >=20 > Hi all, > > we are currently completing a couple of our DIME WG items. > Hence, we will be ready to start new work. > Please let us know whether you would like to discuss your > document. > We need to prepare the agenda for the meeting. >=20 > Ciao > Hannes > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 12 09:29:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraI9-000061-7e; Mon, 12 Nov 2007 09:29:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraI7-0008WN-Im for dime@ietf.org; Mon, 12 Nov 2007 09:29:31 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IraI3-0006FA-98 for dime@ietf.org; Mon, 12 Nov 2007 09:29:31 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE00MZ6DKTEX@szxga02-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 22:29:17 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE0074VDKTKW@szxga02-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 22:29:17 +0800 (CST) Received: from jys3105121962 (125.172.144.61.broad.sz.gd.dynamic.163data.com.cn [61.144.172.125]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE00ANNDKSQ5@szxml02-in.huawei.com>; Mon, 12 Nov 2007 22:29:17 +0800 (CST) Date: Mon, 12 Nov 2007 22:29:16 +0800 From: Tina TSOU Subject: Re: [Dime] Re-Chartering Discussion To: dime@ietf.org, Ulf Bodin Message-id: <005d01c82538$67ea6530$6501a8c0@jys3105121962> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 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: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> <33656995C5C5094A983DE84DA649A9240208F5A9@lulex02.ad.operax.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Hannes and all, We would like to discuss making explicit routing as WG work item. It is optional:) B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: Sent: Monday, November 12, 2007 8:42 PM Subject: RE: [Dime] Re-Chartering Discussion Hi Hannes, We would like to discuss making state recovery an WG work item. Such work item could target a specification for protocol mechanisms enabling protocol aided state recovery. Rgs Ulf > > Hi all, > > we are currently completing a couple of our DIME WG items. > Hence, we will be ready to start new work. > Please let us know whether you would like to discuss your > document. > We need to prepare the agenda for the meeting. > > 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 Mon Nov 12 09:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraTG-0008Nh-I1; Mon, 12 Nov 2007 09:41:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IraTF-0008IU-2Z for dime@ietf.org; Mon, 12 Nov 2007 09:41:01 -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 1IraTE-00027T-QH for dime@ietf.org; Mon, 12 Nov 2007 09:41:00 -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 lACEeepT065506; Mon, 12 Nov 2007 09:40:40 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <473865E2.6050600@tari.toshiba.com> Date: Mon, 12 Nov 2007 09:40:34 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Glen Zorn Subject: Re: [Dime]: A Potential Issue with the New Text for RFC 3558bis References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> <00a301c81db9$c1baa8d0$452ffa70$@net> In-Reply-To: <00a301c81db9$c1baa8d0$452ffa70$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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, > Personally, I think that it would both simplify things & improve security > considerably to simply make TLS a MUST & delete the mention of IPsec. > Sounds good, though I think we should make TLS a SHOULD. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 12 10:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irb9o-0006m3-RZ; Mon, 12 Nov 2007 10:25:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irb9o-0006lY-16 for dime@ietf.org; Mon, 12 Nov 2007 10:25:00 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irb9j-0007xA-1e for dime@ietf.org; Mon, 12 Nov 2007 10:25:00 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE0092OG59AQ@szxga03-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 23:24:45 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE00GXQG596T@szxga03-in.huawei.com> for dime@ietf.org; Mon, 12 Nov 2007 23:24:45 +0800 (CST) Received: from jys3105121962 (125.172.144.61.broad.sz.gd.dynamic.163data.com.cn [61.144.172.125]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE007OUG58P0@szxml01-in.huawei.com>; Mon, 12 Nov 2007 23:24:45 +0800 (CST) Date: Mon, 12 Nov 2007 23:24:44 +0800 From: Tina TSOU Subject: Re: [Dime] Re-Chartering Discussion To: Ulf Bodin , dime@ietf.org, Tina TSOU Message-id: <000801c82540$277bd260$6501a8c0@jys3105121962> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4D35478224365146822AE9E3AD4A2666877743@exchtewks3.starentnetworks.com> <33656995C5C5094A983DE84DA649A9240208F5A9@lulex02.ad.operax.com> <005d01c82538$67ea6530$6501a8c0@jys3105121962> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Hannes and all, Can we request a time slot for it in IETF #70 DIME session for considering it as a WG Item and standard track RFC. B. R. Tina ----- Original Message ----- From: "Tina TSOU" To: ; "Ulf Bodin" Sent: Monday, November 12, 2007 10:29 PM Subject: Re: [Dime] Re-Chartering Discussion > Hi Hannes and all, > We would like to discuss making explicit routing as WG work item. It is > optional:) > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: > Sent: Monday, November 12, 2007 8:42 PM > Subject: RE: [Dime] Re-Chartering Discussion > > > Hi Hannes, > > We would like to discuss making state recovery an WG work item. Such > work item could target a specification for protocol mechanisms enabling > protocol aided state recovery. > > Rgs Ulf > >> >> Hi all, >> >> we are currently completing a couple of our DIME WG items. >> Hence, we will be ready to start new work. >> Please let us know whether you would like to discuss your >> document. >> We need to prepare the agenda for the meeting. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 12 12:55:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdVd-00012F-4r; Mon, 12 Nov 2007 12:55:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrdVc-00012A-S4 for dime@ietf.org; Mon, 12 Nov 2007 12:55:40 -0500 Received: from qmta10.westchester.pa.mail.comcast.net ([76.96.62.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrdVc-0002mF-Em for dime@ietf.org; Mon, 12 Nov 2007 12:55:40 -0500 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA10.westchester.pa.mail.comcast.net with smtp id BtVL1Y00E0mv7h00006b00; Mon, 12 Nov 2007 17:55:39 +0000 Received: from gwzPC ([76.28.183.80]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Btvf1Y0091kVLSs0000000; Mon, 12 Nov 2007 17:55:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=OSC5RCymGJ7CYNvPZ-kA:9 a=sezYIJpzTW5BoHXNRQoCMujESFsA:4 a=50e4U0PicR4A:10 From: "Glen Zorn" To: "'Victor Fajardo'" References: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> <4729C27F.6050906@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7976@ILEXC2U03.ndc.lucent.com> <472A3AA2.2090001@tari.toshiba.com> <5531D43D854B3445955E3AD9CEBA28D0EE7CA2@ILEXC2U03.ndc.lucent.com> <00a301c81db9$c1baa8d0$452ffa70$@net> <473865E2.6050600@tari.toshiba.com> In-Reply-To: <473865E2.6050600@tari.toshiba.com> Subject: RE: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Mon, 12 Nov 2007 09:53:26 -0800 Message-ID: <004b01c82554$edbf0aa0$c93d1fe0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcglOgo6RmjD89KKSCWvWltn0Zd9vQAGdVAg Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Glen, > Personally, I think that it would both simplify things & improve security > considerably to simply make TLS a MUST & delete the mention of IPsec. > Sounds good, though I think we should make TLS a SHOULD. [gwz] Aside from the fact that optional security is a _really_ bad idea, I find it difficult to believe that this doc will make it through IESG review w/o a mandatory-to-implement security method. For those folks who believe that their networks are so impregnable that they need no security, 1) "mandatory to implement" does _not_ mean "mandatory to deploy" and 2) can I get your names? I sense a major profit opportunity... [/gwz] regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 13 08:38:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvyA-0008D1-6R; Tue, 13 Nov 2007 08:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irvy9-00088a-GI for dime@ietf.org; Tue, 13 Nov 2007 08:38:21 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irvy6-0001yO-6X for dime@ietf.org; Tue, 13 Nov 2007 08:38:21 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1278102rvb for ; Tue, 13 Nov 2007 05:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=LHuznHFpPCwrnaM6ZyrmVAdIndsIu1p5EIFcH6+K44s=; b=Zndx7HtrB8iBuLgGETOHLy7e16e9gSPBRnciyE3YjWOzZJU3gG29wnkhwHTvLTNRY0isLTvyMjc+SdohCbeIEIsRn2/ZDJlTYXfxFMBT58mGcau8X0fdfXNm0YIGvqsd4IpLNYH5bDALri8QrQGD3J4x3d9d6tOKUt3Bs8vfIhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Qf1leO2MTE/2MiDNJmr81I1CrRzPGj1NmW/7rok/DvwobrcrvIRvvoewANBphlszLKAvzp5t+BS1TFFJPDCVSkgBlCNq5bye3Rc0pb/t/LvC8WLwEW9Kx2g0XhRT7A0iwrAYLZoqm3yxci1Rqhx8ULPbpo62iWPl191tHx7m68I= Received: by 10.141.153.16 with SMTP id f16mr139950rvo.1194961097390; Tue, 13 Nov 2007 05:38:17 -0800 (PST) Received: by 10.141.195.1 with HTTP; Tue, 13 Nov 2007 05:38:17 -0800 (PST) Message-ID: <459accb50711130538w63aa3ca6q25b4c4e8813d8151@mail.gmail.com> Date: Tue, 13 Nov 2007 19:08:17 +0530 From: "Raghu Kunchum" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Dime] Questions regarding proxies X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, could you please explain the following questions in detail. 1) What is meant by policy and policy enforcement in diameter (in proxy agent). 2) Proxy as a State ful agent, what state it should maintain. Thanks Raghu.S _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 14 06:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGpX-0002iR-F3; Wed, 14 Nov 2007 06:54:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGpV-0002gI-Vk for dime@ietf.org; Wed, 14 Nov 2007 06:54:50 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsGpV-0006iU-Hv for dime@ietf.org; Wed, 14 Nov 2007 06:54:49 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 12:54:47 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C826B5.278A1D92" Date: Wed, 14 Nov 2007 12:54:48 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F965D@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-korhonen-dime-pmip6-01.txt Thread-Index: AcgmtKaoOwd5MVrTQU+7SnWMgUgPawAAD/jQ From: To: X-OriginalArrivalTime: 14 Nov 2007 11:54:47.0597 (UTC) FILETIME=[27A2B5D0:01C826B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Dime] FW: I-D Action:draft-korhonen-dime-pmip6-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C826B5.278A1D92 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FYI, a new revision of the Proxy Mobile IPv6 Diameter I-D. Jouni > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: 14. marraskuuta 2007 13:50 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-korhonen-dime-pmip6-01.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Diameter Proxy Mobile IPv6: Support=20 > For Mobility Access Gateway and Local Mobility Anchor to=20 > Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-korhonen-dime-pmip6-01.txt > Pages : 23 > Date : 2007-11-14 >=20 > This specification defines the Diameter support for the Proxy=20 > Mobile IPv6. The policy information needed by the Proxy=20 > Mobile IPv6 is defined in mobile node's policy profile, which=20 > gets downloaded from the Diameter server to the Mobile Access=20 > Gateway once the mobile node roams into a Proxy Mobile IPv6=20 > Domain and performs the access authentication. The access=20 > authentication procedure into the Proxy Mobile IPv6 Domain=20 > resembles the Mobile IPv6 integrated scenario bootstrapping. =20 > Rather than defining a completely new set of attributes or a=20 > new Diameter application this specification only leverages=20 > the work already done for the Mobile IPv6 bootstrapping. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-korhonen-dime-pmip6-01.txt >=20 ------_=_NextPart_001_01C826B5.278A1D92 Content-Type: text/plain; charset="us-ascii"; name="draft-korhonen-dime-pmip6-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-korhonen-dime-pmip6-01.txt Content-Disposition: attachment; filename="draft-korhonen-dime-pmip6-01.txt" RklMRSBRVUFSQU5USU5FRA0KLS0tLS0tLS0tLS0tLS0tLQ0KDQpNaWNyb3NvZnQgQW50aWdlbiBm b3IgRXhjaGFuZ2UgcmVtb3ZlZCBhIGZpbGUgc2luY2UgaXQgd2FzIGZvdW5kIHRvIG1hdGNoIGEg ZmlsdGVyLg0KRmlsZSBuYW1lOiAiZHJhZnRfa29yaG9uZW5fZGltZV9wbWlwNl8wMS5VUkwiDQpG aWx0ZXIgbmFtZTogIkZJTEUgRklMVEVSPSB1bm5hbWVkOiAqLnVybCINCg== ------_=_NextPart_001_01C826B5.278A1D92 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C826B5.278A1D92-- From dime-bounces@ietf.org Thu Nov 15 08:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf5l-00065V-0V; Thu, 15 Nov 2007 08:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf5k-00065M-Jx for dime@ietf.org; Thu, 15 Nov 2007 08:49:12 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isf5h-00045X-ET for dime@ietf.org; Thu, 15 Nov 2007 08:49:12 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 6849A328E6; Thu, 15 Nov 2007 13:48:39 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Isf5D-0001lK-An; Thu, 15 Nov 2007 08:48:39 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: vfajardo@tari.toshiba.com From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 08:48:39 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Hannes.Tschofenig@nsn.com, dime@ietf.org Subject: [Dime] New Version Notification for draft-ietf-dime-app-design-guide-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 new version of I-D, draft-ietf-dime-app-design-guide-05.txt has been successfuly submitted by Victor Fajardo and posted to the IETF repository. Filename: draft-ietf-dime-app-design-guide Revision: 05 Title: Diameter Applications Design Guidelines Creation_date: 2007-11-13 WG ID: dime Number_of_pages: 20 Abstract: The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 15 08:50:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf6Z-0007tU-JR; Thu, 15 Nov 2007 08:50:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf6Y-0007rj-Uz; Thu, 15 Nov 2007 08:50:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isf6Y-00046f-IA; Thu, 15 Nov 2007 08:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 37047175AB; Thu, 15 Nov 2007 13:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Isf6X-0002QG-OZ; Thu, 15 Nov 2007 08:50:01 -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: Thu, 15 Nov 2007 08:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-05.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 Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-05.txt Pages : 20 Date : 2007-11-15 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-05.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-app-design-guide-05.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-app-design-guide-05.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: <2007-11-15084837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15084837.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 Thu Nov 15 12:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isi5s-000766-8w; Thu, 15 Nov 2007 12:01:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isi5q-00074e-M0 for dime@ietf.org; Thu, 15 Nov 2007 12:01:30 -0500 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isi5n-0005st-ES for dime@ietf.org; Thu, 15 Nov 2007 12:01:30 -0500 Received: by nz-out-0506.google.com with SMTP id n1so552241nzf for ; Thu, 15 Nov 2007 09:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:thread-index:x-mimeole; bh=303wIpMyJ90h+aTbP2AcT1X//rKDe5SWcHqGZJt7NRM=; b=bE9Jal9sVCOAL3/FFOKSrIByIsuX7L6X5uoQOteLZnp7LCam29dFEpqgE0P7EvpFD2xSj6WrRD7OlrcKeJkD/JQbRWvDxlRfCl6rTJn2yIrPjvnSB8pK8Y71ZjaawigbFw4c2GRPuWpAQ+mUqOrOOLtalQEtBujC2+E12MDKAd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:thread-index:x-mimeole; b=ASEFw3aTBNUEZoZw5bJIEJHkSWvXSmb9STlmQ+oO2id+Cf3Ow5xfGNFSmz371oBf0HjRYoI90rsipeZwtNVH51Vqx6iyprwDsCUwFWlbe8qntXKurzd+8zH+YvAuoxSVqtm/pPhOOL5PxM6bOOGkGoHJFZ4yld8vSNyytf+QX/A= Received: by 10.114.123.1 with SMTP id v1mr203163wac.1195146086202; Thu, 15 Nov 2007 09:01:26 -0800 (PST) Received: from Harsha ( [219.64.64.222]) by mx.google.com with ESMTPS id n32sm1627638wag.2007.11.15.09.01.16 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Nov 2007 09:01:24 -0800 (PST) From: "Harsha" To: Date: Thu, 15 Nov 2007 22:30:33 +0530 Message-ID: <000f01c827a9$1c328b90$de4040db@Harsha> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgnqQjAwrSJcG9XT3eWS34pmBo1ZQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.7 (+) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [Dime] Regarding float type AVPs X-BeenThere: dime@ietf.org X-Mailman-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="===============1876557255==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1876557255== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C827D7.35EAC790" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C827D7.35EAC790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello All As per RFC 3588 float AVP type (float32 and float64)should be represented in IEEE Single-Precision 32 bit or IEEE Double-precision 64 bit formats, but it is not clear whether it should be normalized or not, is it not required? Also the RFC tells that float should be sent out in network byte order, but as far as I know little-endian and big-endian rules will not strictly apply to floats, will it not cause any problems?(Please refer to "Floating-point and endianness" in http://en.wikipedia.org/wiki/Endianness) I referred to opendiameter to see a reference implementation but float AVP type is not implemented there. Regards, Harsha ------=_NextPart_000_0010_01C827D7.35EAC790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All

 

     As per RFC 3588 float AVP = type (float32 and float64)should be represented in IEEE Single-Precision 32 = bit or IEEE Double-precision 64 bit formats,

     but it is not clear whether = it should be normalized or not, is it not required?

 

     Also the RFC tells that = float should be sent out in network byte order, but as far as I know = little-endian and big-endian rules will not strictly apply = to

     floats, will it not cause = any problems?(Please refer to “Floating-point and endianness” in http://en.wikipedia.org/= wiki/Endianness)

 

      I referred to = opendiameter to see a reference implementation but float AVP type is not implemented = there.

 

Regards,

Harsha

  

------=_NextPart_000_0010_01C827D7.35EAC790-- --===============1876557255== 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 --===============1876557255==-- From dime-bounces@ietf.org Thu Nov 15 18:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoU7-0002Gv-Nr; Thu, 15 Nov 2007 18:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoU5-0002Ge-Nr for dime@ietf.org; Thu, 15 Nov 2007 18:50:58 -0500 Received: from ro-out-1112.google.com ([72.14.202.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsoU4-0005HM-3w for dime@ietf.org; Thu, 15 Nov 2007 18:50:57 -0500 Received: by ro-out-1112.google.com with SMTP id k4so394341rog for ; Thu, 15 Nov 2007 15:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=r1YPSQgprGuAZtQWhtIId2nMPJsyALuvVm4msM6VbQo=; b=Ej6r+XiBwg55HcwozSPy0Ht7Kh0pz4HWRu4Yqbc2YsZ8U9oyvInUkvXiOZVQYB0JsDtyVwQQlN0xhZpnp6Tmgo/o4sywX3/lpdqDDXTL0vkYxhtTb1wZNfKxYRd9Dds4b38VvYj4SlLVhuG536u9LBjYy5fTGAgIotfR2gPMIxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=bzmlYkKmiS0f+KNVaNUVhEwp38Tr0Byg5dWGtpNjkmWg8p+gwZMy1WkMrJgHMG/s1npe1W8xhSHrUzHV/qOkWaXyVVStChJ/ClnQzYa+mfYxIxKRiS2xwON5T/Txfxd2lDG0yGeGPwMpWy+EaLsw4DgegeLHPVfIBNVpJ2kitC8= Received: by 10.115.54.1 with SMTP id g1mr512356wak.1195170654993; Thu, 15 Nov 2007 15:50:54 -0800 (PST) Received: by 10.114.208.14 with HTTP; Thu, 15 Nov 2007 15:50:54 -0800 (PST) Message-ID: <9cf5ced20711151550j516370c8w351733cbc3d9cfc1@mail.gmail.com> Date: Thu, 15 Nov 2007 18:50:54 -0500 From: "David Frascone" To: Harsha Subject: Re: [Dime] Regarding float type AVPs In-Reply-To: <000f01c827a9$1c328b90$de4040db@Harsha> MIME-Version: 1.0 References: <000f01c827a9$1c328b90$de4040db@Harsha> X-Google-Sender-Auth: 7546ccdfd794f678 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0921139985==" Errors-To: dime-bounces@ietf.org --===============0921139985== Content-Type: multipart/alternative; boundary="----=_Part_11019_10140523.1195170654973" ------=_Part_11019_10140523.1195170654973 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that the text needs to be cleaned up. Can you provide some less ambiguous text? -Dave On Nov 15, 2007 12:00 PM, Harsha wrote: > Hello All > > > > As per RFC 3588 float AVP type (float32 and float64)should be > represented in IEEE Single-Precision 32 bit or IEEE Double-precision 64 bit > formats, > > but it is not clear whether it should be normalized or not, is it not > required? > > > > Also the RFC tells that float should be sent out in network byte > order, but as far as I know little-endian and big-endian rules will not > strictly apply to > > floats, will it not cause any problems?(Please refer to > "Floating-point and endianness" in http://en.wikipedia.org/wiki/Endianness) > > > > > I referred to opendiameter to see a reference implementation but > float AVP type is not implemented there. > > > > Regards, > > Harsha > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- David Frascone Oxymoron: Safe Sex. ------=_Part_11019_10140523.1195170654973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that the text needs to be cleaned up.  Can you provide some less ambiguous text?

-Dave

On Nov 15, 2007 12:00 PM, Harsha <harsha.matadhikari@gmail.com > wrote:

Hello All

 

     As per RFC 3588 float AVP type (float32 and float64)should be represented in IEEE Single-Precision 32 bit or IEEE Double-precision 64 bit formats,

     but it is not clear whether it should be normalized or not, is it not required?

 

     Also the RFC tells that float should be sent out in network byte order, but as far as I know little-endian and big-endian rules will not strictly apply to

     floats, will it not cause any problems?(Please refer to "Floating-point and endianness" in http://en.wikipedia.org/wiki/Endianness)

 

      I referred to opendiameter to see a reference implementation but float AVP type is not implemented there.

 

Regards,

Harsha

  


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




--
David Frascone

Oxymoron: Safe Sex. ------=_Part_11019_10140523.1195170654973-- --===============0921139985== 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 --===============0921139985==-- From dime-bounces@ietf.org Fri Nov 16 09:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2AU-0007z3-DF; Fri, 16 Nov 2007 09:27:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2AT-0007yV-9J for dime@ietf.org; Fri, 16 Nov 2007 09:27:37 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2AT-0003cV-0C for dime@ietf.org; Fri, 16 Nov 2007 09:27:37 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id DDA062AC7C; Fri, 16 Nov 2007 14:27:06 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1It29y-0001os-Lc; Fri, 16 Nov 2007 09:27:06 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: vfajardo@tari.toshiba.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 16 Nov 2007 09:27:06 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: dime@ietf.org, jari.arkko@ericsson.com Subject: [Dime] New Version Notification for draft-ietf-dime-rfc3588bis-09 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 new version of I-D, draft-ietf-dime-rfc3588bis-09.txt has been successfuly submitted by Victor Fajardo and posted to the IETF repository. Filename: draft-ietf-dime-rfc3588bis Revision: 09 Title: Diameter Base Protocol Creation_date: 2007-11-16 WG ID: dime Number_of_pages: 160 Abstract: 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. The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 16 09:30:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2Cp-0003Op-8c; Fri, 16 Nov 2007 09:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2Co-0003Mk-Js; Fri, 16 Nov 2007 09:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2Co-0006UQ-7b; Fri, 16 Nov 2007 09:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1B18A26E92; Fri, 16 Nov 2007 14:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It2Co-0002qd-0e; Fri, 16 Nov 2007 09:30:02 -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: Fri, 16 Nov 2007 09:30:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --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, et al. Filename : draft-ietf-dime-rfc3588bis-09.txt Pages : 160 Date : 2007-11-16 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-09.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-09.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-09.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: <2007-11-16092703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16092703.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 Fri Nov 16 09:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2HB-00046O-8E; Fri, 16 Nov 2007 09:34:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2HA-00044v-KJ for dime@ietf.org; Fri, 16 Nov 2007 09:34:32 -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 1It2HA-0004Bg-42 for dime@ietf.org; Fri, 16 Nov 2007 09:34:32 -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 lAGEYVq0087283 for ; Fri, 16 Nov 2007 09:34:31 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <473DAA69.8080009@tari.toshiba.com> Date: Fri, 16 Nov 2007 09:34:17 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is the summary of changes for RFC3588bis. The latest version of rfc3588bis is now available: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-09.txt. Issues listed in this summary can be found in the tracker: http://www.tschofenig.priv.at:8080/diameter-interop/index. From there, detailed discussions leading up to the suggested solution can be trace in the DIME list. As of this writing, there are no open issues present in the tracker. * Change History: The deltas between 09 and 08 version closes issues: - #64, #65, #35, #39, #70, #52 (updated), #49 (updated) - draft: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-09.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-09-from-8.diff.html The deltas between 08 and 07 version closes issues: - #63 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-08.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-08-from-7.diff.html The deltas between 07 and 06 version closes issues: - #60, #61, #66, #58 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-07.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-07-from-6.diff.html The deltas between 06 and 05 version closes issues: - #62, #67, #68, #55 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-06.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-06-from-5.diff.html The deltas between 05 and 04 versions closes issues: - #20, #56, #57 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-05.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-05-from-4.diff.html The deltas between 04 and 03 versions closes issues: - #34, #50, #54, #53 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-04.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-04-from-3.diff.html The deltas between 03 and 02 versions closes issues: - #28, #33, #37, #38, #51, #52, #50 (partially) - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03-from-2.diff.html The deltas between 02 and 01 versions closes issues: - #32, #36, #44, #49, #41, #40, #31, #26 - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02-from-1.diff.html The deltas between 01 and 00 versions closes issues: - Incorporates the changes proposed in http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt - draft: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01.txt - diff's: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01-from-0.diff.html rfc3588bis-00 and rfc3588 are identical _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 16 09:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2PA-0005qX-Uc; Fri, 16 Nov 2007 09:42:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2PA-0005pW-7I for dime@ietf.org; Fri, 16 Nov 2007 09:42:48 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2P7-0007Yv-BK for dime@ietf.org; Fri, 16 Nov 2007 09:42:48 -0500 Received: by rv-out-0910.google.com with SMTP id l15so627511rvb for ; Fri, 16 Nov 2007 06:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:references:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index:in-reply-to; bh=81scN6x+g9ads6jGF8XjuvxYB/L+6zKetduoJ6NLjHQ=; b=PRMLh0Gg4aQeFCC/uSaZi4c89J9ZJryJDFQbBIhroq9V73Pb713LagEsw+K/lWusOXYPS9cHz/aMIIas5oT0Eg7Ira4HcgP5Um2U+idlZLY19jOixOaxEJDUar+bwYibstHCPsmZbtqXaO+1kEbjRDnfsuDGIYz06e1twdIUxvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:references:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index:in-reply-to; b=YYu5oVnaZfkKtGuCa8oKSgPM23zFvt4Ueo5u5iWscHGPYFQhQA6EgE9XTVlu+w8s+2jmwWab0iBjFjAJfGbsfaKUE1MZbjUs/WeZoHwPDTF0vBsQM/VboZoPXrifvVm6+Dv51IdZ19hLHWcjGkcvR0SiBfjItrzG5FUEcNs+N/Y= Received: by 10.141.178.5 with SMTP id f5mr656592rvp.1195224162901; Fri, 16 Nov 2007 06:42:42 -0800 (PST) Received: from Harsha ( [219.64.139.252]) by mx.google.com with ESMTPS id g31sm801919rvb.2007.11.16.06.42.33 (version=SSLv3 cipher=RC4-MD5); Fri, 16 Nov 2007 06:42:41 -0800 (PST) From: "Harsha" To: "'David Frascone'" References: <000f01c827a9$1c328b90$de4040db@Harsha> <9cf5ced20711151550j516370c8w351733cbc3d9cfc1@mail.gmail.com> Subject: RE: [Dime] Regarding float type AVPs Date: Fri, 16 Nov 2007 20:12:09 +0530 Message-ID: <002d01c8285e$e47eef20$fc8b40db@Harsha> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgn4l02MMsWwonOQySuhRmbMSbrVgAfD8Cg In-Reply-To: <9cf5ced20711151550j516370c8w351733cbc3d9cfc1@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0118055990==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0118055990== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C8288C.FE372B20" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C8288C.FE372B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sorry for the confusion, I think it is not needed. IEEE 754 is clear. Regards, Harsha _____ From: frascone@gmail.com [mailto:frascone@gmail.com] On Behalf Of David Frascone Sent: Friday, November 16, 2007 5:21 AM To: Harsha Cc: dime@ietf.org Subject: Re: [Dime] Regarding float type AVPs I agree that the text needs to be cleaned up. Can you provide some less ambiguous text? -Dave On Nov 15, 2007 12:00 PM, Harsha > wrote: Hello All As per RFC 3588 float AVP type (float32 and float64)should be represented in IEEE Single-Precision 32 bit or IEEE Double-precision 64 bit formats, but it is not clear whether it should be normalized or not, is it not required? Also the RFC tells that float should be sent out in network byte order, but as far as I know little-endian and big-endian rules will not strictly apply to floats, will it not cause any problems?(Please refer to "Floating-point and endianness" in http://en.wikipedia.org/wiki/Endianness) I referred to opendiameter to see a reference implementation but float AVP type is not implemented there. Regards, Harsha _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime -- David Frascone Oxymoron: Safe Sex. ------=_NextPart_000_002E_01C8288C.FE372B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

   Sorry for the = confusion, I think it is not needed.  IEEE 754 is clear.

Regards,

Harsha

 

From: frascone@gmail.com [mailto:frascone@gmail.com] On Behalf Of David Frascone
Sent: Friday, November = 16, 2007 5:21 AM
To: Harsha
Cc: dime@ietf.org
Subject: Re: [Dime] = Regarding float type AVPs

 

I agree that = the text needs to be cleaned up.  Can you provide some less ambiguous = text?

-Dave

On Nov 15, 2007 12:00 PM, Harsha <harsha.matadhikari@gmail.com= > wrote:

Hello All

 

     As per RFC 3588 float AVP type (float32 and float64)should be = represented in IEEE Single-Precision 32 bit or IEEE Double-precision 64 bit = formats,

     but it is not clear whether it should be normalized or not, is it = not required?

 

     Also the RFC tells that float should be sent out in network byte order, = but as far as I know little-endian and big-endian rules will not strictly apply = to

     floats, will it not cause any problems?(Please refer to = "Floating-point and endianness" in http://en.wikipedia.org/wiki/Endianness) =

 

    &nbs= p; I referred to opendiameter to see a reference implementation but float = AVP type is not implemented there.

 

Regards,<= /o:p>

Harsha

  


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




--
David Frascone

Oxymoron: Safe Sex.

------=_NextPart_000_002E_01C8288C.FE372B20-- --===============0118055990== 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 --===============0118055990==-- From dime-bounces@ietf.org Mon Nov 19 04:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2dn-0007NU-Fk; Mon, 19 Nov 2007 04:10:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2dm-0007N8-A4; Mon, 19 Nov 2007 04:10:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2dl-0000Mv-U8; Mon, 19 Nov 2007 04:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CC8B32AC50; Mon, 19 Nov 2007 09:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu2dl-0001Pf-JW; Mon, 19 Nov 2007 04:10:01 -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: Mon, 19 Nov 2007 04:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-03.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 : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-03.txt Pages : 16 Date : 2007-11-19 This document extends the QoSFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing Diameter applications where permitted by the command ABNF and to all new applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-03.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-qos-attributes-03.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-qos-attributes-03.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: <2007-11-19040304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19040304.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 Mon Nov 19 06:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4g7-0001eY-25; Mon, 19 Nov 2007 06:20:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4g4-0001dT-Nc; Mon, 19 Nov 2007 06:20:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu4g4-0000X2-Bm; Mon, 19 Nov 2007 06:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 46D582AC50; Mon, 19 Nov 2007 11:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4fa-0007Dp-1x; Mon, 19 Nov 2007 06:20:02 -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: Mon, 19 Nov 2007 06:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-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 --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 : Protocol for Diameter Quality of Service Application Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-diameter-qos-02.txt Pages : 46 Date : 2007-11-19 This document describes the messages and procedures for the Diameter QoS application. The QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation - Pull and Push are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-02.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-diameter-qos-02.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-diameter-qos-02.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: <2007-11-19061852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19061852.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 Mon Nov 19 06:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu598-0001wk-8j; Mon, 19 Nov 2007 06:50:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu597-0001rC-G5; Mon, 19 Nov 2007 06:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu597-0001jO-37; Mon, 19 Nov 2007 06:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BA12F175AA; Mon, 19 Nov 2007 11:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu58c-0007Sf-7b; Mon, 19 Nov 2007 06:50:02 -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: Mon, 19 Nov 2007 06:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-07.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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-07.txt Pages : 21 Date : 2007-11-19 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.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-mip6-integrated-07.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-mip6-integrated-07.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: <2007-11-19064945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19064945.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 Mon Nov 19 08:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Ew-0000QE-MD; Mon, 19 Nov 2007 08:00:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Er-0000K4-6Z; Mon, 19 Nov 2007 08:00:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6Eq-0005YB-PZ; Mon, 19 Nov 2007 08:00:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6499C175AC; Mon, 19 Nov 2007 13:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu6EL-0003XO-TW; Mon, 19 Nov 2007 08:00:01 -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: Mon, 19 Nov 2007 08:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-06.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 Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-06.txt Pages : 32 Date : 2007-11-19 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.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-mip6-split-06.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-mip6-split-06.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: <2007-11-19075217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19075217.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 Nov 20 03:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOkI-0000G6-W6; Tue, 20 Nov 2007 03:46:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNyX-0000ZN-4O; Tue, 20 Nov 2007 02:56:53 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuNyW-0001dM-Az; Tue, 20 Nov 2007 02:56:53 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IuNyT-0000x4-9d; Tue, 20 Nov 2007 08:56:51 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IuNyR-0004R8-W5; Tue, 20 Nov 2007 08:56:49 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IuNyR-0007A6-Fq; Tue, 20 Nov 2007 08:56:47 +0100 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7D00C2FC00E; Tue, 20 Nov 2007 08:56:46 +0100 (CET) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IuNyO-0007vJ-8K; Tue, 20 Nov 2007 08:56:44 +0100 Message-ID: <4742933B.5060501@tm.uka.de> Date: Tue, 20 Nov 2007 08:56:43 +0100 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 References: <470202BF.4000701@gmx.net> <47146250.1000504@tm.uka.de> <47146E15.9090200@gmx.net> In-Reply-To: <47146E15.9090200@gmx.net> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.2 MISSING_HEADERS Missing To: header 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.6 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-Mailman-Approved-At: Tue, 20 Nov 2007 03:46:13 -0500 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Subject: [Dime] Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, [sorry for the long delay of my reply] Hannes Tschofenig wrote: > There are a couple of reasons why we did not want to re-use the QSPEC > draft as is. > > The first reason is that the Diameter QoS attribute document and the > Diameter QoS application document, see > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt > are independent of NSIS. There is no dependency between NSIS and these > documents although the Diameter interworking may also be used for NSIS. Ok. > The second reason is that the QSPEC draft has a different focus in the > sense that the description that is used for the front-end protocol (in > this case NSIS) is somewhat different to the interaction that takes > place at the backend. If you go through the QSPEC draft then you will > notice that many aspects in the draft are so specific to the NSIS > interactions. Unfortunately, the QSPEC is not just a collection of > parameters. We did not want to let the reader figure out which parts of > the document are relevant for them even if they use the Diameter QoS > work for a different purpose (such as in the interaction with RSVP). In > fact, in previous draft versions we just made references to the QSPEC > and when this was brought to other SDOs then this was a real show > stopper since people got totally confused. Ok. > The third reason is that we are changing the format of the QSPEC > headers. We tried to keep the changes at a minimum but still they are > different. Some time back we even considered to use a Diameter specific > format. There are still comments floating around suggesting it but at > the moment the plain QoS parameters are still in the format of the > QSPEC. We also make use of the registry created for the QoS parameters; > some of my recent mails referred to the mismatch between the QSPEC > registry and the registry created by a document in the TSVWG. > > The final reason is that we are changing the semantic of the > extensibility mechanism. The concept of QoS models (QoSM) as defined in > the QSPEC and the requirements for defining a QoSM does not work with > the Diameter usage. Hence, we had to change it. See Section 5 and 6 of > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt > > I believe these reasons justify a new document. > >> 2) The draft doesn't provide a meaningful definition of which parameters >> should be present together etc. It is only an unstructured list of >> parameter objects and there is no hint given about which combinations >> are allowed or meaningful etc. >> > That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to > say anything about it. draft-ietf-dime-diameter-qos-01.txt and > draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For > example, when someone wants to use the IntServ Controlled-Load Service QoSM > http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt > and if an interaction with the Diameter backend infrastructure is > desired then they would take the respective parameters from the received > NSIS message and copy them into a Diameter message. The QoS profile > would be set to a value as defined in the IntServ Controlled-Load > Service QoSM (note that it has not been done yet). If there are specific > issues that need to be said about the backend infrastructure interaction > then they may be discussed in the respective QoSM but so far I have not > heard about anything. > > For some other QoSMs, such as RMD, I have never heard that a AAA > interaction would be desired. There, the usage model is different. > > Does this make sense to you? Yes. Thanks. Regards, Roland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 20 15:13:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZT4-0007lg-Gf; Tue, 20 Nov 2007 15:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZT2-0007WG-Dl for dime@ietf.org; Tue, 20 Nov 2007 15:13:08 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuZSz-0007hC-7D for dime@ietf.org; Tue, 20 Nov 2007 15:13:08 -0500 Received: (qmail invoked by alias); 20 Nov 2007 20:13:04 -0000 Received: from p5498411A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.65.26] by mail.gmx.net (mp040) with SMTP; 20 Nov 2007 21:13:04 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/90DF/7wX9lPVjnRWkOWuXkbWWOyH1frCjWKxpv2 WHNV+b1lEt5z05 Message-ID: <47433FCD.2030802@gmx.net> Date: Tue, 20 Nov 2007 21:13:01 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] DIME Status Update, November 2007 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, yesterday we had a phone conference call with our ADs to be prepared for the IETF meeting. Based on our discussion we have compiled the status update for November: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 20 16:00:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaCq-0006kn-4A; Tue, 20 Nov 2007 16:00:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaCo-0006i4-IV for dime@ietf.org; Tue, 20 Nov 2007 16:00:26 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuaCo-0003vz-A1 for dime@ietf.org; Tue, 20 Nov 2007 16:00:26 -0500 Received: (qmail invoked by alias); 20 Nov 2007 21:00:25 -0000 Received: from p5498411A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.65.26] by mail.gmx.net (mp012) with SMTP; 20 Nov 2007 22:00:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19g3AsbnDpgiBeiLlb+7z/GMzMWO3kG8QHWKrJqW5 7mARO1jt/mkWmY Message-ID: <47434AE7.3080103@gmx.net> Date: Tue, 20 Nov 2007 22:00:23 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Dime] Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 is the agenda for the meeting: http://www3.ietf.org/proceedings/07dec/agenda/dime.txt _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Nov 20 16:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaPq-0004eO-PT; Tue, 20 Nov 2007 16:13:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaPp-0004dR-Ly for dime@ietf.org; Tue, 20 Nov 2007 16:13:53 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuaPo-0004QI-UY for dime@ietf.org; Tue, 20 Nov 2007 16:13:53 -0500 Received: (qmail invoked by alias); 20 Nov 2007 21:13:51 -0000 Received: from p5498411A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.65.26] by mail.gmx.net (mp004) with SMTP; 20 Nov 2007 22:13:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19AqKsAelxAFHi/mw+xMt3hOkQTP3hWXQjJvbUB77 UuY4Fo26kn64f1 Message-ID: <47434E0D.6060701@gmx.net> Date: Tue, 20 Nov 2007 22:13:49 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Dime] Review Request for RADIUS GEOPRIV Document X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, a long time ago a document was published in the GEOPRIV working group that allowed location information to be conveyed between a AAA client and a AAA server. The document focused on RADIUS but provided functionality also for Diameter via the "Diameter RADIUS Interoperability" considerations. Now, the document is about to get finished and I would appreciate if someone could take a look at Section 6 of the document that contains the "Diameter RADIUS Interoperability" section with the AVP Flag rules. Here is the document: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt Please provide feedback by the end of this week. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 21 08:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupoT-0003WO-Gh; Wed, 21 Nov 2007 08:40:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupoT-0003W9-8f for dime@ietf.org; Wed, 21 Nov 2007 08:40:21 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IupoQ-0005Ai-LM for dime@ietf.org; Wed, 21 Nov 2007 08:40:21 -0500 Received: (qmail 20281 invoked by uid 0); 21 Nov 2007 13:40:17 -0000 Received: from 82.113.121.1 by www071.gmx.net with HTTP; Wed, 21 Nov 2007 14:40:15 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Nov 2007 14:40:15 +0100 From: "Hannes Tschofenig" Message-ID: <20071121134015.26750@gmx.net> MIME-Version: 1.0 To: dime@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18b7epfahEbodIYpVb0U9oD4OHHoEknYkpmNeATMx T0DbipG9Em1FdUZhf0vWrDpYff7gE09xPRuw== Content-Transfer-Encoding: 7bit X-GMX-UID: JEQtKAEyMydhAaQ2qGtlnSJjaGRhZtpM X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Dime] Important: DIME WG Document Reviews X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 are very soon starting a couple of WGLCs to finish our documents. We need YOUR feedback. Hence, we would appreciate to receive a lot of review coments for our current WG documents (even if the feedback is only "I read it and I like it."). I particularly would like to address those people who would like their favorite document to become a DIME working group document. IF YOU DO NOT CONTRIBUTE TO THE WORK IN THIS GROUP THEN YOU CANNOT EXPECT THE GROUP TO WORK ON YOUR DOCUMENT. This is a fairly simple rule. Please keep it in mind when you do your preparation for the IETF#70 meeting. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 21 08:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iupw3-0004ar-PA; Wed, 21 Nov 2007 08:48:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iupw2-0004ae-DI for DiME@ietf.org; Wed, 21 Nov 2007 08:48:10 -0500 Received: from mail96.messagelabs.com ([216.82.254.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iupvx-0005VY-OF for DiME@ietf.org; Wed, 21 Nov 2007 08:48:10 -0500 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-5.tower-96.messagelabs.com!1195652884!12078742!1 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 2118 invoked from network); 21 Nov 2007 13:48:04 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-5.tower-96.messagelabs.com with SMTP; 21 Nov 2007 13:48:04 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 7.0.2FP2) with ESMTP id 2007112119181515-62651 ; Wed, 21 Nov 2007 19:18:15 +0530 To: DiME@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Wed, 21 Nov 2007 19:27:24 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/21/2007 07:27:21 PM, Serialize complete at 11/21/2007 07:27:21 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/21/2007 07:18:15 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/21/2007 07:18:17 PM, Serialize complete at 11/21/2007 07:18:17 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Dime] Regarding DCCA X-BeenThere: dime@ietf.org X-Mailman-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="===============0060365901==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0060365901== Content-Type: multipart/alternative; boundary="=_alternative 004C4F116525739A_=" This is a multipart message in MIME format. --=_alternative 004C4F116525739A_= Content-Type: text/plain; charset="US-ASCII" Hi All, I am going to implement DCCA server and i am not supporting Multiple-Services-Indicator AVP in my server. So i will get indivisual service request in CCR(update) after first interrogation during Authorization. So the client can make multiple service request for which diffrent CCR(update) can come to the server. Suppose user stops to use one of the service, then how the server will know this indication from client? Please clarify this confusion. Thanks in advance. Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ --=_alternative 004C4F116525739A_= Content-Type: text/html; charset="US-ASCII"

Hi All,
       I am going to implement DCCA server and i am not supporting Multiple-Services-Indicator AVP in my server. So i will get indivisual service request in CCR(update) after first interrogation during Authorization. So the client can make multiple service request for which diffrent CCR(update) can come to the server. Suppose user stops to use one of the service, then how the server will know this indication from client?

Please clarify this confusion. Thanks in advance.


Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 004C4F116525739A_=-- --===============0060365901== 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 --===============0060365901==-- From dime-bounces@ietf.org Wed Nov 21 09:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqHv-0000BY-S4; Wed, 21 Nov 2007 09:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqHu-0000B8-4o for dime@ietf.org; Wed, 21 Nov 2007 09:10:46 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqHr-0006Cx-QJ for dime@ietf.org; Wed, 21 Nov 2007 09:10:46 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lALEAfss016201; Wed, 21 Nov 2007 09:10: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 Subject: RE: [Dime] Review Request for RADIUS GEOPRIV Document Date: Wed, 21 Nov 2007 09:10:41 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E75095C3@sonusmail04.sonusnet.com> In-Reply-To: <47434E0D.6060701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review Request for RADIUS GEOPRIV Document Thread-Index: Acgrul6VtS10ptksRXmWQ21qpR2C1gAjXKog References: <47434E0D.6060701@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes,=20 I think we no longer have the P-flag. Similarly "Encryption" column is no more used. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, November 20, 2007 4:14 PM > To: dime@ietf.org > Subject: [Dime] Review Request for RADIUS GEOPRIV Document >=20 > Hi all, >=20 > a long time ago a document was published in the GEOPRIV working group > that allowed location information to be conveyed between a AAA client > and a AAA server. The document focused on RADIUS but provided > functionality also for Diameter via the "Diameter RADIUS > Interoperability" considerations. >=20 > Now, the document is about to get finished and I would appreciate if > someone could take a look at Section 6 of the document that contains the > "Diameter RADIUS Interoperability" section with the AVP Flag rules. >=20 > Here is the document: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt >=20 > Please provide feedback by the end of this week. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 21 09:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqVQ-0001pD-Rl; Wed, 21 Nov 2007 09:24:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqVP-0001p4-Hq for DiME@ietf.org; Wed, 21 Nov 2007 09:24:43 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqVM-0006Yu-5o for DiME@ietf.org; Wed, 21 Nov 2007 09:24:43 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lALEOdaa026359; Wed, 21 Nov 2007 09:24:39 -0500 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] Regarding DCCA Date: Wed, 21 Nov 2007 09:24:39 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E75095C4@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Regarding DCCA Thread-Index: AcgsRS5sc671PKZHSxKFbtOff3oLOAABLuiA References: From: "Asveren, Tolga" To: "Sitansu Swain" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Sitansu, I assume you will make use of CC-Sub-Session-Id but I don't see where = the problem is. Could you send a message flow indicating where you would = expect problems to happen? Thanks, Tolga ________________________________________ From: Sitansu Swain [mailto:Sitansu.Swain@lntinfotech.com]=20 Sent: Wednesday, November 21, 2007 8:57 AM To: DiME@ietf.org Subject: [Dime] Regarding DCCA Hi All,=20 =A0 =A0 =A0 =A0I am going to implement DCCA server and i am not = supporting Multiple-Services-Indicator AVP in my server. So i will get = indivisual service request in CCR(update) after first interrogation = during Authorization. So the client can make multiple service request = for which diffrent CCR(update) can come to the server. Suppose user = stops to use one of the service, then how the server will know this = indication from client?=20 Please clarify this confusion. Thanks in advance.=20 Thanks & Regards, Sitansu Sekhar Swain Software Engineer=20 POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as:=20 [ =A0] L&T Infotech General Business [x] L&T Infotech Internal Use [ =A0] L&T Infotech Confidential [ =A0] L&T Infotech Proprietary This email may contain confidential or privileged information for the = intended recipient(s). If you are not the intended recipient, please do = not use or disseminate the information, notify the sender and delete it = from your system. ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 21 11:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusTD-0007Io-TG; Wed, 21 Nov 2007 11:30:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusTC-0007Ij-Md for dime@ietf.org; Wed, 21 Nov 2007 11:30:34 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IusTA-0002Yq-2j for dime@ietf.org; Wed, 21 Nov 2007 11:30:34 -0500 Received: (qmail invoked by alias); 21 Nov 2007 16:30:30 -0000 Received: from p54985C5A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.92.90] by mail.gmx.net (mp056) with SMTP; 21 Nov 2007 17:30:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19P7hNevetPusc7oT386YW2Y8LUQejIjNvBWNaQtJ jixdlDUX71+NRf Message-ID: <47445D1E.6040500@gmx.net> Date: Wed, 21 Nov 2007 17:30:22 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Review Request for RADIUS GEOPRIV Document References: <47434E0D.6060701@gmx.net> <033458F56EC2A64E8D2D7B759FA3E7E75095C3@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E75095C3@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, I agree with you. However, please note that this document still references RFC 3588. Hence, providing this information is still OK. Ciao Hannes Asveren, Tolga wrote: > Hi Hannes, > > I think we no longer have the P-flag. Similarly "Encryption" column is > no more used. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, November 20, 2007 4:14 PM >> To: dime@ietf.org >> Subject: [Dime] Review Request for RADIUS GEOPRIV Document >> >> Hi all, >> >> a long time ago a document was published in the GEOPRIV working group >> that allowed location information to be conveyed between a AAA client >> and a AAA server. The document focused on RADIUS but provided >> functionality also for Diameter via the "Diameter RADIUS >> Interoperability" considerations. >> >> Now, the document is about to get finished and I would appreciate if >> someone could take a look at Section 6 of the document that contains >> > the > >> "Diameter RADIUS Interoperability" section with the AVP Flag rules. >> >> Here is the document: >> >> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt > >> Please provide feedback by the end of this week. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 21 13:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuVl-0007In-MI; Wed, 21 Nov 2007 13:41:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuVk-0007Ii-R3 for dime@ietf.org; Wed, 21 Nov 2007 13:41:20 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuVd-00079T-Bp for dime@ietf.org; Wed, 21 Nov 2007 13:41:20 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1928054rvb for ; Wed, 21 Nov 2007 10:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=oQAT3485lLF9sjD+qM/Zy5Esv8KwOtnyaJ/Ky4Rpyog=; b=KRJwya4PQPionJd1dpGMCz8eNwbcAFgVRcoB4e863ofcgRKPMr8i2DdISQ2206cBdBszYX7PqUOb4lS08y2H1LgVU5+qLtNbWEELPhK/qNXBO3GdZCeZURQ2wHn2HYOxOsg/PUzMLmrBMvZdfRJUduK7BCqdjcXpLytIoy2VB6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=jQKmIOdsFzxH9jOU8n763PCTa9wav1A9zYb35S/sgjrs7bkAPj/bsm8Hmx3lVttjJHpN20ewfVAOef0725dq3uKvuZuw3AY8AfXNmhNSOQdDGBuCHqsXVT7gIcLiF0RKaVgUYm8YgLfQgXriM9s1yzAbT3RAEx5jm/pQttGWVRw= Received: by 10.140.139.11 with SMTP id m11mr871279rvd.1195670469390; Wed, 21 Nov 2007 10:41:09 -0800 (PST) Received: by 10.141.50.5 with HTTP; Wed, 21 Nov 2007 10:41:09 -0800 (PST) Message-ID: <9cf5ced20711211041o79cba452rc1e14a11d84380cf@mail.gmail.com> Date: Wed, 21 Nov 2007 13:41:09 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 1b6389ee9044134e X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Dime] WGLC for draft-ietf-dime-qos-attributes-03.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: , Content-Type: multipart/mixed; boundary="===============0600125470==" Errors-To: dime-bounces@ietf.org --===============0600125470== Content-Type: multipart/alternative; boundary="----=_Part_13321_3096214.1195670469354" ------=_Part_13321_3096214.1195670469354 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-03). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-03.txt Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs). Best regards, Hannes Tschofenig David Frascone (IETF DIME Working Group Chairs) -- David Frascone Oxymoron: Safe Sex. ------=_Part_13321_3096214.1195670469354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-03). You may view this document at
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-03.txt

Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs).

Best regards,
Hannes Tschofenig
David Frascone
(IETF DIME Working Group Chairs)

--
David Frascone

Oxymoron: Safe Sex. ------=_Part_13321_3096214.1195670469354-- --===============0600125470== 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 --===============0600125470==-- From dime-bounces@ietf.org Wed Nov 21 13:41:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuWG-0007tp-V9; Wed, 21 Nov 2007 13:41:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuWF-0007rD-TY for dime@ietf.org; Wed, 21 Nov 2007 13:41:51 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuWD-0007Ag-Gs for dime@ietf.org; Wed, 21 Nov 2007 13:41:51 -0500 Received: by wa-out-1112.google.com with SMTP id k40so4169909wah for ; Wed, 21 Nov 2007 10:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=1OkWq3L2kJDougS+S0kpwxhtp0WkDpD+zuq8h5RIMLI=; b=WsHknmk2qwtsaYHm8w9ovG8TnkrQu2kbF274F6PrABZBqhNBcgJ064P7DxCDpfbpmE2C7q/yjhv5Sv9zoXNf5wIunwNZPorG/1YkRrdZ5jxmFNARG/VFOuH5EQTXzbXw2wFZGLY5okq3NRbz8F5OLHb2A9DdHcRJty2ZabLUCk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=S3sig3JdmOvwVvn2bqvpdwxGHb4lxTxfiud2m0k1jwYDzczCqsp/1nykjhpvdyPDtMcHxpfpdY3FhtYhRoqqmKOJYL675TDLVu/FBoAyFsJdNbdAt/3Ejw51sSwFmCqsfSukPIPC5RT/1deQ4Jlv47Cwcm8EW5xc946eXKmsYKw= Received: by 10.141.28.12 with SMTP id f12mr3502576rvj.1195670508765; Wed, 21 Nov 2007 10:41:48 -0800 (PST) Received: by 10.141.50.5 with HTTP; Wed, 21 Nov 2007 10:41:48 -0800 (PST) Message-ID: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> Date: Wed, 21 Nov 2007 13:41:48 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 8e0396879320b1e1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.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: , Content-Type: multipart/mixed; boundary="===============0667763526==" Errors-To: dime-bounces@ietf.org --===============0667763526== Content-Type: multipart/alternative; boundary="----=_Part_13324_28585149.1195670508769" ------=_Part_13324_28585149.1195670508769 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-06.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs). Best regards, Hannes Tschofenig David Frascone (IETF DIME Working Group Chairs) -- David Frascone Oxymoron: Safe Sex. ------=_Part_13324_28585149.1195670508769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-06.txt). You may view this document at
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt

Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs).

Best regards,
Hannes Tschofenig
David Frascone
(IETF DIME Working Group Chairs)

--
David Frascone

Oxymoron: Safe Sex. ------=_Part_13324_28585149.1195670508769-- --===============0667763526== 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 --===============0667763526==-- From dime-bounces@ietf.org Wed Nov 21 13:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuWp-0001N5-Ep; Wed, 21 Nov 2007 13:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuWo-0001M1-7h for dime@ietf.org; Wed, 21 Nov 2007 13:42:26 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuuWl-0007Bl-SF for dime@ietf.org; Wed, 21 Nov 2007 13:42:26 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1928402rvb for ; Wed, 21 Nov 2007 10:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=t5uMw1PNHaPDiN0YSe8NaqAllpTf0+T1tb7pv74kVFQ=; b=jEBibbxKgvgGF/359h1USzlNvPf575j05qdPBixpXuyXqkUml+8LSP1vyKIF+evik2sMmN3QkTBSpD8kzIjihTf8bJvrMCBYrMaFh8VH6vGfA8eGxwXrIAeQ05fC2BCQ7ju+Zqf5QlcNN+zUpI7bhLNbs15Os6ZvC19EI7EBLnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=tlLzLCptmp7Q2pu2DTJO+6GeReDwdjax4Qih8BP3K+xqW9WaHEnmbF5kEU4jHFMgSMdvKMQtEwjK67ShVpzlWC1EZqYYfyhpgqVN/Spc30QgUWkMRWtDRQPTsuDf5fSWTZTfQKBifiXtYUdko/VJ8pvuX0JhSGVgc6u2Lp5Tt5Y= Received: by 10.141.171.6 with SMTP id y6mr3499061rvo.1195670541701; Wed, 21 Nov 2007 10:42:21 -0800 (PST) Received: by 10.141.50.5 with HTTP; Wed, 21 Nov 2007 10:42:21 -0800 (PST) Message-ID: <9cf5ced20711211042u721789c7k15bdeb1331c40449@mail.gmail.com> Date: Wed, 21 Nov 2007 13:42:21 -0500 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 2a709bd662ecafa9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Dime] WGLC for draft-ietf-dime-rfc3588bis-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0296471843==" Errors-To: dime-bounces@ietf.org --===============0296471843== Content-Type: multipart/alternative; boundary="----=_Part_13328_56951.1195670541681" ------=_Part_13328_56951.1195670541681 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Base Protocol" ( draft-ietf-dime-rfc3588bis-09.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-09.txt Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs). Best regards, Hannes Tschofenig David Frascone (IETF DIME Working Group Chairs) -- David Frascone Oxymoron: Safe Sex. ------=_Part_13328_56951.1195670541681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Base Protocol" (draft-ietf-dime-rfc3588bis-09.txt). You may view this document at
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-09.txt

Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs).

Best regards,
Hannes Tschofenig
David Frascone
(IETF DIME Working Group Chairs)


--
David Frascone

Oxymoron: Safe Sex. ------=_Part_13328_56951.1195670541681-- --===============0296471843== 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 --===============0296471843==-- From dime-bounces@ietf.org Thu Nov 22 11:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvF2Y-0007mA-Ev; Thu, 22 Nov 2007 11:36:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvF2W-0007m0-9u for dime@ietf.org; Thu, 22 Nov 2007 11:36:32 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvF2V-0004c2-GD for dime@ietf.org; Thu, 22 Nov 2007 11:36:32 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAMGZHLY022403; Thu, 22 Nov 2007 10:36:19 -0600 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 18:35:57 +0200 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 10:35:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Nov 2007 10:35:38 -0600 Message-ID: <19EBBEC503C3B5469070E0A6674A533AC6D66F@daebe104.NOE.Nokia.com> In-Reply-To: <112220070829.8782.47453DDE00094F730000224E2207021053029D0196020A0409@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) Thread-Index: Acgs4dZjPY5OjjIfSXOK7AwzP76faAAQ2ivA References: <112220070829.8782.47453DDE00094F730000224E2207021053029D0196020A0409@comcast.net> From: To: , , X-OriginalArrivalTime: 22 Nov 2007 16:35:40.0819 (UTC) FILETIME=[B83E4E30:01C82D25] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: dime@ietf.org, gwz@netcube.com Subject: [Dime] RE: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) X-BeenThere: dime@ietf.org X-Mailman-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="===============1102462459==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1102462459== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82D25.B85B0C49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82D25.B85B0C49 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glenn, =20 ________________________________ From: ext glenzorn@comcast.net [mailto:glenzorn@comcast.net]=20 Sent: 22 November, 2007 00:29 To: vfajardo@tari.toshiba.com; jari.arkko@ericsson.com; Loughney John (Nokia-NRC/PaloAlto) Cc: gwz@netcube.com; dime@ietf.org; dave@frascone.com Subject: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) =09 =09 Author List I'm still having a very hard time understanding what Jari & John are doing on this list: if the rest of the authors of RFC 3588 have been removed due to lack of involvement in the bis effort, then it seems to me that they should be, too (unless I've missed a lot of email from them). Otherwise, the rest of the original authors should be listed, too. =20 No major comments on this. I did provide text and issues early on, but I know that I have not had much comment as of late. =20 =20 Section 1 Paragraph 1 " ...routers and network access servers (NAS) have increased in complexity and density, putting new demands on AAA protocols."=20 I don't understand what "density means in this context. Do you mean "port density"? Further, is it really the increased complexity and port density oif the hardware that is placing new demands on the NASs or is it the increased complexity in the treatment of the users & traffic? I think the latter...=20 =20 My guess is that it refers to the increased usage of NASes in generally, which increases the demands on AAA systems. Would the term "usage" be acceptable to replace density.=20 =20 Paragraph 3 & following In general, I think that it is much better to use proper names rather than pointers when referring to external entities; in particular, "RADIUS [RFC2865] does not" not "[RFC2865] does not". =20 Paragraph 5 "In order to provide universal support for transmission-level security, and enable both intra- and inter-domain AAA deployments, Diameter also provides support for TLS. Security is discussed in Section 13." Why "also provides support"? Section 13 only mentions TLS... =20 Paragraph 9 Not sure what the purpose of this paragraph is; while it's true that RADIUS doesn't support data-object security mechanisms, neither does Diameter (& RADIUS is coming closer to supporting such every day)... =20 Roaming support In actual point of fact, it's very difficult to see how Diameter offers better support for roaming than RADIUS; in particular, TLS doesn't helpo roamomg at all, at least in the absence of the elusive global PKI. =20 Last paragraph It has been considerably more than a decade since AAA protocols were introduced... I agree with your points here, I suggestion the get fixed in an update. John=20 ------_=_NextPart_001_01C82D25.B85B0C49 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Glenn,
 

From: ext glenzorn@comcast.net=20 [mailto:glenzorn@comcast.net]
Sent: 22 November, 2007=20 00:29
To: vfajardo@tari.toshiba.com; = jari.arkko@ericsson.com;=20 Loughney John (Nokia-NRC/PaloAlto)
Cc: gwz@netcube.com;=20 dime@ietf.org; dave@frascone.com
Subject: comments on=20 draft-ietf-dime-rfc3588bis-09.txt (part 1)

Author List
I'm still having a very hard time understanding what Jari & = John are=20 doing on this list: if the rest of the authors of RFC 3588 have been = removed=20 due to lack of involvement in the bis effort, then it seems to me that = they=20 should be, too (unless I've missed a lot of email from = them). =20 Otherwise, the rest of the original authors should be listed, = too.
 
No=20 major comments on this. I did provide text and issues early on, but I = know=20 that I have not had much comment as of late.
 
 
Section 1
Paragraph 1
" ...routers and network access servers (NAS) have increased = in=20 complexity
   and density, putting new demands on AAA=20 protocols." 
I don't understand what "density means in this context.  Do = you mean=20 "port density"?  Further, is it really the increased complexity=20 and port density oif the hardware that is placing new demands on = the NASs=20 or is it the increased complexity in the treatment of the users &=20 traffic?  I think the latter... 
 
My=20 guess is that it refers to the increased usage of  NASes in=20 generally, which increases the demands on AAA systems.  = Would=20 the term "usage" be acceptable to replace=20 density. 
 
Paragraph 3 & following
In general, I think that it is much better to use proper names = rather=20 than pointers when referring to external entities; in particular, = "RADIUS=20 [RFC2865] does not" not "[RFC2865] does not".
 
Paragraph 5
"In order to provide universal support for transmission-level = security,=20 and enable both intra- and inter-domain AAA deployments, Diameter also = provides support for TLS.  Security is discussed in Section = 13."
Why "also provides support"?  Section 13 only = mentions=20 TLS...
 
Paragraph 9
Not sure what the purpose of this paragraph is; while it's true = that=20 RADIUS doesn't support data-object security mechanisms, neither does = Diameter=20 (& RADIUS is coming closer to supporting such every day)...
 
Roaming support
In actual point of fact, it's very = difficult to=20 see how Diameter offers better support for roaming than RADIUS; in = particular,=20 TLS doesn't helpo roamomg at all, at least in the absence of the = elusive=20 global PKI.
 
Last paragraph
It has been considerably more than a decade since AAA protocols = were=20 introduced...

  I agree with your points here, I suggestion the = get fixed in=20 an update.
John 
------_=_NextPart_001_01C82D25.B85B0C49-- --===============1102462459== 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 --===============1102462459==-- From dime-bounces@ietf.org Thu Nov 22 14:56:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvIA3-0007py-04; Thu, 22 Nov 2007 14:56:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvIA1-0007oo-W2 for dime@ietf.org; Thu, 22 Nov 2007 14:56:30 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvIA1-0003W7-86 for dime@ietf.org; Thu, 22 Nov 2007 14:56:29 -0500 Received: (qmail invoked by alias); 22 Nov 2007 19:56:27 -0000 Received: from p54987B3E.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.123.62] by mail.gmx.net (mp002) with SMTP; 22 Nov 2007 20:56:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/eT9l2Bljes07g0+/taraw+Zt4zVfXrplbo+Quo0 p+3BnwI83Y4eQr Message-ID: <4745DEE7.7090303@gmx.net> Date: Thu, 22 Nov 2007 20:56:23 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Dime] Tough IETF#70 Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, some of you have recognized it already: We have a short DIME slot and many presentations. In order to have a fruitful meeting everyone is encouraged to read through the documents and to provide feedback already before the meeting. For the main DIME WG items I do not expect a lot of discussion unless someone discovers new open issues. The Diameter Base protocol, the Diameter Mobile IPv6, 2 out of 3 Diameter QoS documents are either in WGLC or finished their WGLC already. The Diameter Applications Design Guidelines would certainly need more feedback to start a WGLC in December. For the new items we are thinking about how to present the work in a reasonable fashion without jumping too much into the details. Here are the proposed agenda items: (1) Diameter Proxy Mobile IPv6 (2) Diameter Prefix Delegation (3) Diameter Classifier (4) Diameter extensions to base protocol facilitating development of redundant applications, handling overload situations and improving existing reliability procedures (5) State Recovery (6) Explicit routing (7) Diameter Mobile IPv4 Revision (8) Alternative Diameter Mobile IPv4 (9) Diameter Support for EAP Re-authentication Protocol (10) Diameter MIBs Out of these 10 items we have seen presentations of (1),(3),(4),(5),(6),(8), and (10) already. Only 3 new items. It would be great if the authors of these documents could indicate the following: * As a short summary: What is the suggested work about? * How long is it going to take to finish the work? * Is there a deadline for the work to be completed? * Is your work needed by another SDO or WG? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 03:44:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvU9E-0006ZH-EF; Fri, 23 Nov 2007 03:44:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvU9D-0006Vz-46 for DiME@ietf.org; Fri, 23 Nov 2007 03:44:27 -0500 Received: from mail142.messagelabs.com ([216.82.249.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvU9A-0008Cz-ND for DiME@ietf.org; Fri, 23 Nov 2007 03:44:27 -0500 X-VirusChecked: Checked X-Env-Sender: Sitansu.Swain@lntinfotech.com X-Msg-Ref: server-14.tower-142.messagelabs.com!1195807463!3351612!1 X-StarScan-Version: 5.5.12.14.2; banners=lntinfotech.com,-,- X-Originating-IP: [202.80.57.66] Received: (qmail 4070 invoked from network); 23 Nov 2007 08:44:23 -0000 Received: from unknown (HELO VASHIOUT.lntinfotech.com) (202.80.57.66) by server-14.tower-142.messagelabs.com with SMTP; 23 Nov 2007 08:44:23 -0000 Received: from vashi.lntinfotech.com ([172.17.25.8]) by VASHIOUT.lntinfotech.com (Lotus Domino Release 7.0.2FP2) with ESMTP id 2007112314143478-68481 ; Fri, 23 Nov 2007 14:14:34 +0530 To: DiME@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sitansu Swain Date: Fri, 23 Nov 2007 14:23:44 +0530 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/23/2007 02:23:42 PM, Serialize complete at 11/23/2007 02:23:42 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/23/2007 02:14:34 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 7.0.2FP2|May 14, 2007) at 11/23/2007 02:14:36 PM, Serialize complete at 11/23/2007 02:14:36 PM X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Dime] Regarding DCCA X-BeenThere: dime@ietf.org X-Mailman-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="===============1571651729==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1571651729== Content-Type: multipart/alternative; boundary="=_alternative 003082216525739C_=" This is a multipart message in MIME format. --=_alternative 003082216525739C_= Content-Type: text/plain; charset="US-ASCII" HI All, I am implementing DCCA server . So can any one gives an practical example about the Service-Context-Id Avp and How it is helpful in DCCA? Thanks in Advance Thanks & Regards, Sitansu Sekhar Swain Software Engineer POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as: [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________ --=_alternative 003082216525739C_= Content-Type: text/html; charset="US-ASCII"
HI All,
        I am implementing DCCA server . So can any one gives an practical example about the Service-Context-Id Avp and How it is helpful in DCCA?
Thanks in Advance

Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________
--=_alternative 003082216525739C_=-- --===============1571651729== 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 --===============1571651729==-- From dime-bounces@ietf.org Fri Nov 23 04:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvUuj-0006ov-8m; Fri, 23 Nov 2007 04:33:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvUuh-0006lz-HU for dime@ietf.org; Fri, 23 Nov 2007 04:33:31 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvUug-00028k-VU for dime@ietf.org; Fri, 23 Nov 2007 04:33:31 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 10:33:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Tough IETF#70 Meeting Date: Fri, 23 Nov 2007 10:33:27 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F99A1@SEHAN021MB.tcad.telia.se> In-Reply-To: <4745DEE7.7090303@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Tough IETF#70 Meeting Thread-Index: AcgtQgoHzq+4oeDQTYuCATqpr+XtVwAbrjqw References: <4745DEE7.7090303@gmx.net> From: To: , X-OriginalArrivalTime: 23 Nov 2007 09:33:29.0125 (UTC) FILETIME=[E7CA4D50:01C82DB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > (1) Diameter Proxy Mobile IPv6 > It would be great if the authors of these documents could indicate the > following: > * As a short summary: What is the suggested work about? PMIP6 bootstrapping AAA support and MAG-AAA & LMA-AAA interfaces. Should be a standards track document. > * How long is it going to take to finish the work? Ready for WGLC before 72nd IETF. > * Is there a deadline for the work to be completed? Before Nov 2008 ;-) > * Is your work needed by another SDO or WG? I know 3GPP rel-8 will be a potential "customer".. maybe WiMAX Forum also. Cheers, Jouni >=20 > Ciao > Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 04:39:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvV0G-000618-3K; Fri, 23 Nov 2007 04:39:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvV0D-0005tV-QL for dime@ietf.org; Fri, 23 Nov 2007 04:39:13 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvV0D-0002JO-39 for dime@ietf.org; Fri, 23 Nov 2007 04:39:13 -0500 Received: (qmail invoked by alias); 23 Nov 2007 09:39:10 -0000 Received: from p54987ADD.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.122.221] by mail.gmx.net (mp054) with SMTP; 23 Nov 2007 10:39:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18InSgLNaEI6aRKrR8yLI0URGcGsZGI8uTnt2k/Ht mimr2TH7Qz38DW Message-ID: <47469FBD.5050509@gmx.net> Date: Fri, 23 Nov 2007 10:39:09 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Diameter Proxy Mobile IPv6 @ [Dime] Tough IETF#70 Meeting References: <4745DEE7.7090303@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F99A1@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F99A1@SEHAN021MB.tcad.telia.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: 7aafa0432175920a4b3e118e16c5cb64 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, do you believe that your document is already pretty solid so that the deadlines are within reach? The work obviously depends on the progress of Proxy Mobile IP in the NETLMM working group. Are you positive that the work in NETLMM on the relevant documents can progress quick enough? Ciao Hannes jouni.korhonen@teliasonera.com wrote: >> (1) Diameter Proxy Mobile IPv6 >> > > >> It would be great if the authors of these documents could indicate the >> following: >> * As a short summary: What is the suggested work about? >> > > PMIP6 bootstrapping AAA support and MAG-AAA & LMA-AAA interfaces. > Should be a standards track document. > > >> * How long is it going to take to finish the work? >> > > Ready for WGLC before 72nd IETF. > > >> * Is there a deadline for the work to be completed? >> > > Before Nov 2008 ;-) > > >> * Is your work needed by another SDO or WG? >> > > I know 3GPP rel-8 will be a potential "customer".. > maybe WiMAX Forum also. > > Cheers, > Jouni > > > > >> Ciao >> Hannes >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 05:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvW3g-0008N9-HM; Fri, 23 Nov 2007 05:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvW3e-0008Mp-Vp for dime@ietf.org; Fri, 23 Nov 2007 05:46:51 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvW3b-0003sO-Bm for dime@ietf.org; Fri, 23 Nov 2007 05:46:50 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 11:46:45 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Diameter Proxy Mobile IPv6 @ [Dime] Tough IETF#70 Meeting Date: Fri, 23 Nov 2007 11:46:44 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F99AC@SEHAN021MB.tcad.telia.se> In-Reply-To: <47469FBD.5050509@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Proxy Mobile IPv6 @ [Dime] Tough IETF#70 Meeting Thread-Index: AcgttLVIlCeW8m+bTjKg1NgrzO3OowAB+pow References: <4745DEE7.7090303@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED3024F99A1@SEHAN021MB.tcad.telia.se> <47469FBD.5050509@gmx.net> From: To: X-OriginalArrivalTime: 23 Nov 2007 10:46:45.0975 (UTC) FILETIME=[24845E70:01C82DBE] X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, > Hi Jouni, >=20 > do you believe that your document is already pretty solid so=20 > that the deadlines are within reach? I am positive that 6-7 months should be enough to progress them to a mature state and be ready for a WGLC. Of course "issues" may show up. We could play safe and extent the readiness deadline to 73rd IETF.=20 > The work obviously depends on the progress of Proxy Mobile IP=20 > in the NETLMM working group. > Are you positive that the work in NETLMM on the relevant=20 > documents can progress quick enough? NETLMM specs should be in pretty OK shape to meet our deadlines. Cheers, Jouni >=20 > Ciao > Hannes >=20 > jouni.korhonen@teliasonera.com wrote: > >> (1) Diameter Proxy Mobile IPv6 > >> =20 > > > > =20 > >> It would be great if the authors of these documents could indicate=20 > >> the > >> following: > >> * As a short summary: What is the suggested work about? > >> =20 > > > > PMIP6 bootstrapping AAA support and MAG-AAA & LMA-AAA interfaces. > > Should be a standards track document. > > > > =20 > >> * How long is it going to take to finish the work? > >> =20 > > > > Ready for WGLC before 72nd IETF. > > > > =20 > >> * Is there a deadline for the work to be completed? > >> =20 > > > > Before Nov 2008 ;-) > > > > =20 > >> * Is your work needed by another SDO or WG? > >> =20 > > > > I know 3GPP rel-8 will be a potential "customer".. > > maybe WiMAX Forum also. > > > > Cheers, > > Jouni > > > > > > > > =20 > >> Ciao > >> Hannes > >> =20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 06:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWfs-0004FT-D1; Fri, 23 Nov 2007 06:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWfr-0004Ej-EA for dime@ietf.org; Fri, 23 Nov 2007 06:26:19 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvWfn-00050T-Ql for dime@ietf.org; Fri, 23 Nov 2007 06:26:19 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 12:26:12 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Review Request for RADIUS GEOPRIV Document Date: Fri, 23 Nov 2007 12:26:10 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F99BA@SEHAN021MB.tcad.telia.se> In-Reply-To: <47434E0D.6060701@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review Request for RADIUS GEOPRIV Document Thread-Index: Acgrul9XQjuvQBoARniuK6SNMT0SwQCA/WQw References: <47434E0D.6060701@gmx.net> From: To: , X-OriginalArrivalTime: 23 Nov 2007 11:26:12.0094 (UTC) FILETIME=[A6D579E0:01C82DC3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Some quick comments on -17 revision of the RADIUS GEOPRIV document.=20 I think the flags in section 6. are OK regarding to RFC3588.=20 In the paragraphs following the flags table. Should we add a statement saying that these attributes are not defined for any particular Diameter application and are available for any application as-is using RFC4005 & RFC4072 defined commands? Section 11.2. Informative References to [GMLv3], [GSM], [ISO], [ITU1400], [ITU212] and [Unicode] have double commas before the month & year. Cheers, Jouni > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 20. marraskuuta 2007 23:14 > To: dime@ietf.org > Subject: [Dime] Review Request for RADIUS GEOPRIV Document >=20 >=20 > Hi all, >=20 > a long time ago a document was published in the GEOPRIV=20 > working group that allowed location information to be=20 > conveyed between a AAA client and a AAA server. The document=20 > focused on RADIUS but provided functionality also for=20 > Diameter via the "Diameter RADIUS Interoperability" considerations. >=20 > Now, the document is about to get finished and I would=20 > appreciate if someone could take a look at Section 6 of the=20 > document that contains the "Diameter RADIUS Interoperability"=20 > section with the AVP Flag rules. >=20 > Here is the document: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius- > lo-16.txt >=20 > Please provide feedback by the end of this week. >=20 > Ciao > Hannes >=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 Fri Nov 23 08:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvYnl-0007GI-1p; Fri, 23 Nov 2007 08:42:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvYnj-0007G6-RJ for dime@ietf.org; Fri, 23 Nov 2007 08:42:35 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvYnj-000137-9W for dime@ietf.org; Fri, 23 Nov 2007 08:42:35 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 73668211B5 for ; Fri, 23 Nov 2007 14:42:34 +0100 (CET) X-AuditID: c1b4fb3e-af6a0bb00000459d-d4-4746d8ca6b0a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 60D8121199 for ; Fri, 23 Nov 2007 14:42:34 +0100 (CET) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 14:42:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Nov 2007 14:42:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP PPID for diameter thread-index: Acgt1rQDupm7aaS8SCa5+Zi5pb0ZAw== From: "Patrik Teppo" To: X-OriginalArrivalTime: 23 Nov 2007 13:42:34.0188 (UTC) FILETIME=[B3BDF0C0:01C82DD6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Dime] SCTP PPID for diameter X-BeenThere: dime@ietf.org X-Mailman-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="===============1219508597==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1219508597== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82DD6.B3895F1B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82DD6.B3895F1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This issue has been up before on dime email list, but no conclusion. Has anyone requested or will there be a SCTP Payload Protocol Identifier for diameter. Current list of PPID: http://www.iana.org/assignments/sctp-parameters Best regards, Patrik ------_=_NextPart_001_01C82DD6.B3895F1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SCTP PPID for diameter

Hi all,

This issue has been up before on dime = email list, but no conclusion. Has anyone requested or will there be a = SCTP Payload Protocol Identifier for diameter.

Current list of PPID:
http://www.iana.org/assignments/sctp-parameters=

Best regards,
Patrik

------_=_NextPart_001_01C82DD6.B3895F1B-- --===============1219508597== 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 --===============1219508597==-- From dime-bounces@ietf.org Fri Nov 23 13:24:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdCP-0000A1-AM; Fri, 23 Nov 2007 13:24:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdCO-00009s-4x for dime@ietf.org; Fri, 23 Nov 2007 13:24:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvdCJ-0001ZX-Ag for dime@ietf.org; Fri, 23 Nov 2007 13:24:20 -0500 X-IronPort-AV: E=Sophos;i="4.21,458,1188770400"; d="scan'208";a="158652728" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2007 19:24:14 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lANIOE9W011891; Fri, 23 Nov 2007 19:24:14 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lANIOEZZ029200; Fri, 23 Nov 2007 18:24:14 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 19:24:14 +0100 Received: from [10.0.0.12] ([10.61.65.46]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 19:24:13 +0100 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Fri, 23 Nov 2007 19:24:07 +0100 To: glenzorn@comcast.net, pete.mccann@motorola.com, Hannes Tschofenig , tena@huawei.com, dongsun@alcatel-lucent.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Nov 2007 18:24:13.0531 (UTC) FILETIME=[0C890AB0:01C82DFE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4455; t=1195842254; x=1196706254; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20comments=20on=20 |Sender:=20; bh=5E82KL1QEpPjhDxhTnaivXRqsU8t/LtLkJHrc4XpuMg=; b=ngw7t8YMcsH1IIu8gUxd51zWJgjUS0ai72fPPjBtWK1qTY7ru5Joq0PmFMUC3Ho30VBaaAbh bAE60BgT/DCNLKKtyIAhZDQlSRqHRh2MuH5DGHecLIj0zK8HH7cpZHzr; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: dime@ietf.org Subject: [Dime] comments on X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, Please find some comments/suggestions on draft-ietf-dime-diameter- qos-02.txt. Thanks for conisdering them. Francois QoS Signaling Proxy =============== I understand there is agreement that the document should allow (and explicitly discuss) scenarios involving Proxy QoS signaling on the DCA-client (as opposed to relying on end-to-end QoS signaling). See: * http://www1.ietf.org/mail-archive/web/dime/current/msg02036.html * http://www1.ietf.org/mail-archive/web/dime/current/msg02033.html, * http://www1.ietf.org/mail-archive/web/dime/current/msg02022.html) In particular, : - in the Push mode, we would want the DQA-S to be able (in the QIR) to instruct the DQA-C to initiate QoS signaling on behalf of sender (ie behave as QoS-signaling sender proxy). - in the Pull mode, we would want the DQA-S to be able (in the QAA) to instruct the DQA-C to terminate QoS Signaling on behalf of the receiver (ie behave as QoS-signaling Receiver Proxy). However, this does not seem to be covered in the updated version. Can we assume it will be covered in subsequent versions? Would it help to propose text for this? Comments: ========= * section 3.2.2: As discussed above, I am interested to see "QoS signaling" being supported/discussed in the Push mode (via use of QoS-Signaling sender proxy). However, as the text of 3.2.2 currently stands (ie there is no mention of QoS signaling proxy) and as the Figure 4 currently stands (ie it does not show any QoS signaling in the Push mode), the following statement seems out of place in section 3.2.2: "Note that the reserved QoS resources reported in the QIA message MAY be different than those initially authorized with the QIR message, due to the QoS signaling specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path. " This text will become relevant when QoS signaling sender-proxy are actually discussed. * section 5.1 & 5.2: should the messages in ABNF format not be called "" and "" instead of "" and ""? * section 7.1: In general, when resource reservation is performed for a SIP session, it is a good idea to use SIP Preconditions (RFC3312) so reservation can be done before ringing. Shouldn't the picture in figure 23 assume illustrate call flow with RFC3312 Precondition? * section 7.1: Figure 23 illustrates a case where QoS-signaling uses sender- initiated signaling for one direction of teh call and receiver- initiated signaling for the other direction. As the objective of the figure is to illustrate how the various steps (SIP signaling, QoS signaling , QoS Authorisation,..) are tied/synchronised together (as opposed to showing all the sophistication of the QoS signaling), I would recommend you illustrate operation with receiver driven signaling in both direction. It will convey the main point more clearly. * section 7.1 the text description uses "Host A/Host B" while the figure uses "End- host requesting QoS" and "Correspondent Node". You want to use one set of terms in both. * section 7.1: The call flow shown with NSLP applies equally to RSVP without any modification. I would like to see this be made explicit. One way would be to: * replace "QoS NLSP Query" by "QoS NSLP Query or RSVP Path" * and replace "QoS NLSP Reserve" by "QoS NSLP Query or RSVP Resv" * section 7.1: The current text only describes half of what is shown in the picture (ie with QoS reservation in the first direction). I suggest we add at least a bit of text saying to the effect of "same happens in reverse direction". * section 7.2: The text: " Note that the examples above show a sender-initiated reservation from the End-Host towards the corresponding node and a receiver-initiated reservation from the correspondent node towards the End-Host." should be removed from 7.2 as the call flow in 7.2 does not involve any QoS signaling. * section 7.x: I'd recommend including call flows here involving QoS signaling proxy (eg Push with QoS Signaling sender proxy). Again, let me know if you'd like proposed text. * I suggest you add [RFC2205] in Informational References since RSVP is mentioned multiple times. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 13:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvddN-00068w-A8; Fri, 23 Nov 2007 13:52:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvddM-00060s-1u for DiME@ietf.org; Fri, 23 Nov 2007 13:52:12 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvddJ-0002TH-8u for DiME@ietf.org; Fri, 23 Nov 2007 13:52:12 -0500 X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1195843927!4885493!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 9504 invoked from network); 23 Nov 2007 18:52:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-153.messagelabs.com with SMTP; 23 Nov 2007 18:52:07 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id lANIq752029108 for ; Fri, 23 Nov 2007 11:52:07 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id lANIq61L013270 for ; Fri, 23 Nov 2007 12:52:06 -0600 (CST) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id lANIq4ff013251 for ; Fri, 23 Nov 2007 12:52:05 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Regarding DCCA Date: Sat, 24 Nov 2007 02:48:18 +0800 Message-ID: <60D839F897E571458DEEFEE669C5546CACB33F@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Regarding DCCA Thread-Index: AcgsRS5sc671PKZHSxKFbtOff3oLOAABLuiAAG3f658= References: <033458F56EC2A64E8D2D7B759FA3E7E75095C4@sonusmail04.sonusnet.com> From: "G Nadaf Liyaqatali-a21917" To: "Sitansu Swain" , X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0843820468==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0843820468== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82E01.EFC12A38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82E01.EFC12A38 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sitansu In the case that you have mentioned, there are two options that the = client can go for.=20 1. The client can stop requesting for units i.e. stop adding RSU in the = MSCC of that service. In this way, no more units will be granted or be = reserved for that service by the server. 2. The client can send CCR terminate for that service alone. =20 Regards Liyaqatali G Nadaf -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wed 11/21/2007 7:54 PM To: Sitansu Swain; DiME@ietf.org Subject: RE: [Dime] Regarding DCCA =20 Hi Sitansu, I assume you will make use of CC-Sub-Session-Id but I don't see where = the problem is. Could you send a message flow indicating where you would = expect problems to happen? Thanks, Tolga ________________________________________ From: Sitansu Swain [mailto:Sitansu.Swain@lntinfotech.com]=20 Sent: Wednesday, November 21, 2007 8:57 AM To: DiME@ietf.org Subject: [Dime] Regarding DCCA Hi All,=20 I am going to implement DCCA server and i am not supporting = Multiple-Services-Indicator AVP in my server. So i will get indivisual = service request in CCR(update) after first interrogation during = Authorization. So the client can make multiple service request for which = diffrent CCR(update) can come to the server. Suppose user stops to use = one of the service, then how the server will know this indication from = client?=20 Please clarify this confusion. Thanks in advance.=20 Thanks & Regards, Sitansu Sekhar Swain Software Engineer=20 POSDATA ODC Communication & Embedded Systems SBU L & T Infotech Limited Vashi Mobile : +919892844710 Ph : 02255945629 The information contained in this email has been classified as:=20 [ ] L&T Infotech General Business [x] L&T Infotech Internal Use [ ] L&T Infotech Confidential [ ] L&T Infotech Proprietary This email may contain confidential or privileged information for the = intended recipient(s). If you are not the intended recipient, please do = not use or disseminate the information, notify the sender and delete it = from your system. ______________________________________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C82E01.EFC12A38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] Regarding DCCA

Hi Sitansu

In the case that you have mentioned, there are two options that the = client can go for.
1. The client can stop requesting for units i.e. stop adding RSU in the = MSCC of that service. In this way, no more units will be granted or be = reserved for that service by the server.
2. The client can send CCR terminate for that service alone.


Regards
Liyaqatali G Nadaf



-----Original Message-----
From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wed 11/21/2007 7:54 PM
To: Sitansu Swain; DiME@ietf.org
Subject: RE: [Dime] Regarding DCCA

Hi Sitansu,

I assume you will make use of CC-Sub-Session-Id but I don't see where = the problem is. Could you send a message flow indicating where you would = expect problems to happen?

   Thanks,
   Tolga
________________________________________
From: Sitansu Swain [mailto:Sitansu.Swain@lntinf= otech.com]
Sent: Wednesday, November 21, 2007 8:57 AM
To: DiME@ietf.org
Subject: [Dime] Regarding DCCA



Hi All,
       I am going to implement DCCA server = and i am not supporting Multiple-Services-Indicator AVP in my server. So = i will get indivisual service request in CCR(update) after first = interrogation during Authorization. So the client can make multiple = service request for which diffrent CCR(update) can come to the server. = Suppose user stops to use one of the service, then how the server will = know this indication from client?

Please clarify this confusion. Thanks in advance.


Thanks & Regards,
Sitansu Sekhar Swain
Software Engineer
POSDATA ODC
Communication & Embedded Systems SBU
L & T Infotech Limited
Vashi
Mobile : +919892844710
Ph : 02255945629

The information contained in this email has been classified as:
[  ] L&T Infotech General Business
[x] L&T Infotech Internal Use
[  ] L&T Infotech Confidential
[  ] L&T Infotech Proprietary
This email may contain confidential or privileged information for the = intended recipient(s). If you are not the intended recipient, please do = not use or disseminate the information, notify the sender and delete it = from your system.


______________________________________________________________________
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime

------_=_NextPart_001_01C82E01.EFC12A38-- --===============0843820468== 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 --===============0843820468==-- From dime-bounces@ietf.org Fri Nov 23 14:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ive68-0000Bb-Ga; Fri, 23 Nov 2007 14:21:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ive67-0000BT-4p for dime@ietf.org; Fri, 23 Nov 2007 14:21:55 -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 1Ive65-0003SV-IC for dime@ietf.org; Fri, 23 Nov 2007 14:21:55 -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 lANJKkcC025771; Fri, 23 Nov 2007 14:20:46 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4747280E.8030800@tari.toshiba.com> Date: Fri, 23 Nov 2007 14:20:46 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: john.loughney@nokia.com References: <112220070829.8782.47453DDE00094F730000224E2207021053029D0196020A0409@comcast.net> <19EBBEC503C3B5469070E0A6674A533AC6D66F@daebe104.NOE.Nokia.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533AC6D66F@daebe104.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: dime@ietf.org, gwz@netcube.com, jari.arkko@ericsson.com Subject: [Dime] Re: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Glenn, Thanks for the review. > > _*Author List*_ > I'm still having a very hard time understanding what Jari & John > are doing on this list: if the rest of the authors of RFC 3588 > have been removed due to lack of involvement in the bis effort, > then it seems to me that they should be, too (unless I've missed a > /lot/ of email from them). Otherwise, the rest of the original > authors should be listed, too. > > No major comments on this. I did provide text and issues early on, > but I know that I have not had much comment as of late. > Speaking on Jari's behalf, his involvement is over a few conferences calls specifically on 3588 issues and cleanup so it may not be as public. Anyway, given the recent efforts that the previous authors have put in, we do plan to update authors list to make it fair. > > > _*Section 1*_ > _Paragraph 1_ > " ...routers and network access servers (NAS) have increased in > complexity > and density, putting new demands on AAA protocols." > I don't understand what "density means in this context. Do you > mean "port density"? Further, is it really the increased > complexity and port density oif the hardware that is placing new > demands on the NASs or is it the increased complexity in the > treatment of the users & traffic? I think the latter... > > My guess is that it refers to the increased usage of NASes in > generally, which increases the demands on AAA systems. Would the > term "usage" be acceptable to replace density. > > _Paragraph 3 & following_ > In general, I think that it is much better to use proper names > rather than pointers when referring to external entities; in > particular, "RADIUS [RFC2865] does not" not "[RFC2865] does not". > Ok. > > _Paragraph 5_ > "In order to provide universal support for transmission-level > security, and enable both intra- and inter-domain AAA deployments, > Diameter also provides support for TLS. Security is discussed in > Section 13." > Why "also provides support"? Section 13 /only/ mentions TLS... > Ok. BTW, TLS support is a MUST to implement but its a "SHOULD" to deploy. Is that ok with you ? > > _Paragraph 9_ > Not sure what the purpose of this paragraph is; while it's true > that RADIUS doesn't support data-object security mechanisms, > neither does Diameter (& RADIUS is coming closer to supporting > such every day)... > > _Roaming support > _In actual point of fact, it's very difficult to see how Diameter > offers better support for roaming than RADIUS; in particular, TLS > doesn't helpo roamomg at all, at least in the absence of the > elusive global PKI. > Agree. I think we can safely remove these paragraphs. > > _Last paragraph_ > It has been considerably more than a decade since AAA protocols > were introduced... > Sure :) regards, victor > > I agree with your points here, I suggestion the get fixed in an > update. > John > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 23 14:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveUV-0002n9-HJ; Fri, 23 Nov 2007 14:47:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveUT-0002n2-Ud for dime@ietf.org; Fri, 23 Nov 2007 14:47:05 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IveUT-0004Mh-Im for dime@ietf.org; Fri, 23 Nov 2007 14:47:05 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 6212519867C; Fri, 23 Nov 2007 21:47:02 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 048F219867A; Fri, 23 Nov 2007 21:47:01 +0200 (EET) Message-ID: <47472E35.6060902@piuha.net> Date: Fri, 23 Nov 2007 21:47:01 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: gwz@netcube.com Subject: Re: [Dime] Re: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) References: <112220070829.8782.47453DDE00094F730000224E2207021053029D0196020A0409@comcast.net> <19EBBEC503C3B5469070E0A6674A533AC6D66F@daebe104.NOE.Nokia.com> <4747280E.8030800@tari.toshiba.com> In-Reply-To: <4747280E.8030800@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, >> >> _*Author List*_ >> I'm still having a very hard time understanding what Jari & John >> are doing on this list: if the rest of the authors of RFC 3588 >> have been removed due to lack of involvement in the bis effort, >> then it seems to me that they should be, too (unless I've missed a >> /lot/ of email from them). Otherwise, the rest of the original >> authors should be listed, too. >> No major comments on this. I did provide text and issues >> early on, >> but I know that I have not had much comment as of late. >> > > Speaking on Jari's behalf, his involvement is over a few conferences > calls specifically on 3588 issues and cleanup so it may not be as > public. Anyway, given the recent efforts that the previous authors > have put in, we do plan to update authors list to make it fair. For what it is worth, my involvement really has been minimal this time. I did participate a few conf calls and other private exchanges. I was planning to do a full walkthrough of the spec, but have so far not found time for that. I feel bad about that. By the way, Hannes brought up the author list issue early on when they were starting the bis effort. At that time I said that I wouldn't mind if my name was dropped off the author list, and that I was not the main author of RFC 3588 -- I still feel like that. Some other people from the old list may be worth retaining, however. I also suggested that they not spend too much time worrying about the list beforehand, because its hard to predict who does most of the work over the course of a long project. If the project is now close to its end, it may be a good time to figure out who the right names on the list are. Please remember that you have many tools to deal with people with varying degrees of involvement, including the author list, contributor and acknowledgment sections, etc. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Nov 24 06:36:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJ5-00082N-OA; Sat, 24 Nov 2007 06:36:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJ4-000825-Rw; Sat, 24 Nov 2007 06:36:18 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtJ3-0001F3-TN; Sat, 24 Nov 2007 06:36:18 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm24947481569; Sat, 24 Nov 2007 19:49:15 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmcf47419042; Mon, 19 Nov 2007 20:12:37 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 20:12:37 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4g8-0001f9-WD; Mon, 19 Nov 2007 06:20:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4g4-0001dT-Nc; Mon, 19 Nov 2007 06:20:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu4g4-0000X2-Bm; Mon, 19 Nov 2007 06:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 46D582AC50; Mon, 19 Nov 2007 11:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4fa-0007Dp-1x; Mon, 19 Nov 2007 06:20:02 -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: Mon, 19 Nov 2007 06:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-02.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org 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 : Protocol for Diameter Quality of Service Application Author(s) : G. Zorn, et al. Filename : draft-ietf-dime-diameter-qos-02.txt Pages : 46 Date : 2007-11-19 This document describes the messages and procedures for the Diameter QoS application. The QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation - Pull and Push are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-02.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-diameter-qos-02.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-diameter-qos-02.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: <2007-11-19061852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19061852.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sat Nov 24 06:36:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJC-00086K-Lv; Sat, 24 Nov 2007 06:36:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJ9-00085W-Ca; Sat, 24 Nov 2007 06:36:24 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtJ5-0006yM-6u; Sat, 24 Nov 2007 06:36:23 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1347481aa6; Sat, 24 Nov 2007 19:49:16 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmdb474192f8; Mon, 19 Nov 2007 20:26:41 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 20:26:41 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu59B-00024J-6S; Mon, 19 Nov 2007 06:50:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu597-0001rC-G5; Mon, 19 Nov 2007 06:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu597-0001jO-37; Mon, 19 Nov 2007 06:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BA12F175AA; Mon, 19 Nov 2007 11:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu58c-0007Sf-7b; Mon, 19 Nov 2007 06:50:02 -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: Mon, 19 Nov 2007 06:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-07.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org 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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-07.txt Pages : 21 Date : 2007-11-19 A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.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-mip6-integrated-07.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-mip6-integrated-07.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: <2007-11-19064945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19064945.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sat Nov 24 06:36:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJY-0008Sa-F9; Sat, 24 Nov 2007 06:36:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJW-0008N6-Lz; Sat, 24 Nov 2007 06:36:46 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtJV-0001GG-L2; Sat, 24 Nov 2007 06:36:46 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1e8474835a5; Sat, 24 Nov 2007 19:49:43 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd94741ac06; Mon, 19 Nov 2007 21:44:08 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 21:44:07 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Ez-0000R0-6G; Mon, 19 Nov 2007 08:00:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6Er-0000K4-6Z; Mon, 19 Nov 2007 08:00:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6Eq-0005YB-PZ; Mon, 19 Nov 2007 08:00:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6499C175AC; Mon, 19 Nov 2007 13:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu6EL-0003XO-TW; Mon, 19 Nov 2007 08:00:01 -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: Mon, 19 Nov 2007 08:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-06.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@ietf.org 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 Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-06.txt Pages : 32 Date : 2007-11-19 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.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-mip6-split-06.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-mip6-split-06.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: <2007-11-19075217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19075217.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sun Nov 25 04:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDTP-0001wj-GE; Sun, 25 Nov 2007 04:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDTN-0001we-LG for dime@ietf.org; Sun, 25 Nov 2007 04:08:17 -0500 Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwDTK-0008Ty-1Q for dime@ietf.org; Sun, 25 Nov 2007 04:08:17 -0500 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Gx881Y0011GXsuc0A00100; Sun, 25 Nov 2007 09:08:16 +0000 Received: from smailcenter87.comcast.net ([204.127.205.187]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id Gx8F1Y00543749o0800000; Sun, 25 Nov 2007 09:08:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=pWbyF_bP0hQA:10 a=wuCGr+PlLRdzulCyz8bj+g==:17 a=q8rcINzlNWTCXgJswZAA:9 a=sKKIASmsWZxJQGnXj8LsMbToD5oA:4 a=_3nJN2eeWHAA:10 a=Qbjde3qFmYo2JgARDKoA:9 a=cFuLVFg6aMEJFDjDflwM5q3ZXf8A:4 a=37WNUvjkh6kA:10 Received: from [203.155.1.251] by smailcenter87.comcast.net; Sun, 25 Nov 2007 09:08:10 +0000 From: glenzorn@comcast.net To: Victor Fajardo , john.loughney@nokia.com Date: Sun, 25 Nov 2007 09:08:10 +0000 Message-Id: <112520070908.2528.47493B7900045B56000009E02213484373029D0196020A0409@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 30 2007) X-Authenticated-Sender: Z2xlbnpvcm5AY29tY2FzdC5uZXQ= MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dime@ietf.org, gwz@netcube.com, jari.arkko@ericsson.com Subject: [Dime] Re: comments on draft-ietf-dime-rfc3588bis-09.txt (part 1) X-BeenThere: dime@ietf.org X-Mailman-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="===============1761824480==" Errors-To: dime-bounces@ietf.org --===============1761824480== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_2528_1195981690_0" --NextPart_Webmail_9m3u9jl4l_2528_1195981690_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit ... > > > > > > _*Section 1*_ > > _Paragraph 1_ > > " ...routers and network access servers (NAS) have increased in > > complexity > > and density, putting new demands on AAA protocols." > > I don't understand what "density means in this context. Do you > > mean "port density"? Further, is it really the increased > > complexity and port density of the hardware that is placing new > > demands on the NASs or is it the increased complexity in the > > treatment of the users & traffic? I think the latter... > > > > My guess is that it refers to the increased usage of NASes in > > generally, which increases the demands on AAA systems. Would the > > term "usage" be acceptable to replace density. How about this? Over time, with the growth of the Internet and the introduction of new access technologies (including wireless, DSL, Mobile IP and Ethernet), both the amount and complexity of processing performed by routers and network access servers (NAS) have increased, putting new demands on AAA protocols. ... > > > > _Paragraph 5_ > > "In order to provide universal support for transmission-level > > security, and enable both intra- and inter-domain AAA deployments, > > Diameter also provides support for TLS. Security is discussed in > > Section 13." > > Why "also provides support"? Section 13 /only/ mentions TLS... > > > > > Ok. BTW, TLS support is a MUST to implement but its a "SHOULD" to > deploy. Is that ok with you ? OK w/me; I'm a little worried about the secdir review but it might be OK. ... --NextPart_Webmail_9m3u9jl4l_2528_1195981690_0 Content-Type: text/html Content-Transfer-Encoding: 8bit
...
> >
> >
> > _*Section 1*_
> > _Paragraph 1_
> > " ...routers and network access servers (NAS) have increased in
> > complexity
> > and density, putting new demands on AAA protocols."
> > I don't understand what "density means in this context. Do you
> > mean "port density"? Further, is it really the increased
> > complexity and port density of the hardware that is placing new
> > demands on the NASs or is it the increased complexity in the
> > treatment of the users & traffic? I think the latter...
> >
> > My guess is that it refers to the increased usage of NASes in
> > generally, which increases the demands on AAA systems. Would the
> > term "usage" be acceptable to replace density.
 
How about this?
 
Over time, with the growth of the Internet and the introduction of new access technologies (including wireless, DSL, Mobile IP and Ethernet), both the amount and complexity of processing performed by routers and network access servers (NAS) have increased, putting new demands on AAA protocols.

...
 
> >
> > _Paragraph 5_
> > "In order to provide universal support for transmission-level
> > security, and enable both intra- and inter-domain AAA deployments,
> > Diameter also provides support for TLS. Security is discussed in
> > Section 13."
> > Why "also provides support"? Section 13 /only/ mentions TLS...
> >
>
>
> Ok. BTW, TLS support is a MUST to implement but its a "SHOULD" to
> deploy. Is that ok with you ?
 
OK w/me; I'm a little worried about the secdir review but it might be OK.

...
--NextPart_Webmail_9m3u9jl4l_2528_1195981690_0-- --===============1761824480== 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 --===============1761824480==-- From dime-bounces@ietf.org Sun Nov 25 04:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDiW-0002yy-DH; Sun, 25 Nov 2007 04:23:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDiU-0002jE-Jf for dime@ietf.org; Sun, 25 Nov 2007 04:23:54 -0500 Received: from qmta10.emeryville.ca.mail.comcast.net ([76.96.30.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwDiU-0000fS-47 for dime@ietf.org; Sun, 25 Nov 2007 04:23:54 -0500 Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id GxMs1Y0040x6nqc0A00500; Sun, 25 Nov 2007 09:23:57 +0000 Received: from smailcenter87.comcast.net ([204.127.205.187]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id GxPw1Y00243749o0800000; Sun, 25 Nov 2007 09:23:57 +0000 X-Authority-Analysis: v=1.0 c=1 a=4gzjiy3AYu8A:10 a=wuCGr+PlLRdzulCyz8bj+g==:17 a=Loq0aNvgbVLzWlS_fh4A:9 a=fnVLN1p6u3RQrb8-xGkA:7 a=AEnBdYcetXbLAJs7fNVSrB2ui4EA:4 a=BDXKcin-EtgA:10 a=xWB7fRZBnjp0oER_gzgA:7 a=os71fPkbO0tjucj_IIJV3RN4idcA:4 a=37WNUvjkh6kA:10 Received: from [203.155.1.251] by smailcenter87.comcast.net; Sun, 25 Nov 2007 09:23:51 +0000 From: glenzorn@comcast.net To: Victor Fajardo , john.loughney@nokia.com, jari.arkko@ericsson.com, Date: Sun, 25 Nov 2007 09:23:51 +0000 Message-Id: <112520070923.9142.47493F270003523D000023B62213484373029D0196020A0409@comcast.net> X-Mailer: AT&T Message Center Version 1 (Oct 30 2007) X-Authenticated-Sender: Z2xlbnpvcm5AY29tY2FzdC5uZXQ= MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dime@ietf.org, gwz@netcube.com Subject: [Dime] comments on draft-ietf-dime-rfc3588bis-09.txt (part 2) X-BeenThere: dime@ietf.org X-Mailman-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="===============1280630799==" Errors-To: dime-bounces@ietf.org --===============1280630799== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_9142_1195982631_0" --NextPart_Webmail_9m3u9jl4l_9142_1195982631_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Section 1.1, penultimate paragraph "A Diameter agent is a node that does not authenticate and/or authorize messages locally; agents include proxies, redirects and relay agents." This doesn't really make sense to me. Suggest "A Diameter agent is a node that does not provide local user authentication or authorization services; agents include proxies, redirects and relay agents." Section 1.1, last paragraph Don't want to be too politically correct, but "abort" is a pretty loaded word, especially in the US; suggest "The Diameter protocol also supports server-initiated messages, such as a request to discontinue service to a particular user." --NextPart_Webmail_9m3u9jl4l_9142_1195982631_0 Content-Type: text/html Content-Transfer-Encoding: 8bit

Section 1.1, penultimate paragraph

"A Diameter agent is a node that does not authenticate and/or authorize messages locally; agents include proxies, redirects and relay agents." 

This doesn't really make sense to me.  Suggest

"A Diameter agent is a node that does not provide local user authentication or authorization services; agents include proxies, redirects and relay agents."

Section 1.1, last paragraph

Don't want to be too politically correct, but "abort" is a pretty loaded word, especially in the US; suggest "The Diameter protocol also supports server-initiated messages, such as a request to discontinue service to a particular user."

--NextPart_Webmail_9m3u9jl4l_9142_1195982631_0-- --===============1280630799== 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 --===============1280630799==-- From dime-bounces@ietf.org Sun Nov 25 04:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwE5K-00073x-F3; Sun, 25 Nov 2007 04:47:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwE5J-00073m-7b for dime@ietf.org; Sun, 25 Nov 2007 04:47:29 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwE5I-00065V-VO for dime@ietf.org; Sun, 25 Nov 2007 04:47:29 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 2F0CA19867C; Sun, 25 Nov 2007 11:47:28 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id BA9D219867A; Sun, 25 Nov 2007 11:47:27 +0200 (EET) Message-ID: <474944B0.70103@piuha.net> Date: Sun, 25 Nov 2007 11:47:28 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: glenzorn@comcast.net Subject: Re: [Dime] comments on draft-ietf-dime-rfc3588bis-09.txt (part 2) References: <112520070923.9142.47493F270003523D000023B62213484373029D0196020A0409@comcast.net> In-Reply-To: <112520070923.9142.47493F270003523D000023B62213484373029D0196020A0409@comcast.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: gwz@netcube.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Glen, > *Section 1.1, last paragraph* > > Don't want to be too politically correct, > I seem to recall some of your t-shirts that support this statement ;-) > but "abort" is a pretty loaded word, especially in the US; suggest > "The Diameter protocol also supports server-initiated messages, such > as a request to discontinue service to a particular user." > This might be OK for the text that you refer to. But "abort" is used in the name of a message in Diameter, and we are NOT changing the names of the Diameter messages to be politically correct :-) I would therefore suggest that we do not start cleaning up the language here either. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Nov 25 04:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwEFP-0007OU-GF; Sun, 25 Nov 2007 04:57:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwEFO-0007Du-4P for dime@ietf.org; Sun, 25 Nov 2007 04:57:54 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwEFN-0001OA-DI for dime@ietf.org; Sun, 25 Nov 2007 04:57:53 -0500 Received: (qmail invoked by alias); 25 Nov 2007 09:57:51 -0000 Received: from p54985FA5.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.95.165] by mail.gmx.net (mp012) with SMTP; 25 Nov 2007 10:57:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xQIVtyjQxGJtoE2dNM6C35aAyusxpvonVpEV/GA Adu+frB063dX+f Message-ID: <4749471C.8090507@gmx.net> Date: Sun, 25 Nov 2007 10:57:48 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.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 I read through http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt At this point in time I only have high-level comments. I am not sure about the usefulness of the proposed mechanism. In some sense you dynamically establish an explicit route based on the initial routing of the message. Then, this information is used for subsequent messages. When something changes along the path then a new route is being "established" and cached by the originator. Diameter routes do not regularly change. If they change then there is a good reason (e.g., failure of a node). This mechanism only seems to be useful for the cases where Diameter routes change because of some irrelevant reason but routing through the explicit path would still be possible. Is there some evidence that the proposed mechanism would actually be helpful? Do we have some real-world data indicating that this is indeed a problem rather than an academic exercise? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Nov 26 04:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa7Q-00087n-Aj; Mon, 26 Nov 2007 04:19:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwa7P-00082i-7y for dime@ietf.org; Mon, 26 Nov 2007 04:19:07 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwa7G-0008PT-Hu for dime@ietf.org; Mon, 26 Nov 2007 04:19:07 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300JS6WBKWL@szxga02-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:14:08 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3002YPWBJL9@szxga02-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:14:08 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300HGMWBJ0J@szxml03-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:14:07 +0800 (CST) Date: Mon, 26 Nov 2007 17:14:07 +0800 From: Tina TSOU Subject: Re: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt To: dime@ietf.org, Hannes Tschofenig Message-id: <012401c8300c$b2ba3e30$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <4749471C.8090507@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1423977824==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1423977824== Content-type: multipart/alternative; boundary="Boundary_(ID_V7lNbMXO1BaZTThfj1s5Rw)" This is a multi-part message in MIME format. --Boundary_(ID_V7lNbMXO1BaZTThfj1s5Rw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear Hannes, Thank you for your review:) Please see my comments in line demarked as [Tina: ...]. B. R. Tina -------------------------------------------------------- Mondays aren't so bad; and pigs have wings... ----- Original Message ----- From: Hannes Tschofenig To: dime@ietf.org Sent: Sunday, November 25, 2007 5:57 PM Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt I read through http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt At this point in time I only have high-level comments. I am not sure about the usefulness of the proposed mechanism. In some sense you dynamically establish an explicit route based on the initial routing of the message. Then, this information is used for subsequent messages. When something changes along the path then a new route is being "established" and cached by the originator. Diameter routes do not regularly change. If they change then there is a good reason (e.g., failure of a node). This mechanism only seems to be useful for the cases where Diameter routes change because of some irrelevant reason but routing through the explicit path would still be possible. [Tina: There is Relay Agent in Diameter routing path, at the same time, in the case it has relative many next hop nodes, routing probably changes. It is because that the Diameter Relay Agent is likely to select the next hop node by random. In Diameter Base Protocol, usually when session starts, the Destination-Host is not appointed. Only the Destination-Realm is appointed. However, The subsequent requests in the session need to appoint Destination-Host to assure it is routed to the same server, as the routing may changes. And the mechanism define by this protocol, is to assure that it is routed to the intermediate stateful Proxy Agent.] Is there some evidence that the proposed mechanism would actually be helpful? [Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" in draft-tsou-dime-base-routing-ext-03.txt. After a Diameter Relay Agent, there are two stateful Proxy Agents. VISITED NETWORK | HOME NETWORK | +--------+ +--------+ | +--------+ | Client |<--->| Relay1 |<----->| Proxy1 | +--------+ +--------+ | +--------+\ \ | \+-------------+ \ | | Home Server | \| /+-------------+ \ +--------+/ |---| Proxy2 | | +--------+ ] Do we have some real-world data indicating that this is indeed a problem rather than an academic exercise? [Tina: Here are some application with stateful Proxy Agent in 3GPP and ETSI TISPAN. I think that if there is stateful Proxy Agent, such mechanism is needed. [TS23.234] 3GPP, "3GPP system to Wireles Local Area Network (WLAN) interworking; System description", 3GPP TS 23.234 Version 7.4.0 2006. Here, 3GPP AAA Proxy is a stateful Proxy Agent. RES/TISPAN-02045-NGN-R2 V0.0.5 ETSI Standard Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS) Here, in Visited NGN Network, the UAAF, CLF are also in this case. ] Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_V7lNbMXO1BaZTThfj1s5Rw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Dear Hannes,
Thank you for your review:)
Please see my comments in line demarked as [Tina: ...].
 
B. R.
Tina
--------------------------------------------------------
Mondays aren't so bad; and pigs have wings...
----- Original Message -----
Sent: Sunday, November 25, 2007 5:57 PM
Subject: [Dime] Review of draft-tsou-dime-base-routing-ext-03.txt

I read through
http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-03.txt

At this point in time I only have high-level comments.

I am not sure about the usefulness of the proposed mechanism. In some
sense you dynamically establish an explicit route based on the initial
routing of the message. Then, this information is used for subsequent
messages. When something changes along the path then a new route is
being "established" and cached by the originator.

Diameter routes do not regularly change. If they change then there is a
good reason (e.g., failure of a node).
This mechanism only seems to be useful for the cases where Diameter
routes change because of some irrelevant reason but routing through the
explicit path would still be possible.
[Tina: There is Relay Agent in Diameter routing path, at the same time, in the case it has relative many next hop nodes, routing probably changes.
It is because that the Diameter Relay Agent is likely to select the next hop node by random.
In Diameter Base Protocol, usually when session starts, the Destination-Host is not appointed. Only the Destination-Realm is appointed. However,
The subsequent requests in the session need to appoint Destination-Host to assure it is routed to the same server, as the routing may changes.
And the mechanism define by this protocol, is to assure that it is routed to the intermediate stateful Proxy Agent.]

Is there some evidence that the proposed mechanism would actually be
helpful?
[Tina: Please look at the "Figure 1: Generic Stateful Proxy Problem" in draft-tsou-dime-base-routing-ext-03.txt.
After a Diameter Relay Agent, there are two stateful Proxy Agents.

              VISITED NETWORK     |    HOME NETWORK
                                  |
      +--------+     +--------+   |   +--------+
      | Client |<--->| Relay1 |<----->| Proxy1 |
      +--------+     +--------+   |   +--------+\
                               \  |              \+-------------+
                                \ |               | Home Server |
                                 \|              /+-------------+
                                  \   +--------+/
                                  |---| Proxy2 |
                                  |   +--------+

]

Do we have some real-world data indicating that this is indeed a problem
rather than an academic exercise?
[Tina: Here are some application with stateful Proxy Agent in 3GPP and ETSI TISPAN. I think that if there is stateful Proxy Agent, such mechanism is needed.
[TS23.234]
              3GPP, "3GPP system to Wireles Local Area Network (WLAN)
              interworking; System description", 3GPP TS 23.234 Version
              7.4.0 2006.
Here, 3GPP AAA Proxy is a stateful Proxy Agent.
 
 
RES/TISPAN-02045-NGN-R2  V0.0.5
ETSI Standard
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
NGN Functional Architecture;
Network Attachment Sub-System (NASS)
Here, in Visited NGN Network, the UAAF, CLF are also in this case.
]

Ciao
Hannes


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_V7lNbMXO1BaZTThfj1s5Rw)-- --===============1423977824== 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 --===============1423977824==-- From dime-bounces@ietf.org Mon Nov 26 04:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaA4-0002By-4b; Mon, 26 Nov 2007 04:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaA3-0002Bs-Jl for dime@ietf.org; Mon, 26 Nov 2007 04:21:51 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwa9w-0008TT-7L for dime@ietf.org; Mon, 26 Nov 2007 04:21:51 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3002PGWMKDX@szxga03-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:20:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300J88WMJM6@szxga03-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:20:44 +0800 (CST) Received: from z24109b ([10.70.76.84]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300D8TWMJCV@szxml03-in.huawei.com> for dime@ietf.org; Mon, 26 Nov 2007 17:20:43 +0800 (CST) Date: Mon, 26 Nov 2007 17:20:42 +0800 From: Tina TSOU Subject: (6) Explicit routing//Re: [Dime] Tough IETF#70 Meeting To: dime@ietf.org, Hannes Tschofenig Message-id: <013901c8300d$9e8036d0$544c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <4745DEE7.7090303@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076436671==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0076436671== Content-type: multipart/alternative; boundary="Boundary_(ID_8zEFnwBAsGI/SP7s7wWn6Q)" This is a multi-part message in MIME format. --Boundary_(ID_8zEFnwBAsGI/SP7s7wWn6Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear Hannes and all, Wrt (6) Explicit routing, > * As a short summary: What is the suggested work about? > Explicit routing becomes a WG item, and target for a standard > track, maybe an informal RFC. > > * How long is it going to take to finish the work? [Authors: Two IETF meetings.] > > * Is there a deadline for the work to be completed? [Authors: Supposed June 2008.] > > * Is your work needed by another SDO or WG? [Authors: It is needed by 3GPP and ETSI TISPAN potentially. We seem to have hidden features like source routing and statefull proxies already in specs that would potentially benefit from explicit routing I-D.] B. R. Tina ----- Original Message ----- From: Hannes Tschofenig To: dime@ietf.org Sent: Friday, November 23, 2007 3:56 AM Subject: [Dime] Tough IETF#70 Meeting Hi all, some of you have recognized it already: We have a short DIME slot and many presentations. In order to have a fruitful meeting everyone is encouraged to read through the documents and to provide feedback already before the meeting. For the main DIME WG items I do not expect a lot of discussion unless someone discovers new open issues. The Diameter Base protocol, the Diameter Mobile IPv6, 2 out of 3 Diameter QoS documents are either in WGLC or finished their WGLC already. The Diameter Applications Design Guidelines would certainly need more feedback to start a WGLC in December. For the new items we are thinking about how to present the work in a reasonable fashion without jumping too much into the details. Here are the proposed agenda items: (1) Diameter Proxy Mobile IPv6 (2) Diameter Prefix Delegation (3) Diameter Classifier (4) Diameter extensions to base protocol facilitating development of redundant applications, handling overload situations and improving existing reliability procedures (5) State Recovery (6) Explicit routing (7) Diameter Mobile IPv4 Revision (8) Alternative Diameter Mobile IPv4 (9) Diameter Support for EAP Re-authentication Protocol (10) Diameter MIBs Out of these 10 items we have seen presentations of (1),(3),(4),(5),(6),(8), and (10) already. Only 3 new items. It would be great if the authors of these documents could indicate the following: * As a short summary: What is the suggested work about? * How long is it going to take to finish the work? * Is there a deadline for the work to be completed? * Is your work needed by another SDO or WG? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_8zEFnwBAsGI/SP7s7wWn6Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Dear Hannes and all,
Wrt (6) Explicit routing,
> * As a short summary: What is the suggested work about?
> Explicit routing becomes a WG item, and target for a standard
> track, maybe an informal RFC.
>
> * How long is it going to take to finish the work?
[Authors: Two IETF meetings.]
>
> * Is there a deadline for the work to be completed?
[Authors: Supposed June 2008.]
>
> * Is your work needed by another SDO or WG?
[Authors: It is needed by 3GPP and ETSI TISPAN potentially.
We seem to have hidden features like source routing and statefull
proxies already in specs that would potentially benefit
from explicit routing I-D.]
 
B. R.
Tina
 
----- Original Message -----
Sent: Friday, November 23, 2007 3:56 AM
Subject: [Dime] Tough IETF#70 Meeting

Hi all,

some of you have recognized it already: We have a short DIME slot and
many presentations.

In order to have a fruitful meeting everyone is encouraged to read
through the documents and to provide feedback already before the meeting.

For the main DIME WG items I do not expect a lot of discussion unless
someone discovers new open issues. The Diameter Base protocol, the
Diameter Mobile IPv6, 2 out of 3 Diameter QoS documents are either in
WGLC or finished their WGLC already. The Diameter Applications Design
Guidelines would certainly need more feedback to start a WGLC in December.

For the new items we are thinking about how to present the work in a
reasonable fashion without jumping too much into the details. Here are
the proposed agenda items:

(1) Diameter Proxy Mobile IPv6
(2) Diameter Prefix Delegation
(3) Diameter Classifier
(4) Diameter extensions to base protocol facilitating development of
redundant applications, handling overload situations and improving
existing reliability procedures
(5) State Recovery
(6) Explicit routing
(7) Diameter Mobile IPv4 Revision
(8) Alternative Diameter Mobile IPv4
(9) Diameter Support for EAP Re-authentication Protocol
(10) Diameter MIBs

Out of these 10 items we have seen presentations of
(1),(3),(4),(5),(6),(8), and (10) already. Only 3 new items.

It would be great if the authors of these documents could indicate the
following:
* As a short summary: What is the suggested work about?
* How long is it going to take to finish the work?
* Is there a deadline for the work to be completed?
* Is your work needed by another SDO or WG?

Ciao
Hannes


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_8zEFnwBAsGI/SP7s7wWn6Q)-- --===============0076436671== 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 --===============0076436671==-- From dime-bounces@ietf.org Mon Nov 26 11:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhD1-0002BJ-51; Mon, 26 Nov 2007 11:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhD0-00029B-3y for dime@ietf.org; Mon, 26 Nov 2007 11:53:22 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhCv-0003Lw-LJ for dime@ietf.org; Mon, 26 Nov 2007 11:53:22 -0500 Received: by rv-out-0910.google.com with SMTP id l15so564619rvb for ; Mon, 26 Nov 2007 08:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=3oeoVGb00ykwKqIFVlUIYODx+fsuMchT0gmhvrST9pg=; b=PrDAvKFD/7iGLwe2HLkXlwWiEDkhdG8y018dYkT8Qev5jIcxXcXNvBX2xsqIXA8SUPdvpjsLe2621cSgiNy7X98w3hz/40g6fWiomsEK8CBO4Uwu3FEQ2EyGlaH/azUbW/unwejRJC+5SNO+4LSLs5K8JihFIDvgul+ya5JzH5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=oV+xS1T+KyAGADdgmbDZ7G5UOSKTMOf3IINW3Z3NOn0qIL6nOgb2+VGrH+HuuZMB/1aURFLv5xkTQeREGE87WieyfvTjYkZIfzGf4pVyD4m3Dg7F8msES4cuAt4LhDrzyfcNBZ99jNjQDM1GWQG8XkRovdSEstgZpsdbPjcsCRk= Received: by 10.140.83.41 with SMTP id g41mr1274196rvb.1196095992390; Mon, 26 Nov 2007 08:53:12 -0800 (PST) Received: by 10.141.50.5 with HTTP; Mon, 26 Nov 2007 08:53:12 -0800 (PST) Message-ID: <9cf5ced20711260853p46cead9aj42cc6bf93a6c287e@mail.gmail.com> Date: Mon, 26 Nov 2007 11:53:12 -0500 From: "David Frascone" To: "Jari Arkko" Subject: Re: [Dime] comments on draft-ietf-dime-rfc3588bis-09.txt (part 2) In-Reply-To: <474944B0.70103@piuha.net> MIME-Version: 1.0 References: <112520070923.9142.47493F270003523D000023B62213484373029D0196020A0409@comcast.net> <474944B0.70103@piuha.net> X-Google-Sender-Auth: 72eb422e3d44053c X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dime@ietf.org, gwz@netcube.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507795471==" Errors-To: dime-bounces@ietf.org --===============1507795471== Content-Type: multipart/alternative; boundary="----=_Part_21269_1693360.1196095992392" ------=_Part_21269_1693360.1196095992392 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Nov 25, 2007 4:47 AM, Jari Arkko wrote: > > > but "abort" is a pretty loaded word, especially in the US; suggest > > "The Diameter protocol also supports server-initiated messages, such > > as a request to discontinue service to a particular user." > > > > This might be OK for the text that you refer to. But "abort" is used in > the name of a message in Diameter, and we are NOT changing the names of > the Diameter messages to be politically correct :-) > > I would therefore suggest that we do not start cleaning up the language > here either. > Why not refer to the actual command then? -- David Frascone Oxymoron: Safe Sex. ------=_Part_21269_1693360.1196095992392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On Nov 25, 2007 4:47 AM, Jari Arkko <jari.arkko@piuha.net> wrote:

> but "abort" is a pretty loaded word, especially in the US; suggest
> "The Diameter protocol also supports server-initiated messages, such
> as a request to discontinue service to a particular user."
>

This might be OK for the text that you refer to. But "abort" is used in
the name of a message in Diameter, and we are NOT changing the names of
the Diameter messages to be politically correct :-)

I would therefore suggest that we do not start cleaning up the language
here either.

Why not refer to the actual command then?




--
David Frascone

Oxymoron: Safe Sex. ------=_Part_21269_1693360.1196095992392-- --===============1507795471== 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 --===============1507795471==-- From dime-bounces@ietf.org Mon Nov 26 13:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwit0-0002Xf-NU; Mon, 26 Nov 2007 13:40:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwisz-0002XZ-Bc for dime@ietf.org; Mon, 26 Nov 2007 13:40:49 -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 1Iwisw-00087D-TT for dime@ietf.org; Mon, 26 Nov 2007 13:40:49 -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 lAQIeEH7033900; Mon, 26 Nov 2007 13:40:15 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <474B1307.80304@tari.toshiba.com> Date: Mon, 26 Nov 2007 13:40:07 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Review Request for RADIUS GEOPRIV Document References: <47434E0D.6060701@gmx.net> In-Reply-To: <47434E0D.6060701@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, Section 6 looks ok to me. Maybe we should be explicit on whether these AVPs can be piggybacked to applications other than 4005 and 4072. regards, victor > Hi all, > > a long time ago a document was published in the GEOPRIV working group > that allowed location information to be conveyed between a AAA client > and a AAA server. The document focused on RADIUS but provided > functionality also for Diameter via the "Diameter RADIUS > Interoperability" considerations. > > Now, the document is about to get finished and I would appreciate if > someone could take a look at Section 6 of the document that contains > the "Diameter RADIUS Interoperability" section with the AVP Flag rules. > > Here is the document: > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt > > Please provide feedback by the end of this week. > > 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 Nov 26 14:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjua-0007BG-S5; Mon, 26 Nov 2007 14:46:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjuZ-00079W-C0 for dime@ietf.org; Mon, 26 Nov 2007 14:46:31 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwjuY-0003M1-RJ for dime@ietf.org; Mon, 26 Nov 2007 14:46:31 -0500 Received: (qmail invoked by alias); 26 Nov 2007 19:46:29 -0000 Received: from p54985274.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.82.116] by mail.gmx.net (mp010) with SMTP; 26 Nov 2007 20:46:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19KE1M8OAdKn1Y+GR7DhGrhgxvv9CQyTivRdhdVyH 02UmufUffjtxe8 Message-ID: <474B2290.5070805@gmx.net> Date: Mon, 26 Nov 2007 20:46:24 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Review Request for RADIUS GEOPRIV Document References: <47434E0D.6060701@gmx.net> <474B1307.80304@tari.toshiba.com> In-Reply-To: <474B1307.80304@tari.toshiba.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: a7d6aff76b15f3f56fcb94490e1052e4 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. I will add this text. Victor Fajardo wrote: > Hi Hannes, > > Section 6 looks ok to me. Maybe we should be explicit on whether these > AVPs can be piggybacked to applications other than 4005 and 4072. > > regards, > victor > > >> Hi all, >> >> a long time ago a document was published in the GEOPRIV working group >> that allowed location information to be conveyed between a AAA client >> and a AAA server. The document focused on RADIUS but provided >> functionality also for Diameter via the "Diameter RADIUS >> Interoperability" considerations. >> >> Now, the document is about to get finished and I would appreciate if >> someone could take a look at Section 6 of the document that contains >> the "Diameter RADIUS Interoperability" section with the AVP Flag rules. >> >> Here is the document: >> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-16.txt >> >> Please provide feedback by the end of this week. >> >> 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 Tue Nov 27 00:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwt6T-0007Ep-VY; Tue, 27 Nov 2007 00:35:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwt6S-0007EA-61 for dime@ietf.org; Tue, 27 Nov 2007 00:35:24 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwt6R-0006s2-P8 for dime@ietf.org; Tue, 27 Nov 2007 00:35:24 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAR5ZKR14469; Tue, 27 Nov 2007 05:35:20 GMT 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: (8) [Dime] Tough IETF#70 Meeting Date: Mon, 26 Nov 2007 23:28:51 -0600 Message-ID: In-Reply-To: <4745DEE7.7090303@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (8) [Dime] Tough IETF#70 Meeting Thread-Index: AcgtQgq3FmwNkw+mScKkFowUjbu1PgDce2mA References: <4745DEE7.7090303@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Hannes, My Apologies for responding a little late. US Thanksgiving holiday:) Please see my comments/answers below. Please let me know if you need further information. Many thanks in advance!=20 Regards, Ahmad =20 > the details. Here are the proposed agenda items: >=20 > (8) Alternative Diameter Mobile IPv4 >=20 > It would be great if the authors of these documents could indicate the > following: > * As a short summary: What is the suggested work about? Since both 3GPP2 and WiMAX relies on EAP for access authentication and session keys derivation and distribution, the FA is not mandated to authenticate MIP4 RRQ using MN-AAA AE (especially with WiMAX) and consequently an FA trip to the AAA during MIP4 initial registration is not mandatory. Here both SDOs 4G architecture require an interface between the HA and AAA for MIP4 authorization and MIP4 registration keys dynamic allocation. Current RFC4004 relies on RFC3957 for MIP4 Registration keys dynamic allocation using nonce and it is not needed as per the aforementioned architectures. In addition to the above, a performance issue is possible because of the coupling of initial MIP4 signaling with Diameter MIP4 Application signaling. Having said the above, a new Diameter MIP4 Application inline with 3GPP2 and WiMAX 4G architectures is needed. This is needed officially and supported by both SDOs. =20 > * How long is it going to take to finish the work? Well, I guess the answer is: it depends. Right. But I believe if we start right away after IETF70, we could adopt the document by IETF71 as a wg doc and hopefully by IETF73 it should be have passed last call and probably AD review:) > * Is there a deadline for the work to be completed? I would leave this for Avi to answer. I believe 3GPP2 is looking for the timeframe of Aug. Sept 2008. > * Is your work needed by another SDO or WG? Absolutely. 3GPP2 and WiMAX have adopted high level drafts to that extent. >=20 > Ciao > Hannes >=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 Tue Nov 27 02:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwv7p-0006WE-4W; Tue, 27 Nov 2007 02:44:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwv7o-0006W7-LS for DiME@ietf.org; Tue, 27 Nov 2007 02:44:56 -0500 Received: from chn-hclin-gws01.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwv7n-0000XY-TS for DiME@ietf.org; Tue, 27 Nov 2007 02:44:56 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id B251037C0BD for ; Tue, 27 Nov 2007 13:14:52 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id 9166137C038for ; Tue, 27 Nov 2007 13:14:52 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 13:14:52 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Nov 2007 13:14:45 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC602F441BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on Credit Control Server FSM Thread-Index: AcgwyWFP1KtE1y+8RnauZ6EhMgvICg== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 27 Nov 2007 07:44:52.0211 (UTC) FILETIME=[650F2430:01C830C9] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-16.8883 TC:1F TRN:40 TV:5.0.1023(15570.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [Dime] Clarification on Credit Control Server FSM X-BeenThere: dime@ietf.org X-Mailman-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="===============0820463124==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0820463124== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C830C9.61ADC438" This is a multi-part message in MIME format. ------_=_NextPart_001_01C830C9.61ADC438 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I need some clarification regarding the Credit control server FSM=2E In RFC 4006, the session based CC client receives RAR received event in "CLIENT, SESSION BASED for intermediate and final interrogations FSM"=2E But in CC Server FSM , there is no state record to send RAR request =2E=2E Can anyone explain the complete flow For Re-Auth=2E 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=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C830C9.61ADC438 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clarification on Credit Control Server FSM

Hi All,

    I need some clarification regarding the Credit control server FSM=2E In= RFC 4006,= the= session based CC client receives RAR received event in= “CLIENT, SESSION BASED for intermediate and final= interrogations FSM”=2E

    But in CC Server FSM , there is no state record to send RAR request =2E= =2E Can anyone explain the complete= flow   For Re-Auth= =2E

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

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C830C9.61ADC438-- --===============0820463124== 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 --===============0820463124==-- From dime-bounces@ietf.org Tue Nov 27 09:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1Jb-0007vm-4w; Tue, 27 Nov 2007 09:21:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1JZ-0007vA-HS for dime@ietf.org; Tue, 27 Nov 2007 09:21:29 -0500 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1JY-0004QK-Qc for dime@ietf.org; Tue, 27 Nov 2007 09:21:29 -0500 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id lARELKca083476 for ; Tue, 27 Nov 2007 15:21:20 +0100 (CET) (envelope-from Ulf.Bodin@operax.com) 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] Tough IETF#70 Meeting Date: Tue, 27 Nov 2007 15:21:23 +0100 Message-ID: <33656995C5C5094A983DE84DA649A9240217FC65@lulex02.ad.operax.com> In-Reply-To: <4745DEE7.7090303@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Tough IETF#70 Meeting Thread-Index: AcgtQg/FEp3ae8ZVT02AfOV0eOouzADuBajw References: <4745DEE7.7090303@gmx.net> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Tue, 27 Nov 2007 15:21:20 +0100 (CET) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/4930/Tue Nov 27 10:03:33 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org (5) State Recovery * As a short summary: What is the suggested work about? Standardizing mechanisms for protocol aided state recovery. Such mechanisms include e.g. backup server selection and timing of state reconstruction after failure. The foreseen work is suggested to be based partly on mechanisms defined in http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing-reqs-03.tx t and partly on complementary mechnisms discussed on the dime list towards draft-asveren-dime-state-recovery-01 (expired draft).=20 * How long is it going to take to finish the work? Assuming that the suggested approach of basing this work on earlier defined and discussed mechanisms it should take just a few meetings to finish this work.=20 * Is there a deadline for the work to be completed? No.=20 * Is your work needed by another SDO or WG? Yes. This work is desired by ETSI TISPAN, which has issued an liasion statement earlier this year on the topic. In addition ITU-T and 3GPP are likely to find use for state recovery mechanisms provided by the IETF.=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 22 november 2007 20:56 To: dime@ietf.org Subject: [Dime] Tough IETF#70 Meeting Hi all, some of you have recognized it already: We have a short DIME slot and many presentations. In order to have a fruitful meeting everyone is encouraged to read through the documents and to provide feedback already before the meeting. For the main DIME WG items I do not expect a lot of discussion unless someone discovers new open issues. The Diameter Base protocol, the Diameter Mobile IPv6, 2 out of 3 Diameter QoS documents are either in WGLC or finished their WGLC already. The Diameter Applications Design Guidelines would certainly need more feedback to start a WGLC in December. For the new items we are thinking about how to present the work in a reasonable fashion without jumping too much into the details. Here are the proposed agenda items: (1) Diameter Proxy Mobile IPv6 (2) Diameter Prefix Delegation (3) Diameter Classifier (4) Diameter extensions to base protocol facilitating development of redundant applications, handling overload situations and improving existing reliability procedures (5) State Recovery (6) Explicit routing (7) Diameter Mobile IPv4 Revision (8) Alternative Diameter Mobile IPv4 (9) Diameter Support for EAP Re-authentication Protocol (10) Diameter MIBs Out of these 10 items we have seen presentations of (1),(3),(4),(5),(6),(8), and (10) already. Only 3 new items. It would be great if the authors of these documents could indicate the following: * As a short summary: What is the suggested work about? * How long is it going to take to finish the work? * Is there a deadline for the work to be completed? * Is your work needed by another SDO or WG? 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 Tue Nov 27 15:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix79T-0008SS-OA; Tue, 27 Nov 2007 15:35:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix79S-0008QY-BU for dime@ietf.org; Tue, 27 Nov 2007 15:35:26 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix79S-0006h7-11 for dime@ietf.org; Tue, 27 Nov 2007 15:35:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: (8) [Dime] Tough IETF#70 Meeting Date: Tue, 27 Nov 2007 15:35:24 -0500 Message-ID: In-Reply-To: References: <4745DEE7.7090303@gmx.net> From: "Avi Lior" To: "Ahmad Muhanna" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 >=20 > > * Is there a deadline for the work to be completed? >=20 > I would leave this for Avi to answer. I believe 3GPP2 is=20 > looking for the timeframe of Aug. Sept 2008. Both WiMAX and 3GPP2 will need this by Q2, 2008. =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 28 01:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGOy-0003O1-DC; Wed, 28 Nov 2007 01:28:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGOx-0003Nu-IZ for DiME@ietf.org; Wed, 28 Nov 2007 01:28:03 -0500 Received: from gws04.hcl.in ([203.105.186.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxGOw-0002tS-HX for DiME@ietf.org; Wed, 28 Nov 2007 01:28:03 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 65F193670C1 for ; Wed, 28 Nov 2007 11:57:59 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id 4483B361B89for ; Wed, 28 Nov 2007 11:57:59 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 11:57:58 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 11:57:45 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC602F7CB3E@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need some clarification on RAR from CCR Thread-Index: Acgxh8l5H/cdZXmVRxqanBbo8Z2Www== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 28 Nov 2007 06:27:58.0901 (UTC) FILETIME=[D1B9A650:01C83187] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.4066 TC:03 TRN:43 TV:5.0.1023(15572.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [Dime] Need some clarification on RAR from CCR X-BeenThere: dime@ietf.org X-Mailman-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="===============1734116629==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1734116629== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83187.CA074C52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83187.CA074C52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, In RFC4006, the CC client FSM has some State records to process incoming RAR=2E But in CC server FSm, no state record to send RAR=2E "5=2E5=2E Server-Initiated Credit Re-Authorization The Diameter credit-control application supports server-initiated re-authorization=2E The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]=2E The Auth- Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY=2E" Can any one give some real time scenario to send the re-auth-request=2E Regards, Bala DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C83187.CA074C52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Need some clarification on RAR from CCR

Hi All,

     In RFC4006, the= CC client FSM has some State records to process incoming RAR=2E But in CC= server FSm, no state record to send RAR=2E

  = “5=2E5=2E = Server-Initiated Credit Re-Authorization

   The Diameter credit-control application supports= server-initiated

   re-authorization=2E  The credit-control server MAY= optionally initiate

   the credit re-authorization by issuing a Re-Auth-Request= (RAR) as

   defined in the Diameter base protocol [DIAMBASE]= =2E  The Auth-

   Application-Id in the RAR message is set to 4 to= indicate Diameter

   Credit Control, and the Re-Auth-Request-Type is set= to

   AUTHORIZE_ONLY=2E”

  Can any one give some real time scenario to send the= re-auth-request=2E

Regards,

Bala

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

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

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C83187.CA074C52-- --===============1734116629== 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 --===============1734116629==-- From dime-bounces@ietf.org Wed Nov 28 01:30:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGRi-000565-7h; Wed, 28 Nov 2007 01:30:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGRg-00055w-89 for DiME@ietf.org; Wed, 28 Nov 2007 01:30:52 -0500 Received: from chn-hclin-gws01.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxGRf-00035z-81 for DiME@ietf.org; Wed, 28 Nov 2007 01:30:52 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id DA15A37C136 for ; Wed, 28 Nov 2007 12:00:47 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id CF09337C11Ffor ; Wed, 28 Nov 2007 12:00:47 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 12:00:47 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 12:00:46 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC602F7CB58@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need some clarification on RAR from CCS Thread-Index: Acgxh8l5H/cdZXmVRxqanBbo8Z2Www== From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 28 Nov 2007 06:30:47.0522 (UTC) FILETIME=[363B2C20:01C83188] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-7.4066 TC:03 TRN:43 TV:5.0.1023(15572.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Subject: [Dime] Need some clarification on RAR from CCS X-BeenThere: dime@ietf.org X-Mailman-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="===============0105339477==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0105339477== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83188.362ED904" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83188.362ED904 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, In RFC4006, the CC client FSM has some State records to process incoming RAR=2E But in CC server FSm, no state record to send RAR=2E "5=2E5=2E Server-Initiated Credit Re-Authorization The Diameter credit-control application supports server-initiated re-authorization=2E The credit-control server MAY optionally initiate the credit re-authorization by issuing a Re-Auth-Request (RAR) as defined in the Diameter base protocol [DIAMBASE]=2E The Auth- Application-Id in the RAR message is set to 4 to indicate Diameter Credit Control, and the Re-Auth-Request-Type is set to AUTHORIZE_ONLY=2E" Can any one give some real time scenario to send the re-auth-request=2E Regards, Bala DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C83188.362ED904 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Need some clarification on RAR from CCS

Hi All,

     In RFC4006, the= CC client FSM has some State records to process incoming RAR=2E But in CC= server FSm, no state record to send RAR=2E

   “5=2E5=2E = Server-Initiated Credit Re-Authorization

   The Diameter credit-control application supports= server-initiated

   re-authorization=2E  The credit-control server MAY= optionally initiate

   the credit re-authorization by issuing a Re-Auth-Request= (RAR) as

   defined in the Diameter base protocol [DIAMBASE]= =2E  The Auth-

   Application-Id in the RAR message is set to 4 to= indicate Diameter

   Credit Control, and the Re-Auth-Request-Type is set= to

   AUTHORIZE_ONLY=2E”

  Can any one give some real time scenario to send the= re-auth-request=2E

Regards,

Bala

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

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

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C83188.362ED904-- --===============0105339477== 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 --===============0105339477==-- From dime-bounces@ietf.org Wed Nov 28 10:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOs9-00038Y-9H; Wed, 28 Nov 2007 10:30:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOs8-00038L-AO for dime@ietf.org; Wed, 28 Nov 2007 10:30:44 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxOs8-0005el-0z for dime@ietf.org; Wed, 28 Nov 2007 10:30:44 -0500 X-IronPort-AV: E=Sophos;i="4.23,225,1194238800"; d="scan'208";a="87261697" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 28 Nov 2007 10:30:43 -0500 X-IronPort-AV: E=Sophos;i="4.23,225,1194238800"; d="scan'208";a="128973181" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Nov 2007 10:30:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: (8) [Dime] Tough IETF#70 Meeting Date: Wed, 28 Nov 2007 16:30:03 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (8) [Dime] Tough IETF#70 Meeting Thread-Index: AcgxNRd43l8YUVyCSvineLpR9yxhkwAnmM2g References: <4745DEE7.7090303@gmx.net> From: "Romascanu, Dan (Dan)" To: "Avi Lior" , "Ahmad Muhanna" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 'need' like in approved, or published, or something else?=20 Thanks,=20 Dan =20 =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Tuesday, November 27, 2007 10:35 PM > To: Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > Subject: RE: (8) [Dime] Tough IETF#70 Meeting >=20 >=20 > >=20 > > > * Is there a deadline for the work to be completed? > >=20 > > I would leave this for Avi to answer. I believe 3GPP2 is=20 > looking for=20 > > the timeframe of Aug. Sept 2008. >=20 > Both WiMAX and 3GPP2 will need this by Q2, 2008. >=20 >=20 > =20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Nov 28 10:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxP58-0000G9-V0; Wed, 28 Nov 2007 10:44:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxP58-0000Ed-Ak for dime@ietf.org; Wed, 28 Nov 2007 10:44:10 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxP57-0003NI-Sq for dime@ietf.org; Wed, 28 Nov 2007 10:44:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: (8) [Dime] Tough IETF#70 Meeting Date: Wed, 28 Nov 2007 10:44:08 -0500 Message-ID: In-Reply-To: References: <4745DEE7.7090303@gmx.net> From: "Avi Lior" To: "Romascanu, Dan (Dan)" , "Ahmad Muhanna" , "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 In 3GPP2 the concept is approved. Which means that it is going to be standerdized. Thus need mean required. PP2 will develp the text and will publish something. We hope that this would be the same as IETF text. In WiMAX, it may be the same but perhaps a little softer. But it has been discussed and indication is that we need to move in that direction. We havent gotten to approval yet. I may be wrong hence CCing Alper. > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: November 28, 2007 10:30 AM > To: Avi Lior; Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > Subject: RE: (8) [Dime] Tough IETF#70 Meeting >=20 > 'need' like in approved, or published, or something else?=20 >=20 > Thanks,=20 >=20 > Dan >=20 >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, November 27, 2007 10:35 PM > > To: Ahmad Muhanna; Hannes Tschofenig; dime@ietf.org > > Subject: RE: (8) [Dime] Tough IETF#70 Meeting > >=20 > >=20 > > >=20 > > > > * Is there a deadline for the work to be completed? > > >=20 > > > I would leave this for Avi to answer. I believe 3GPP2 is > > looking for > > > the timeframe of Aug. Sept 2008. > >=20 > > Both WiMAX and 3GPP2 will need this by Q2, 2008. > >=20 > >=20 > > =20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 29 02:24:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixdl4-0006tN-GF; Thu, 29 Nov 2007 02:24:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixdl3-0006tD-MJ for dime@ietf.org; Thu, 29 Nov 2007 02:24:25 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixdl2-000089-AG for dime@ietf.org; Thu, 29 Nov 2007 02:24:25 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAT7OLn14945; Thu, 29 Nov 2007 07:24:21 GMT 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] WGLC for draft-ietf-dime-mip6-split-06.txt Date: Thu, 29 Nov 2007 01:24:03 -0600 Message-ID: In-Reply-To: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Thread-Index: AcgsbjQ/bhsShWyZTJOEzQRu7iZUqgFcYi7A References: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> From: "Ahmad Muhanna" To: "David Frascone" , , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, =20 I had reviewed this document and please find my detailed comments below. =20 As a quick note, I believe this document needs a little more attention to improve readability. Best Regards, Ahmad ++++++++++++++++++++++++++ Detailed Comments ++++++++++++++ =20 Abstract [Ahmad-1-START] Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication protocol. In addition to authentication authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. [Ahmad-1] I Propose the below text for Abstract: ------------------------------------------------ This document specify a new Diameter application, Diameter MIPv6 Application, that enables the interaction between Home Agent and Diameter server of the Mobile Service Provider (MSP) to support Mobile IPv6 authentication, authorization and bootstrapping of Mobile IPv6 configuration parameters. The new application defines the required Mobile IPv6 AVPs that carry Mobile IPv6 parameters as part of the Diameter EAP and Diameter NASREQ applications messages during the IKEv2 with EAP authentication mechanism and IKEv2 with certificates and pre-shared secrets authentication mechanism, respectively. Additionally, two new Diameter messages are being defined as part of the Diameter MIPv6 application to support Mobile IPv6 authentication, authorization and bootstrapping of Mobile IPv6 configuration parameters based on the Auth protocol [3]. The collection of Mobile IPv6 services accounting information is also defined. [Ahmad-1-END] [Ahmad-2-Start] 1. Introduction Performing the Mobile IPv6 protocol [1], requires the Mobile Node (MN) to own a Home Address (HoA) and to have an assigned Home Agent (HA) to the MN. The MN needs to register with the HA in order enable its reachability and mobility, when away from home. The registration process itself requires establishment of IPsec security associations (SA) and cryptographic material between the MN and HA. Providing the collection of home address, HA address and keying material is generally referred to as the Mobile IPv6 bootstrapping problem [13]. The purpose of this specification is to provide Diameter support for the interaction between the HA and the AAA server required to solve the bootstrapping problem in the split scenario [2] in a manner that satisfies the requirements defined in [14]. [Ahmad-2] Can we rephrase the above paragraph as below: ------------------------------------------------------- Mobile IPv6 protocol [1] requires the Mobile Node (MN) to be assigned a Home Address (HoA) and a Home Agent (HA). The MN registers with its HA to receive Mobile IPv6 service and reachability while it is away from home. Before the Mobile Node starts the Mobile IPv6 registration process, the mobile node is required to establish an IPsec security associations (IPsec SA) and have access to all cryptographic material that are needed for its relationship with the HA. The process of delivering the collection of the home address, HA address and keying material is generally referred to as the Mobile IPv6 bootstrapping mechanism [13]. The purpose of this specification is to define the Diameter details for the interaction between the HA and the AAA server that is required for the support of Mobile IPv6 bootstrapping mechanism in the split scenario [2] inline with the requirements defined in [14]. [Ahmad-2-END] =20 [Ahmad-3-Start] From a mobility service provider (MSP) perspective, it is important to verify that the MN is authenticated and authorized to utilize Mobile IPv6 service and that such services are accounted for. Only when the MN is authenticated and authorized, the MSP allows the bootstrapping of Mobile IPv6 parameters. Thus, prior to processing the Mobile IPv6 registrations, the HA, participates in the authentication of the MN to verify the MN's identity. The HA also participates in the Mobile IPv6 authorization process involving the Diameter infrastructure. The HA, due to its role in traffic forwarding, may also perform accounting for the Mobile IPv6 service provided to the MN. [Ahmad-3] Can we combine the third and 4th sentences above as below: -------------------------------------------------------------------- Thus, prior to processing the Mobile IPv6 registration, the HA participates in the verification of the MN identity, the authentication of the MN, and the authorization of the Mobile IPv6 services through the help of the Diameter infrastructure. [Ahmad-3-END] [Ahmad-4-START] Authentication: Asserting or helping with assertion of the ........... Although the authentication is performed by the AAA server there is an impact for the HA as different set of command codes are needed for the respective authentication procedures. [Ahmad-4] /s/for the HA/on the HA/ Authorization: The HA must verify that the user is authorized to use the Mobile IPv6 service using the assistance of the MSP Diameter servers. This is accomplished through the use of new Diameter commands specifically designed for performing Mobile IPv6 authorization decisions. This document defines these commands and requires the HA to support them and to participate in this authorization signaling. [Ahmad-4] Can we rephrase the Authorization as follows: ----------------------------------------------------------- Authorization: The Home Agent must verify that the user is authorized to receive Mobile IPv6 service via the MSP Diameter servers. In order for the HA to verify the user Mobile IPv6 service authorization, the HA is required to support the new Diameter application specified in this document. [Ahmad-4-END] [Ahmad-5-START] Mobile IPv6 signaling between the MN and the HA can protected using two different mechanisms, namely using IPsec and via the MIPv6 Authentication Protocol [3]. [Ahmad-5] replace can protected by "can be protected" The important aspect is, however, that for these two approaches several different authentication and key exchange solutions are available. [Ahmad-5] What is meant by the above sentence? To establish IPsec security associations, protecting of Mobile IPv6 signaling messages IKEv2 is used [4]. IKEv2 supports EAP-based authentication, certificates and pre-shared secrets. For protecting using the MIPv6 Authentication Protocol [3] a mechanism has been designed that is very similar to the one used by Mobile IPv4. [Ahmad-5] Can we rephrase the above 3 sentences as follows: ----------------------------------------------------------- Internet Key Exchange IKEv2 [4] is used for the establishment of IPsec security association and the protection of Mobile IPv6 signaling. Additionally, IKEv2 supports the use of EAP-based authentication, certificates and pre-shared secrets. On the other hand, Mobile IPv6 Authentication Protocol [3] has been designed to protect Mobile IPv6 signaling in a way similar to the authentication extensions mechanism that is part of Mobile IPv4 [RFC-3344]. [Ahmad-5-END] =20 [Ahmad-6-START] The ability to use different credentials has an impact on the interaction between the HA (acting as a Diameter client) and the Diameter Server. For that reason this document illustrates the usage of these authentication mechanisms with different subsections for: o IKEv2 usage with EAP. o IKEv2 usage with certificates and pre-shared secrets. o MIPv6 Authentication Protocol. [Ahmad-6] I am not sure I understand what is meant by the above paragraph and the three bullets. [Ahmad-6-END] =20 [Ahmad-7-START] AVPs specific to Mobile IPv6 bootstrapping are added to the EAP application commands. [Ahmad-7] EAP application commands is replaced by Diameter EAP. --------------------------------------------------------------- ..... are added to the Diameter EAP Application commands. Figure 2 shows the message flow involved during the authentication phase when EAP is used. [Ahmad-7] Make the above sentence more specific as below. --------------------------------------------------------- Figure 2 shows the message flow involved during the authentication phase when IKEv2 with EAP is used. [Ahmad-7-END] [Ahmad-8-START] This message is routed to the MNs Diameter server/EAP server. The Diameter server selects the EAP method and replies with the DEA Message. Depending on the type of EAP method chosen, a number of DER and DEA messages carry the method specific exchanges between the MN and the Diameter server/EAP server. [Ahmad-8] The first time DEA is mentioned, let us follow the same as DER and state what it stands for, please add Diameter-EAP-Answer before DEA. [Ahmad-8] Depending on the type of EAP method chosen, a number..... replace with Depending on the type of the chosen EAP method, a number ... [Ahmad-8] What does the last sentence under section 4.1. "below" means? "The IKEv2 responder may A network operator needs to be aware of this limitation." [Ahmad-8-END] [Ahmad-9-START] General Comments:=20 ---------------- 1. In the case of using IKEv2 with EAP, Certificates, or pre-shared keys, Do we achieve both Authentication and authorization at the same time? That is my understanding. If that is true, then we need to be consistent when we refer to these IKEv2 mechanisms and mention that what they exactly do. 2. Let us use the same naming for authentication options as per RFC4285bis, i.e. MN-HA Authentication mobility option and MN-AAA Authentication mobility option. In the case of using IKEv2 with EAP, Certificates, or pre-shared keys, Do we achieve both Authentication and authorization at the same time? That is my understanding. If that is true, then we need to be consistent when we refer to these IKEv2 mechanisms and mention that what they exactly do. [Ahmad-9-END] [Ahmad-10-START] Under section 5.2.2, It says: "If the Mobile IPv6 authentication procedure was successful then the response MAY include any set of bootstrapping AVPs." =20 [Ahmad-10] What does the above mean, SHOULD not we be more specific to what to expect, what any means, can we receive no HoA IP address for example!? [Ahmad-10-END] [Ahmad-11-START] Under section 5.3.1, It states that Mobility message replay protection option using timestamp is included in MIPv6 Request Message. Why? As far as RFC4285bis, it says that the HA is the entity which verifies the replay protection if the authentication is successful. On the other hand, If we would like to make the AAA to verify the replay protection, we may need to include the HA timestamp too. NO? [Ahmad-11-END] [Ahmad-12-START] In the case of the collocation of LMA and HA and the possibility of a mobile node to access the HA via Client MIPv6 and then roam into an area with PMIPv6 support, the MN may be then provided PMIPv6 support, this means that the MN will be assigned a whole HNP rather a HoA. In that kind of deployment: SHOULD not we allow the possibility for bootstrapping a HNP and/or a HoA even in the case of Client MIPv6? [Ahmad-12-END] [Ahmad-13-START] Under section 5.3.1: I do not see where the HA request the MN-HA secret or MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA. They are supposed to be flags inside MIP6-feature-vector but is it defined somewhere else? Also, Why in the MAM I see only MIP-MN-to-HA-MSA is returned from the HAAA server? Are we assuming that MN-HA SA is symmetric? Also, why I see MIP-Session-Key AVP by itself in the MAM message. Should not this AVP be part of the MIP-MN-to-HA-MSA AVP? [Ahmad-13-END] [Ahmad-14-START] Under section6.2. MIP-MN-AAA-SPI AVP, we need to use the correct name of the MN-AAA Auth. option as per RFC4285bis, i.e. .... contains an SPI code extracted from the MN-AAA Authentication message option included in the received BU message. [Ahmad-14-END] [Ahmad-15-START] Why are we using MIP-nonce and what is its value in this context? Is it transmitted back to the MN? Also, is not replay protection identified based on the presence of replay protection message option? or I am missing something. why do we need it here? In other words, either SQN is supported or not. If it is, then HA would accept BU with SQN only, if it is not, HA will not accept BU without the timestamp. No? [Ahmad-15-END] [Ahmad-16-START] Under section 7.1, it says: MIP6-TIMESTAMP-MISMATCH (Status Code TBD) This error code is used by the home agent to indicate to the HA that the timestamp value provided as part of the MN-AAA option has an unacceptable clock-drift. s/indicate to the HA/indicate to the MN/ Also, timestamp was not provided as part of the MN-AAA option. what you are trying to say here? [Ahmad-16-END] =20 [Ahmad-17-START] Finally: Is it possible to change the names of the Diameter MIPv6 Application messages?: 1. Diameter-MIP6-Request (DMR) 2. Diameter-MIP6-Answer (DMA) Just a suggestion! =20 [Ahmad-17-END]=20 =20 Regards,=20 Ahmad=20 ________________________________ From: David Frascone [mailto:dave@frascone.com]=20 Sent: Wednesday, November 21, 2007 12:42 PM To: dime@ietf.org Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt =09 =09 This message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-06.txt). You may view this document at =09 http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt =20 =09 Please post comments and questions to the DIME mailing list (or to the authors) no later than 18 December 2007 (4 weeks because of the upcoming IETF meeting and the involvement of other SDOs). =09 Best regards, Hannes Tschofenig David Frascone (IETF DIME Working Group Chairs) =09 --=20 David Frascone =09 Oxymoron: Safe Sex.=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 29 04:56:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg8g-00089S-CB; Thu, 29 Nov 2007 04:56:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixg8e-00085v-LP for DiME@ietf.org; Thu, 29 Nov 2007 04:56:56 -0500 Received: from jaguar.aricent.com ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixg8Y-0005lE-Cy for DiME@ietf.org; Thu, 29 Nov 2007 04:56:56 -0500 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lAT9ks6n002692 for ; Thu, 29 Nov 2007 15:16:54 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id lAT9ksxU002670; Thu, 29 Nov 2007 15:16:54 +0530 In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC602F441BA@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> To: "Balamurugan T, TLS-Chennai" Subject: Re: [Dime] Clarification on Credit Control Server FSM MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Thu, 29 Nov 2007 15:26:26 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 29/11/2007 03:31:31 PM, Serialize complete at 29/11/2007 03:31:31 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: DiME@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769577921==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1769577921== Content-Type: multipart/alternative; boundary="=_alternative 0036A139652573A2_=" This is a multipart message in MIME format. --=_alternative 0036A139652573A2_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20!=0D=0A=0D=0AServer=20can=20send=20the=20RAR=20message=20to=20client= =20when=20the=20session=20is=20in=20open=20=0D=0Astate.=20A=20credit=20co= ntrol=20client=20that=20receives=20an=20RAR=20message=20with=20=0D=0ASess= ion-Id=20equal=20to=20a=20currently=20active=20credit-control=20session= =20MUST=20=0D=0Aacknowledge=20the=20request=20by=20sending=20the=20Re-Aut= h-Answer=20(RAA)=20message=20and=20=0D=0AMUST=20initiate=20the=20credit= =20re-authorization=20toward=20the=20server=20by=20sending=20a=20=0D=0ACr= edit-Control-Request=20message=20with=20the=20CC-Request-Type=20AVP=20set= =20to=20the=20=0D=0Avalue=20UPDATE_REQUEST.=20The=20Result-Code=202002=20= (DIAMETER_LIMITED_SUCCESS)=20=0D=0ASHOULD=20be=20used=20in=20the=20RAA=20= message=20to=20indicate=20that=20an=20additional=20message=20=0D=0A(i.e.,= =20CCR=20message=20=20with=20the=20value=20UPDATE_REQUEST)=20is=20require= d=20to=20complete=20=0D=0Athe=20procedure.=0D=0A=0D=0AThis=20is=20capture= d=20in=20the=20RFC=20but=20same=20is=20not=20present=20in=20the=20server= =20FSM.=20=0D=0A=0D=0ARegards=0D=0APreeti=0D=0A=0D=0A=0D=0A=0D=0A"Balamur= ugan=20T,=20TLS-Chennai"=20=20=0D=0A11/27/2007=2001:= 14=20PM=0D=0A=0D=0A=0D=0ATo=0D=0A=0D=0Acc=0D=0A=0D=0ASubje= ct=0D=0A[Dime]=20Clarification=20on=20Credit=20Control=20Server=20FSM=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AHi=20All,=0D=0A=20=20=20=20I=20nee= d=20some=20clarification=20regarding=20the=20Credit=20control=20server=20= FSM.=20In=20=0D=0ARFC=204006,=20the=20session=20based=20CC=20client=20rec= eives=20RAR=20received=20event=20in=20=0D=0A?CLIENT,=20SESSION=20BASED=20= for=20intermediate=20and=20final=20interrogations=20FSM?.=0D=0A=20=20=20= =20But=20in=20CC=20Server=20FSM=20,=20there=20is=20no=20state=20record=20= to=20send=20RAR=20request=20..=20=0D=0ACan=20anyone=20explain=20the=20com= plete=20flow=20=20=20For=20Re-Auth.=0D=0AThanks=20in=20Advance,=0D=0ABala= =0D=0A=0D=0ADISCLAIMER:=0D=0A--------------------------------------------= -------------------------------------------------------------------------= --=0D=0A=0D=0AThe=20contents=20of=20this=20e-mail=20and=20any=20attachmen= t(s)=20are=20confidential=20and=20=0D=0Aintended=20for=20the=20named=20re= cipient(s)=20only.=0D=0AIt=20shall=20not=20attach=20any=20liability=20on= =20the=20originator=20or=20HCL=20or=20its=20=0D=0Aaffiliates.=20Any=20vie= ws=20or=20opinions=20presented=20in=20=0D=0Athis=20email=20are=20solely= =20those=20of=20the=20author=20and=20may=20not=20necessarily=20reflect=20= =0D=0Athe=20opinions=20of=20HCL=20or=20its=20affiliates.=0D=0AAny=20form= =20of=20reproduction,=20dissemination,=20copying,=20disclosure,=20=0D=0Am= odification,=20distribution=20and=20/=20or=20publication=20of=20=0D=0Athi= s=20message=20without=20the=20prior=20written=20consent=20of=20the=20auth= or=20of=20this=20=0D=0Ae-mail=20is=20strictly=20prohibited.=20If=20you=20= have=0D=0Areceived=20this=20email=20in=20error=20please=20delete=20it=20a= nd=20notify=20the=20sender=20=0D=0Aimmediately.=20Before=20opening=20any= =20mail=20and=20=0D=0Aattachments=20please=20check=20them=20for=20viruses= =20and=20defect.=0D=0A=0D=0A---------------------------------------------= -------------------------------------------------------------------------= -=0D=0A_______________________________________________=0D=0ADiME=20mailin= g=20list=0D=0ADiME@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/d= ime=0D=0A=0D=0A=0D=0A=0D=0A***********************=20=20Aricent-Restricte= d=20=20=20***********************=0D=0A=0D=0A***********************=20= =20Aricent-Restricted=20=20=20***********************=0D=0A"DISCLAIMER:= =20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20inten= ded=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20i= t=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confidential= =20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=20fo= r=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If= =20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=20not= ify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=20inte= nded=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0A= prohibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the= =20contents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibil= ity=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the= =20information=20transmitted=20by=20this=20email=20including=20damage=20f= rom=20virus."=0A --=_alternative 0036A139652573A2_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20!=0D=0A
=0D=0A=
Server=20can=20send=20the=20RAR=20m= essage=20to=20client=0D=0Awhen=20the=20session=20is=20in=20open=20state.= =20A=20credit=20control=20client=20that=20receives=0D=0Aan=20RAR=20messag= e=20with=20Session-Id=20equal=20to=20a=20currently=20active=20credit-cont= rol=0D=0Asession=20MUST=20acknowledge=20the=20request=20by=20sending=20th= e=20Re-Auth-Answer=20(RAA)=0D=0Amessage=20and=20MUST=20initiate=20the=20c= redit=20re-authorization=20toward=20the=20server=0D=0Aby=20sending=20a=20= Credit-Control-Request=20message=20with=20the=20CC-Request-Type=20AVP=0D= =0Aset=20to=20the=20value=20UPDATE_REQUEST.=20The=20Result-Code=202002=20= (DIAMETER_LIMITED_SUCCESS)=0D=0ASHOULD=20be=20used=20in=20the=20RAA=20mes= sage=20to=20indicate=20that=20an=20additional=20message=0D=0A(i.e.,=20CCR= =20message=20 with=20the=20value=20UPDATE_REQUEST)=20is=20required= =20to=0D=0Acomplete=20the=20procedure.=0D=0A
=0D=0A
This=20is=20captured=20in=20the=20RFC=20but=20s= ame=20is=20not=0D=0Apresent=20in=20the=20server=20FSM.=20=0D=0A=0D=0A
Regards=0D=0APreeti=0D=0A
=0D=0A
= =0D=0A
=0D=0A=0D=0A=0D=0A"Balamuruga= n=20T,=20TLS-Chennai"=0D=0A<tbalamurugan@hcl.in>=20= =0D=0A

11/27/2007=2001:14=20PM=0D=0A
=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0ATo=0D=0A<DiME@ietf.org>=0D=0A=0D=0A=0D=0Acc= =0D=0A=0D=0A=0D=0A=0D=0A<= font=20size=3D1=20face=3D"sans-serif">Subject=0D=0A[Dime]=20Clarification= =20on=20Credit=0D=0AControl=20Server=20FSM=0D=0A
=0D=0A= =0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A
Hi=20All,=0D=0A

&n= bsp;=20 =20I=20need=20some=20clarification=0D=0Aregarding=20the=0D= =0ACredit=20control=20server=20FSM.=20In=20RFC=204006,=20the=0D=0Asession= =20based=20CC=20client=20receives=20RAR=20received=20event=0D=0Ain= =20R= 20;CLIENT,=0D=0ASESSION=20BASED=20for=20intermediate=20and=20final=20inte= rrogations=20FSM”.=0D=0A

 =20 =20But=20in=20CC=20Server=20FSM=0D=0A,=20there=20= is=20no=20state=20record=20to=20send=0D=0ARAR=20request=20..=20Can=20anyo= ne=20explain=20the=20complete=20flow=20 =20For=20Re-Auth.=0D= =0A

Thanks=20in=20Advance,=0D=0A

Bala=0D=0A<= p>=0D=0A=0D=0A=0D=0ADISCLAIMER:
=0D=0A-------------------------= -------------------------------------------------------------------------= ---------------------
=0D=0A
=0D=0AThe=20contents=20of=20this=20e-m= ail=20and=20any=20attachment(s)=20are=20confidential=20and=0D=0Aintended= =20for=20the=20named=20recipient(s)=20only.
=0D=0AIt=20shall=20not=20a= ttach=20any=20liability=20on=20the=20originator=20or=20HCL=20or=20its=20a= ffiliates.=0D=0AAny=20views=20or=20opinions=20presented=20in=20
=0D=0A= this=20email=20are=20solely=20those=20of=20the=20author=20and=20may=20not= =20necessarily=20reflect=0D=0Athe=20opinions=20of=20HCL=20or=20its=20affi= liates.
=0D=0AAny=20form=20of=20reproduction,=20dissemination,=20copyi= ng,=20disclosure,=20modification,=0D=0Adistribution=20and=20/=20or=20publ= ication=20of=20
=0D=0Athis=20message=20without=20the=20prior=20written= =20consent=20of=20the=20author=20of=20this=20e-mail=0D=0Ais=20strictly=20= prohibited.=20If=20you=20have
=0D=0Areceived=20this=20email=20in=20err= or=20please=20delete=20it=20and=20notify=20the=20sender=20immediately.=0D= =0ABefore=20opening=20any=20mail=20and=20
=0D=0Aattachments=20please= =20check=20them=20for=20viruses=20and=20defect.
=0D=0A
=0D=0A------= -------------------------------------------------------------------------= ----------------------------------------=0D=0A
_______________________________________________
=0D=0ADiM= E=20mailing=20list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.ietf.org/= mailman/listinfo/dime
=0D=0A=0D=0A

=0D=0A
=0D=0A***********************=20 Ar= icent-Restricted=20 =20***********************
=0D=0A
=0D=0A**= *********************=20 Aricent-Restricted=20 =20*************= **********=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20A=
ricent=20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=
=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20p=
rivileged=20or=20confidential=20information=20and=20should=20not=20be=20=
=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=20wh=
at=20it=20is=20intended.=20If=20you=20have=20received=20this=20message=20=
in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=
=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notified=
=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20=
altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20Ari=
cent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20aris=
ing=20from=20the=20use=20of=20the=20information=20transmitted=20by=20this=
=20email=20including=20damage=20from=20virus."=0A
<= /table> --=_alternative 0036A139652573A2_=-- --===============1769577921== 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 --===============1769577921==-- From dime-bounces@ietf.org Thu Nov 29 10:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixkvr-0000Ge-KU; Thu, 29 Nov 2007 10:04:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixkvq-0000GP-BL for dime@ietf.org; Thu, 29 Nov 2007 10:04:02 -0500 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixkvq-0002rr-0k for dime@ietf.org; Thu, 29 Nov 2007 10:04:02 -0500 Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id lATF41fO012820 for ; Thu, 29 Nov 2007 10:04:01 -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: Thu, 29 Nov 2007 10:04:00 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E75095E8@sonusmail04.sonusnet.com> In-Reply-To: <4745DEE7.7090303@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (4) Redundancy extensions/congestion/duplicate detection Thread-Index: AcgtQgmD+qKK+0RdTRuhACcE6/7hiQFVbhmA References: <4745DEE7.7090303@gmx.net> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Dime] (4) Redundancy extensions/congestion/duplicate detection X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org (We are planning to present only for the overload control mechanism, for the other items I will try to get feedback/opinion after IETF70 via e-mail and possibly conference call) What is the suggested work about:=20 It is about using overload status of Diameter nodes to loadbalance traffic/prevent collapse due to overload.=20 How long would it take to finish it: ~ 3 IETF meetings Is there a deadline for the work: No hard deadline. OTOH the earlier the better so that Diameter has an overload control mechanism. Is needed by other SDO/WG: No. Needed by people which actually develop/deploy Diameter systems :-) Thanks, Tolga=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 29 13:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoF3-0008M5-OT; Thu, 29 Nov 2007 13:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxoF2-0008Le-OS for dime@ietf.org; Thu, 29 Nov 2007 13:36:04 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxoF0-0008Py-HE for dime@ietf.org; Thu, 29 Nov 2007 13:36:04 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 19:36:01 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Date: Thu, 29 Nov 2007 19:35:59 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9B1C@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Thread-Index: AcgsbjQ/bhsShWyZTJOEzQRu7iZUqgFcYi7AADLZHTA= References: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> From: To: , , , X-OriginalArrivalTime: 29 Nov 2007 18:36:01.0232 (UTC) FILETIME=[B0D62500:01C832B6] X-Spam-Score: -4.0 (----) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 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 Ahmad, Thanks for a very extensive review. I'll have some initial comments for your comments inline. [snip] > [Ahmad-6-START] >=20 > The ability to use different credentials has an impact on the > interaction between the HA (acting as a Diameter client) and the > Diameter Server. For that reason this document=20 > illustrates the usage > of these authentication mechanisms with different subsections for: >=20 > o IKEv2 usage with EAP. >=20 > o IKEv2 usage with certificates and pre-shared secrets. >=20 > o MIPv6 Authentication Protocol. >=20 >=20 > [Ahmad-6] > I am not sure I understand what is meant by the above paragraph and > the three bullets. >=20 > [Ahmad-6-END] It is meant to state which cases are covered by this I-D. Each of them is slightly different from the AAA point of view. [snap] =20 > What does the last sentence under section 4.1. "below" means? "The > IKEv2 responder may A network operator needs to be aware of this > limitation." > [Ahmad-8-END] D'oh. It should only read "A network operator needs to be aware of this limitation." > > [Ahmad-9-START] >=20 > General Comments:=20 > ---------------- >=20 > 1. In the case of using IKEv2 with EAP, Certificates, or=20 > pre-shared > keys, Do we achieve both Authentication and=20 > authorization at the > same time? That is my understanding. If that is true, then we That's correct. > need to be consistent when we refer to these IKEv2=20 > mechanisms and > mention that what they exactly do. OK. > 2. Let us use the same naming for authentication options as per > RFC4285bis, i.e. MN-HA Authentication mobility option=20 > and MN-AAA > Authentication mobility option. OK. [snipetisnip] > [Ahmad-10-START] >=20 > Under section 5.2.2, It says: "If the Mobile IPv6 authentication > procedure was successful then the response MAY include any set of > bootstrapping AVPs." > =20 > [Ahmad-10] > What does the above mean, SHOULD not we be more specific to what to > expect, what any means, can we receive no HoA IP address for > example!? Hmm.. MIP6-Feature-Vector in optional. The AAA does not need to return one especially if the HA did not do so either in the request. Also AAA does not need return HoA if the HA did not ask one. Also QoS AVPs are optional and depend obviously on subscription profile. Now that I wrote some of this here, it could definitely be written also to draft ;) > [Ahmad-10-END] >=20 >=20 > [Ahmad-11-START] > Under section 5.3.1, It states that Mobility message replay > protection option using timestamp is included in MIPv6 Request > Message. Why? The AVP is optinal in the ABNF. If the BU contains replay protection option with timestamp that is then conveyed to the AAA. > As far as RFC4285bis, it says that the HA is the entity which > verifies the replay protection if the authentication is successful. Afair 3GPP2 needs it in AAA for their auth option processing... not that they would ever use this spec for that, though. > On the other hand, If we would like to make the AAA to verify the > replay protection, we may need to include the HA timestamp=20 > too. NO? Don't think so. At least the existing documented use in 3GPP2 does not do that. > [Ahmad-11-END] >=20 >=20 > [Ahmad-12-START] > In the case of the collocation of LMA and HA and the=20 > possibility of a > mobile node to access the HA via Client MIPv6 and then roam into an > area with PMIPv6 support, the MN may be then provided=20 > PMIPv6 support, > this means that the MN will be assigned a whole HNP rather=20 > a HoA. In > that kind of deployment: SHOULD not we allow the possibility for > bootstrapping a HNP and/or a HoA even in the case of Client MIPv6? > [Ahmad-12-END] See section 6.4. ".. In case the Diameter server assigns only a Home Network Prefix to the Mobile Node the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address MUST be set to zero." Anyway, the combined PMIP & CMIP case is a bit mess atm. If the proposed *-dime-pmip6-* draft gets adopted we need to sync these a bit more.=20 > [Ahmad-13-START] > Under section 5.3.1: I do not see where the HA request the MN-HA > secret or MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA. They are supposed > to be flags inside MIP6-feature-vector but is it defined somewhere > else? Hmmm.. The assumption has been that AAA always returns MN-HA secret when this application is used. > Also, Why in the MAM I see only MIP-MN-to-HA-MSA is=20 > returned from the > HAAA server? Are we assuming that MN-HA SA is symmetric? Yes. This is something that always bothers me whether that should be asymmetric. Every time I ask opinions about it, no one seems to care about anything else that symmetric SA. > Also, why I see MIP-Session-Key AVP by itself in the MAM message. > Should not this AVP be part of the MIP-MN-to-HA-MSA AVP? > [Ahmad-13-END] That is an editing error. It is part of MIP-MN-to-HA-MSA and should only be in there. [chop] > [Ahmad-15-START] > Why are we using MIP-nonce and what is its value in this=20 > context? Is > it transmitted back to the MN? >=20 > Also, is not replay protection identified based on the > presence of replay protection message option? or I am missing > something. why do we need it here? I need to poke Hannes about nonces. > In other words, either SQN is supported or not. If it is, then HA > would accept BU with SQN only, if it is not, HA will not accept BU > without the timestamp. No? > [Ahmad-15-END] >=20 >=20 > [Ahmad-16-START] > Under section 7.1, it says: MIP6-TIMESTAMP-MISMATCH=20 > (Status Code TBD) >=20 > This error code is used by the home agent to indicate to=20 > the HA that > the timestamp value provided as part of the MN-AAA option has an > unacceptable clock-drift. s/indicate to the HA/indicate to the MN/ >=20 > Also, timestamp was not provided as part of the MN-AAA option. what > you are trying to say here? "This error code is used by the home agent to indicate to the MN that the timestamp value provided in the BU has an unacceptable clock-drift." > [Ahmad-16-END] >=20 > =20 > [Ahmad-17-START] > Finally: Is it possible to change the names of the=20 > Diameter MIPv6 Application > messages?: >=20 > 1. Diameter-MIP6-Request (DMR) >=20 > 2. Diameter-MIP6-Answer (DMA) >=20 > Just a suggestion! =20 > [Ahmad-17-END]=20 >=20 > =20 > Regards, > Ahmad=20 Cheers, Jouni >=20 >=20 > ________________________________ >=20 > From: David Frascone [mailto:dave@frascone.com]=20 > Sent: Wednesday, November 21, 2007 12:42 PM > To: dime@ietf.org > Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt > =09 > =09 >=20 > This message marks the issuance of a working group last call > (WGLC) on DIME's Internet Draft entitled "Diameter Mobile=20 > IPv6: Support > for Home Agent to Diameter Server Interaction" > (draft-ietf-dime-mip6-split-06.txt). You may view this document at > =09 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt > t-06.txt>=20 > =09 > Please post comments and questions to the DIME mailing list (or > to the authors) no later than 18 December 2007 (4 weeks because of the > upcoming IETF meeting and the involvement of other SDOs). > =09 > Best regards, > Hannes Tschofenig > David Frascone > (IETF DIME Working Group Chairs) > =09 > --=20 > David Frascone > =09 > Oxymoron: Safe Sex.=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Nov 29 17:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrch-0006JL-B5; Thu, 29 Nov 2007 17:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrcf-0006IR-DW for dime@ietf.org; Thu, 29 Nov 2007 17:12:41 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixrcd-0002D0-QW for dime@ietf.org; Thu, 29 Nov 2007 17:12:41 -0500 Received: (qmail invoked by alias); 29 Nov 2007 22:12:38 -0000 Received: from p54985860.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.88.96] by mail.gmx.net (mp036) with SMTP; 29 Nov 2007 23:12:38 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18gE3FrrdkgP67C2rHg3sEyM94c9+IR9jcOJcIQol vVBHlvxVBITNs7 Message-ID: <474F3955.4010005@gmx.net> Date: Thu, 29 Nov 2007 23:12:37 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] draft-korhonen-dime-pmip6-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 I read through the draft and think it is pretty well written. I couldn't find any showstoppers. The distribution of the configuration parameters seems to be fine for me. I did notice that the assumption was made that the MAG and the LMA have established some keying material already. That assumption is fine for me at the moment but I am sure that this issue will be raised in the future. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 30 01:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzHR-0005S1-TP; Fri, 30 Nov 2007 01:23:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzHR-0005Rm-Dh for dime@ietf.org; Fri, 30 Nov 2007 01:23:17 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxzHQ-0001sP-D5 for dime@ietf.org; Fri, 30 Nov 2007 01:23:17 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lAU6K2W08754; Fri, 30 Nov 2007 06:20:02 GMT 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] WGLC for draft-ietf-dime-mip6-split-06.txt Date: Fri, 30 Nov 2007 00:23:08 -0600 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9B1C@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Thread-Index: AcgsbjQ/bhsShWyZTJOEzQRu7iZUqgFcYi7AADLZHTAAF1QxAA== References: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9B1C@SEHAN021MB.tcad.telia.se> From: "Ahmad Muhanna" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, Please see comments inline. Regards, Ahmad =20 > Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt >=20 > Hi Ahmad, >=20 > Thanks for a very extensive review. I'll have some initial=20 > comments for your comments inline. >=20 >=20 > [snip] >=20 > > [Ahmad-6-START] > >=20 > > The ability to use different credentials has an impact on the > > interaction between the HA (acting as a Diameter client) and the > > Diameter Server. For that reason this document illustrates the=20 > > usage > > of these authentication mechanisms with different=20 > subsections for: > >=20 > > o IKEv2 usage with EAP. > >=20 > > o IKEv2 usage with certificates and pre-shared secrets. > >=20 > > o MIPv6 Authentication Protocol. > >=20 > >=20 > > [Ahmad-6] > > I am not sure I understand what is meant by the above=20 > paragraph and > > the three bullets. > >=20 > > [Ahmad-6-END] >=20 > It is meant to state which cases are covered by this I-D.=20 > Each of them is slightly different from the AAA point of view. [Ahmad] Can we rephrase the paragraph as follows or something like that: In order to provide the proper details of the different authentication mechanisms, the following three authentication mechanisms will be addressed under separate subsections. o IKEv2 usage with EAP. o IKEv2 usage with certificates and pre-shared secrets. o MIPv6 Authentication Protocol. > >=20 > >=20 > > [Ahmad-11-START] > > Under section 5.3.1, It states that Mobility message replay > > protection option using timestamp is included in MIPv6 Request > > Message. Why? >=20 > The AVP is optinal in the ABNF. If the BU contains replay=20 > protection option with timestamp that is then conveyed to the AAA. [Ahmad] I am not against including the timestamp received in BU, I just want to know the purpose of it. According to what you just said, it is included based on 3GPP2 requirements and need. On the other hand and under section 6.16 it says: " The support for replay protection is an optional feature in [3]. When the Diameter server checks the timestamp provided by the MN via the HA and recognizes a clock-drift (outside a locally defined replay protection window) then it MUST initiate the re-synchronization procedure by returning a MIP6-Answer-Message with Result-Code set to MIP6-TIMESTAMP-MISMATCH and attaches the MIP-Timestamp AVP including it's current time back to the HA. " Apparently, it says that the Diameter server is the one making the replay protection check. That is in conflict with RFC4285bis? Now, what is the justification and the logic of the above text and why Diameter Server does the replay protection and against which clock? >=20 > > As far as RFC4285bis, it says that the HA is the entity which > > verifies the replay protection if the authentication is successful. >=20 > Afair 3GPP2 needs it in AAA for their auth option=20 > processing... not that they would ever use this spec for that, though. >=20 > > On the other hand, If we would like to make the AAA to verify the > > replay protection, we may need to include the HA timestamp too. =20 > > NO? >=20 > Don't think so. At least the existing documented use in 3GPP2=20 > does not do that. [Ahmad] Please see the above comment. >=20 > > [Ahmad-11-END] > >=20 > >=20 > > [Ahmad-12-START] > > In the case of the collocation of LMA and HA and the=20 > possibility of=20 > > a > > mobile node to access the HA via Client MIPv6 and then=20 > roam into an > > area with PMIPv6 support, the MN may be then provided > > PMIPv6 support, > > this means that the MN will be assigned a whole HNP=20 > rather a HoA. =20 > > In > > that kind of deployment: SHOULD not we allow the possibility for > > bootstrapping a HNP and/or a HoA even in the case of=20 > Client MIPv6? > > [Ahmad-12-END] >=20 > See section 6.4. >=20 > ".. In case the Diameter server assigns only a Home Network Prefix > to the Mobile Node the lower 64 bits of the MIP-Mobile-Node-Address > AVP provided address MUST be set to zero." [Ahmad] Thanks for the pointer! Now I remember that I read it before:) >=20 > Anyway, the combined PMIP & CMIP case is a bit mess atm. If=20 > the proposed *-dime-pmip6-* draft gets adopted we need to=20 > sync these a bit more.=20 >=20 > > [Ahmad-13-START] > > Under section 5.3.1: I do not see where the HA request the MN-HA > > secret or MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA. They=20 > are supposed > > to be flags inside MIP6-feature-vector but is it defined=20 > somewhere > > else? >=20 > Hmmm.. The assumption has been that AAA always returns MN-HA=20 > secret when this application is used. [Ahmad] It would be nice to have an explicit indication just like RFC4004. I believe that is cleaner. Also, that assumption is not documented any where; at least I did not see it. >=20 > > Also, Why in the MAM I see only MIP-MN-to-HA-MSA is returned from the > > HAAA server? Are we assuming that MN-HA SA is symmetric? >=20 > Yes. This is something that always bothers me whether that=20 > should be asymmetric. Every time I ask opinions about it, no=20 > one seems to care about anything else that symmetric SA. [Ahmad] IMO, I do not believe that there is any justification for having asymmetric SA in the case of MIPv6 Auth protocol, for the very simple reason:=20 1. Replay protection is guaranteed by timestamp or SQN. I like timestamp though. SQN in RFC3775 is not used for replay protection, it is used for sequencing. We have beaten this to death during PMIPv6 discussion. And at the same time the MN-HA SA is between the MN and the HA ONLY. 2. Reflection attack is impossible, since HA can not receive BA and MN can not receive BU. At any rate, if we would like to use symmetric MN-HA MSA, then we need to change the AVP name from: MIP-MN-to-HA-MSA to MIP-MN-HA-MSA (new AVP) because the MIP-MN-to-HA-MSA [RFC4004] assumes asymmetric MSA. We also need to clearly document that choice. >=20 > > Also, why I see MIP-Session-Key AVP by itself in the MAM message. > > Should not this AVP be part of the MIP-MN-to-HA-MSA AVP? > > [Ahmad-13-END] >=20 > That is an editing error. It is part of MIP-MN-to-HA-MSA and=20 > should only be in there. >=20 > [chop] >=20 > > [Ahmad-15-START] > > Why are we using MIP-nonce and what is its value in this=20 > context? =20 > > Is > > it transmitted back to the MN? > >=20 > > Also, is not replay protection identified based on the > > presence of replay protection message option? or I am missing > > something. why do we need it here? >=20 > I need to poke Hannes about nonces. [Ahmad] At least we need to update the following text: 6.14. MIP-nonce AVP The AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the Mobile Node. This AVP is re-used from [12]. To be changed as follows or something similar: ---------------------------------------------- 6.14. MIP-nonce AVP The AVP (AVP Code 335) is of type OctetString and contains the nonce that to be sent to the Mobile Node. If this AVP is returned in the MAM message, the nonce MUST be sent to the Mobile Node to be used in deriving the MN-HA session secret key. The mechanism that the AAA and the Mobile Node use to derive the MN-HA session secret key is out of scope. >=20 > > In other words, either SQN is supported or not. If it=20 > is, then HA > > would accept BU with SQN only, if it is not, HA will not=20 > accept BU > > without the timestamp. No? > > [Ahmad-15-END] > >=20 > >=20 > > [Ahmad-16-START] > > Under section 7.1, it says: MIP6-TIMESTAMP-MISMATCH (Status Code=20 > > TBD) > >=20 > > This error code is used by the home agent to indicate to the HA=20 > > that > > the timestamp value provided as part of the MN-AAA option has an > > unacceptable clock-drift. s/indicate to the HA/indicate=20 > to the MN/ > >=20 > > Also, timestamp was not provided as part of the MN-AAA=20 > option. what > > you are trying to say here? >=20 > "This error code is used by the home agent to indicate to the MN > that the timestamp value provided in the BU has an unacceptable > clock-drift." [Ahmad] Ok. >=20 > > [Ahmad-16-END] > >=20 > > =20 > > [Ahmad-17-START] > > Finally: Is it possible to change the names of the=20 > Diameter MIPv6=20 > > Application > > messages?: > >=20 > > 1. Diameter-MIP6-Request (DMR) > >=20 > > 2. Diameter-MIP6-Answer (DMA) > >=20 > > Just a suggestion! =20 > > [Ahmad-17-END] > >=20 > > =20 > > Regards, > > Ahmad >=20 >=20 > Cheers, > Jouni >=20 > >=20 > >=20 > > ________________________________ > >=20 > > From: David Frascone [mailto:dave@frascone.com]=20 > > Sent: Wednesday, November 21, 2007 12:42 PM > > To: dime@ietf.org > > Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt > > =09 > > =09 > >=20 > > This message marks the issuance of a working group last call > > (WGLC) on DIME's Internet Draft entitled "Diameter Mobile=20 > > IPv6: Support > > for Home Agent to Diameter Server Interaction" > > (draft-ietf-dime-mip6-split-06.txt). You may view this document at > > =09 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt > > > t-06.txt>=20 > > =09 > > Please post comments and questions to the DIME mailing list (or > > to the authors) no later than 18 December 2007 (4 weeks=20 > because of the > > upcoming IETF meeting and the involvement of other SDOs). > > =09 > > Best regards, > > Hannes Tschofenig > > David Frascone > > (IETF DIME Working Group Chairs) > > =09 > > --=20 > > David Frascone > > =09 > > Oxymoron: Safe Sex.=20 > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Nov 30 05:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3Jb-0005Pr-Vf; Fri, 30 Nov 2007 05:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3Ja-0005Pf-MM for dime@ietf.org; Fri, 30 Nov 2007 05:41:46 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy3JY-0007OK-FX for dime@ietf.org; Fri, 30 Nov 2007 05:41:46 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:41:42 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Date: Fri, 30 Nov 2007 11:41:40 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED3024F9B3E@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt Thread-Index: AcgsbjQ/bhsShWyZTJOEzQRu7iZUqgFcYi7AADLZHTAAF1QxAAAI02rg References: <9cf5ced20711211041t101d5513y377684ea31366c73@mail.gmail.com> <59D7431DE2527D4CB0F1EFEDA5683ED3024F9B1C@SEHAN021MB.tcad.telia.se> From: To: , , , X-OriginalArrivalTime: 30 Nov 2007 10:41:42.0839 (UTC) FILETIME=[98B9BC70:01C8333D] X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Ahmad, Thanks again. Very constructive comments! Please see inline. [snip] > > > [Ahmad-11-START] > > > Under section 5.3.1, It states that Mobility message replay > > > protection option using timestamp is included in MIPv6 Request > > > Message. Why? > >=20 > > The AVP is optinal in the ABNF. If the BU contains replay=20 > protection=20 > > option with timestamp that is then conveyed to the AAA. >=20 > [Ahmad] > I am not against including the timestamp received in BU, I=20 > just want to know the purpose of it. According to what you=20 > just said, it is included based on 3GPP2 requirements and=20 > need. On the other hand and under section 6.16 it says: >=20 > " The support for replay protection is an optional feature in [3]. > When the Diameter server checks the timestamp provided by=20 > the MN via > the HA and recognizes a clock-drift (outside a locally=20 > defined replay > protection window) then it MUST initiate the re-synchronization > procedure by returning a MIP6-Answer-Message with=20 > Result-Code set to > MIP6-TIMESTAMP-MISMATCH and attaches the MIP-Timestamp AVP=20 > including > it's current time back to the HA. > " >=20 > Apparently, it says that the Diameter server is the one=20 > making the replay protection check. That is in conflict with=20 > RFC4285bis? In the current draft it is the AAA server that does the replay protectection... which is not inline with RFC4385bis, as you noted. > Now, what is the justification and the logic of the above=20 > text and why Diameter Server does the replay protection and=20 > against which clock? See my following comment. > > > As far as RFC4285bis, it says that the HA is the entity which > > > verifies the replay protection if the authentication is > successful. > >=20 > > Afair 3GPP2 needs it in AAA for their auth option processing... not=20 > > that they would ever use this spec for that, though. > >=20 > > > On the other hand, If we would like to make the AAA to=20 > verify the > > > replay protection, we may need to include the HA=20 > timestamp too. =20 > > > NO? > >=20 > > Don't think so. At least the existing documented use in=20 > 3GPP2 does not=20 > > do that. >=20 > [Ahmad] > Please see the above comment. I re-checked the pp2 stuff. Even if the AAA wants to know the timestamp for its IK computation, the replay protection is still preformed by the HA (after a successfull auth/authz). The same would work for wimax also. Thanks for pointing at the timestamp text & logic here! It is clearly messed up and must be fixed. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime