From dime-bounces@ietf.org Mon Apr 02 15:50: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 1HYSYH-00026j-R0; Mon, 02 Apr 2007 15:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSY7-0001vu-8p; Mon, 02 Apr 2007 15:50:43 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYSY0-00019J-Oi; Mon, 02 Apr 2007 15:50:43 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DE2902ACA6; Mon, 2 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYSXS-0000YZ-LL; Mon, 02 Apr 2007 15:50:02 -0400 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, 02 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-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 : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-03.txt Pages : 158 Date : 2007-4-2 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-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-rfc3588bis-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-rfc3588bis-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-4-2144701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-2144701.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 Apr 02 17:45: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 1HYULS-0001Yo-Tp; Mon, 02 Apr 2007 17:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYULS-0001Ye-0p for dime@ietf.org; Mon, 02 Apr 2007 17:45:46 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYULN-00070F-Ko for dime@ietf.org; Mon, 02 Apr 2007 17:45:46 -0400 Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l32LjQW3013818 for ; Mon, 2 Apr 2007 17:45:26 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <461179A8.5030804@tari.toshiba.com> Date: Mon, 02 Apr 2007 17:46:16 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Dime] rfc3588bis document update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, The latest version of rfc3588bis is now available. Changes includes some of the decisions made during IETF68. http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-03.txt As a short summary, the change history of this document are as follows: * 00 and rfc3588 are identical * 01 incorporates the changes proposed in http://tools.ietf.org/id/draft-fajardo-dime-diameter-errata-00.txt * 02 includes solutions for 32, 36, 44, 49, 41, 40, 31, 26 * 03 includes solutions for 28, 33, 37, 38, 51, 52, 50 (partially) * Open issues remain: 34, 35, 39, 50 (partially) For easier reading the relevant diffs are: * between 01 from 3588: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-01-from-rfc3588.diff.html * between 02 from 01: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-02-from-1.diff.html * between 03 from 02: http://www.opendiameter.org/public/draft-ietf-dime-rfc3588bis-03-from-2.diff.html The issue tracker can be found in: http://www.tschofenig.priv.at:8080/diameter-interop/index regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 04 18:58: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 1HZEQW-0001jv-Ls; Wed, 04 Apr 2007 18:58:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEQV-0001jq-BL for dime@ietf.org; Wed, 04 Apr 2007 18:58:03 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZEQU-0003RF-2d for dime@ietf.org; Wed, 04 Apr 2007 18:58:03 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFZ00LCVX4PHF@usaga01-in.huawei.com> for dime@ietf.org; Wed, 04 Apr 2007 15:58:01 -0700 (PDT) Received: from N737011 (pool-71-112-121-192.sttlwa.dsl-w.verizon.net [71.112.121.192]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFZ00J0UX4JIK@usaga01-in.huawei.com> for dime@ietf.org; Wed, 04 Apr 2007 15:58:01 -0700 (PDT) Date: Wed, 04 Apr 2007 15:58:01 -0700 From: Madjid Nakhjiri In-reply-to: <5e2406980703310509s3da8a81cl784bcbeed104d814@mail.gmail.com> To: 'Julien Bournelle' , dime@ietf.org Message-id: <001701c7770c$b271bde0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdzjYV1lTIv2I8PTlSCDOU5a2yvFwDfnHOg X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'Hannes Tschofenig' Subject: [Dime] RE: HA-to-AAAH draft/support of RFC 4285 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Julien, Sorry for the delay. Have been really busy this week. Let me ask you this: Aside from authentication, are the two 4285 and IKEv2 any different? i.e. do they both try to achieve authentication with the AAA server, while delivering exact same of parameters and functionality? If yes, then the option 2 may not be too bad. Still I prefer option 1, since its seems that some of AAA signaling goes in the middle of IKEv2 signaling and that may complicate the timings and other things unnecessarily. It seems to be easier to have two commands that carry an overlap of AVPs, than trying to carry different AVPs over different times and conditions over the same command. Hope this helps, Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Saturday, March 31, 2007 5:10 AM To: dime@ietf.org Cc: Gerardo Giaretta; Madjid Nakhjiri; Hannes Tschofenig Subject: HA-to-AAAH draft/support of RFC 4285 Hi all, as discussed during the DiME WG meeting, we have to support the RFC4285 in our Diameter Application for mip6. Let me reexplain briefly the situation: MN ----------- HA/AAAclient ----------------AAA server Our application defines the protocol between the AAAclient located in the HA and the AAA server. Between, the MN and the HA, we use: A/ either IKEv2 with EAP to setup IPsec SAs (to protect mip6 signalling). B/ or RFC 4285 aka Mobile IPv6 Authentication Option (could be compared to what is used in mip4). In A/, EAP is used for authentication, our Diameter Application will carry EAP packets and will deliver specific mip6 AVPs. At the end of the AAA process, IPsec SAs are setup and the MN can send its mip6 Binding Update. In B/, the MN has a pre-shared key with the AAA server. It sends its mip6 Binding Update signed using this pre-shared key to the HA. Our Diameter Application is then used to perform Authentication by the AAA server (owner of the pre-shared key). So, to sum up, we have two different MN-HA interaction (IKEv2-EAP and RFC4285) and one Diameter Application between HA and AAA. To solve this, we have two options in our Application: Option 1: we define 2 different commands: one command to deal with EAP and one command to deal with RFC 4285. Option 2: we define one command and one generic Authentication AVP. I'd like to hear your opinion on this. My personal feeling is that I would prefer Option 1. The reason is that I think it's cleaner for the server to know from the command-code the associated authentication method. More especially when we have EAP type authentication. Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Apr 08 10:07: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 1HaY3L-00084p-N0; Sun, 08 Apr 2007 10:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaY3K-00084j-8S for dime@ietf.org; Sun, 08 Apr 2007 10:07:34 -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 1HaY3I-00025X-UT for dime@ietf.org; Sun, 08 Apr 2007 10:07:34 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l38E6f13039059; Sun, 8 Apr 2007 10:06:41 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4617F5D6.3000206@tari.toshiba.com> Date: Sat, 07 Apr 2007 15:49:42 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Dime] FYI: Diameter application design guidelines doc update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, An updated version of the Diameter Application Design Guidelines document is now available at: http://www.ietf.org/internet-drafts/draft-fajardo-dime-app-design-guide-01.txt This is a major re-write of the previous version. Pls review. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 11 03:27: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 1HbXF9-0003NS-A1; Wed, 11 Apr 2007 03:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXF9-0003NN-12 for dime@ietf.org; Wed, 11 Apr 2007 03:27:51 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXF6-0006Pw-Nq for dime@ietf.org; Wed, 11 Apr 2007 03:27:51 -0400 Received: by an-out-0708.google.com with SMTP id d30so106987and for ; Wed, 11 Apr 2007 00:27:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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:content-transfer-encoding:content-disposition:references; b=I/q9Dz3Ip6lMQhRhHaVLlj8Qm6tF06eYY/TAqm2CGkqB5mRT+n/UhmRBSBsg0Frf7fHhH7+iTuoYjDmFH7DDZ8q4HFcyO6SvagCg8KJ+bEQ2iJPARMRTlzk1Z65ZxrE0/NNZGH3nwk4aj78Zh7+3sopPgqAOZaGDyU1d5/YmfpQ= 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:content-transfer-encoding:content-disposition:references; b=Vk7Nc1FAi8RF0XpM0N42s1SwIxLlPdSxTTY6BnTGfaMf3Z4RNbxRqq8fTxDVP5eUldRAMR/HsooOak/pI83ZMLTX6sUdbzzR2JCSfAJhHWavdYEgs/38X5EB6fH24LOkvaTQbsCPQ7Mg5zUcX39PjdnfuJEfBnjS4nV5qnmHbws= Received: by 10.100.195.10 with SMTP id s10mr149867anf.1176276468307; Wed, 11 Apr 2007 00:27:48 -0700 (PDT) Received: by 10.100.93.19 with HTTP; Wed, 11 Apr 2007 00:27:48 -0700 (PDT) Message-ID: <5e2406980704110027j3bac708cwf1e3d344ed040dc3@mail.gmail.com> Date: Wed, 11 Apr 2007 09:27:48 +0200 From: "Julien Bournelle" To: "Madjid Nakhjiri" In-Reply-To: <001701c7770c$b271bde0$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980703310509s3da8a81cl784bcbeed104d814@mail.gmail.com> <001701c7770c$b271bde0$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Hannes Tschofenig , dime@ietf.org Subject: [Dime] Re: HA-to-AAAH draft/support of RFC 4285 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi madjid, all, sorry for the delay too :) On 4/5/07, Madjid Nakhjiri wrote: > Hi Julien, > > Sorry for the delay. Have been really busy this week. > Let me ask you this: Aside from authentication, are the two 4285 and IKEv2 > any different? i.e. do they both try to achieve authentication with the AAA > server, while delivering exact same of parameters and functionality? In IKEv2, we setup IPsec SAs and then the MN sends the BU. Moreover, we have multiple EAP round trip to be handled by the AAA application. (kind of Diameter EAP) In 4285, we send the BU and then we do AAA operations. (kind of Diameter Mobile IPV4) > > If yes, then the option 2 may not be too bad. > Still I prefer option 1, since its seems that some of AAA signaling goes in > the middle of IKEv2 signaling and that may complicate the timings and other > things unnecessarily. > It seems to be easier to have two commands that carry an overlap of AVPs, > than trying to carry different AVPs over different times and conditions over > the same command. That's also my opinion. Let see if others have opinion on this. Regards, Julien > > Hope this helps, > > Madjid > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Saturday, March 31, 2007 5:10 AM > To: dime@ietf.org > Cc: Gerardo Giaretta; Madjid Nakhjiri; Hannes Tschofenig > Subject: HA-to-AAAH draft/support of RFC 4285 > > Hi all, > > as discussed during the DiME WG meeting, we have to support the > RFC4285 in our Diameter Application for mip6. > > Let me reexplain briefly the situation: > > MN ----------- HA/AAAclient ----------------AAA server > > Our application defines the protocol between the AAAclient located in > the HA and the AAA server. > > Between, the MN and the HA, we use: > > A/ either IKEv2 with EAP to setup IPsec SAs (to protect mip6 signalling). > > B/ or RFC 4285 aka Mobile IPv6 Authentication Option (could be compared > to what is used in mip4). > > In A/, EAP is used for authentication, our Diameter Application will carry > EAP packets and will deliver specific mip6 AVPs. At the end of the AAA > process, > IPsec SAs are setup and the MN can send its mip6 Binding Update. > > In B/, the MN has a pre-shared key with the AAA server. It sends its mip6 > Binding Update signed using this pre-shared key to the HA. Our > Diameter Application > is then used to perform Authentication by the AAA server (owner of the > pre-shared > key). > > So, to sum up, we have two different MN-HA interaction (IKEv2-EAP and > RFC4285) > and one Diameter Application between HA and AAA. To solve this, we > have two options > in our Application: > > Option 1: we define 2 different commands: one command to deal with EAP and > one command to deal with RFC 4285. > > Option 2: we define one command and one generic Authentication AVP. > > I'd like to hear your opinion on this. > > My personal feeling is that I would prefer Option 1. The reason is > that I think it's cleaner > for the server to know from the command-code the associated > authentication method. More especially when we have EAP type > authentication. > > Regards, > > Julien > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 13 01:52:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEiE-0004OU-Ej; Fri, 13 Apr 2007 01:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEiD-0004OK-Gz for dime@ietf.org; Fri, 13 Apr 2007 01:52:45 -0400 Received: from [203.199.83.133] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcEiA-00064s-2m for dime@ietf.org; Fri, 13 Apr 2007 01:52:45 -0400 Received: (qmail 31633 invoked by uid 510); 13 Apr 2007 05:52:35 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=b5y4fR/XJQ7FOfX0zjc6E94+Gez3MtzRYecBUDCb283VLf7Qa1o5XPreylDkZcDfQffu8va/qhchmrDqM6kEiCfmGGVQD4rx4HGVVTD/wNpecghLYjNqg/XzbfI52ptu0DvjWxQdEu8mSdBM1djHLgiXEAl/uGbD24cqeq/UKRA= ; Date: 13 Apr 2007 05:52:35 -0000 Message-ID: <20070413055235.31631.qmail@webmail43.rediffmail.com> Received: from unknown (202.131.155.13) by rediffmail.com via HTTP; 13 apr 2007 05:52:35 -0000 MIME-Version: 1.0 From: "Valesh Chandu" To: dime@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Dime] End-to-end & Hop by hop in case of redirect message X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valesh Chandu List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1806563838==" Errors-To: dime-bounces@ietf.org This is a multipart mime message --===============1806563838== Content-type: multipart/alternative; boundary="Next_1176443555---0-203.199.83.133-31629" This is a multipart mime message --Next_1176443555---0-203.199.83.133-31629 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,=0A=0Ai have a doubt regarding hop-by-hop and end-to-end id of a red= irecting request message.=0A=0AFrom the RFC3588 seciotn 6.1.7=0A=0A"When a = redirect agent receives a request whose routing entry is set to REDIRECT, i= t MUST reply with an answer message with the 'E' bit set, while maintaining= the Hop-by-Hop Identifier in the header, and include the Result-Code AVP t= o DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the ro= uting entry are added in separate Redirect-Host AVP. The receiver of the a= nswer message with the 'E' bit set, and the Result-Code AVP set to DIAMET= ER_REDIRECT_INDICATION uses the hop-by- hop field in the Diameter header t= o identify the request in the pending message queue (see Section 5.3) tha= t is to be redirected. If no transport connection exists with the new agen= t, one is created, and the request is sent directly to it."=0A=0AMy doubt i= s while sending out the request to the new agent, what are the values of ho= p-by-hop id and End-to-End id? i mean are they same as the original request= message? or they need to be chanegd with new values?=0A=0AThanks & Best Re= gards,=0AChandu=0A=0A=0A --Next_1176443555---0-203.199.83.133-31629 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi all,
=0A
=0Ai have a doubt regarding hop-by-hop and end-to-e= nd id of a redirecting request message.
=0A
=0AFrom the RFC3588 secio= tn 6.1.7
=0A
=0A"When a redirect agent receives a request whose = routing entry is set to REDIRECT, it MUST reply with an answer message with= the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header= , and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.  Ea= ch of the servers associated with the routing entry are added in separate R= edirect-Host AVP.  The receiver of the answer message with the 'E' bit= set, and the  Result-Code AVP set to DIAMETER_REDIRECT_INDICATION us= es the hop-by-  hop field in the Diameter header to identify the reque= st in the  pending message queue (see Section 5.3) that is to be redi= rected.  If no transport connection exists with the new agent, one is = created, and the request is sent directly to it."
=0A
=0AMy doub= t is while sending out the request to the new agent, what are the values of= hop-by-hop id and End-to-End id? i mean are they same as the original requ= est message? or they need to be chanegd with new values?
=0A
=0AThank= s & Best Regards,
=0AChandu
=0A
=0A
=0A=0A

=0A

= =0A
3D'Dre=
--Next_1176443555---0-203.199.83.133-31629-- --===============1806563838== 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 --===============1806563838==-- From dime-bounces@ietf.org Fri Apr 13 02:11: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 1HcF0P-0007Qz-1J; Fri, 13 Apr 2007 02:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcF0O-0007NO-1V for dime@ietf.org; Fri, 13 Apr 2007 02:11:32 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcF0M-00026d-LL for dime@ietf.org; Fri, 13 Apr 2007 02:11:32 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGF00FJ3AJ53R@usaga01-in.huawei.com> for dime@ietf.org; Thu, 12 Apr 2007 23:11:29 -0700 (PDT) Received: from huawei.com ([172.17.1.31]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGF000LBAJ47X@usaga01-in.huawei.com> for dime@ietf.org; Thu, 12 Apr 2007 23:11:29 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.70.145.164]) by szxmc03-in.huawei.com (mshttpd); Fri, 13 Apr 2007 14:11:26 +0800 Date: Fri, 13 Apr 2007 14:11:26 +0800 From: rajithr 70236 Subject: Re: [Dime] End-to-end & Hop by hop in case of redirect message To: Valesh Chandu Message-id: <3c8be393c9035a.3c9035a3c8be39@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 1.2 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline I think it is better to change the hop-by-hop id. Consider a cross over b/w the retransmitted original request & the redirect indication response. If you use the same hop-by-hop id for the redirected request, you may require additional checks during transaction match as the duplicate response to the retransmitted original request & the original response to the redirected request will have the same hop-by-hop id. For end-to-end id, I think it is better to retain it. This may be useful in cases where Diameter agents itself process the redirect indication & send out the redirected request. Hope this helps. Rajith --Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ) Content-type: multipart/alternative; boundary="Boundary_(ID_ethc5grYGM8Ps/msxH24OQ)" --Boundary_(ID_ethc5grYGM8Ps/msxH24OQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi all, i have a doubt regarding hop-by-hop and end-to-end id of a redirecting request message. >From the RFC3588 seciotn 6.1.7 "When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in separate Redirect-Host AVP. The receiver of the answer message with the 'E' bit set, and the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- hop field in the Diameter header to identify the request in the pending message queue (see Section 5.3) that is to be redirected. If no transport connection exists with the new agent, one is created, and the request is sent directly to it." My doubt is while sending out the request to the new agent, what are the values of hop-by-hop id and End-to-End id? i mean are they same as the original request message? or they need to be chanegd with new values? Thanks & Best Regards, Chandu --Boundary_(ID_ethc5grYGM8Ps/msxH24OQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline

Hi all,

i have a doubt regarding hop-by-hop and end-to-end id of a redirecting request message.

>From the RFC3588 seciotn 6.1.7

"When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.  Each of the servers associated with the routing entry are added in separate Redirect-Host AVP.  The receiver of the answer message with the 'E' bit set, and the  Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-  hop field in the Diameter header to identify the request in the  pending message queue (see Section 5.3) that is to be redirected.  If no transport connection exists with the new agent, one is created, and the request is sent directly to it."

My doubt is while sending out the request to the new agent, what are the values of hop-by-hop id and End-to-End id? i mean are they same as the original request message? or they need to be chanegd with new values?

Thanks & Best Regards,
Chandu




Dreams
--Boundary_(ID_ethc5grYGM8Ps/msxH24OQ)-- --Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ) 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 --Boundary_(ID_DPN2q0AVuF1K4+2aP3pQXQ)-- From dime-bounces@ietf.org Fri Apr 13 02:42: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 1HcFUK-0001CW-VT; Fri, 13 Apr 2007 02:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcFUJ-0001CJ-NV for dime@ietf.org; Fri, 13 Apr 2007 02:42:27 -0400 Received: from [203.199.83.247] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcFUH-0001wI-Gb for dime@ietf.org; Fri, 13 Apr 2007 02:42:27 -0400 Received: (qmail 16282 invoked by uid 510); 13 Apr 2007 06:42:19 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=k9070RMPjLXAl7nUlZ21VYX9dlVm/f0/k3D2zaRtlSflPXwUF1sX9TLoYcRpsfNH1gdosAK3uvCkYWeE+ffdGHpgpY3SJYGQ+/JKKFcY1//z7wDluEX0E9rlvmlhfoJOqB9OyzMne0yfo6L4EOnXghQ7eOTGByu2UQIQVVQah8M= ; Date: 13 Apr 2007 06:42:19 -0000 Message-ID: <20070413064219.16280.qmail@webmail34.rediffmail.com> Received: from unknown (202.131.155.13) by rediffmail.com via HTTP; 13 apr 2007 06:42:19 -0000 MIME-Version: 1.0 From: "Valesh Chandu" To: "rajithr 70236" Subject: Re: Re: [Dime] End-to-end & Hop by hop in case of redirect message X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valesh Chandu List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0203818728==" Errors-To: dime-bounces@ietf.org This is a multipart mime message --===============0203818728== Content-type: multipart/alternative; boundary="Next_1176446539---0-203.199.83.247-16277" This is a multipart mime message --Next_1176446539---0-203.199.83.247-16277 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =A0=0AHi Rajith,=0A=0AThanks for your reply, i have one more doubt, what w= ould be the destination-host avp in the retransmitted request message that = has to be send to the new agent? is it the FQDN of new agent (consider also= the case where the new aget is another redirect agent)? =0A=0ABest regards= ,=0AChandu=0A=0AOn Fri, 13 Apr 2007 rajithr 70236 wrote :=0A>I think it is = better to change the hop-by-hop id. Consider a cross over b/w the retransmi= tted original request & the redirect indication response. If you use the sa= me hop-by-hop id for the redirected request, you may require additional che= cks during transaction match as the duplicate response to the retransmitted= original request & the original response to the redirected request will ha= ve the same hop-by-hop id.=0A>=0A>For end-to-end id, I think it is better t= o retain it. This may be useful in cases where Diameter agents itself proce= ss the redirect indication & send out the redirected request.=0A>=0A>Hope t= his helps.=0A>=0A>Rajith=0A>Hi all,=0A>=0A>i have a doubt regarding hop-by-= hop and end-to-end id of a redirecting request message.=0A>=0A> From the RF= C3588 seciotn 6.1.7=0A>=0A>"When a redirect agent receives a request whose = routing entry is set to REDIRECT, it MUST reply with an answer message with= the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header= , and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of= the servers associated with the routing entry are added in separate Redire= ct-Host AVP. The receiver of the answer message with the 'E' bit set, and = the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- = hop field in the Diameter header to identify the request in the pending = message queue (see Section 5.3) that is to be redirected. If no transport = connection exists with the new agent, one is created, and the request is se= nt directly to it."=0A>=0A>My doubt is while sending out the request to the= new agent, what are the values of hop-by-hop id and End-to-End id? i mean = are they same as the original request message? or they need to be chanegd w= ith new values?=0A>=0A>Thanks & Best Regards,=0A>Chandu=0A>=0A>=0A>________= _______________________________________=0A>DiME mailing list=0A>DiME@ietf.o= rg=0A>https://www1.ietf.org/mailman/listinfo/dime=0A --Next_1176446539---0-203.199.83.247-16277 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0AHi Rajith,
=0A
=0AThanks for your reply, i have o= ne more doubt, what would be the destination-host avp in the retransmitted = request message that has to be send to the new agent? is it the FQDN of new= agent (consider also the case where the new aget is another redirect agent= )?
=0A
=0ABest regards,
=0AChandu
=0A
=0AOn Fri, 13 Apr 200= 7 rajithr 70236 wrote :
=0A>I think it is better to change the hop-by= -hop id. Consider a cross over b/w the retransmitted original request &= the redirect indication response. If you use the same hop-by-hop id for th= e redirected request, you may require additional checks during transaction = match as the duplicate response to the retransmitted original request &= the original response to the redirected request will have the same hop-by-= hop id.
=0A>
=0A>For end-to-end id, I think it is better to ret= ain it. This may be useful in cases where Diameter agents itself process th= e redirect indication & send out the redirected request.
=0A>
= =0A>Hope this helps.
=0A>
=0A>Rajith
=0A>Hi all,
= =0A>
=0A>i have a doubt regarding hop-by-hop and end-to-end id of = a redirecting request message.
=0A>
=0A> From the RFC3588 secio= tn 6.1.7
=0A>
=0A>"When a redirect agent receives a reques= t whose routing entry is set to REDIRECT, it MUST reply with an answer mess= age with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in th= e header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.&= nbsp; Each of the servers associated with the routing entry are added in se= parate Redirect-Host AVP.  The receiver of the answer message with the= 'E' bit set, and the  Result-Code AVP set to DIAMETER_REDIRECT_INDIC= ATION uses the hop-by-  hop field in the Diameter header to identify t= he request in the  pending message queue (see Section 5.3) that is to= be redirected.  If no transport connection exists with the new agent,= one is created, and the request is sent directly to it."
=0A>=0A>My doubt is while sending out the request to the new agent, what a= re the values of hop-by-hop id and End-to-End id? i mean are they same as t= he original request message? or they need to be chanegd with new values?=0A>
=0A>Thanks & Best Regards,
=0A>Chandu
=0A>=0A>
=0A>_______________________________________________
=0A&= gt;DiME mailing list
=0A>DiME@ietf.org
=0A>https://www1.ietf.or= g/mailman/listinfo/dime
=0A=0A

=0A

=0A
3D'CJ'
--Next_1176446539---0-203.199.83.247-16277-- --===============0203818728== 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 --===============0203818728==-- From dime-bounces@ietf.org Fri Apr 13 07:55: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 1HcKNA-0003HB-6U; Fri, 13 Apr 2007 07:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKN9-0003H6-C0 for dime@ietf.org; Fri, 13 Apr 2007 07:55:23 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKN7-0004Mg-2v for dime@ietf.org; Fri, 13 Apr 2007 07:55:23 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3DBtKX4024180 for ; Fri, 13 Apr 2007 07:55:20 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Apr 2007 07:55:20 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Dime] End-to-end & Hop by hop in case of redirect message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 07:55:20 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DF98@sonusmail04.sonusnet.com> In-Reply-To: <3c8be393c9035a.3c9035a3c8be39@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] End-to-end & Hop by hop in case of redirect message Thread-Index: Acd9kphSbVDeA0IJSf+oRUSNIldC5AALxcbg References: <3c8be393c9035a.3c9035a3c8be39@huawei.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 13 Apr 2007 11:55:20.0911 (UTC) FILETIME=[9CADC5F0:01C77DC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org hop-by-hop Id is better kept per Diameter connection, it is used mainly to delete requests from retransmission buffer. It needs to be unique on a given connection so that it can be used for that purpose. So, in the scenario described, hop-by-hop Id for the new connection (the connection for the host which is indicated in the redirect response) needs to be used, which BTW could be the same like the one in the original request just by coincidence. End-to-end Id is used by the receiver of the request for duplicate detection. Considering that the original request did not make it to the final destination, end-to-end Id may be reused but I don't see any advantage of it. I would just use a new one. After redirection, it is a new request from base protocol point of view. Thanks, Tolga -----Original Message----- From: rajithr 70236 [mailto:rajithr@huawei.com]=20 Sent: Friday, April 13, 2007 2:11 AM To: Valesh Chandu Cc: dime@ietf.org Subject: Re: [Dime] End-to-end & Hop by hop in case of redirect message I think it is better to change the hop-by-hop id. Consider a cross over b/w the retransmitted original request & the redirect indication response. If you use the same hop-by-hop id for the redirected request, you may require additional checks during transaction match as the duplicate response to the retransmitted original request & the original response to the redirected request will have the same hop-by-hop id. For end-to-end id, I think it is better to retain it. This may be useful in cases where Diameter agents itself process the redirect indication & send out the redirected request. Hope this helps. Rajith _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 13 14:51: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 1HcQs2-0004Hl-N9; Fri, 13 Apr 2007 14:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQs1-0004Hf-FX for dime@ietf.org; Fri, 13 Apr 2007 14:51:41 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQs0-000876-5K for dime@ietf.org; Fri, 13 Apr 2007 14:51:41 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGG00I0M9Q382@usaga01-in.huawei.com> for dime@ietf.org; Fri, 13 Apr 2007 11:51:39 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGG00HKX9PXYO@usaga01-in.huawei.com> for dime@ietf.org; Fri, 13 Apr 2007 11:51:39 -0700 (PDT) Date: Fri, 13 Apr 2007 11:51:38 -0700 From: Madjid Nakhjiri In-reply-to: <5e2406980704110027j3bac708cwf1e3d344ed040dc3@mail.gmail.com> To: 'Julien Bournelle' Message-id: <006c01c77dfc$c5d500d0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd8CvCDoV21Qt4fSJ+JuvGPc+nmLwB8axgw X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 'Hannes Tschofenig' , dime@ietf.org Subject: [Dime] RE: HA-to-AAAH draft/support of RFC 4285 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org So it seems that the IKEv2 and 4285 hit the AAA server at two different times, before versus after BU and it would make sense to separate the commands. Madjid -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Wednesday, April 11, 2007 12:28 AM To: Madjid Nakhjiri Cc: dime@ietf.org; Gerardo Giaretta; Hannes Tschofenig Subject: Re: HA-to-AAAH draft/support of RFC 4285 Hi madjid, all, sorry for the delay too :) On 4/5/07, Madjid Nakhjiri wrote: > Hi Julien, > > Sorry for the delay. Have been really busy this week. > Let me ask you this: Aside from authentication, are the two 4285 and IKEv2 > any different? i.e. do they both try to achieve authentication with the AAA > server, while delivering exact same of parameters and functionality? In IKEv2, we setup IPsec SAs and then the MN sends the BU. Moreover, we have multiple EAP round trip to be handled by the AAA application. (kind of Diameter EAP) In 4285, we send the BU and then we do AAA operations. (kind of Diameter Mobile IPV4) > > If yes, then the option 2 may not be too bad. > Still I prefer option 1, since its seems that some of AAA signaling goes in > the middle of IKEv2 signaling and that may complicate the timings and other > things unnecessarily. > It seems to be easier to have two commands that carry an overlap of AVPs, > than trying to carry different AVPs over different times and conditions over > the same command. That's also my opinion. Let see if others have opinion on this. Regards, Julien > > Hope this helps, > > Madjid > > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Saturday, March 31, 2007 5:10 AM > To: dime@ietf.org > Cc: Gerardo Giaretta; Madjid Nakhjiri; Hannes Tschofenig > Subject: HA-to-AAAH draft/support of RFC 4285 > > Hi all, > > as discussed during the DiME WG meeting, we have to support the > RFC4285 in our Diameter Application for mip6. > > Let me reexplain briefly the situation: > > MN ----------- HA/AAAclient ----------------AAA server > > Our application defines the protocol between the AAAclient located in > the HA and the AAA server. > > Between, the MN and the HA, we use: > > A/ either IKEv2 with EAP to setup IPsec SAs (to protect mip6 signalling). > > B/ or RFC 4285 aka Mobile IPv6 Authentication Option (could be compared > to what is used in mip4). > > In A/, EAP is used for authentication, our Diameter Application will carry > EAP packets and will deliver specific mip6 AVPs. At the end of the AAA > process, > IPsec SAs are setup and the MN can send its mip6 Binding Update. > > In B/, the MN has a pre-shared key with the AAA server. It sends its mip6 > Binding Update signed using this pre-shared key to the HA. Our > Diameter Application > is then used to perform Authentication by the AAA server (owner of the > pre-shared > key). > > So, to sum up, we have two different MN-HA interaction (IKEv2-EAP and > RFC4285) > and one Diameter Application between HA and AAA. To solve this, we > have two options > in our Application: > > Option 1: we define 2 different commands: one command to deal with EAP and > one command to deal with RFC 4285. > > Option 2: we define one command and one generic Authentication AVP. > > I'd like to hear your opinion on this. > > My personal feeling is that I would prefer Option 1. The reason is > that I think it's cleaner > for the server to know from the command-code the associated > authentication method. More especially when we have EAP type > authentication. > > Regards, > > Julien > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Apr 15 09:43: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 1Hd50n-0001w5-Hr; Sun, 15 Apr 2007 09:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd50m-0001w0-Ek for dime@ietf.org; Sun, 15 Apr 2007 09:43:24 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd50l-0006xs-8h for dime@ietf.org; Sun, 15 Apr 2007 09:43:24 -0400 Received: by an-out-0708.google.com with SMTP id d30so1498742and for ; Sun, 15 Apr 2007 06:43:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=MmkNue5sHatPHTJOXHe8RUi7EJkVV1T8+6E1qxLdIUTptgbCGb5MRr8Pfu13H4UkdU6o7uJtlqikzX0yQELormZu4FvT+Xg/HaCQvWJoMIUoejN8hRaDJCYkVHuaV8zcKjPfscb6zpeHsCAY8CIhkm0Jp38LOFO9C3vbd97VRuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=swBeRkU8e2ALeC0t9mroZ/p9+bttCNoxL0XFiPFxvlheh9tCjTeDEbaupDmyhswt/xN0fgvayL9Fk+9VdlAVzIYm2CWXD2kZeHG/bF60OhFdg3X1fTnR6b6O8mB7Tqh42zvST3APv5RLP6rfXHq6J9LgCCEUnxtu/NqY24/Gfws= Received: by 10.100.128.8 with SMTP id a8mr3783335and.1176644602743; Sun, 15 Apr 2007 06:43:22 -0700 (PDT) Received: by 10.100.154.8 with HTTP; Sun, 15 Apr 2007 06:43:22 -0700 (PDT) Message-ID: <76dadd3c0704150643h51888209qa2e6cb8602bb51ec@mail.gmail.com> Date: Sun, 15 Apr 2007 19:13:22 +0530 From: "akshi jain" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Dime] Parsing SDP message to diameter 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="===============1587284252==" Errors-To: dime-bounces@ietf.org --===============1587284252== Content-Type: multipart/alternative; boundary="----=_Part_28302_29149648.1176644602696" ------=_Part_28302_29149648.1176644602696 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Can anyone give a method to Parse SDP message to diameter AVPs in an IMS application? Regards Akshi Jain ------=_Part_28302_29149648.1176644602696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Can anyone give a method to Parse SDP message to diameter AVPs in an IMS application?
 
Regards
Akshi Jain
------=_Part_28302_29149648.1176644602696-- --===============1587284252== 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 --===============1587284252==-- From dime-bounces@ietf.org Sun Apr 15 13:28: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 1Hd8WX-0006yv-T3; Sun, 15 Apr 2007 13:28:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd8WW-0006yq-4Q for dime@ietf.org; Sun, 15 Apr 2007 13:28:24 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd8WU-0002KS-KN for dime@ietf.org; Sun, 15 Apr 2007 13:28:23 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3FHSMap030301 for ; Sun, 15 Apr 2007 13:28:22 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:28:21 -0400 Date: Sun, 15 Apr 2007 13:28:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: Limited flexibility with NAPTR queries X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: Acd/g3a9t5rOc1yKRayobip0M9uidw== From: "Asveren, Tolga" To: X-OriginalArrivalTime: 15 Apr 2007 17:28:21.0917 (UTC) FILETIME=[771CD4D0:01C77F83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Dime] Limited flexibility with NAPTR queries X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Something, which is bothering me recently is the limited flexibility = when using NAPTR service fields to locate Diameter servers. The current = values placed in the registry allow to find *a* Diameter server in a = given domain. It doesn't help much if one is looking for a server for a = specific application in a given domain. This could work in environments = where each domain (or better said each domain which envisions use of DNS = to locate its servers) has a relay/redirect as the main contact point. My initial thoughts are: a) We can have registry entries for each Diameter application (could be = hard to manage ?) b) We can explain in the bis document that NAPTR query should resolve to = a relay/redirect for the domain, if the domain supports more than one = Diameter application. Or am I missing something? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Apr 15 13:47: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 1Hd8ot-0006Jw-H9; Sun, 15 Apr 2007 13:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd8or-0006Jq-Ui for dime@ietf.org; Sun, 15 Apr 2007 13:47:21 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd8oq-0002el-N9 for dime@ietf.org; Sun, 15 Apr 2007 13:47:21 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3FHlKHE015673 for ; Sun, 15 Apr 2007 13:47:20 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:47:20 -0400 Date: Sun, 15 Apr 2007 13:47:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DD87@sonusmail04.sonusnet.com> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: Issue39: What to verify in TLS certificates X-MimeOLE: Produced By Microsoft Exchange V6.5 Thread-Index: Acd/hh1fUFR29JZeQviGw5P9W3hm2A== From: "Asveren, Tolga" To: X-OriginalArrivalTime: 15 Apr 2007 17:47:20.0009 (UTC) FILETIME=[1D77E390:01C77F86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Dime] Issue39: What to verify in TLS certificates X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org If we use subjectAltName for a postcheck for TLS certificates in the = following way: a) dNSName contains the name of the domain, the host claims to be in = (OriginRealm in CER/CEA) b) otherName contains the Id of the application, which the host claims = to host for the realm specified in a) Do we need to verify that the TLS certificate is valid for the domain of = the server which was returned by the DNS query as well? It doesn't seem = necessary to me, afterall what we care is that the host is valid to = provide a given service for a given domain. As an example if we are interested in getting serviceA for domainA and = if at the end of DNS queries we end up with = host5.thirdpartydiamnetwork.com, are we really interested that we have a = valid certificate for the domain thirdpartydiamnetwork.com? Currently, in RFC3588 we have the following: If the server is using a site certificate, the domain name in the query = and the domain name in the replacement field MUST both be valid based on = the site certificate handed out by the server in the TLS or IKE = exchange.=20 Does that text refer to the type of usage I think as unnecessary? Thanks, Tolga=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 16 11:12: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 1HdSsB-0007fV-Q2; Mon, 16 Apr 2007 11:12:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSs9-0007fP-Qr for dime@ietf.org; Mon, 16 Apr 2007 11:12:05 -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 1HdSs9-0007V9-I6 for dime@ietf.org; Mon, 16 Apr 2007 11:12:05 -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 l3GFBixL090454; Mon, 16 Apr 2007 11:11:44 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46239264.8020905@tari.toshiba.com> Date: Mon, 16 Apr 2007 11:12:36 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Issue39: What to verify in TLS certificates References: <033458F56EC2A64E8D2D7B759FA3E7E702DD87@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702DD87@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, Comments inline: > If we use subjectAltName for a postcheck for TLS certificates in the following way: > a) dNSName contains the name of the domain, the host claims to be in (OriginRealm in CER/CEA) > b) otherName contains the Id of the application, which the host claims to host for the realm specified in a) > > Do we need to verify that the TLS certificate is valid for the domain of the server which was returned by the DNS query as well? It doesn't seem necessary to me, afterall what we care is that the host is valid to provide a given service for a given domain. > My personal preference is not to even deal with this issue in the base protocol simply because certificate ownership/usage validation is may not be limited to diameter only. The "issue" may also be relevant to other protocols so its probably better to "specify" the solution (if there isn't already one) in more relevant security related documents which the base protocol can simply refer to. > As an example if we are interested in getting serviceA for domainA and if at the end of DNS queries we end up with host5.thirdpartydiamnetwork.com, are we really interested that we have a valid certificate for the domain thirdpartydiamnetwork.com? > > Currently, in RFC3588 we have the following: > > If the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS or IKE exchange. > The example you mentioned above re-enforces my idea so I agree that it maybe better to remove these text from the base spec. It also helps simplify the base protocol similar to the removal of the IPsec usage. regards, victor > Does that text refer to the type of usage I think as unnecessary? > > Thanks, > Tolga > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 16 11:32: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 1HdTC6-0007Nm-8J; Mon, 16 Apr 2007 11:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTC6-0007Nh-2Y for dime@ietf.org; Mon, 16 Apr 2007 11:32:42 -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 1HdTC4-0000a3-Nq for dime@ietf.org; Mon, 16 Apr 2007 11:32:42 -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 l3GFWFhL090541; Mon, 16 Apr 2007 11:32:16 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46239734.8040301@tari.toshiba.com> Date: Mon, 16 Apr 2007 11:33:08 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Limited flexibility with NAPTR queries References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, > Something, which is bothering me recently is the limited flexibility when using NAPTR service fields to locate Diameter servers. The current values placed in the registry allow to find *a* Diameter server in a given domain. It doesn't help much if one is looking for a server for a specific application in a given domain. This could work in environments where each domain (or better said each domain which envisions use of DNS to locate its servers) has a relay/redirect as the main contact point. > > > My initial thoughts are: > a) We can have registry entries for each Diameter application (could be hard to manage ?) > b) We can explain in the bis document that NAPTR query should resolve to a relay/redirect for the domain, if the domain supports more than one Diameter application. > I would prefer option (b) for simplicity though I'm concerned about explain deployment considerations such as these in the base spec. It may open up the door for adding many more possible deployment scenarios within the base spec. It maybe possible to add this in the guidelines doc but I'm sure. regards, victor regards, victor > Or am I missing something? > > Thanks, > Tolga > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 16 11:48:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTRU-0004oX-FA; Mon, 16 Apr 2007 11:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTRT-0004oR-F9 for dime@ietf.org; Mon, 16 Apr 2007 11:48:35 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTRS-0008GT-Vg for dime@ietf.org; Mon, 16 Apr 2007 11:48:35 -0400 Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3GFmYlA025896 for ; Mon, 16 Apr 2007 11:48:34 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 11:48:33 -0400 Content-class: urn:content-classes:message Subject: RE: [Dime] Issue39: What to verify in TLS certificates Date: Mon, 16 Apr 2007 11:48:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFA5@sonusmail04.sonusnet.com> In-Reply-To: <46239264.8020905@tari.toshiba.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Issue39: What to verify in TLS certificates Thread-Index: AceAOZyVBWIOaEpUSaSPI8+3JKjlHwAA/qjw References: <033458F56EC2A64E8D2D7B759FA3E7E702DD87@sonusmail04.sonusnet.com> <46239264.8020905@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 16 Apr 2007 15:48:33.0931 (UTC) FILETIME=[B0686DB0:01C7803E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, I think we need to agree on some form of post check for TLS certificates for interoperability purposes. AFAICS, there is nothing we need to define new from technology perspective; we just need to decide the fields to use in the certificate and the meaning of the corresponding values. Overall, this probably will be a few paragraphs. I don't know what is the best place to define this, just thinking a separate document only for this issue could be an overkill (I don't know whether there are plans for a security type of document). Thanks, Tolga -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Monday, April 16, 2007 11:13 AM To: Asveren, Tolga Cc: dime@ietf.org Subject: Re: [Dime] Issue39: What to verify in TLS certificates Hi Tolga, Comments inline: > If we use subjectAltName for a postcheck for TLS certificates in the following way: > a) dNSName contains the name of the domain, the host claims to be in (OriginRealm in CER/CEA) > b) otherName contains the Id of the application, which the host claims to host for the realm specified in a) > > Do we need to verify that the TLS certificate is valid for the domain of the server which was returned by the DNS query as well? It doesn't seem necessary to me, afterall what we care is that the host is valid to provide a given service for a given domain. > =20 My personal preference is not to even deal with this issue in the base=20 protocol simply because certificate ownership/usage validation is may=20 not be limited to diameter only. The "issue" may also be relevant to=20 other protocols so its probably better to "specify" the solution (if=20 there isn't already one) in more relevant security related documents=20 which the base protocol can simply refer to. > As an example if we are interested in getting serviceA for domainA and if at the end of DNS queries we end up with host5.thirdpartydiamnetwork.com, are we really interested that we have a valid certificate for the domain thirdpartydiamnetwork.com? > > Currently, in RFC3588 we have the following: > > If the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS or IKE exchange.=20 > =20 The example you mentioned above re-enforces my idea so I agree that it=20 maybe better to remove these text from the base spec. It also helps=20 simplify the base protocol similar to the removal of the IPsec usage. regards, victor > Does that text refer to the type of usage I think as unnecessary? > > Thanks, > Tolga=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 Apr 16 11:56: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 1HdTZ8-0007hj-9n; Mon, 16 Apr 2007 11:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTZ6-0007hZ-KC for dime@ietf.org; Mon, 16 Apr 2007 11:56:28 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTZ5-0003LR-Bl for dime@ietf.org; Mon, 16 Apr 2007 11:56:28 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3GFuRCc000433 for ; Mon, 16 Apr 2007 11:56:27 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Apr 2007 11:56:26 -0400 Content-class: urn:content-classes:message Subject: RE: [Dime] Limited flexibility with NAPTR queries Date: Mon, 16 Apr 2007 11:56:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFA7@sonusmail04.sonusnet.com> In-Reply-To: <46239734.8040301@tari.toshiba.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Limited flexibility with NAPTR queries Thread-Index: AceAPHmCY6QjQ+QBRo2A3otwnn7tFgAAxjHQ References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> <46239734.8040301@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 16 Apr 2007 15:56:26.0736 (UTC) FILETIME=[CA38BF00:01C7803F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, If we settle for b), I also do not think that it is mandatory to provide an extra explanation in the bis document.=20 Thanks, Tolga -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: Monday, April 16, 2007 11:33 AM To: Asveren, Tolga Cc: dime@ietf.org Subject: Re: [Dime] Limited flexibility with NAPTR queries Hi Tolga, > Something, which is bothering me recently is the limited flexibility when using NAPTR service fields to locate Diameter servers. The current values placed in the registry allow to find *a* Diameter server in a given domain. It doesn't help much if one is looking for a server for a specific application in a given domain. This could work in environments where each domain (or better said each domain which envisions use of DNS to locate its servers) has a relay/redirect as the main contact point. > > > My initial thoughts are: > a) We can have registry entries for each Diameter application (could be hard to manage ?) > b) We can explain in the bis document that NAPTR query should resolve to a relay/redirect for the domain, if the domain supports more than one Diameter application. > =20 I would prefer option (b) for simplicity though I'm concerned about=20 explain deployment considerations such as these in the base spec. It may open up the door for adding many more possible deployment scenarios=20 within the base spec. It maybe possible to add this in the guidelines=20 doc but I'm sure. regards, victor regards, victor > Or am I missing something? > > Thanks, > Tolga > > _______________________________________________ > 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 Apr 18 05:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6Kc-0008BI-OQ; Wed, 18 Apr 2007 05:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6Kb-0008Am-3C for dime@ietf.org; Wed, 18 Apr 2007 05:20:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He6KZ-0008AC-NI for dime@ietf.org; Wed, 18 Apr 2007 05:20:05 -0400 Received: (qmail invoked by alias); 18 Apr 2007 09:20:02 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp050) with SMTP; 18 Apr 2007 11:20:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18NS0pUCfMNy/5B3RdpYnbaEBellhZwxOoKhekliH SaDr1A76GoehDq Message-ID: <4625E2C2.1020506@gmx.net> Date: Wed, 18 Apr 2007 11:20:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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: 08e48e05374109708c00c6208b534009 Subject: [Dime] Meeting Minutes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/07mar/minutes/dime.txt Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 09:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9yI-0001ju-U2; Wed, 18 Apr 2007 09:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9yH-0001jk-Ru for dime@ietf.org; Wed, 18 Apr 2007 09:13:17 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9yG-0007QU-FQ for dime@ietf.org; Wed, 18 Apr 2007 09:13:17 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3IDDGvF018742 for ; Wed, 18 Apr 2007 09:13:16 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:13:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Dime] Limited flexibility with NAPTR queries MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 09:13:15 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFC6@sonusmail04.sonusnet.com> In-Reply-To: <46239734.8040301@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Limited flexibility with NAPTR queries Thread-Index: AceAPHmCY6QjQ+QBRo2A3otwnn7tFgBfgMcQ References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> <46239734.8040301@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 18 Apr 2007 13:13:16.0018 (UTC) FILETIME=[53533D20:01C781BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org After having a quick look to the meeting minutes I saw that this issue was touched as well. So, does anybody have some proposal or are we going to rely on SLP? Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, April 16, 2007 11:33 AM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] Limited flexibility with NAPTR queries >=20 > Hi Tolga, >=20 > > Something, which is bothering me recently is the limited flexibility > when using NAPTR service fields to locate Diameter servers. The current > values placed in the registry allow to find *a* Diameter server in a given > domain. It doesn't help much if one is looking for a server for a specific > application in a given domain. This could work in environments where each > domain (or better said each domain which envisions use of DNS to locate > its servers) has a relay/redirect as the main contact point. > > > > > > My initial thoughts are: > > a) We can have registry entries for each Diameter application (could be > hard to manage ?) > > b) We can explain in the bis document that NAPTR query should resolve to > a relay/redirect for the domain, if the domain supports more than one > Diameter application. > > >=20 > I would prefer option (b) for simplicity though I'm concerned about > explain deployment considerations such as these in the base spec. It may > open up the door for adding many more possible deployment scenarios > within the base spec. It maybe possible to add this in the guidelines > doc but I'm sure. >=20 > regards, > victor >=20 > regards, > victor >=20 >=20 > > Or am I missing something? > > > > Thanks, > > Tolga > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 09:17: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 1HeA1w-0002zq-Aa; Wed, 18 Apr 2007 09:17:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA1v-0002zl-6a for dime@ietf.org; Wed, 18 Apr 2007 09:17:03 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA1u-0000HA-Qm for dime@ietf.org; Wed, 18 Apr 2007 09:17:03 -0400 Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3IDH2sD022839 for ; Wed, 18 Apr 2007 09:17:02 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:17:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Dime] Issue39: What to verify in TLS certificates MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 09:17:02 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFC7@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702DFA5@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Issue39: What to verify in TLS certificates Thread-Index: AceAOZyVBWIOaEpUSaSPI8+3JKjlHwAA/qjwAF9w+nA= References: <033458F56EC2A64E8D2D7B759FA3E7E702DD87@sonusmail04.sonusnet.com><46239264.8020905@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E702DFA5@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 18 Apr 2007 13:17:02.0178 (UTC) FILETIME=[DA208420:01C781BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 saw that this issue has been discussed as well in the last IETF meeting. I agree that a "write once use everywhere" approach makes sense. One warning though: For Diameter we probably need to verify more than just domain names (unlike SIP for example). We probably want to verify domain name+appId pairs. So, I don't know how this could be addressed in a generic document. Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Monday, April 16, 2007 11:49 AM > To: dime@ietf.org > Subject: RE: [Dime] Issue39: What to verify in TLS certificates >=20 >=20 > Hi Victor, >=20 > I think we need to agree on some form of post check for TLS certificates > for interoperability purposes. AFAICS, there is nothing we need to > define new from technology perspective; we just need to decide the > fields to use in the certificate and the meaning of the corresponding > values. Overall, this probably will be a few paragraphs. >=20 > I don't know what is the best place to define this, just thinking a > separate document only for this issue could be an overkill (I don't know > whether there are plans for a security type of document). >=20 > Thanks, > Tolga >=20 > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Monday, April 16, 2007 11:13 AM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] Issue39: What to verify in TLS certificates >=20 > Hi Tolga, >=20 > Comments inline: >=20 > > If we use subjectAltName for a postcheck for TLS certificates in the > following way: > > a) dNSName contains the name of the domain, the host claims to be in > (OriginRealm in CER/CEA) > > b) otherName contains the Id of the application, which the host claims > to host for the realm specified in a) > > > > Do we need to verify that the TLS certificate is valid for the domain > of the server which was returned by the DNS query as well? It doesn't > seem necessary to me, afterall what we care is that the host is valid to > provide a given service for a given domain. > > >=20 > My personal preference is not to even deal with this issue in the base > protocol simply because certificate ownership/usage validation is may > not be limited to diameter only. The "issue" may also be relevant to > other protocols so its probably better to "specify" the solution (if > there isn't already one) in more relevant security related documents > which the base protocol can simply refer to. >=20 > > As an example if we are interested in getting serviceA for domainA and > if at the end of DNS queries we end up with > host5.thirdpartydiamnetwork.com, are we really interested that we have a > valid certificate for the domain thirdpartydiamnetwork.com? > > > > Currently, in RFC3588 we have the following: > > > > If the server is using a site certificate, the domain name in the > query and the domain name in the replacement field MUST both be valid > based on the site certificate handed out by the server in the TLS or IKE > exchange. > > >=20 > The example you mentioned above re-enforces my idea so I agree that it > maybe better to remove these text from the base spec. It also helps > simplify the base protocol similar to the removal of the IPsec usage. >=20 >=20 > regards, > victor >=20 > > Does that text refer to the type of usage I think as unnecessary? > > > > Thanks, > > Tolga > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 09:36: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 1HeALA-00076v-VG; Wed, 18 Apr 2007 09:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAL7-00072J-NB for dime@ietf.org; Wed, 18 Apr 2007 09:36:53 -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 1HeAIA-00050R-3W for dime@ietf.org; Wed, 18 Apr 2007 09:33:50 -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 l3IDXTKe099544; Wed, 18 Apr 2007 09:33:29 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46261EC7.8090602@tari.toshiba.com> Date: Wed, 18 Apr 2007 09:36:07 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Limited flexibility with NAPTR queries References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> <46239734.8040301@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E702DFC6@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702DFC6@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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, > After having a quick look to the meeting minutes I saw that this issue > was touched as well. So, does anybody have some proposal or are we going > to rely on SLP? > The current idea is to remove SLP and NAPTR from the base document to simplify the bis; the base doc will rely on basic DNS and redirects. If other SDOs may see some usefulness in SLP and others, one idea is that it maybe up to them to define/redefine its use. Any thoughts on this approach ? regards, victor > Thanks, > Tolga > >> -----Original Message----- >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >> Sent: Monday, April 16, 2007 11:33 AM >> To: Asveren, Tolga >> Cc: dime@ietf.org >> Subject: Re: [Dime] Limited flexibility with NAPTR queries >> >> Hi Tolga, >> >> >>> Something, which is bothering me recently is the limited flexibility >>> >> when using NAPTR service fields to locate Diameter servers. The >> > current > >> values placed in the registry allow to find *a* Diameter server in a >> > given > >> domain. It doesn't help much if one is looking for a server for a >> > specific > >> application in a given domain. This could work in environments where >> > each > >> domain (or better said each domain which envisions use of DNS to >> > locate > >> its servers) has a relay/redirect as the main contact point. >> >>> My initial thoughts are: >>> a) We can have registry entries for each Diameter application (could >>> > be > >> hard to manage ?) >> >>> b) We can explain in the bis document that NAPTR query should >>> > resolve to > >> a relay/redirect for the domain, if the domain supports more than one >> Diameter application. >> >> I would prefer option (b) for simplicity though I'm concerned about >> explain deployment considerations such as these in the base spec. It >> > may > >> open up the door for adding many more possible deployment scenarios >> within the base spec. It maybe possible to add this in the guidelines >> doc but I'm sure. >> >> regards, >> victor >> >> regards, >> victor >> >> >> >>> Or am I missing something? >>> >>> Thanks, >>> Tolga >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime >>> >>> >>> >>> >>> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 09:39: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 1HeANh-00006C-UU; Wed, 18 Apr 2007 09:39:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA7S-0004OW-DS for dime@ietf.org; Wed, 18 Apr 2007 09:22:46 -0400 Received: from dhcp-76-216.netzwert.ag ([192.108.76.216] helo=noir.netzwert.ag) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA7P-0001k5-9Y for dime@ietf.org; Wed, 18 Apr 2007 09:22:46 -0400 Received: by noir.netzwert.ag (Postfix, from userid 531) id 59413A07E69; Wed, 18 Apr 2007 15:21:49 +0200 (CEST) Date: Wed, 18 Apr 2007 15:21:49 +0200 From: Alexis Hildebrandt To: dime@ietf.org Message-ID: <20070418132149.GF32344@noir.netzwert.ag> Mail-Followup-To: dime@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.1 (/) X-Scan-Signature: c9f32637d681d0f0b9116f923e25825c X-Mailman-Approved-At: Wed, 18 Apr 2007 09:39:31 -0400 Subject: [Dime] Review of "Diameter Applications Design Guidelines 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 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Dear gentlepeople, please find attached a quick and more editorial review of the draft-fajardo-dime-app-design-guide-01.txt. For your convenience I attached an edited version of the document, as well as a diff. The change suggestions around line 414 include a '(?)' where I'd like to indicate, that I wasn't quite sure if I understood the text correctly myself. 1) Either as I suggested an "application server is provisioned to use a different protocol to access the accounting server" or the difference between the two accounting servers as it is in the document at the moment should be explained in detail. 2) Is the intention to say: In a) all b) most of the cases above... ? Feedback on the suggestions is greatly appreciated. Best regards, Alexis. -- Alexis Hildebrandt, Software Development Voice: +49.30.590080-1172 Netzwert AG, An den Treptowers 1, 12435 Berlin, Germany Fax: +49.30.5900800700, http://www.netzwert.ag Vorstand: Ralf U. Holighaus, Ralf Moritz Aufsichtsrat: Clemens Schrimpe (Vorsitzender) Steuernr.: 37/491/20570 Ust-IdNr.: DE 813 06 78 94 Sitz: Berlin Handelsregister: Amtsgericht Charlottenburg HRB 72960 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="draft-fajardo-dime-app-design-guide-01-review.txt" Diameter Maintanence and V. Fajardo, Ed. Extensions (DIME) Toshiba America Research Inc. Internet-Draft T. Asveren Intended status: Informational Ulticom Inc. Expires: October 7, 2007 H. Tschofenig Siemens Networks GmbH & Co KG G. McGregor Alcatel-Lucent J. Loughney Nokia Research Center April 5, 2007 Diameter Applications Design Guidelines draft-fajardo-dime-app-design-guide-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Diameter Base protocol provides rules on how to extend Diameter Fajardo, et al. Expires October 7, 2007 [Page 1] Internet-Draft Diameter Applications Design Guidelines April 2007 and to create new Diameter applications. This is a companion document to clarify these rules. This document does not intended to add, remove or change these rules, rather it helps protocol designers to extend Diameter. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3 4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4 4.1. Rules on Extending Existing Applications . . . . . . . . . 5 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 5.1. Diameter Accounting Support . . . . . . . . . . . . . . . 7 5.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 8 5.3. Updating an existing Application . . . . . . . . . . . . . 9 5.4. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 10 5.5. Deleting AVPs from a Command ABNF . . . . . . . . . . . . 10 5.6. Justifying the Allocation of Application-Id . . . . . . . 11 5.7. Use of Application-Id in a Message . . . . . . . . . . . . 11 5.8. Support for Server Initiated Requests . . . . . . . . . . 11 5.9. System Architecture and Deployment . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Fajardo, et al. Expires October 7, 2007 [Page 2] Internet-Draft Diameter Applications Design Guidelines April 2007 1. Introduction The Diameter Base protocol document defines rules on how one would extend Diameter (see Section 1.2 of [1]). In the context of this document, extending Diameter means that a new Diameter application is being defined which may or may not be based on an existing Diameter application. A decision to define a new application would mean allocation of a new application ID. By themselves, the rules defined in the Diameter Base protocol are not necessarily comprehensive enough that one can easily derive good design decisions from them. The effect of this can be seen in various attempts to extend Diameter where protocol designers have no clear answer on whether to even define a new application or not. At worst, some existing Diameter applications that had purposely been derived from another existing application resulted in some in- appropriate design decision in which both applications are no longer interoperable in certain conditions. The intent of this document is to influence ongoing and future Diameter application design by providing the following content: o Clarify existing Diameter extensibility rules present in the Diameter Base Protocol. o Clarify usage of certain Diameter functionality which are not explicitly described in the Diameter Base specification. o Discuss design choices when defining new applications. o Present tradeoffs of design choices. Note that it is not always possible to offer a complete and concise answer to certain design choices. There is, however, the belief that at a minimum, this document can be used as a guide to Diameter extensibility. 2. Terminology This document reuses the terminology used in [1]. 3. Diameter Application Model As it is currently interpreted and practiced, the Diameter Base protocol is a two-layer protocol. The lower layer is mainly responsible for managing connections between neighboring peers and Fajardo, et al. Expires October 7, 2007 [Page 3] Internet-Draft Diameter Applications Design Guidelines April 2007 for message routing. The upper layer is where the Diameter applications reside. This model is inline with a Diameter node having an application layer and a peer-to-peer delivery layer. The Diameter Base protocol document completely defines the architecture and behavior of the message delivery layer and then provides the framework for designing Diameter applications on the application layer. This framework includes definitions of application sessions and accounting support (see Section 8 and 9 of [1]). The remainder of this document also treats a Diameter node as a single instance of a Diameter message delivery layer and one or more Diameter applications using it. 4. Rules on Diameter Extensibility The general theme of Diameter extensibility is to reuse AVPs, AVP values, commands and applications as much as possible. However, there are also rules for extending Diameter as specified in Section 1.2 of [1]. As is, the rules apply to the scenario where one is trying to define a new Diameter application. Defining a new Diameter application can be done by: Defining a completely new application This case applies to applications which have requirements that cannot be filled by existing applications and would require definition of new command(s), AVPs and AVP values. Typically, there is little ambiguity about the decision to create these types of applications. Some examples are the interfaces defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh ([4] and [5]) etc . Though some decisions may be clear, designers should also consider certain aspects of the application itself. Some of these are described in Section 5. Applications design should also follow the theme of Diameter extensibility which advocates reuse of AVPs and AVP values as much as possible even in newly defined commands. In certain cases where accounting will be used, the models described in Section 5.1 should be considered. Extending an existing application In this case, the requirements for the new applications are not completely unique and there are existing applications that can be reused to solve some or all of the application's requirements. Thus there is a greater likelihood of ambiguity on how much and to what extend the existing application can be reused, and what the implications for both the new and existing application are. Section 4.1 discusses some of the issues in this case. Fajardo, et al. Expires October 7, 2007 [Page 4] Internet-Draft Diameter Applications Design Guidelines April 2007 4.1. Rules on Extending Existing Applications The Diameter base protocol provides a clear set of rules on when one should define a new Diameter application. In the context of this document, the rules are: Adding an AVP to a command ABNF of an existing application The rules are strict in the case where the AVP(s) to be added is mandatory to be understood and interpreted. This means that the M-bit is set and the AVP(s) is required to exist in the command ABNF. Note that this mandatory AVP rule applies to AVP(s) that either already exist in the same or in another application or the AVP(s) are yet to be defined. In the latter case, the ambiguity arises when trying to decide whether the AVP(s) should be mandatory or not. There are several questions that application designers should contemplate when trying to decide: * Does the AVP(s) change the state machine of the application ? * Would the presence of the AVP(s) cause additional message round-trips; effectively changing the state machine of the application ? * Will the AVP be used to fulfill new required functionality ? * Would the AVP be used to differentiate between old and new versions of the same application ? * Will it have duality in meaning; i.e., be used to carry application related information as well as be used to indicate that the message is for a new application ? These questions are not comprehensive in any way but in all cases the semantics of the application must change to justify the use of mandatory AVPs. However, care should also be taken when opting for optional AVPs instead of mandatory AVPs simply to avoid allocating new applications. Optional AVPs that fall into any of the categorical questions above would have consequences. See Section 5.4 for details. Add a new AVP value to an to an existing AVP In this case, the rule applies to existing mandatory AVPs already present in a command ABNF where the semantics of the AVP changes. This means that the meaning or usage of the AVP has changed and Fajardo, et al. Expires October 7, 2007 [Page 5] Internet-Draft Diameter Applications Design Guidelines April 2007 significantly affects the behavior of the application. Although this case may be less common or seem more subtle, the exact same considerations given in the first scenario above apply here as well. Add a command to an existing application In this case, the rule applies to defining a new command for an existing application or importing an existing command from another application so as to inherit some or all of the functionality of that application. In the first case, the decision is straight forward since this is typically a result of adding new functionality that does not yet exist. The latter case would result in a new application but it has a more subtle issue such as deciding whether importing of commands and functionality is really better than simply using the existing application as it is in conjunction with any new application. A typical example would be the Diameter MIPv6 split scenario (see [6]) in which several application models would have been possible during the design phase; one model would reuse existing Diameter EAP application combined with a new Diameter MIPv6 application to form a complete authentication and authorization scheme and another would be to reuse Diameter EAP like commands within the new Diameter MIPv6 application to accomplish the same result. In this case, the latter model was chosen which would permit the reuse of commands and/or AVPs from one application to another. Other applications such as Diameter QoS (see [7]) would likely face similar decisions. In general, it is difficult to come to a hard and fast guideline for this scenario so a case by case study of each application requirement should be applied. Before importing a command, application designers should consider whether: * The existing application can be reused as is without fundamental changes; i.e. an optional AVP is sufficient to indicate support for new optional functionality if any. There are pitfalls to this as well. See Section 5.4 * Reuse of existing applications would result in a distributed environment which may not be conducive to certain requirements of the applications; i.e. security and or deployment difficulties - because of Diameter routing, messages for different applications providing service to the same user may end up in different servers would then need to be co- related. This could mean extra signaling between application servers. A typical example would be the initial proposal for Fajardo, et al. Expires October 7, 2007 [Page 6] Internet-Draft Diameter Applications Design Guidelines April 2007 Diameter MIPv6 split scenario (see [6]) where authorization and authentication is separated. 5. Design Considerations The following are some of the design considerations that apply to a Diameter application. 5.1. Diameter Accounting Support Accounting can be treated as an auxiliary application which is used in support of other applications. In most cases, accounting support is required when defining new applications. However, the lack of clarity in the base protocol document has prevented easy use of the base accounting messages (ACR/ACA). This document provides two(2) possible models for using accounting: Split Accounting Model In this model, the accounting messages will use the Diameter base accounting application ID (value of 3). The design implication for this is that the accounting is treated as an independent application, especially during routing. This means that accounting commands emanating from an application may be routed separately from the rest of the other application messages. This also implies that the messages generally end up in a central accounting server. A split accounting model is a good design choice when: * The application itself will not define its own unique accounting commands. * The overall system architecture permits the use of centralized accounting for one or more Diameter applications. From a Diameter architecture perspective, this model should be the typical design choice. Note that when using this model, the accounting server must use the Acct-Application-Id AVP to determine which application is being accounted for. Therefore, the application designer should specify the proper values used in Acct-Application-Id AVP when sending ACR messages. Fajardo, et al. Expires October 7, 2007 [Page 7] Internet-Draft Diameter Applications Design Guidelines April 2007 Coupled Accounting Model In this model, the accounting messages will use the application ID of the application using the accounting service. The design implication for this is that the accounting messages is tightly coupled with the application itself; meaning that accounting messages will be routed like any other application messages. It would then be the responsibility of the application server (application entity receiving the ACR message) to send the accounting records carried by the accounting messages to the proper accounting server. The application server is also responsible for formulating a proper response (ACA). A coupled accounting model is a good design choice when: * The system architecture or deployment will not provide an accounting server that supports Diameter. * The system architecture or deployment requires that the accounting for the specific application should be handled by the application itself. * The application(?) server is provisioned to use a different protocol to access the accounting server; i.e., via LDAP, XML etc. This includes attempting to supporting older accounting systems that are not Diameter aware. In all/most cases(?) above, there will generally be no direct Diameter access to the accounting server. These models provide a basis for using accounting messages. Application designers may obviously deviate from these models provided that the factors being addressed here have also been taken into account. Though it is not recommended, examples of other methods would be defining a new set of commands to carry application specific accounting records. Additionally, the application ID in the message header and the Acct- Application-Id AVP are populated depending on the accounting model used for a specific application, as described in [1]. Therefore, application designers have to specify the accounting model used to guarantee proper routing of accounting requests. 5.2. Generic Diameter Extensions Generic Diameter extensions are AVPs, commands or applications that are designed to support other Diameter applications. They are auxiliary applications meant to improve or enhance the Diameter protocol itself or Diameter applications/functionality. Some Fajardo, et al. Expires October 7, 2007 [Page 8] Internet-Draft Diameter Applications Design Guidelines April 2007 examples include the extensions to support auditing and redundancy (see [8]), improvements in duplicate detection scheme (see [9]). Since generic extensions can cover many aspects of Diameter and Diameter applications, it is not possible to enumerate all the probable scenarios in this document. However, some of the most common considerations are as follows: o Backward compatibility: Dealing with existing applications that do not understand the new extension. Designers also have to make sure that new extensions do not break the expected message delivery layer behavior. o Forward compatibility: Making sure that the design will not introduce undue restrictions for future applications. Future applications attempting to support this feature should not have to go through great lengths to implement any new extensions. o Tradeoffs in signaling: Designers may have to choose between the use of optional AVPs piggybacked onto existing commands versus defining new commands and applications. Optional AVPs are simpler to implement and may not need changes to existing applications; i.e., use of proxy agents. However, the drawback is that the timing of sending extension data will be tied to when the application would be sending a message. This has consequences if the application and the extensions have different timing requirements. The use of commands and applications solves this issue but the tradeoff is the additional complexity of defining and deploying a new application. It is the designer's choice to find a good balance among these tradeoffs based on the requirements of the extension. 5.3. Updating an existing Application An application that is being upgraded must follow the same rules mentioned in Section 4. Even if the new version is fundamentally the same application, allocation of a new application ID is possible if it meets those criteria. Optional AVPs can also be used to indicate version differences. If this approach is chosen, it is recommended that the optional AVP is used specifically to indicate version information only and nothing else. Additionally, the use of too many optional AVPs to carry application enhancements should be avoided since such approach has a tendency to become unmanageable and introduce interoperability issues. These pitfalls are discussed in Section 5.4 Fajardo, et al. Expires October 7, 2007 [Page 9] Internet-Draft Diameter Applications Design Guidelines April 2007 For the same reason, care should be taken in attempting to justify allocation of new application ID for every change. The pitfalls of this approach is discussed in Section 5.6. 5.4. Use of optional AVPs Problems arise when there is a tendency by application designers to keep adding optional AVPs to an existing command so they can circumvent the extension rules in Section 4. Some of the pitfalls that application designers should avoid are: o Use of optional AVPs with intersecting meaning; one AVP has partially the same usage and/or meaning as another AVP. The presence of both can lead to confusion. o Optional AVPs with dual purpose; i.e.; to carry applications data as well as to indicate support for one or more features. This has a tendency to introduce interpretation issues. o Use of optional AVPs with a minimum occurrence of one(1) in the command ABNF. This is generally contradictory. Application designers should not use this scheme to circumvent definition of mandatory AVPs. Any of these practices generally result in interoperability problems so they should be avoided as much as possible. 5.5. Deleting AVPs from a Command ABNF Although this scenario is not as common, the deletion of AVPs from a command ABNF is significant when trying to extend an existing application. Deletion can be categorized between deletion of mandatory and optional AVPs. In the unlikely event that an application designer would require that mandatory AVPs must be deleted then it constitutes a fundamental change to an existing application. Though not specified in [1], deletion of mandatory would require the allocation of a new application since it dictates changes in the behavior and semantics of an application. The deletion of an optional AVP may not necessarily indicate allocation of a new application. An optional AVP with a minimum occurrence of at least one(1) in the command ABNF would mean that the AVP is required and that if deleted, there would effectively be changes to the behavior of the application as well. Such cases are highly dubious to begin with since those AVPs already exhibits properties of mandatory AVPs. It should therefore fall into the Fajardo, et al. Expires October 7, 2007 [Page 10] Internet-Draft Diameter Applications Design Guidelines April 2007 category of deleting mandatory AVPs. In other cases, it is recommended that application designers reuse the command ABNF as is and safely ignore (but not delete) any optional AVP that will not be used. This is to maintain compatibility with existing applications that will not know about the new functionality as well as maintain the integrity of existing dictionaries. 5.6. Justifying the Allocation of Application-Id Application designers should avoid justifying the allocation of application IDs for every change that is made to an existing application. Proliferation of application ID can lead to confusion and an in-efficient use of the application ID namespaces. Application designers should always use Section 4 as a basis for justifying allocation of a new application ID. 5.7. Use of Application-Id in a Message When designing new applications, designers should specify that the application ID carried in all session level messages must be the application ID of the application using those messages. This includes the session level messages defined in base protocol, i.e., RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled accounting model, see Section 5.1. Existing specifications may not adhere to this rule for historical or other reasons. However, this scheme is followed to avoid possible routing problems for these messages. Additionally, application designers using the Vendor-Specific- Application-Id AVP should note that the Vendor-Id AVP will not be used in any way by the Diameter message delivery layer. Therefore its meaning and usage should be segregated only within the application. 5.8. Support for Server Initiated Requests Section 8 of [1] implies that only client sessions can initiate a request messages. Assuming that the Diameter client and server sessions can be de-coupled from application client and server entities, an application design requiring server initiated request can simply create a Diameter client session and the client entity can then initiate a corresponding Diameter server session. Fajardo, et al. Expires October 7, 2007 [Page 11] Internet-Draft Diameter Applications Design Guidelines April 2007 5.9. System Architecture and Deployment The following are some of the architecture considerations that applications designers should contemplate when defining new applications: o For general AAA applications, Diameter requires more message exchanges for the same set of services compared to RADIUS. Therefore, application designers should consider scalability issues during the design process. o Application design should be agnostic to any Diameter topology. Application designers should not always assume a particular Diameter topology; i.e., assume that there will always be application proxies in the path or assume that only intra-domain routing is applicable. o Security Considerations. Application designers should take into account that there is no end-to-end authentication built into Diameter. o Application design should consider some form of redundancy. Session state information is the primary data necessary for backup/recovering endpoints to continue processing for an previously existing session. Carrying enough information in the messages to reconstruct session state facilitates redundant implementations and is highly recommended. o Application design should segregate message delivery layer processing from application level processing. An example is the use of timers to detect lack of a response for a previously sent requests. Although the Diameter base protocol defines a watchdog timer Tw, its use on application level is discouraged since Tw is a hop-by-hop timer and it would not be relevant for end-to- end message delivery error detection. In such a case, it is recommended that applications should define their own set of timers for such purpose. 6. IANA Considerations This document does not require actions by IANA. 7. Security Considerations This document does provides guidelines and considerations for extending Diameter and Diameter applications. It does not define nor Fajardo, et al. Expires October 7, 2007 [Page 12] Internet-Draft Diameter Applications Design Guidelines April 2007 address security related protocols or schemes. 8. Acknowledgments We greatly appreciate the insight provided by Diameter implementers who have highlighted the issues and concerns being addressed by this document. 9. References 9.1. Normative References [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [2] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message contents", 3GPP TS 29.228 Version 7.0.0 2006. [3] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229 Version 7.0.0 2006. [4] 3GPP, "IMS Sh interface : signalling flows and message content", 3GPP TS 29.328 Version 6.8.0 2005. [5] 3GPP, "IMS Sh interface based on the Diameter protocol; Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. [6] Bournelle, J., "Diameter Mobile IPv6: HA-to-AAAH support", draft-ietf-dime-mip6-split-01 (work in progress), October 2006. [7] Zorn, G., "Diameter Quality of Service Application", draft-ietf-dime-diameter-qos-00 (work in progress), February 2007. 9.2. Informative References [8] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. [9] Asveren, T., "Diameter Duplicate Detection Cons.", draft-asveren-dime-dupcons-00 (work in progress), August 2006. Fajardo, et al. Expires October 7, 2007 [Page 13] Internet-Draft Diameter Applications Design Guidelines April 2007 Authors' Addresses Victor Fajardo (editor) Toshiba America Research Inc. One Telcordia Drive Piscataway, NJ 08854 USA Email: vfajardo@tari.toshiba.com Tolga Asveren Ulticom Inc. 1020 Briggs Road Mount Laurel, NJ, 08054 USA Email: asveren@ulticom.com Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.priv.at Glenn McGregor Alcatel-Lucent USA Email: glenn@aaa.lucent.com John Loughney Nokia Research Center USA Email: john.loughney@nokia.com Fajardo, et al. Expires October 7, 2007 [Page 14] Internet-Draft Diameter Applications Design Guidelines April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Fajardo, et al. Expires October 7, 2007 [Page 15] --9jxsPFA5p3P2qPhR Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="draft-fajardo-dime-app-design-guide-01.diff" --- /tmp/draft-fajardo-dime-app-design-guide-01.txt 2007-04-16 15:45:00.429554626 +0200 +++ /tmp/draft-fajardo-dime-app-design-guide-01-review.txt 2007-04-16 15:42:11.510997880 +0200 @@ -146,7 +146,7 @@ o Present tradeoffs of design choices. Note that it is not always possible to offer a complete and concise - answer to certain design choices. There is, however, the believe + answer to certain design choices. There is, however, the belief that at a minimum, this document can be used as a guide to Diameter extensibility. @@ -174,12 +174,12 @@ having an application layer and a peer-to-peer delivery layer. The Diameter Base protocol document completely defines the architecture and behavior of the message delivery layer and then provides the - framework for designing Diameter applications for the application + framework for designing Diameter applications on the application layer. This framework includes definitions of application sessions and accounting support (see Section 8 and 9 of [1]). The remainder - of this document also treats a Diameter node a single instance of a + of this document also treats a Diameter node as a single instance of a Diameter message delivery layer and one or more Diameter applications - that uses it. + using it. 4. Rules on Diameter Extensibility @@ -193,28 +193,28 @@ Defining a completely new application - This case applies to applications which has requirements that + This case applies to applications which have requirements that cannot be filled by existing applications and would require definition of new command(s), AVPs and AVP values. Typically, there is little ambiguity about the decision to create these types of applications. Some examples are the interfaces defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh - ([4] and [5]) etc . Though some decisions maybe clear, designers + ([4] and [5]) etc . Though some decisions may be clear, designers should also consider certain aspects of the application itself. Some of these are described in Section 5. Applications design should also follow the theme of Diameter extensibility which advocates reuse of AVPs and AVP values as much as possible even in newly defined commands. In certain cases where accounting will be - used, models described in Section 5.1 should be considered. + used, the models described in Section 5.1 should be considered. Extending an existing application - In this case, the requirements of the new applications are not + In this case, the requirements for the new applications are not completely unique and there are existing applications that can be - reused to solve some or all of the application requirements. - Therefore, there is a greater likelihood of ambiguity on how much - of the existing application can be reused, to what extent and what - are the implications for both the new and existing application. + reused to solve some or all of the application's requirements. + Thus there is a greater likelihood of ambiguity on how much and to + what extend the existing application can be reused, and what + the implications for both the new and existing application are. Section 4.1 discusses some of the issues in this case. @@ -235,10 +235,10 @@ The rules are strict in the case where the AVP(s) to be added is mandatory to be understood and interpreted. This means that the - M-bit is set and the AVP(s) is required to exists in command ABNF. - Note that this mandatory AVP rules applies to AVP(s) that either + M-bit is set and the AVP(s) is required to exist in the command ABNF. + Note that this mandatory AVP rule applies to AVP(s) that either already exist in the same or in another application or the AVP(s) - are yet to be defined. In this case, the ambiguity arises when + are yet to be defined. In the latter case, the ambiguity arises when trying to decide whether the AVP(s) should be mandatory or not. There are several questions that application designers should contemplate when trying to decide: @@ -258,13 +258,13 @@ application related information as well as be used to indicate that the message is for a new application ? - These questions are not comprehensive in anyway but in all cases + These questions are not comprehensive in any way but in all cases the semantics of the application must change to justify the use of mandatory AVPs. However, care should also be taken when opting for optional AVPs instead of mandatory AVPs simply to avoid allocating new - applications. Optional AVPs that falls into any of the + applications. Optional AVPs that fall into any of the categorical questions above would have consequences. See Section 5.4 for details. @@ -282,8 +282,8 @@ significantly affects the behavior of the application. Although - this case maybe less common or seem more subtle, the exact same - considerations given in the first scenario above applies here as + this case may be less common or seem more subtle, the exact same + considerations given in the first scenario above apply here as well. Add a command to an existing application @@ -296,7 +296,7 @@ functionality that does not yet exist. The latter case would result in a new application but it has a more subtle issue such as deciding whether importing of commands and functionality is really - better than simply using the existing application as is in + better than simply using the existing application as it is in conjunction with any new application. A typical example would be the Diameter MIPv6 split scenario (see @@ -313,7 +313,7 @@ In general, it is difficult to come to a hard and fast guideline for this scenario so a case by case study of each application - requirements should be applied. Before importing a command, + requirement should be applied. Before importing a command, application designers should consider whether: * The existing application can be reused as is without @@ -321,7 +321,7 @@ indicate support for new optional functionality if any. There are pitfalls to this as well. See Section 5.4 - * Reuse of existing applications as is would result in a + * Reuse of existing applications would result in a distributed environment which may not be conducive to certain requirements of the applications; i.e. security and or deployment difficulties - because of Diameter routing, messages @@ -352,7 +352,7 @@ Accounting can be treated as an auxiliary application which is used in support of other applications. In most cases, accounting support is required when defining new applications. However, the lack of - clarity in the base protocol document have prevented easy use the + clarity in the base protocol document has prevented easy use of the base accounting messages (ACR/ACA). This document provides two(2) possible models for using accounting: @@ -362,7 +362,7 @@ accounting application ID (value of 3). The design implication for this is that the accounting is treated as an independent application, especially during routing. This means that - accounting commands emanating from an application maybe routed + accounting commands emanating from an application may be routed separately from the rest of the other application messages. This also implies that the messages generally end up in a central accounting server. A split accounting model is a good design @@ -414,22 +414,22 @@ accounting for the specific application should be handled by the application itself. - * The accounting server is provisioned to use a different + * The application(?) server is provisioned to use a different protocol to access the accounting server; i.e., via LDAP, XML etc. This includes attempting to supporting older accounting systems that are not Diameter aware. - In all most above, there will generally be no direct Diameter + In all/most cases(?) above, there will generally be no direct Diameter access to the accounting server. These models provide a basis for using accounting messages. Application designers may obviously deviate from these models provided that the factors being addressed here have also been taken - into account. Though its not recommended, examples of other methods - would be defining a new set of command to carry application specific + into account. Though it is not recommended, examples of other methods + would be defining a new set of commands to carry application specific accounting records. - Additionally, application ID in the message header and Accounting- + Additionally, the application ID in the message header and the Acct- Application-Id AVP are populated depending on the accounting model used for a specific application, as described in [1]. Therefore, application designers have to specify the accounting model used to @@ -459,7 +459,7 @@ o Backward compatibility: Dealing with existing applications that do not understand the new extension. Designers also have to make - sure that new extensions does not break expected message delivery + sure that new extensions do not break the expected message delivery layer behavior. o Forward compatibility: Making sure that the design will not @@ -468,7 +468,7 @@ go through great lengths to implement any new extensions. o Tradeoffs in signaling: Designers may have to choose between the - use of optional AVPs piggybacked into existing commands versus + use of optional AVPs piggybacked onto existing commands versus defining new commands and applications. Optional AVPs are simpler to implement and may not need changes to existing applications; i.e., use of proxy agents. However, the drawback is that the @@ -477,15 +477,15 @@ the application and the extensions have different timing requirements. The use of commands and applications solves this issue but the tradeoff is the additional complexity of defining - and deploying a new application. It is left up to the designer to + and deploying a new application. It is the designer's choice to find a good balance among these tradeoffs based on the requirements of the extension. 5.3. Updating an existing Application - An application that is being upgraded must follow the same rules in - Section 4. Even if the new version is fundamentally the same + An application that is being upgraded must follow the same rules mentioned + in Section 4. Even if the new version is fundamentally the same application, allocation of a new application ID is possible if it meets those criteria. @@ -511,10 +511,10 @@ 5.4. Use of optional AVPs - Problems arises when there is a tendency by applications designers to + Problems arise when there is a tendency by application designers to keep adding optional AVPs to an existing command so they can circumvent the extension rules in Section 4. Some of the pitfalls - that application designers should avoid is as follows: + that application designers should avoid are: o Use of optional AVPs with intersecting meaning; one AVP has partially the same usage and/or meaning as another AVP. The @@ -529,13 +529,13 @@ designers should not use this scheme to circumvent definition of mandatory AVPs. - All of these practices generally results in interoperability problems + Any of these practices generally result in interoperability problems so they should be avoided as much as possible. 5.5. Deleting AVPs from a Command ABNF Although this scenario is not as common, the deletion of AVPs from a - command ABNF is significant to when trying to extend an existing + command ABNF is significant when trying to extend an existing application. Deletion can be categorized between deletion of mandatory and optional AVPs. @@ -648,11 +648,11 @@ o Application design should segregate message delivery layer processing from application level processing. An example is the use of timers to detect lack of a response for a previously sent - requests. Although Diameter base protocol defines a watchdog + requests. Although the Diameter base protocol defines a watchdog timer Tw, its use on application level is discouraged since Tw is - a hop-by-hop timer and its use would not be relevant for end-to- + a hop-by-hop timer and it would not be relevant for end-to- end message delivery error detection. In such a case, it is - recommended that applications should define its own set of timers + recommended that applications should define their own set of timers for such purpose. --9jxsPFA5p3P2qPhR 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 --9jxsPFA5p3P2qPhR-- From dime-bounces@ietf.org Wed Apr 18 10:08: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 1HeApc-0003on-34; Wed, 18 Apr 2007 10:08:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeApa-0003nw-5k for dime@ietf.org; Wed, 18 Apr 2007 10:08:22 -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 1HeApY-0002V0-SG for dime@ietf.org; Wed, 18 Apr 2007 10:08:22 -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 l3IE30kY099684 for ; Wed, 18 Apr 2007 10:03:00 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <462625B4.80909@tari.toshiba.com> Date: Wed, 18 Apr 2007 10:05:40 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Review of "Diameter Applications Design Guidelines Document" References: <20070418132149.GF32344@noir.netzwert.ag> In-Reply-To: <20070418132149.GF32344@noir.netzwert.ag> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Alexis, Thanks for the review. Since you have a lot of editorial comments, I will publish a 02 version to polish the doc. Additional comments in-line: > Dear gentlepeople, > please find attached a quick and more editorial review of the > draft-fajardo-dime-app-design-guide-01.txt. > > For your convenience I attached an edited version of the document, as > well as a diff. > > The change suggestions around line 414 include a '(?)' where I'd like to > indicate, that I wasn't quite sure if I understood the text correctly > myself. > > 1) Either as I suggested an "application server is provisioned to use > a different protocol to access the accounting server" or the > difference between the two accounting servers as it is in the > document at the moment should be explained in detail. > The intent of the text is what you have suggested. > 2) Is the intention to say: In > a) all > b) most > of the cases above... ? > The intent is 'all'. thanks, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 10:31: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 1HeBBZ-0000TB-5n; Wed, 18 Apr 2007 10:31:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBBY-0000T6-Rx for dime@ietf.org; Wed, 18 Apr 2007 10:31:04 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBBW-0006ok-Hb for dime@ietf.org; Wed, 18 Apr 2007 10:31:04 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 8D2BF7DEE for ; Wed, 18 Apr 2007 07:30:58 -0700 (PDT) Received: from [10.83.199.220] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 9757C7DD1 for ; Wed, 18 Apr 2007 07:30:56 -0700 (PDT) Message-ID: <46262B98.5020903@frascone.com> Date: Wed, 18 Apr 2007 10:30:48 -0400 From: David Frascone User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Dime] Diameter Application Design Guide (please read) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org At the IETF#68 DIME meeting, we did a "hum" to show support for the "Diameter Application Design Guide" document http://tools.ietf.org/html/draft-fajardo-dime-app-design-guide-00 Comments were incorporated. We are now proposing that the new draft: http://tools.ietf.org/wg/dime/draft-fajardo-dime-app-design-guide-01.txt to become a WG item. A number of people have read the document and support it. Nobody has objected. We would like to confirm the decision on the mailing list. Does anyone in the WG object? Deadline for responding: 28th April 2007 -Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Apr 18 18:08: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 1HeIKC-0006WC-Bk; Wed, 18 Apr 2007 18:08:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIKB-0006W7-Hq for dime@ietf.org; Wed, 18 Apr 2007 18:08:27 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIKB-0007pM-8d for dime@ietf.org; Wed, 18 Apr 2007 18:08:27 -0400 Received: from sonusmail01.sonusnet.com (sonusmail01.sonusnet.com [10.128.32.75]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3IM8RZq005148 for ; Wed, 18 Apr 2007 18:08:27 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail01.sonusnet.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 18 Apr 2007 18:08:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Dime] Limited flexibility with NAPTR queries MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 18:08:26 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFD2@sonusmail04.sonusnet.com> In-Reply-To: <46261EC7.8090602@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Limited flexibility with NAPTR queries Thread-Index: AceBvjQQ5xRXqaqJQgGKheID6iDR8gAL44tw References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> <46239734.8040301@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E702DFC6@sonusmail04.sonusnet.com> <46261EC7.8090602@tari.toshiba.com> From: "Asveren, Tolga" To: X-OriginalArrivalTime: 18 Apr 2007 22:08:27.0014 (UTC) FILETIME=[16F86260:01C78206] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, My impression from the interop and from the deployments I saw till now is that dropping SLP/NAPTR from bis shouldn't be a big issue. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, April 18, 2007 9:36 AM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] Limited flexibility with NAPTR queries >=20 > Hi Tolga, >=20 > > After having a quick look to the meeting minutes I saw that this issue > > was touched as well. So, does anybody have some proposal or are we going > > to rely on SLP? > > >=20 > The current idea is to remove SLP and NAPTR from the base document to > simplify the bis; the base doc will rely on basic DNS and redirects. If > other SDOs may see some usefulness in SLP and others, one idea is that > it maybe up to them to define/redefine its use. Any thoughts on this > approach ? >=20 > regards, > victor >=20 >=20 > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: Monday, April 16, 2007 11:33 AM > >> To: Asveren, Tolga > >> Cc: dime@ietf.org > >> Subject: Re: [Dime] Limited flexibility with NAPTR queries > >> > >> Hi Tolga, > >> > >> > >>> Something, which is bothering me recently is the limited flexibility > >>> > >> when using NAPTR service fields to locate Diameter servers. The > >> > > current > > > >> values placed in the registry allow to find *a* Diameter server in a > >> > > given > > > >> domain. It doesn't help much if one is looking for a server for a > >> > > specific > > > >> application in a given domain. This could work in environments where > >> > > each > > > >> domain (or better said each domain which envisions use of DNS to > >> > > locate > > > >> its servers) has a relay/redirect as the main contact point. > >> > >>> My initial thoughts are: > >>> a) We can have registry entries for each Diameter application (could > >>> > > be > > > >> hard to manage ?) > >> > >>> b) We can explain in the bis document that NAPTR query should > >>> > > resolve to > > > >> a relay/redirect for the domain, if the domain supports more than one > >> Diameter application. > >> > >> I would prefer option (b) for simplicity though I'm concerned about > >> explain deployment considerations such as these in the base spec. It > >> > > may > > > >> open up the door for adding many more possible deployment scenarios > >> within the base spec. It maybe possible to add this in the guidelines > >> doc but I'm sure. > >> > >> regards, > >> victor > >> > >> regards, > >> victor > >> > >> > >> > >>> Or am I missing something? > >>> > >>> Thanks, > >>> Tolga > >>> > >>> _______________________________________________ > >>> DiME mailing list > >>> DiME@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/dime > >>> > >>> > >>> > >>> > >>> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 19 10:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXSg-0004Yl-M3; Thu, 19 Apr 2007 10:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXSg-0004Yg-3a for dime@ietf.org; Thu, 19 Apr 2007 10:18:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXSf-0008FZ-AO for dime@ietf.org; Thu, 19 Apr 2007 10:18:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 67E5C203B7 for ; Thu, 19 Apr 2007 16:18:12 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-1c-46277a245406 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4CF2D2016A for ; Thu, 19 Apr 2007 16:18:12 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 16:18:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Apr 2007 16:18:10 +0200 Message-ID: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4004 errata - status? Thread-Index: AceCjY8DCMjNGgOWS+OLf4WD9irzHg== From: "Ulf Wiger \(TN/EAB\)" To: X-OriginalArrivalTime: 19 Apr 2007 14:18:12.0118 (UTC) FILETIME=[8FFEAB60:01C7828D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Dime] rfc4004 errata - status? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1606893356==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1606893356== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7828D.8FC2A4A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7828D.8FC2A4A1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies, I'm a newcomer on this list. In the process of developing a Diameter framework, I've=20 come across RFC4004. My strategy is to generate code for encode/decode etc. by copying and pasting from the=20 spec into a text document, then parsing it and generating code. As a result, errors in the spec tend to lead to=20 compilation error. For RFC4004, I stumbled on the AVPs MIP-MN-HA-SPI and MIP-HA-to-MN-SPI, which are not defined. They are=20 mentioned in the grouped AVPs MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA respectively. After some googling, I found that this had been noticed, and=20 a post by Peter McCann, 3 Jan 2007*, seemed to suggest=20 that I should simply remove them. Is this a correct assumption? * http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html BTW, while I'm at it, I might as well contribute another one for the=20 upcoming rfc4004 errata: Session-ID in the ABNF for AA-Mobile-Node-Request should be=20 Session-Id. While the names of messages and AVPs are really of informational nature, they are useful for mapping to structs, class names, etc., and these will be case-sensitive in many languages. BR, Ulf Wiger Ericsson AB ------_=_NextPart_001_01C7828D.8FC2A4A1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable rfc4004 errata - status?

Apologies, I'm a newcomer on this = list.

In the process of developing a Diameter = framework, I've
come across RFC4004. My strategy is to = generate code
for encode/decode etc. by copying and = pasting from the
spec into a text document, then = parsing it and generating
code. As a result, errors in the spec = tend to lead to
compilation error.

For RFC4004, I stumbled on the AVPs = MIP-MN-HA-SPI
and MIP-HA-to-MN-SPI, which are not = defined. They are
mentioned in the grouped AVPs = MIP-MN-to-HA-MSA
and MIP-HA-to-MN-MSA = respectively.

After some googling, I found that this = had been noticed, and
a post by Peter McCann, 3 Jan 2007*, = seemed to suggest
that I should simply remove them. Is = this a correct assumption?

* http://www1.ietf.org/mail-archive/web/dime/current/msg0114= 9.html

BTW, while I'm at it, I might as well = contribute another one for the
upcoming rfc4004 errata:

Session-ID in the ABNF for = AA-Mobile-Node-Request should be
Session-Id. While the names of = messages and AVPs are really
of informational nature, they are = useful for mapping to structs,
class names, etc., and these will be = case-sensitive in many
languages.

BR,
Ulf Wiger
Ericsson AB

------_=_NextPart_001_01C7828D.8FC2A4A1-- --===============1606893356== 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 --===============1606893356==-- From dime-bounces@ietf.org Thu Apr 19 11:10: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 1HeYGy-0000KE-BQ; Thu, 19 Apr 2007 11:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYGx-0000K8-MA for dime@ietf.org; Thu, 19 Apr 2007 11:10:11 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeYGx-0003Z6-AV for dime@ietf.org; Thu, 19 Apr 2007 11:10:11 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1176995410!7959940!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 16418 invoked from network); 19 Apr 2007 15:10:10 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-153.messagelabs.com with SMTP; 19 Apr 2007 15:10:10 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l3JFA9M4020321 for ; Thu, 19 Apr 2007 08:10:09 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l3JFA7x6007848 for ; Thu, 19 Apr 2007 10:10:08 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3JFA47h007799 for ; Thu, 19 Apr 2007 10:10:05 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] rfc4004 errata - status? Date: Thu, 19 Apr 2007 11:10:01 -0400 Message-ID: In-Reply-To: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc4004 errata - status? Thread-Index: AceCjY8DCMjNGgOWS+OLf4WD9irzHgABqljA References: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> From: "McCann Peter-A001034" To: "Ulf Wiger \(TN/EAB\)" , X-Vontu: Pass 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, Ulf, It is still my opinion that these SPI AVPs can be left out of the Diameter messages. However, I'd like to hear from someone who is actually deploying a complete system including RFC 3957. Anyone? I can see your point regarding Session-ID vs. Session-Id. However, as you note this is an internal implementation matter and won't affect interoperability. I am not sure whether it warrants an errata. -Pete Ulf Wiger (TN/EAB) wrote: > Apologies, I'm a newcomer on this list. >=20 > In the process of developing a Diameter framework, I've come across > RFC4004. My strategy is to generate code for encode/decode etc. by > copying and pasting from the spec into a text document, then parsing > it and generating code. As a result, errors in the spec tend to lead > to compilation error. =20 >=20 > For RFC4004, I stumbled on the AVPs MIP-MN-HA-SPI and > MIP-HA-to-MN-SPI, which are not defined. They are mentioned in the > grouped AVPs MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA respectively. =20 >=20 > After some googling, I found that this had been noticed, and a post > by Peter McCann, 3 Jan 2007*, seemed to suggest that I should simply > remove them. Is this a correct assumption? =20 >=20 > * http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html > =20 >=20 > BTW, while I'm at it, I might as well contribute another one for the > upcoming rfc4004 errata:=20 >=20 > Session-ID in the ABNF for AA-Mobile-Node-Request should be > Session-Id. While the names of messages and AVPs are really of > informational nature, they are useful for mapping to structs, class > names, etc., and these will be case-sensitive in many languages. =20 >=20 > BR, > Ulf Wiger > Ericsson AB _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 19 11:10: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 1HeYHL-0000PU-Ld; Thu, 19 Apr 2007 11:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYHK-0000PP-Ki for dime@ietf.org; Thu, 19 Apr 2007 11:10:34 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYHH-0003aO-FT for dime@ietf.org; Thu, 19 Apr 2007 11:10:34 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D78262014C; Thu, 19 Apr 2007 17:10:30 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-9e-46278666afae Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B5ECF21546; Thu, 19 Apr 2007 17:10:30 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:10:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] rfc4004 errata - status? Date: Thu, 19 Apr 2007 17:10:28 +0200 Message-ID: <6616D98C65DD514BA2E1DDC5F922315501AC4B82@esealmw115.eemea.ericsson.se> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701A611FC@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc4004 errata - status? Thread-Index: AceCjY8DCMjNGgOWS+OLf4WD9irzHgAAV9JwAAFcDqA= References: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> <8F6CBC7005099442AECDB784C9E9D7E701A611FC@MCHP7R6A.ww002.siemens.net> From: "Ulf Wiger \(TN/EAB\)" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 19 Apr 2007 15:10:30.0671 (UTC) FILETIME=[DEB7D9F0:01C78294] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 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="===============0114063690==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0114063690== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78294.DE2EF082" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78294.DE2EF082 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes, =20 To be fair, I am not aiming at a working implementation either - at least not now. =20 I'm just incorporating it in order to inherit some attributes into another specification. =20 These were the things I needed to do to make it compile: =20 ;; Source: ftp://ftp.isi.edu/in-notes/rfc4004.txt ;; ;; - Corrected Session-ID to Session-Id in AA-Mobile-Node-Request ;; - Commented out MIP-HA-to-MN-SPI, MIP-MN-FA-SPI & MIP-MN-HA-SPI ;; - Changed MIP-nonce to MIP-Nonce in MIP-MN-to-FA-MSA & ;; MIP-MN-to-HA-MSA =20 For my purposes, it's perfectly ok to exclude the above AVPs, since I=20 don't need them at this point. =20 BR, Ulf W =20 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@nsn.com]=20 Sent: den 19 april 2007 17:00 To: Ulf Wiger (TN/EAB); dime@ietf.org Subject: AW: [Dime] rfc4004 errata - status? =09 =09 Hi Ulf,=20 =20 so far our efforts have focused on the revision of the Diameter Base protocol specification.=20 With the past two interop events we did a lot of Base protocol testing in order to get feedback from implementers. =20 We haven't had a lot of feedback regarding RFC 4004. In fact, at the first interop we had=20 no implementation available to test (if I recall it correctly) and at the second interop we had 2 companies supporting RFC 4004.=20 =20 Nevertheless, we are interested in collecting bugs for all Diameter specifications. I will create a roundup issue tracker for this document as well.=20 =20 Ciao Hannes =20 ________________________________ Von: Ulf Wiger (TN/EAB) [mailto:ulf.wiger@ericsson.com]=20 Gesendet: Donnerstag, 19. April 2007 16:18 An: dime@ietf.org Betreff: [Dime] rfc4004 errata - status? =09 =09 =09 =09 Apologies, I'm a newcomer on this list.=20 In the process of developing a Diameter framework, I've=20 come across RFC4004. My strategy is to generate code=20 for encode/decode etc. by copying and pasting from the=20 spec into a text document, then parsing it and generating=20 code. As a result, errors in the spec tend to lead to=20 compilation error.=20 For RFC4004, I stumbled on the AVPs MIP-MN-HA-SPI=20 and MIP-HA-to-MN-SPI, which are not defined. They are=20 mentioned in the grouped AVPs MIP-MN-to-HA-MSA=20 and MIP-HA-to-MN-MSA respectively.=20 After some googling, I found that this had been noticed, and=20 a post by Peter McCann, 3 Jan 2007*, seemed to suggest=20 that I should simply remove them. Is this a correct assumption?=20 * http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html =20 BTW, while I'm at it, I might as well contribute another one for the=20 upcoming rfc4004 errata:=20 Session-ID in the ABNF for AA-Mobile-Node-Request should be=20 Session-Id. While the names of messages and AVPs are really=20 of informational nature, they are useful for mapping to structs,=20 class names, etc., and these will be case-sensitive in many=20 languages.=20 BR,=20 Ulf Wiger=20 Ericsson AB=20 ------_=_NextPart_001_01C78294.DE2EF082 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable rfc4004 errata - status?
Hi=20 Hannes,
 
To be=20 fair, I am not aiming at a working implementation either - at least not=20 now.
 
I'm=20 just incorporating it in order to inherit some attributes into another=20 specification.
 
These=20 were the things I needed to do to make it compile:
 
;;=20 Source: ftp://ftp.isi.edu/in-note= s/rfc4004.txt
;;
;;=20 - Corrected Session-ID to Session-Id in AA-Mobile-Node-Request
;; - = Commented=20 out MIP-HA-to-MN-SPI, MIP-MN-FA-SPI & MIP-MN-HA-SPI
;; - Changed=20 MIP-nonce to MIP-Nonce in MIP-MN-to-FA-MSA &
;;  =20 MIP-MN-to-HA-MSA
 
For my=20 purposes, it's perfectly ok to exclude the above AVPs, since I=20
don't=20 need them at this point.
 
BR,
Ulf=20 W
 

From: Tschofenig, Hannes=20 [mailto:hannes.tschofenig@nsn.com]
Sent: den 19 april 2007=20 17:00
To: Ulf Wiger (TN/EAB); = dime@ietf.org
Subject: AW:=20 [Dime] rfc4004 errata - status?

Hi Ulf,
 
so far our efforts have focused on=  the revision of the Diameter Base pro= tocol specification.=20
With the past two interop = events we did=20 a lot of Base protocol testing in order to get feedback from=20 implementers.
 
We haven't had a lot of feedback regarding = RFC 4004.=20 In fact, at the first interop we had =
no implementation available to test (if I = recall it=20 correctly) and at the second interop we had 2 companies supporting RFC = 4004.=20
 
Nevertheless, we are interested in = collecting bugs=20 for all Diameter specifications. I will create a roundup issue tracker = for=20 this document as well.
 
Ciao
Hannes
 
Von: Ulf Wiger (TN/EAB)=20 [mailto:ulf.wiger@ericsson.com]
Gesendet: Donnerstag, 19. = April=20 2007 16:18
An: dime@ietf.org
Betreff: [Dime] = rfc4004=20 errata - status?


Apologies, I'm a newcomer on this = list.=20

In the process of developing a = Diameter=20 framework, I've
come across = RFC4004. My=20 strategy is to generate code
for=20 encode/decode etc. by copying and pasting from the
spec into a text document, then parsing it and = generating
code. As a result, = errors in=20 the spec tend to lead to
compilation=20 error.

For RFC4004, I stumbled on the AVPs=20 MIP-MN-HA-SPI
and = MIP-HA-to-MN-SPI, which=20 are not defined. They are
mentioned in=20 the grouped AVPs MIP-MN-to-HA-MSA
and=20 MIP-HA-to-MN-MSA respectively.

After some googling, I found that = this had been=20 noticed, and
a post by Peter = McCann, 3=20 Jan 2007*, seemed to suggest
that I=20 should simply remove them. Is this a correct assumption?

* http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html= =20

BTW, while I'm at it, I might as well = contribute=20 another one for the
upcoming = rfc4004=20 errata:

Session-ID in the ABNF for = AA-Mobile-Node-Request=20 should be
Session-Id. While = the names of=20 messages and AVPs are really
of=20 informational nature, they are useful for mapping to structs, =
class names, etc., and these will be = case-sensitive in many
languages.=20

BR,
Ulf=20 Wiger
Ericsson AB=20

------_=_NextPart_001_01C78294.DE2EF082-- --===============0114063690== 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 --===============0114063690==-- From dime-bounces@ietf.org Thu Apr 19 11:16:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYNN-0004BR-HZ; Thu, 19 Apr 2007 11:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeY7Q-0006fv-SH for dime@ietf.org; Thu, 19 Apr 2007 11:00:20 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeY7Q-0000i4-56 for dime@ietf.org; Thu, 19 Apr 2007 11:00:20 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3JF0GGA011716; Thu, 19 Apr 2007 17:00:16 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l3JF0Gi5009102; Thu, 19 Apr 2007 17:00:16 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:00:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Dime] rfc4004 errata - status? Date: Thu, 19 Apr 2007 17:00:14 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A611FC@MCHP7R6A.ww002.siemens.net> In-Reply-To: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc4004 errata - status? Thread-Index: AceCjY8DCMjNGgOWS+OLf4WD9irzHgAAV9Jw From: "Tschofenig, Hannes" To: "Ulf Wiger \(TN/EAB\)" , X-OriginalArrivalTime: 19 Apr 2007 15:00:16.0287 (UTC) FILETIME=[70844AF0:01C78293] X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 X-Mailman-Approved-At: Thu, 19 Apr 2007 11:16:49 -0400 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="===============0225616466==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0225616466== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78293.6FF3924E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78293.6FF3924E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulf,=20 =20 so far our efforts have focused on the revision of the Diameter Base protocol specification.=20 With the past two interop events we did a lot of Base protocol testing in order to get feedback from implementers. =20 We haven't had a lot of feedback regarding RFC 4004. In fact, at the first interop we had=20 no implementation available to test (if I recall it correctly) and at the second interop we had 2 companies supporting RFC 4004.=20 =20 Nevertheless, we are interested in collecting bugs for all Diameter specifications. I will create a roundup issue tracker for this document as well.=20 =20 Ciao Hannes =20 ________________________________ Von: Ulf Wiger (TN/EAB) [mailto:ulf.wiger@ericsson.com]=20 Gesendet: Donnerstag, 19. April 2007 16:18 An: dime@ietf.org Betreff: [Dime] rfc4004 errata - status? =09 =09 =09 =09 Apologies, I'm a newcomer on this list.=20 In the process of developing a Diameter framework, I've=20 come across RFC4004. My strategy is to generate code=20 for encode/decode etc. by copying and pasting from the=20 spec into a text document, then parsing it and generating=20 code. As a result, errors in the spec tend to lead to=20 compilation error.=20 For RFC4004, I stumbled on the AVPs MIP-MN-HA-SPI=20 and MIP-HA-to-MN-SPI, which are not defined. They are=20 mentioned in the grouped AVPs MIP-MN-to-HA-MSA=20 and MIP-HA-to-MN-MSA respectively.=20 After some googling, I found that this had been noticed, and=20 a post by Peter McCann, 3 Jan 2007*, seemed to suggest=20 that I should simply remove them. Is this a correct assumption?=20 * http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html =20 BTW, while I'm at it, I might as well contribute another one for the=20 upcoming rfc4004 errata:=20 Session-ID in the ABNF for AA-Mobile-Node-Request should be=20 Session-Id. While the names of messages and AVPs are really=20 of informational nature, they are useful for mapping to structs, class names, etc., and these will be case-sensitive in many=20 languages.=20 BR,=20 Ulf Wiger=20 Ericsson AB=20 ------_=_NextPart_001_01C78293.6FF3924E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable rfc4004 errata - status?
Hi Ulf,
 
so far our efforts have focused on=  the revision of the Diameter Base pro= tocol specification.=20
With the past two interop = events we did a=20 lot of Base protocol testing in order to get feedback from=20 implementers.
 
We haven't had a lot of feedback regarding = RFC 4004. In=20 fact, at the first interop we had
no implementation available to test (if I = recall it=20 correctly) and at the second interop we had 2 companies supporting RFC = 4004.=20
 
Nevertheless, we are interested in collecting = bugs for=20 all Diameter specifications. I will create a roundup issue tracker for = this=20 document as well.
 
Ciao
Hannes
 
Von: Ulf Wiger (TN/EAB)=20 [mailto:ulf.wiger@ericsson.com]
Gesendet: Donnerstag, 19. = April=20 2007 16:18
An: dime@ietf.org
Betreff: [Dime] = rfc4004=20 errata - status?


Apologies, I'm a newcomer on this = list.

In the process of developing a Diameter = framework,=20 I've
come across RFC4004. My = strategy is to=20 generate code
for encode/decode = etc. by=20 copying and pasting from the
spec into a=20 text document, then parsing it and generating
code. As a result, errors in the spec tend to lead to =
compilation error.

For RFC4004, I stumbled on the AVPs=20 MIP-MN-HA-SPI
and = MIP-HA-to-MN-SPI, which=20 are not defined. They are
mentioned in the=20 grouped AVPs MIP-MN-to-HA-MSA
and=20 MIP-HA-to-MN-MSA respectively.

After some googling, I found that this = had been=20 noticed, and
a post by Peter = McCann, 3 Jan=20 2007*, seemed to suggest
that I = should=20 simply remove them. Is this a correct assumption?

* http://www1.ietf.org/mail-archive/web/dime/current/msg01149.html= =20

BTW, while I'm at it, I might as well = contribute=20 another one for the
upcoming = rfc4004=20 errata:

Session-ID in the ABNF for = AA-Mobile-Node-Request=20 should be
Session-Id. While the = names of=20 messages and AVPs are really
of = informational nature, they are useful for mapping to structs, =
class names, etc., and these will be = case-sensitive in=20 many
languages.

BR,
Ulf=20 Wiger
Ericsson AB=20

------_=_NextPart_001_01C78293.6FF3924E-- --===============0225616466== 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 --===============0225616466==-- From dime-bounces@ietf.org Thu Apr 19 11:34: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 1HeYeW-0000VD-MM; Thu, 19 Apr 2007 11:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYeV-0000V7-Pt for dime@ietf.org; Thu, 19 Apr 2007 11:34:31 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYeU-00020j-BV for dime@ietf.org; Thu, 19 Apr 2007 11:34:31 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8CE720944; Thu, 19 Apr 2007 17:34:29 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-8c-46278c055126 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9F6812050E; Thu, 19 Apr 2007 17:34:29 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:34:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] rfc4004 errata - status? Date: Thu, 19 Apr 2007 17:34:28 +0200 Message-ID: <6616D98C65DD514BA2E1DDC5F922315501AC4BDC@esealmw115.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] rfc4004 errata - status? Thread-Index: AceCjY8DCMjNGgOWS+OLf4WD9irzHgABqljAAAA8SNA= References: <6616D98C65DD514BA2E1DDC5F922315501AC4A63@esealmw115.eemea.ericsson.se> From: "Ulf Wiger \(TN/EAB\)" To: "McCann Peter-A001034" , X-OriginalArrivalTime: 19 Apr 2007 15:34:29.0599 (UTC) FILETIME=[3862D6F0:01C78298] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 McCann Peter-A001034 wrote: >=20 > I can see your point regarding Session-ID vs. Session-Id. > However, as you note this is an internal implementation=20 > matter and won't affect interoperability. I am not sure=20 > whether it warrants an errata. Perhaps not, if an errata is published for other reasons, one may perhaps note such things as well. (: In fact, generating code from specs is something I would like to recommend. I can build a dictionary from an=20 error-free specification in around 20 minutes. Alas, I=20 have yet to find an error-free specification... ;-) It helps a lot that all Diameter specs from IETF, 3GPP and TISPAN use the same kind of ABNF for messages and=20 grouped AVPs. AVP types listed in tables are not quite as easy to handle, as I end up with a number of different variants: - ASCII tables (partially) delimited by '|', and with occasional word wraps in the first column - PDF tables (empty columns collapsed into a single space, when copied into a text document) - Word tables (tabs between each column) A tool that parses the specs and reports on=20 inconsistencies would be quite useful. I will try to=20 keep adding specifications, and will of course pass on any errors found by my code generator. It would also be great to have some form of=20 recognizable markers surrounding formal descriptions.=20 Then, the spec could be parsed directly. (: BR, Ulf W _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Apr 19 19:26: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 1Heg1C-0002jm-J5; Thu, 19 Apr 2007 19:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heg1A-0002dL-Uc for dime@ietf.org; Thu, 19 Apr 2007 19:26:24 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heg1A-0001SU-Cc for dime@ietf.org; Thu, 19 Apr 2007 19:26:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3JNQDW7014242; Fri, 20 Apr 2007 02:26:21 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 02:26:19 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 18:26:17 -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] Limited flexibility with NAPTR queries Date: Thu, 19 Apr 2007 18:26:15 -0500 Message-ID: <071568CA7B789D4AA170CEF8C9613B4F7612C0@daebe103.NOE.Nokia.com> In-Reply-To: <46261EC7.8090602@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Limited flexibility with NAPTR queries Thread-Index: AceBvrxLFhSWvzk6RnenQqGmJP3BuwBGy6TA References: <033458F56EC2A64E8D2D7B759FA3E7E702DD86@sonusmail04.sonusnet.com> <46239734.8040301@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E702DFC6@sonusmail04.sonusnet.com> <46261EC7.8090602@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 19 Apr 2007 23:26:17.0233 (UTC) FILETIME=[210D0010:01C782DA] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, One of the reasons suggested to use NAPTR was to avoid using specific TLS ports, but to have a way to query which ports were secure, when trying to find a Diameter agent. This was based upon some IESG guidence. I don't believe that is needed any more, so I think it is fine to remove NAPTR from the base spec. Has anyone implemented it? John=20 >-----Original Message----- >From: ext Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 >Sent: 18 April, 2007 06:36 >To: Asveren, Tolga >Cc: dime@ietf.org >Subject: Re: [Dime] Limited flexibility with NAPTR queries > >Hi Tolga, > >> After having a quick look to the meeting minutes I saw that=20 >this issue=20 >> was touched as well. So, does anybody have some proposal or are we=20 >> going to rely on SLP? >> =20 > >The current idea is to remove SLP and NAPTR from the base=20 >document to simplify the bis; the base doc will rely on basic=20 >DNS and redirects. If other SDOs may see some usefulness in=20 >SLP and others, one idea is that it maybe up to them to=20 >define/redefine its use. Any thoughts on this approach ? > >regards, >victor > > >> Thanks, >> Tolga >> =20 >>> -----Original Message----- >>> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] >>> Sent: Monday, April 16, 2007 11:33 AM >>> To: Asveren, Tolga >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] Limited flexibility with NAPTR queries >>> >>> Hi Tolga, >>> >>> =20 >>>> Something, which is bothering me recently is the limited=20 >flexibility >>>> =20 >>> when using NAPTR service fields to locate Diameter servers. The >>> =20 >> current >> =20 >>> values placed in the registry allow to find *a* Diameter server in a >>> =20 >> given >> =20 >>> domain. It doesn't help much if one is looking for a server for a >>> =20 >> specific >> =20 >>> application in a given domain. This could work in environments where >>> =20 >> each >> =20 >>> domain (or better said each domain which envisions use of DNS to >>> =20 >> locate >> =20 >>> its servers) has a relay/redirect as the main contact point. >>> =20 >>>> My initial thoughts are: >>>> a) We can have registry entries for each Diameter=20 >application (could >>>> =20 >> be >> =20 >>> hard to manage ?) >>> =20 >>>> b) We can explain in the bis document that NAPTR query should >>>> =20 >> resolve to >> =20 >>> a relay/redirect for the domain, if the domain supports=20 >more than one=20 >>> Diameter application. >>> =20 >>> I would prefer option (b) for simplicity though I'm concerned about=20 >>> explain deployment considerations such as these in the base spec. It >>> =20 >> may >> =20 >>> open up the door for adding many more possible deployment scenarios=20 >>> within the base spec. It maybe possible to add this in the=20 >guidelines=20 >>> doc but I'm sure. >>> >>> regards, >>> victor >>> >>> regards, >>> victor >>> >>> >>> =20 >>>> Or am I missing something? >>>> >>>> Thanks, >>>> Tolga >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 21 08:52: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 1HfF4b-0000yC-Vs; Sat, 21 Apr 2007 08:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfF4a-0000xo-OO for dime@ietf.org; Sat, 21 Apr 2007 08:52:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfF4Z-0004tK-8e for dime@ietf.org; Sat, 21 Apr 2007 08:52:16 -0400 Received: (qmail invoked by alias); 21 Apr 2007 12:52:13 -0000 Received: from ip-90-187-161-22.web.vodafone.de (EHLO [90.187.161.22]) [90.187.161.22] by mail.gmx.net (mp032) with SMTP; 21 Apr 2007 14:52:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/fbBp1wE7fBDmNdb6g/qzG85HIN2TCdxWx3NgaDs 3JSDQC1RlmouXh Message-ID: <462A08FB.9020303@gmx.net> Date: Sat, 21 Apr 2007 14:52:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6HA-to-AAAHsupport References: <7CCD07160348804497EF29E9EA5560D7024D9D49$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D49$0001@exchtewks2.starentnetworks.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: a87a9cdae4ac5d3fbeee75cd0026d632 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 Kuntal, how can the IDr field be used for service selection? Ciao Hannes Chowdhury, Kuntal wrote: > Hi all, > > I would agree with a single Diameter application for both authentication > and authorization for MIP6 service with IKEv2/IPsec. > > In some scenarios, the IPsec gateway (e.g. 3GPP:PDG, 3GPP2:PDIF) may be > collocated with the Home Agent. To support such scenarios, there should > be a clear way to identify the type of service the MN is trying to > access i.e. it is trying to only establish an IPsec session with the > IPsec gateway or it wants to access MIPv6 service as well. The IDr field > in the IKEv2 exchange can be used for this type of service selection. > > So, I would suggest that MIPv6 Diameter application is used when such > (IPsec or IPsec+MIP6) indication is available at the Home Agent. > > Best regards, > Kuntal > > > >> -----Original Message----- >> From: Avi Lior [mailto:avi@bridgewatersystems.com] >> Sent: Wednesday, March 14, 2007 10:06 PM >> To: Hannes Tschofenig; dime@ietf.org >> Subject: RE: [Dime] Consensus Call regarding Diameter Mobile >> > IPv6HA-to- > >> AAAHsupport >> >> Yes. >> >> Authentication -- the EAP part and Authorization should happen in one >> Diameter Application. >> >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, March 14, 2007 5:22 PM >> To: dime@ietf.org >> Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 >> HA-to-AAAHsupport >> >> Hi all, >> >> with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" >> > document > >> (see >> http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) >> we defined a new Diameter application and we then decided that we >> > should > >> separate the authentication and authorization interaction to avoid an >> update of this specification when RFC 4072 is updated. This means that >> the Diameter MIPv6 app-ID is used for the authorization part and the >> Diameter EAP app-ID is used for the authentication part. Diameter >> routing may cause authentication and authorization messages to be >> > routed > >> to different servers. This caused a lengthy debate on security issues. >> It seems that there is a lot of complexity associated with this >> approach. >> >> I would therefore like to hear whether working group members are OK >> > with > >> performing authentication and authorization as part of one Diameter >> application. This would therefore mean that we are going to use the >> Diameter MIPv6 app-ID for authentication and for authorization. >> >> Please state your opinion. >> >> 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 >> > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 21 08:52: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 1HfF4k-00010J-80; Sat, 21 Apr 2007 08:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfF4j-00010E-4j for dime@ietf.org; Sat, 21 Apr 2007 08:52:25 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfF4h-0004vV-MQ for dime@ietf.org; Sat, 21 Apr 2007 08:52:25 -0400 Received: (qmail invoked by alias); 21 Apr 2007 12:52:22 -0000 Received: from ip-90-187-161-22.web.vodafone.de (EHLO [90.187.161.22]) [90.187.161.22] by mail.gmx.net (mp018) with SMTP; 21 Apr 2007 14:52:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19KTZl0HfFKiam2y2OxU8QjIIiSSK207OtIIkLmZ3 9Bo495uNtvh9qD Message-ID: <462A0905.9080609@gmx.net> Date: Sat, 21 Apr 2007 14:52:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Dime] MIP6 NAS-HAAA issue #1 References: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@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: e1e48a527f609d1be2bc8d8a70eb76cb 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, a grouped AVP is also OK for me. Ciao Hannes jouni.korhonen@teliasonera.com wrote: > About the issue #1 presented during the Dime WG meeting. If > the ASP/NAS needs to send or the MSA needs to return more than > one HA information the current AVP formulation does not work. > This is because we have defined AVP counts as "at most one". > Furthermore, if we are about to allow "zero or more" AVPs we > need to have a way to group HA address, FQDN, home link prefix > etc together. For that purpose a grouped AVP would be OK. > > So the question is (also related to the issue #2) whether > "zero or more" HAs must be supported. At least the recent > discussion in MIP6 list points to this direction. > > Anyway, my personal opinion is that defining a grouped AVP > does-no-harm anyway. Below is one proposal for a grouped AVP: > > MIP6-Info ::= < AVP Header: 297 > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > ... > > Any opinions? > > Cheers, > Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Apr 21 10:09: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 1HfGGv-0000ku-LI; Sat, 21 Apr 2007 10:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfGGu-0000eI-5A for dime@ietf.org; Sat, 21 Apr 2007 10:09:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfGGs-0005LH-NQ for dime@ietf.org; Sat, 21 Apr 2007 10:09:04 -0400 Received: (qmail invoked by alias); 21 Apr 2007 14:09:01 -0000 Received: from ip-90-187-254-168.web.vodafone.de (EHLO [90.187.254.168]) [90.187.254.168] by mail.gmx.net (mp039) with SMTP; 21 Apr 2007 16:09:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18k3EUNwAgk3CNbqS0Xs+LOSBc0Gpirhdk5FkoGXV mjkVFxQPzkvN/7 Message-ID: <462A1AFB.1070807@gmx.net> Date: Sat, 21 Apr 2007 16:08:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: akshi jain Subject: Re: [Dime] Parsing SDP message to diameter AVPs References: <76dadd3c0704150643h51888209qa2e6cb8602bb51ec@mail.gmail.com> In-Reply-To: <76dadd3c0704150643h51888209qa2e6cb8602bb51ec@mail.gmail.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: 7655788c23eb79e336f5f8ba8bce7906 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Akshi, I am not sure I understood your question. What exactly do you want todo? Is your question related to QoS handling? Ciao Hannes akshi jain wrote: > Can anyone give a method to Parse SDP message to diameter AVPs in an IMS > application? > > Regards > Akshi Jain > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing 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 Apr 23 02:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsBQ-0000pt-Dh; Mon, 23 Apr 2007 02:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfsBP-0000pe-9u for dime@ietf.org; Mon, 23 Apr 2007 02:37:55 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfsBM-0006Sn-O1 for dime@ietf.org; Mon, 23 Apr 2007 02:37:55 -0400 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 l3N6bjDT064079 for ; Mon, 23 Apr 2007 08:37:45 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] Parsing SDP message to diameter AVPs Date: Mon, 23 Apr 2007 08:37:45 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401305601@lulex02.ad.operax.com> In-Reply-To: <462A1AFB.1070807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Parsing SDP message to diameter AVPs Thread-Index: AceEHqn03yCUN4HNQk2evn/cpYmgqgBUoXBg 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, 23 Apr 2007 08:37:46 +0200 (CEST) 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.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3150/Mon Apr 23 06:33:18 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Akshi,=20 I may have misuderstood what you're aiming for, but if I understand correctly your question applies to the 3GPP and ETSI TISPAN rather than IETF Dime. Both these SDOs have defined Diameter applications allowing SIP proxies to request network services. In appendixes of the Gq and Gq' specification you'll find instructions for how to map SDP information to Diameter AVPs for this purpose (see http://www.3gpp.org/ftp/Specs/html-info/29209.htm for the Gq specification). =20 Rgs=20 Ulf=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: den 21 april 2007 16:09 To: akshi jain Cc: dime@ietf.org Subject: Re: [Dime] Parsing SDP message to diameter AVPs Hi Akshi, I am not sure I understood your question. What exactly do you want todo? Is your question related to QoS handling? Ciao Hannes akshi jain wrote: > Can anyone give a method to Parse SDP message to diameter AVPs in an=20 > IMS application? > > Regards > Akshi Jain > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 23 11:53: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 1Hg0qi-0004VL-57; Mon, 23 Apr 2007 11:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0qh-0004Sz-JL for dime@ietf.org; Mon, 23 Apr 2007 11:53:07 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0qg-0003Cc-Aw for dime@ietf.org; Mon, 23 Apr 2007 11:53:07 -0400 Received: by py-out-1112.google.com with SMTP id f31so1293489pyh for ; Mon, 23 Apr 2007 08:53:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=r8kmrkv/UkBVcYJX7kzpnldav2de4DpSPzHHp01jHXbGSC0LF0hbo7z8Dq951P0CvMPx6anHV9siuvFkNKBgl5qeh/Bp8X0p9hnMzUnK1tXo3jsyw6OS7X0GO5EGmo0cZBt6g6MBh22B+asJoXsCT2q7Ke7p7ln7+1DVKPLl/tI= 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:content-transfer-encoding:content-disposition:x-google-sender-auth; b=HIb5jtejL+/wF3rBCl2KwsftANILvzcHqJtM2keTQKay3mqqWqH15L7iHctqzQe6qbO7+R9MXsXMNggTQFg8fQRd7OktDmep5oYbaH6+QbOEGheSHlYSs8/Ey7U3gRnl6b1cBca28lUB0q5l5ehdB1mMq8wjLWLHcOMZpDsCtiQ= Received: by 10.64.241.3 with SMTP id o3mr12220461qbh.1177343585331; Mon, 23 Apr 2007 08:53:05 -0700 (PDT) Received: by 10.65.177.8 with HTTP; Mon, 23 Apr 2007 08:53:05 -0700 (PDT) Message-ID: <9b0e41640704230853i7394fff8k53ecbdac7a4a21e1@mail.gmail.com> Date: Mon, 23 Apr 2007 12:53:05 -0300 From: "Christian Esteve" To: dime@ietf.org Subject: Re: [Dime] Parsing SDP message to diameter AVPs MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 16119d81804310a8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Akshi, to my understanding what you are looking for is some kind of rules for derivation of service information within Diameter AVPs from SDP information. Look into 3GPP TS 29.208 to see how the P-CSCF performs the QoS (SDP) parameter mapping. You might also want to look into the policy control over Gq interface described in 3GPP TS 29.209 specs and the work being done for the Diameter ETSI TISPAN Rq and 3GPP Rx and Gx interfaces. Best regards, Christian > > Message: 3 > Date: Sat, 21 Apr 2007 16:08:59 +0200 > From: Hannes Tschofenig > Subject: Re: [Dime] Parsing SDP message to diameter AVPs > To: akshi jain > Cc: dime@ietf.org > Message-ID: <462A1AFB.1070807@gmx.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Akshi, > > I am not sure I understood your question. What exactly do you want todo? > Is your question related to QoS handling? > > Ciao > Hannes > > akshi jain wrote: > > Can anyone give a method to Parse SDP message to diameter AVPs in an IMS > > application? > > > > Regards > > Akshi Jain > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > End of DiME Digest, Vol 16, Issue 14 > ************************************ > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 23 14:58:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3jv-0001uw-2s; Mon, 23 Apr 2007 14:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3jt-0001uq-HH for dime@ietf.org; Mon, 23 Apr 2007 14:58:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg3js-0006lg-Sp for dime@ietf.org; Mon, 23 Apr 2007 14:58:17 -0400 Received: (qmail invoked by alias); 23 Apr 2007 18:58:15 -0000 Received: from p54986402.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.100.2] by mail.gmx.net (mp046) with SMTP; 23 Apr 2007 20:58:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19PROVpko1PsJOI7lVQqgGfhPO3c8Im97J+P+7vYn YqaGPluxHjxsR2 Message-ID: <462D01C7.4010409@gmx.net> Date: Mon, 23 Apr 2007 20:58:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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: a92270ba83d7ead10c5001bb42ec3221 Subject: [Dime] [Fwd: Review of QoS approach] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, Avi did a review of the QoS documents and he sent it to me privately. With his permission I forward them to the DIME mailing list. Ciao Hannes -------- Original Message -------- Subject: Review of QoS approach Date: Thu, 22 Mar 2007 00:33:59 -0400 From: Avi Lior To: Hannes Tschofenig References: <45EE9907.8030900@gmx.net> The approach being taken with respect to QoS in Dime is to define three QoS related documents: The first document is the an Diameter QoS application. http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 It is a Diameter Application which defines 4 Commands and reuses a handfull of base commands. It defines 6 QoS specific attributes. It uses numerous base attributes and attributes from Credit Control Of particular interes is ExtendedQoSFilterRule attribute is encoded as an OctetString. It is a combination of the QoSFilterRule and IPFilterRule of the base and some new classifiers: flos-label, ipsec-spi Quick question about this attribute: Action as stated comes from DIABASE which is allow/deny. That doesnt make sense for this a qos attribute. IMO if you are going to be using this style of attribute (and there is other ways) then action should be the qos-id that will be used if the classifier matches. Also the ExtendedQoSFilterRule calls out "options" but doesnt define them: Are they: TCP flags IP fragment flag IP options ICMP types The QSPEC is defined by another document: I-D.korhonen-dime-qos-parameters, it is used in the Diameter Application via containment in the QoS-Parameter AVP which binds the qos parameters to a QoS-ID. In the PARAMETERS draft we define a number of QoS Parameters which have their own format. They dont match RADIUS or DIAMETER AVP encoding and are meant to be opaque to RADIUS and DIAMETER. The QoS-Parameter attribute is not required to have QOSSPEC as defined in the PARAMETERS document. THis is a good thing because as we have seen many SDO want to define their own SDO specific attributes or QoS blob. The disadvantage of the PARAMETERS is that they define a new attribute encoding style. And then there is the draft-korhonen-dime-qos-attributes-00.txt work. Which basically takes the QoS attributes defined in the QoS application and defines that outside that application so that they can be carried inside the EAP message. I think if we are going to use this approach wouldnt we take the QoS attributes out of the Diameter QoS Application so you only have it documented in one place? I like the approach of definig attributes outside a diameter applications and then defining the an application and commands as a seperate document. But that is not really necessary as long as we understand that we can use the attributes defined by one diameter application in another diameter application. I think the real advantage is that we can define the QoS Attributes much faster then we can agree on how an application using those attribute would really work. But then again, the excercise of defining the application helps us get the attributes correct. Hmmmmmmmmm..... But on the flip side, people are defining the QoS attributes into their own SDO specific applications. So seperation is a good thing. As you know I dont like the idea of using "string" type of encoding for the classifier part. It would be good to get rid of that. We can put it in the QoS Attribute. I guess we can allow for both methods. I would like to work on that with you guys if there is support. WRT to RADIUS work the classifier did change to allow support for filtering on either IP or Layer 2. "The filtering attributes specified in this document enable description of layer 2 and layer 3 filters as well as redirection, and therefore extend the filter language described in [RFC3588]. The attributes defined in this document may be used with RADIUS dynamic authorization [RFC3576]. " One thing that maybe omitted by Diameter work is setting up QoS for L2 (Ethernet-CS). Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183 ------------------------------------------------------------------------ *From:* Hannes Tschofenig *Sent:* Wed 3/7/2007 5:50 AM *To:* dime@ietf.org *Subject:* [Dime] Updated QoS Drafts Hi all, new versions of the QoS documents are available as you have seen from the draft announcements. I would like to clarify the relationship between the documents: http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 This document describes the Diameter QoS application. http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt This document contains QoS parameters taken from an NSIS working group document and placed into a separate document. We did this to (a) improve readability, (b) remove functionality that is not needed for the Diameter action and to (c) at the same time leverage existing work. Currently we assume that the same registry is used. The final decision depends on the policy for adding new parameters to the registry. These QoS parameters are utilized by , by and by corresponding RADIUS documents. http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt This document defines the Extended-QoS-Filter-Rule in the spirit of the QoS-Filter-Rule. Unlike the document it addresses scenarios where the updated QoS-Filter-Rule attribute is carried within other applications. It therefore only addresses a limited set of scenarios. One could compare the approach with the mobility documents. This document also assumes that an extended version of the IPFilterRule attribute is available. Currently, the required extensions are described in and "imported" into this document. There is ongoing work in the RADEXT working group to define a more powerful version of the IPFilterRule / NAS-Traffic-Rule, see http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt We obviously need to align our work with the RADEXT working group with regard to this aspect since the newly defined attribute will be made available as described in the Diameter Compatibility section of . http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01 This document takes a different spin and extends the document by supporting a "generic push" approach. By "generic push" I refer to the ability of an arbitrary entity, such as an SIP proxy, to signal to another box. Note that this is not the same as the server-initiated communication. 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 Apr 23 18:16: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 1Hg6q9-0008Nx-6i; Mon, 23 Apr 2007 18:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6q8-0008KZ-54 for dime@ietf.org; Mon, 23 Apr 2007 18:16:56 -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 1Hg6q7-00053p-R8 for dime@ietf.org; Mon, 23 Apr 2007 18:16:56 -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 l3NMGWl0026052; Mon, 23 Apr 2007 18:16:32 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <462D3068.8060303@tari.toshiba.com> Date: Mon, 23 Apr 2007 18:17:12 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: David Frascone Subject: Re: [Dime] Diameter Application Design Guide (please read) References: <46262B98.5020903@frascone.com> In-Reply-To: <46262B98.5020903@frascone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, I've updated the document. The new draft is: http://tools.ietf.org/wg/dime/draft-fajardo-dime-app-design-guide-02.txt regards, victor > At the IETF#68 DIME meeting, we did a "hum" to show support for the > "Diameter Application Design Guide" document > http://tools.ietf.org/html/draft-fajardo-dime-app-design-guide-00 > > Comments were incorporated. We are now proposing that the new draft: > http://tools.ietf.org/wg/dime/draft-fajardo-dime-app-design-guide-01.txt > to become a WG item. > > A number of people have read the document and support it. Nobody has > objected. > > We would like to confirm the decision on the mailing list. > > Does anyone in the WG object? > > Deadline for responding: 28th April 2007 > > -Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 27 14:50: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 1HhVWf-0006o3-C3; Fri, 27 Apr 2007 14:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVWe-0006nt-LX for dime@ietf.org; Fri, 27 Apr 2007 14:50:36 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhVWe-0004RZ-CL for dime@ietf.org; Fri, 27 Apr 2007 14:50:36 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH6004EO70BZF@usaga01-in.huawei.com> for dime@ietf.org; Fri, 27 Apr 2007 11:50:36 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH6006U77075U@usaga01-in.huawei.com> for dime@ietf.org; Fri, 27 Apr 2007 11:50:35 -0700 (PDT) Date: Fri, 27 Apr 2007 11:50:36 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 In-reply-to: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> To: jouni.korhonen@teliasonera.com, dime@ietf.org Message-id: <004801c788fc$f1a53260$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJAcfP2bw X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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, I have no problem with the general idea of grouped AVP, only a few notes regarding the construct: 1) calling the AVP MIP6-Info may be a bit problematic, basically you are putting the entire MIP6 application info into one grouped AVP? Will we then be able to define this group AVP in a way that any possible AVP people come up with to support MIP6 can easily be integrated in this AVP? If yes, then no problem. Right now, I can have an idea about a couple of things that can be MIP6-info related AVPs and are not shown below. Just call it MIP6_HA_info (leave HOA out of it, IMO) or call it MIP6_ADDR_info and leave HOA in. 2) Not debating whether or not we should send multiple HA info together, The suggested construct does not show how many HAs there are in the AVP. I would guess you would need something to indicate that. Hope this helps, Madjid -----Original Message----- From: jouni.korhonen@teliasonera.com [mailto:jouni.korhonen@teliasonera.com] Sent: Thursday, March 22, 2007 5:38 AM To: dime@ietf.org Subject: [Dime] MIP6 NAS-HAAA issue #1 About the issue #1 presented during the Dime WG meeting. If the ASP/NAS needs to send or the MSA needs to return more than one HA information the current AVP formulation does not work. This is because we have defined AVP counts as "at most one". Furthermore, if we are about to allow "zero or more" AVPs we need to have a way to group HA address, FQDN, home link prefix etc together. For that purpose a grouped AVP would be OK. So the question is (also related to the issue #2) whether "zero or more" HAs must be supported. At least the recent discussion in MIP6 list points to this direction. Anyway, my personal opinion is that defining a grouped AVP does-no-harm anyway. Below is one proposal for a grouped AVP: MIP6-Info ::= < AVP Header: 297 > [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] [ MIP6-Home-Link-Prefix ] [ MIP6-Home-Address ] ... Any opinions? Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Apr 27 16:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXGF-0002We-RD; Fri, 27 Apr 2007 16:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXGE-0002Pt-Nq for dime@ietf.org; Fri, 27 Apr 2007 16:41:46 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXGE-0003wE-7l for dime@ietf.org; Fri, 27 Apr 2007 16:41:46 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 22:41:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 Date: Fri, 27 Apr 2007 22:41:43 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301D80C6A@SEHAN021MB.tcad.telia.se> In-Reply-To: <004801c788fc$f1a53260$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] MIP6 NAS-HAAA issue #1 Thread-Index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJAcfP2bwAANYWzA= References: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> <004801c788fc$f1a53260$2f01a8c0@china.huawei.com> From: To: , X-OriginalArrivalTime: 27 Apr 2007 20:41:44.0847 (UTC) FILETIME=[77F471F0:01C7890C] X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Madjid,=20 > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Sent: 27. huhtikuuta 2007 21:51 > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 >=20 > Hi Jouni, >=20 > I have no problem with the general idea of grouped AVP, only=20 > a few notes regarding the construct: Good. > 1) calling the AVP MIP6-Info may be a bit problematic,=20 > basically you are putting the entire MIP6 application info=20 > into one grouped AVP? Will we then be able to define this=20 > group AVP in a way that any possible AVP people come up with=20 > to support MIP6 can easily be integrated in this AVP? If yes,=20 > then no problem.=20 Right.. if extending the MIP6-Info is desired we could define it as: MIP6-Info ::=3D < AVP Header: xyz > [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] [ MIP6-Home-Link-Prefix ] [ MIP6-Home-Address ] *[ AVP ] > Right now, I can have an idea about a couple of things that=20 > can be MIP6-info related AVPs and are not shown below. Just=20 > call it MIP6_HA_info (leave HOA out of it, IMO) or call it=20 > MIP6_ADDR_info and leave HOA in. There is definitely a lot of stuff that could be put in.. e.g. in a case when the NAS is co-located with MAG. I am open to extend the coverage but I am not sure if it is in scope of the ID. > 2) Not debating whether or not we should send multiple HA=20 > info together, The suggested construct does not show how many=20 > HAs there are in the AVP. I would guess you would need=20 > something to indicate that. It is always at most one HA per grouped AVP. If more HAs are needed, the message just needs to include multiple grouped MIP6-Info AVPs. >=20 > Hope this helps, Cheers, Jouni >=20 > Madjid >=20 > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com] >=20 > Sent: Thursday, March 22, 2007 5:38 AM > To: dime@ietf.org > Subject: [Dime] MIP6 NAS-HAAA issue #1 >=20 >=20 > About the issue #1 presented during the Dime WG meeting. If=20 > the ASP/NAS needs to send or the MSA needs to return more=20 > than one HA information the current AVP formulation does not work. > This is because we have defined AVP counts as "at most one". > Furthermore, if we are about to allow "zero or more" AVPs we=20 > need to have a way to group HA address, FQDN, home link=20 > prefix etc together. For that purpose a grouped AVP would be OK. >=20 > So the question is (also related to the issue #2) whether=20 > "zero or more" HAs must be supported. At least the recent=20 > discussion in MIP6 list points to this direction. >=20 > Anyway, my personal opinion is that defining a grouped AVP=20 > does-no-harm anyway. Below is one proposal for a grouped AVP: >=20 > MIP6-Info ::=3D < AVP Header: 297 > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > ... >=20 > Any opinions? >=20 > Cheers, > Jouni >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 30 10:50: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 1HiXCX-00079C-Qf; Mon, 30 Apr 2007 10:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXCW-000797-Ll for dime@ietf.org; Mon, 30 Apr 2007 10:50:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXCV-0002kn-NI for dime@ietf.org; Mon, 30 Apr 2007 10:50:04 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B55A20178 for ; Mon, 30 Apr 2007 16:50:03 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-25-4636021bdc44 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0B73420070 for ; Mon, 30 Apr 2007 16:50:03 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 16:50:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 16:50:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about draft-ietf-dime-rfc3588bis-03.txt in relationship to DCC (RFC4006) Thread-Index: AceLNtT1HqcDETCiTCGTs4hJ21HFDg== From: =?iso-8859-1?Q?Mats_J=F6rsmo_=28KA/EAB=29?= To: X-OriginalArrivalTime: 30 Apr 2007 14:50:02.0960 (UTC) FILETIME=[D57D4500:01C78B36] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt in relationship to DCC (RFC4006) X-BeenThere: dime@ietf.org X-Mailman-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="===============1618004226==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1618004226== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78B36.D54166CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78B36.D54166CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Would appreciate some advice for a newbie in this area regarding chapter = 7.1.5 (draft-ietf-dime-rfc3588bis-03.tx) http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-03#page-94 .....'In error conditions where it is not possible or efficient to = compose application specific answer grammar=20 then answer messages with E-bit set and complying to the grammar = described in 7.2 MAY also be used=20 for permanent errors.=20 To provide backward compatibility with existing implementations that = follow [RFC3588],=20 some of the error values that have previously been used in this category = by [RFC3588] will not be re-used. =20 Therefore the error values enumerated here maybe non-sequential.' Does this mean that using the E-bit is applicable only for future = error-codes to come or also for existing ones?=20 Reason for asking is we would like to avoid the dummy values in the = following scenario and instead use E-bit described in chapter 7.2 = (draft-ietf-dime-rfc3588bis-03.tx) If a CCR is received in the DCC server where one or several of the = mandatory AVPs Auth-Application-Id, CC-Request-Type and = CC-Request-Number are missing;=20 In the CCA, Auth-Application-Id, CC-Request-Type and CC-Request-Number = are filled with 'dummyvalues' and the the Failed-AVP AVP is included and = filled with Auth-Application-Id, CC-Request-Type and CC-Request-Number = where these AVPs are set to 'zero' Example: Credit-Control-Answer Session-Id =3D 123 Result-Code =3D 5005 Origin-Host =3D hostname Origin-Realm =3D realm Auth-Application-Id =3D 4 // Dummyvalue, we're only serving DCC CC-Request-Type =3D 4 // Dummyvalue, TERMINATION_REQUEST CC-Request-Number =3D 0 // Dummyvalue,=20 Failed-AVP { Auth-Application-Id =3D 0 // Zero CC-Request-Type =3D 0 // Zero, violates AVP definition of = CC-Request-Type=20 CC-Request-Number =3D 0 // Zero Regards, ///Mats J=20 ------_=_NextPart_001_01C78B36.D54166CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question about draft-ietf-dime-rfc3588bis-03.txt in relationship = to DCC (RFC4006)

Hi,

Would appreciate some advice for a = newbie in this area regarding chapter 7.1.5 = (draft-ietf-dime-rfc3588bis-03.tx)
http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-03#p= age-94

.....'In error conditions where it is = not possible or efficient to compose application specific answer grammar =
then answer messages with E-bit set = and complying to the grammar described in 7.2 MAY also be used
for  permanent errors.

To provide backward compatibility with = existing implementations that follow [RFC3588],
some of the error values that have = previously been used in this category by [RFC3588] will not be = re-used. 
Therefore the error values enumerated = here maybe non-sequential.'


Does this mean that using the E-bit is = applicable only for future error-codes to come or also for existing = ones?


Reason for asking is we would like to = avoid the dummy values in the following scenario and instead use E-bit = described in chapter 7.2 (draft-ietf-dime-rfc3588bis-03.tx)

If a CCR is received in the DCC server = where one or several of the mandatory AVPs = Auth-Application-Id, CC-Request-Type and = CC-Request-Number are missing;

      In the CCA, Auth-Application-Id, CC-Request-Type = and CC-Request-Number are filled with 'dummyvalues' and the the Failed-AVP AVP = is included and filled with Auth-Application-Id, CC-Request-Type = and CC-Request-Number where these AVPs are set to 'zero'

      Example:

      Credit-Control-Answer
              Session-Id =3D 123
              Result-Code =3D 5005
              Origin-Host =3D hostname
              Origin-Realm =3D realm
              Auth-Application-Id =3D 4 // Dummyvalue, we're only serving = DCC
              CC-Request-Type =3D 4     // Dummyvalue, = TERMINATION_REQUEST
              CC-Request-Number =3D 0   // Dummyvalue,
              Failed-AVP {
              =         Auth-Application-Id =3D 0 // Zero
              =         CC-Request-Type =3D 0     // Zero, violates AVP = definition of CC-Request-Type
              =         CC-Request-Number =3D 0   // Zero


Regards,
///Mats J




------_=_NextPart_001_01C78B36.D54166CC-- --===============1618004226== 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 --===============1618004226==-- From dime-bounces@ietf.org Mon Apr 30 11:11: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 1HiXX7-00029O-V0; Mon, 30 Apr 2007 11:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXX7-00029I-Dj for dime@ietf.org; Mon, 30 Apr 2007 11:11:21 -0400 Received: from sonussf1.sonusnet.com ([208.45.178.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXX7-0006ub-2w for dime@ietf.org; Mon, 30 Apr 2007 11:11:21 -0400 Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonussf1.sonusnet.com (8.13.7/8.13.7) with ESMTP id l3UFBK4d001061 for ; Mon, 30 Apr 2007 11:11:20 -0400 Received: from sonusmail04.sonusnet.com ([10.128.35.98]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 11:11:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt inrelationship to DCC (RFC4006) Date: Mon, 30 Apr 2007 11:11:19 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DFFF@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt inrelationship to DCC (RFC4006) Thread-Index: AceLNtT1HqcDETCiTCGTs4hJ21HFDgAAnAWw References: From: "Asveren, Tolga" To: X-OriginalArrivalTime: 30 Apr 2007 15:11:20.0238 (UTC) FILETIME=[CECE6CE0:01C78B39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Mats, AFAICR, in the text you quoted, first and second paragraph are referring = to different changes. I think the second one is there because the = failure category for certain error cases has changed in the bis. You should be able to use E-bit for error codes in permanent failures = category (in addition to what was already allowed in RFC3588). Thanks, Tolga ________________________________________ From: Mats J=F6rsmo (KA/EAB) [mailto:mats.jorsmo@ericsson.com]=20 Sent: Monday, April 30, 2007 10:50 AM To: dime@ietf.org Subject: [Dime] Question about draft-ietf-dime-rfc3588bis-03.txt = inrelationship to DCC (RFC4006) Hi,=20 Would appreciate some advice for a newbie in this area regarding chapter = 7.1.5 (draft-ietf-dime-rfc3588bis-03.tx)=20 http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-03#page-94=20 .....'In error conditions where it is not possible or efficient to = compose application specific answer grammar=20 then answer messages with E-bit set and complying to the grammar = described in 7.2 MAY also be used=20 for=A0 permanent errors.=20 To provide backward compatibility with existing implementations that = follow [RFC3588],=20 some of the error values that have previously been used in this category = by [RFC3588] will not be re-used.=A0=20 Therefore the error values enumerated here maybe non-sequential.'=20 Does this mean that using the E-bit is applicable only for future = error-codes to come or also for existing ones?=20 Reason for asking is we would like to avoid the dummy values in the = following scenario and instead use E-bit described in chapter 7.2 = (draft-ietf-dime-rfc3588bis-03.tx) If a CCR is received in the DCC server where one or several of the = mandatory AVPs Auth-Application-Id, CC-Request-Type and = CC-Request-Number are missing;=20 In the CCA, Auth-Application-Id, CC-Request-Type and CC-Request-Number = are filled with 'dummyvalues' and the the Failed-AVP AVP is included and = filled with Auth-Application-Id, CC-Request-Type and CC-Request-Number = where these AVPs are set to 'zero' Example:=20 Credit-Control-Answer=20 =A0=A0=A0=A0=A0=A0=A0 Session-Id =3D 123 =A0=A0=A0=A0=A0=A0=A0 Result-Code =3D 5005 =A0=A0=A0=A0=A0=A0=A0 Origin-Host =3D hostname =A0=A0=A0=A0=A0=A0=A0 Origin-Realm =3D realm =A0=A0=A0=A0=A0=A0=A0 Auth-Application-Id =3D 4 // Dummyvalue, we're = only serving DCC =A0=A0=A0=A0=A0=A0=A0 CC-Request-Type =3D 4=A0=A0=A0=A0 // Dummyvalue, = TERMINATION_REQUEST =A0=A0=A0=A0=A0=A0=A0 CC-Request-Number =3D 0=A0=A0 // Dummyvalue,=20 =A0=A0=A0=A0=A0=A0=A0 Failed-AVP {=20 =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Auth-Application-Id =3D 0 // = Zero =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 CC-Request-Type =3D = 0=A0=A0=A0=A0 // Zero, violates AVP definition of CC-Request-Type =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 CC-Request-Number =3D = 0=A0=A0 // Zero=20 Regards,=20 ///Mats J=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 30 15:14: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 1HibK4-0008R9-2D; Mon, 30 Apr 2007 15:14:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibK3-0008Qy-HF for dime@ietf.org; Mon, 30 Apr 2007 15:14:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HibK3-000682-4C for dime@ietf.org; Mon, 30 Apr 2007 15:14:07 -0400 Received: (qmail invoked by alias); 30 Apr 2007 19:14:05 -0000 Received: from p54986906.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.105.6] by mail.gmx.net (mp047) with SMTP; 30 Apr 2007 21:14:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/m0Gp0wDHm4AjtnC0zb+eNiEKVSjfTrIuZU3fQxb cVUHQfySWYwwuv Message-ID: <46363FFD.9040702@gmx.net> Date: Mon, 30 Apr 2007 21:14:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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: 92df29fa99cf13e554b84c8374345c17 Subject: [Dime] [Fwd: Diameter QoS: Feedback] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, Michael Montemurro reviewed the QoS draft. See message below. Thank you Mike. Ciao Hannes -------- Original Message -------- Subject: Re: Diameter QoS: Feedback Needed Date: Fri, 27 Apr 2007 12:19:59 -0400 From: Michael Montemurro To: Tschofenig, Hannes CC: Tschofenig, Hannes References: <8F6CBC7005099442AECDB784C9E9D7E701A61662@MCHP7R6A.ww002.siemens.net> Hannes, I read through draft-ietf-dime-diameter-qos-00 and evaluated it in the context of WLAN and here is my analysis. Overall I think it maps well to what is included for admission control in IEEE 802.11. - The draft maps well to the IEEE 802.11e admission control mechansisms, which allows a WLAN device to request a flow via a TSPEC. I haven't looked at it in detail, but the QSPEC maps to a subset of the TSPEC specification in IEEE 802.11e. - QoS-Reserve/Response messages map to ADDTS-Request/Response messages in 11e. There is an additional DELTS in IEEE 802.11e which could be send from the AP, if signaled by the QoS Authorization server. - Internally to the AP or WLAN controller, the scheduler would have to be tied into the Diameter Client in the WLAN infrastructure. - In IEEE 802.11e the ADDTS includes a Traffic Specification which includes TSPEC IE's. In the response, the Access Point/infrastructure can suggest a TSPEC that it will admit if it does not like the request. For example, the device may ask for a G.711 TSPEC, but the AP with a G.729 TSPEC. - The server-side can preempt a QoS stream by sending a DELTS as triggered by a QoS authorization message from the Authrizing entity. - IEEE 802.11 QoS restricts a device to one QoS flow per user priority (there are 8 user priorities). A STA can update an existing flow dependent using another QoS request (ADDTS). The server would have to interpret this as overwriting its existing QoS flow. - The WLAN AP also will make a decision to admit a QoS flow depending on its load (number of other flows, number of clients, medium time available, etc.). This probably is out of scope of this protocol, but >from a system perspective, there could be a case where the flow is authorized, but the AP cannot admit the flow. - When a device roams from one AP to another, it re-issues its QoS requests for any active flows. I believe the protocol is capable of handling the case where the Authorization Server gets a request from the device on a new network element. In a standalone AP case, this could happen. In a case where there is a WLAN controller, I would expect that this behaviour would be hidden from the QoS Authorization server. Cheers, Mike _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Apr 30 15:52: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 1Hibul-0007Op-6x; Mon, 30 Apr 2007 15:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibuj-0007Mu-4e for dime@ietf.org; Mon, 30 Apr 2007 15:52:01 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hibuh-0004E0-Nh for dime@ietf.org; Mon, 30 Apr 2007 15:52:01 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHB00ANATUM1Y@usaga01-in.huawei.com> for dime@ietf.org; Mon, 30 Apr 2007 12:51:58 -0700 (PDT) Received: from N737011 (pool-71-112-139-16.sttlwa.dsl-w.verizon.net [71.112.139.16]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHB002F2TUHWD@usaga01-in.huawei.com> for dime@ietf.org; Mon, 30 Apr 2007 12:51:58 -0700 (PDT) Date: Mon, 30 Apr 2007 12:51:58 -0700 From: Madjid Nakhjiri Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 In-reply-to: <59D7431DE2527D4CB0F1EFEDA5683ED301D80C6A@SEHAN021MB.tcad.telia.se> To: jouni.korhonen@teliasonera.com, dime@ietf.org Message-id: <000d01c78b61$03ce9fb0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJAcfP2bwAANYWzAAlaJykA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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, It is ok to extend the grouped AVP with *[AVP], I guess, but my point was since we will have a Diameter Mobile IPv6 application (at least for split case), it is easier to call the attribute what it is: MIP6_Addresses without expanding its scope rather than including everything that is related to that application into one AVP. I may need to send Mobile IP6 attributes in an uplink message TO the server, then what? As you said your ID scope is confined and you don't want to and should not deal with all future Mobile IP6 related attributes that may be defined later. As far as multiple HA and multiple grouped AVPs, I guess that is fine. Is there a need to indicate how many HA s are included in the message and whether there is a preference on which one to pick? R, Madjid -----Original Message----- From: jouni.korhonen@teliasonera.com [mailto:jouni.korhonen@teliasonera.com] Sent: Friday, April 27, 2007 1:42 PM To: mnakhjiri@huawei.com; dime@ietf.org Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 Hi Madjid, > -----Original Message----- > From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com] > Sent: 27. huhtikuuta 2007 21:51 > To: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org > Subject: RE: [Dime] MIP6 NAS-HAAA issue #1 > > Hi Jouni, > > I have no problem with the general idea of grouped AVP, only > a few notes regarding the construct: Good. > 1) calling the AVP MIP6-Info may be a bit problematic, > basically you are putting the entire MIP6 application info > into one grouped AVP? Will we then be able to define this > group AVP in a way that any possible AVP people come up with > to support MIP6 can easily be integrated in this AVP? If yes, > then no problem. Right.. if extending the MIP6-Info is desired we could define it as: MIP6-Info ::= < AVP Header: xyz > [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] [ MIP6-Home-Link-Prefix ] [ MIP6-Home-Address ] *[ AVP ] > Right now, I can have an idea about a couple of things that > can be MIP6-info related AVPs and are not shown below. Just > call it MIP6_HA_info (leave HOA out of it, IMO) or call it > MIP6_ADDR_info and leave HOA in. There is definitely a lot of stuff that could be put in.. e.g. in a case when the NAS is co-located with MAG. I am open to extend the coverage but I am not sure if it is in scope of the ID. > 2) Not debating whether or not we should send multiple HA > info together, The suggested construct does not show how many > HAs there are in the AVP. I would guess you would need > something to indicate that. It is always at most one HA per grouped AVP. If more HAs are needed, the message just needs to include multiple grouped MIP6-Info AVPs. > > Hope this helps, Cheers, Jouni > > Madjid > > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Thursday, March 22, 2007 5:38 AM > To: dime@ietf.org > Subject: [Dime] MIP6 NAS-HAAA issue #1 > > > About the issue #1 presented during the Dime WG meeting. If > the ASP/NAS needs to send or the MSA needs to return more > than one HA information the current AVP formulation does not work. > This is because we have defined AVP counts as "at most one". > Furthermore, if we are about to allow "zero or more" AVPs we > need to have a way to group HA address, FQDN, home link > prefix etc together. For that purpose a grouped AVP would be OK. > > So the question is (also related to the issue #2) whether > "zero or more" HAs must be supported. At least the recent > discussion in MIP6 list points to this direction. > > Anyway, my personal opinion is that defining a grouped AVP > does-no-harm anyway. Below is one proposal for a grouped AVP: > > MIP6-Info ::= < AVP Header: 297 > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > ... > > Any opinions? > > Cheers, > Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime