From dime-bounces@ietf.org Tue Jun 3 05:45:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86C928C0E2; Tue, 3 Jun 2008 05:45:13 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5BCA63A6967; Tue, 3 Jun 2008 05:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080603124501.5BCA63A6967@core3.amsl.com> Date: Tue, 3 Jun 2008 05:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-09.txt Pages : 36 Date : 2008-06-03 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-mip6-split-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-03053452.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Jun 3 08:38:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A143D3A6B05; Tue, 3 Jun 2008 08:38:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408EB3A6959 for ; Tue, 3 Jun 2008 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5KPyRlD7gU8 for ; Tue, 3 Jun 2008 08:38:25 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.177]) by core3.amsl.com (Postfix) with ESMTP id 5110A3A6B05 for ; Tue, 3 Jun 2008 08:38:25 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id n30so56116elf.14 for ; Tue, 03 Jun 2008 08:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=w24u/+FaNJWAM7CfMfKfortDgKzARVyiArt3lHBBk2U=; b=jOtsSAallI9xhgBJIDE8p4VNa7/b60D0xIWjpTIKUrxQjTGBdCZQUq7+63I8/T/U7cVQZoTj+wJJkBLlpJ89rFIS+rruseTFlclPSN0F+nOJIDgSdLgsaHMc6pFUZhhvLrSEt3qB+nuRgaUbyDSh7ANRjvvB6PBTcSlW8s+k+TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=uXJGRs7JH+a0QBUuKRTKh3kgIZWZip+TNw8wH0PZNgbxEeRz5tOdcz9EhZ/Kgygu6NXlqT2xW9M1ye0zDOEcI2bqJPUXKsvKPglulvQbbkLTMKv51ueVLNzAYMwk7o2+N4JZ9Qz77kgXafP9bhgi/BQDWP+Qn18NvaIHdATyByU= Received: by 10.114.39.16 with SMTP id m16mr5985296wam.98.1212507504839; Tue, 03 Jun 2008 08:38:24 -0700 (PDT) Received: by 10.114.102.6 with HTTP; Tue, 3 Jun 2008 08:38:24 -0700 (PDT) Message-ID: Date: Tue, 3 Jun 2008 21:08:24 +0530 From: "Venu K" To: dime@ietf.org MIME-Version: 1.0 Subject: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0494925004==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0494925004== Content-Type: multipart/alternative; boundary="----=_Part_1940_18225686.1212507504831" ------=_Part_1940_18225686.1212507504831 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi , If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B in cases where client A is not reachable/down. Assuming Client B knows about session and hostidentifiers of client A. Regards, Venu ------=_Part_1940_18225686.1212507504831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi ,

If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B  in cases where client A is not reachable/down.
Assuming Client B knows about session and hostidentifiers of client A.

Regards,
Venu
------=_Part_1940_18225686.1212507504831-- --===============0494925004== 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://www.ietf.org/mailman/listinfo/dime --===============0494925004==-- From dime-bounces@ietf.org Wed Jun 4 05:35:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2BF28C269; Wed, 4 Jun 2008 05:35:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F198928C264 for ; Wed, 4 Jun 2008 05:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9bJXfYe9s8Y for ; Wed, 4 Jun 2008 05:35:12 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 4E5A33A6CFA for ; Wed, 4 Jun 2008 05:31:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1212582672!6797279!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6152 invoked from network); 4 Jun 2008 12:31:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 4 Jun 2008 12:31:12 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m54CVCvX004028 for ; Wed, 4 Jun 2008 05:31:12 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m54CVBFM021887 for ; Wed, 4 Jun 2008 07:31:12 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m54CVASC021877 for ; Wed, 4 Jun 2008 07:31:11 -0500 (CDT) Received: from [10.232.37.39] ([10.232.37.39]) by ZMY16EXM70.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jun 2008 20:31:09 +0800 Message-ID: <48468A09.4010404@motorola.com> Date: Wed, 04 Jun 2008 17:56:49 +0530 From: a21917 User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Venu K References: In-Reply-To: X-OriginalArrivalTime: 04 Jun 2008 12:31:09.0177 (UTC) FILETIME=[DDD0A690:01C8C63E] X-CFilter-Loop: Reflected Cc: dime@ietf.org Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0057152869==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0057152869== Content-Type: multipart/alternative; boundary="------------000601050201010301070202" This is a multi-part message in MIME format. --------------000601050201010301070202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Venu This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary. Regards, Liyaqatali G Nadaf Venu K wrote: > Hi , > > If a response is received by a diameter node for Diameter client > A(from where request had originated) , can the response be forwarded > to client B in cases where client A is not reachable/down. > Assuming Client B knows about session and hostidentifiers of client A. > > Regards, > Venu > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------000601050201010301070202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Venu

This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary.

Regards,
Liyaqatali G Nadaf

Venu K wrote:
Hi ,

If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B  in cases where client A is not reachable/down.
Assuming Client B knows about session and hostidentifiers of client A.

Regards,
Venu

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--------------000601050201010301070202-- --===============0057152869== 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://www.ietf.org/mailman/listinfo/dime --===============0057152869==-- From dime-bounces@ietf.org Wed Jun 4 06:52:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09163A6C5A; Wed, 4 Jun 2008 06:52:59 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673873A6C5A for ; Wed, 4 Jun 2008 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve6icZRh7CrR for ; Wed, 4 Jun 2008 06:52:57 -0700 (PDT) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id EAA7C3A6B7E for ; Wed, 4 Jun 2008 06:52:56 -0700 (PDT) Received: by el-out-1112.google.com with SMTP id o28so32017ele.26 for ; Wed, 04 Jun 2008 06:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=V00vuh/Id90VWu91jDSPKJYCMg798TFeiNzixPBS1zY=; b=L+8wpBjrGwaknYtNHlu0BlB+FvkfoBq4nmPEMiliDqk+z4xftIUbkqzvXCsu0xoCDx sCKAKGeSkBYv/lzsfkC6yUT37QbOp/FMQ+egp6X0qmZTZ8ybG02vYl80IWWFAvuIbSOX hG4oiJ953IuD/cP7mRHBC8iU8b6e0h0gUZ+GQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=rDmAh8sm016rhdXE7v1NA+Fr3MmJ5a2RKpf5T03PjKLJ/0icr6wTfC7wI6CoEIAIxG fM6MfoxLL1iabGT31xX1R8TUA3h6X+bnJSKtDETx+iJ/ATpCIchsJFOXVpAjiBKsi+RN LNN84akDfiQZGfHglVK4Iau1GIdHYuxYvCusg= Received: by 10.115.14.1 with SMTP id r1mr12742333wai.139.1212587579547; Wed, 04 Jun 2008 06:52:59 -0700 (PDT) Received: by 10.114.102.6 with HTTP; Wed, 4 Jun 2008 06:52:59 -0700 (PDT) Message-ID: Date: Wed, 4 Jun 2008 19:22:59 +0530 From: "Venu K" To: a21917 In-Reply-To: <48468A09.4010404@motorola.com> MIME-Version: 1.0 References: <48468A09.4010404@motorola.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1264407103==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1264407103== Content-Type: multipart/alternative; boundary="----=_Part_7389_24841720.1212587579538" ------=_Part_7389_24841720.1212587579538 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you, Is there any way we could possibly send it to a client with different hostname ? Regards, Venu On Wed, Jun 4, 2008 at 5:56 PM, a21917 wrote: > Hi Venu > > This scenario is identical to the scenario wherein there has been a > connection re-establishment between the client and server before the answer > is sent back by the server. If the host name and domain name of the > secondary client are same as that of the primary's then you can seamlessly > send the answer message to the secondary. > > Regards, > Liyaqatali G Nadaf > > Venu K wrote: > > Hi , > > If a response is received by a diameter node for Diameter client A(from > where request had originated) , can the response be forwarded to client B > in cases where client A is not reachable/down. > Assuming Client B knows about session and hostidentifiers of client A. > > Regards, > Venu > > ------------------------------ > > _______________________________________________ > DiME mailing listDiME@ietf.orghttps://www.ietf.org/mailman/listinfo/dime > > -- Regards, Venu(http://venugrk.blogspot.com/) ------=_Part_7389_24841720.1212587579538 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank you, Is there any way we could possibly send it to a client with different hostname ?

Regards,
Venu

On Wed, Jun 4, 2008 at 5:56 PM, a21917 <a21917@motorola.com> wrote:
Hi Venu

This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary.

Regards,
Liyaqatali G Nadaf

Venu K wrote:
Hi ,

If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B  in cases where client A is not reachable/down.
Assuming Client B knows about session and hostidentifiers of client A.

Regards,
Venu

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



--
Regards,
Venu(http://venugrk.blogspot.com/) ------=_Part_7389_24841720.1212587579538-- --===============1264407103== 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://www.ietf.org/mailman/listinfo/dime --===============1264407103==-- From dime-bounces@ietf.org Wed Jun 4 10:52:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C813A6CA3; Wed, 4 Jun 2008 10:52:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331E73A6CA3 for ; Wed, 4 Jun 2008 10:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8QkZLfkj3dw for ; Wed, 4 Jun 2008 10:52:22 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id EFA1C3A686C for ; Wed, 4 Jun 2008 10:52:21 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m54HqNan006941; Wed, 4 Jun 2008 13:52:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 13:52:22 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7F01633@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter failover Thread-Index: AcjGSlLLJZBCCPBOTWCLFhUHvIM9TAAEY4WQ References: <48468A09.4010404@motorola.com> From: "Asveren, Tolga" To: "Venu K" , "a21917" Cc: dime@ietf.org Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I think not trying to send the answer to the client is a better option in t= his case: a) If client went down, standby client would resend the request. b) If connection went down, client would either try to send the request via= another next-hop or would resend it after connection reestablishment = I would classify "retransmissions" in b) in two different categories. The f= irst one is on base protocol level. For the second one, I would expect base= protocol to inform the application that it failed to send the request (ass= uming there are no alternate next-hops) and the application trying to send = a new message, i.e. a request which is a new one from base protocol perspec= tive. Sending back the answer to an alternate client may require some smarts on t= he client side: a) It would require the standby-client to recognize the answer as a valid o= ne (corresponding request was not sent by it) b) It would require the client to be ready to handle two answers for the sa= me request for the connection reestablishment. = Thanks, Tolga ________________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ven= u K Sent: Wednesday, June 04, 2008 9:53 AM To: a21917 Cc: dime@ietf.org Subject: Re: [Dime] Diameter failover Thank you, Is there any way we could possibly send it to a client with diff= erent hostname ? Regards, Venu On Wed, Jun 4, 2008 at 5:56 PM, a21917 wrote: Hi Venu This scenario is identical to the scenario wherein there has been a connect= ion re-establishment between the client and server before the answer is sen= t back by the server. If the host name and domain name of the secondary cli= ent are same as that of the primary's then you can seamlessly send the answ= er message to the secondary. Regards, Liyaqatali G Nadaf Venu K wrote: = Hi , If a response is received by a diameter node for Diameter client A(from whe= re request had originated) , can the response be forwarded to client B=A0 i= n cases where client A is not reachable/down. Assuming Client B knows about session and hostidentifiers of client A. Regards, Venu ________________________________________ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime = -- = Regards, Venu(http://venugrk.blogspot.com/) = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 4 11:45:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B47528C1EC; Wed, 4 Jun 2008 11:45:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357028C1E7 for ; Wed, 4 Jun 2008 11:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDztaSYWy8js for ; Wed, 4 Jun 2008 11:45:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 420EB3A6CDD for ; Wed, 4 Jun 2008 11:45:12 -0700 (PDT) Received: (qmail invoked by alias); 04 Jun 2008 18:45:15 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp009) with SMTP; 04 Jun 2008 20:45:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19wMcEKy4ZwhVL94i6MHzHTyoI/OAa+VjRRs0+Lj1 Ru9hnUJivCDb88 Message-ID: <4846E2B8.5070102@gmx.net> Date: Wed, 04 Jun 2008 21:45:12 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Asveren, Tolga" References: <48468A09.4010404@motorola.com> <033458F56EC2A64E8D2D7B759FA3E7E7F01633@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7F01633@sonusmail04.sonusnet.com> X-Y-GMX-Trusted: 0 Cc: dime@ietf.org, a21917 , Venu K Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I believe that the entire scenario does not seem to be right. Venu, could you motivate it a bit more? Ciao Hannes Asveren, Tolga wrote: > I think not trying to send the answer to the client is a better option in this case: > > a) If client went down, standby client would resend the request. > b) If connection went down, client would either try to send the request via another next-hop or would resend it after connection reestablishment > > I would classify "retransmissions" in b) in two different categories. The first one is on base protocol level. For the second one, I would expect base protocol to inform the application that it failed to send the request (assuming there are no alternate next-hops) and the application trying to send a new message, i.e. a request which is a new one from base protocol perspective. > > Sending back the answer to an alternate client may require some smarts on the client side: > a) It would require the standby-client to recognize the answer as a valid one (corresponding request was not sent by it) > b) It would require the client to be ready to handle two answers for the same request for the connection reestablishment. > > > Thanks, > Tolga > > ________________________________________ > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Venu K > Sent: Wednesday, June 04, 2008 9:53 AM > To: a21917 > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter failover > > Thank you, Is there any way we could possibly send it to a client with different hostname ? > > Regards, > Venu > On Wed, Jun 4, 2008 at 5:56 PM, a21917 wrote: > Hi Venu > > This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary. > > Regards, > Liyaqatali G Nadaf > > Venu K wrote: > Hi , > > If a response is received by a diameter node for Diameter client A(from where request had originated) , can the response be forwarded to client B in cases where client A is not reachable/down. > Assuming Client B knows about session and hostidentifiers of client A. > > Regards, > Venu > ________________________________________ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 4 19:00:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2655E3A6AB6; Wed, 4 Jun 2008 19:00:11 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158503A6A1E for ; Wed, 4 Jun 2008 19:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6-OFOev4NOX for ; Wed, 4 Jun 2008 19:00:09 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 112CE3A67A8 for ; Wed, 4 Jun 2008 19:00:08 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id ZvL21Z05Q1HzFnQ530G500; Thu, 05 Jun 2008 02:00:12 +0000 Received: from gwzPC ([124.120.222.145]) by OMTA14.westchester.pa.mail.comcast.net with comcast id a1zN1Z00E38pyvw3a1zufL; Thu, 05 Jun 2008 02:00:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=HLZrJzgksJMKEXI44rEA:9 a=-RHpmsGVgzsT-0mjMH80T8jNwQQA:4 a=X_HkFOEsjF8A:10 a=DLWQtoLnVnAA:10 From: "Glen Zorn" To: "'a21917'" References: <48468A09.4010404@motorola.com> In-Reply-To: <48468A09.4010404@motorola.com> Date: Thu, 5 Jun 2008 08:59:04 +0700 Message-ID: <007301c8c6af$cccc59e0$66650da0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjGP9bb3R1vTQw2RAq8za4zrJpQWwAb0fbQ Content-Language: en-us Cc: dime@ietf.org, 'Venu K' Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Liyaqatali G Nadaf [mailto://a21917@motorola.com] writes: Hi Venu This scenario is identical to the scenario wherein there has been a connection re-establishment between the client and server before the answer is sent back by the server. If the host name and domain name of the secondary client are same as that of the primary's then you can seamlessly send the answer message to the secondary. [gwz] What an interesting idea! I wonder how the DNS will function in the face of two or more hosts w/the same FQDN... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 4 19:18:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADAB33A6A47; Wed, 4 Jun 2008 19:18:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120D53A6B16 for ; Wed, 4 Jun 2008 19:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwutPOTfX56Q for ; Wed, 4 Jun 2008 19:18:48 -0700 (PDT) Received: from female.eservglobal.co.nz (mail.eservglobal.co.nz [125.236.61.195]) by core3.amsl.com (Postfix) with ESMTP id 8DF573A6B47 for ; Wed, 4 Jun 2008 19:18:28 -0700 (PDT) Received: from rloader.eservglobal.co.nz (rloader.eservglobal.co.nz [192.168.7.230]) by female.eservglobal.co.nz (8.13.8/8.13.8/Debian-3) with ESMTP id m552IO9S005831; Thu, 5 Jun 2008 14:18:24 +1200 Date: Thu, 5 Jun 2008 14:18:24 +1200 From: Ralph Loader Message-ID: <20080605141824.02626e14@rloader.eservglobal.co.nz> In-Reply-To: <007301c8c6af$cccc59e0$66650da0$@net> References: <48468A09.4010404@motorola.com> <007301c8c6af$cccc59e0$66650da0$@net> Organization: eServGlobal X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-redhat-linux-gnu) Mime-Version: 1.0 Cc: dime@ietf.org, 'Venu K' Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > If the host name and domain name > of the secondary client are same as that of the primary's then you > can seamlessly send the answer message to the secondary. I don't see how this can work. How is the request/answer matching meant to work if an answer is sent on a connection that the request was not sent on? The hop-by-hop id is only guarenteed unique per-connection, and the end-end id might not unique across client re-boots. So unless the server knows that the clients provide uniqueness guarentees beyond those required by the protocol, an answer sent on a different connection than the request is potentially ambiguous. Ralph. > > [gwz] What an interesting idea! I wonder how the DNS will function > in the face of two or more hosts w/the same FQDN... > > ... > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 6 08:26:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FF43A6D83; Fri, 6 Jun 2008 08:26:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC233A6B26 for ; Fri, 6 Jun 2008 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALAZ+iIIpqaK for ; Fri, 6 Jun 2008 08:26:26 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by core3.amsl.com (Postfix) with ESMTP id 603E93A6D83 for ; Fri, 6 Jun 2008 08:26:26 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m36so424929rnd.18 for ; Fri, 06 Jun 2008 08:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=/I+GxgOPpMjzr0c2Hx9eCL4ewYS2wa1abXh6I5EJagI=; b=UstHTolgwfwc6ny99Gb/x3QSTpCWJnnkBmNHQmi7cMC3jFcSDYSufv+CN2ffYLFje/ zjbTj+q0ujUNfmFWf68V201BcN0Nb7g96hlts1coIenQ6kEhEHdVXWWbPEAZOA3t570p Su5YGf8NZsVCyp4yZl0/O4vUS5DOgdoa0KP2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ptv9c9xTJRSOdzpAp3V4FKlujK08s80MSUKlEdhqj9vBf2Wgqr4ARn9OEyNji6qtu/ h9ML+PGs4kKBp+X5YKRZZew7zjRAxJgMiQqRXZOIwJlVNUZIk/b4tN4OoZdxhX8HvgYx My8Jx3zscKnEXqLpRgjnx6qRpk8/govinRKo0= Received: by 10.114.184.11 with SMTP id h11mr239062waf.175.1212765992861; Fri, 06 Jun 2008 08:26:32 -0700 (PDT) Received: by 10.114.102.6 with HTTP; Fri, 6 Jun 2008 08:26:32 -0700 (PDT) Message-ID: Date: Fri, 6 Jun 2008 20:56:32 +0530 From: "Venu K" To: "Ralph Loader" In-Reply-To: <20080605141549.66b33a1e@rloader.eservglobal.co.nz> MIME-Version: 1.0 References: <48468A09.4010404@motorola.com> <20080605141549.66b33a1e@rloader.eservglobal.co.nz> Cc: dime@ietf.org, a21917 Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1241036301==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1241036301== Content-Type: multipart/alternative; boundary="----=_Part_6662_33283815.1212765992848" ------=_Part_6662_33283815.1212765992848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank You all, The requirement is because when AS(application server) in a cluster fails , another AS node picks up requests served by the server that is out of service. The diameter messages to be sent to the out of service AS needs to be forwarded to AS node which has picked up the requests. Regards Venu On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader wrote: > > > This scenario is identical to the scenario wherein there has been a > > connection re-establishment between the client and server before the > > answer is sent back by the server. If the host name and domain name > > of the secondary client are same as that of the primary's then you > > can seamlessly send the answer message to the secondary. > > I don't see how this can work. > > How is the request/answer matching meant to work if an answer is sent > on a connection that the request was not sent on? > > The hop-by-hop id is only guarenteed unique per-connection, and the > end-end id might not unique across client re-boots (or over different > clients). > > So unless the server knows that the clients provide uniqueness > guarentees beyond those required by the protocol, sending an answer > on a different connection than the request is potentially ambiguous as > to what request it matches. > > Ralph. > > > > > Regards, > > Liyaqatali G Nadaf > > > > Venu K wrote: > > > Hi , > > > > > > If a response is received by a diameter node for Diameter client > > > A(from where request had originated) , can the response be > > > forwarded to client B in cases where client A is not > > > reachable/down. Assuming Client B knows about session and > > > hostidentifiers of client A. > > > > > > Regards, > > > Venu > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > > > ------=_Part_6662_33283815.1212765992848 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thank You all, The requirement is because when AS(application server) in a cluster fails , another AS node picks up requests served by the
server that is out of service. The diameter messages to be sent to the out of service AS needs to be forwarded to AS node which has picked
up the requests.



Regards
Venu

On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader <ralph.loader@eservglobal.com> wrote:

> This scenario is identical to the scenario wherein there has been a
> connection re-establishment between the client and server before the
> answer is sent back by the server. If the host name and domain name
> of the secondary client are same as that of the primary's then you
> can seamlessly send the answer message to the secondary.

I don't see how this can work.

How is the request/answer matching meant to work if an answer is sent
on a connection that the request was not sent on?

The hop-by-hop id is only guarenteed unique per-connection, and the
end-end id might not unique across client re-boots (or over different
clients).

So unless the server knows that the clients provide uniqueness
guarentees beyond those required by the protocol, sending an answer
on a different connection than the request is potentially ambiguous as
to what request it matches.

Ralph.

>
> Regards,
> Liyaqatali G Nadaf
>
> Venu K wrote:
> > Hi ,
> >
> > If a response is received by a diameter node for Diameter client
> > A(from where request had originated) , can the response be
> > forwarded to client B  in cases where client A is not
> > reachable/down. Assuming Client B knows about session and
> > hostidentifiers of client A.
> >
> > Regards,
> > Venu
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >


------=_Part_6662_33283815.1212765992848-- --===============1241036301== 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://www.ietf.org/mailman/listinfo/dime --===============1241036301==-- From dime-bounces@ietf.org Sat Jun 7 23:19:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E75C3A6A8C; Sat, 7 Jun 2008 23:19:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6163A6A8C for ; Sat, 7 Jun 2008 23:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSJYj1MiFOFT for ; Sat, 7 Jun 2008 23:19:50 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 16E953A68DB for ; Sat, 7 Jun 2008 23:19:50 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so1565170wah.25 for ; Sat, 07 Jun 2008 23:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=iGkMEq8f4k3O/Fp8Ld+gDuCDm3hhzX8vtonpJpCL0FY=; b=mbYG4uLHuuz+yQcuG8HondyU9RQnl8Yg+wUQctM2Pss7yAkN9P5SGvMxhdzUkkMk7L 21JMhhoREnbKw3fVpQ0F94yEtQVffUOZRV/+hey7foe/FJn1ebyqX/gfu8hkCF/yEHNv Ppem41xPydENWMXVKuArhk6q8qpxugsDRbVjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ZkqroBbY/dE214tLmOTHrboGr1XX8l8mbcnDKscgRefvt7iX9lzMQyQax0dpa74qba gTS/yMQdZisD7eqn4afW2Ux6K+Gc08JY9O/ucJvEzaar5CmzLjieGTJKxVKhChqUyt+B i35DVPgKWvTM6ajlQwkPKejhSrYGtwXOXDuZY= Received: by 10.114.106.13 with SMTP id e13mr1974571wac.157.1212906000968; Sat, 07 Jun 2008 23:20:00 -0700 (PDT) Received: by 10.114.102.6 with HTTP; Sat, 7 Jun 2008 23:20:00 -0700 (PDT) Message-ID: Date: Sun, 8 Jun 2008 11:50:00 +0530 From: "Venu K" To: "Himanshu Rawat" In-Reply-To: <9addac050806071033q26cea75eo3f1e8451fbe290ef@mail.gmail.com> MIME-Version: 1.0 References: <48468A09.4010404@motorola.com> <20080605141549.66b33a1e@rloader.eservglobal.co.nz> <9addac050806071033q26cea75eo3f1e8451fbe290ef@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0895371618==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0895371618== Content-Type: multipart/alternative; boundary="----=_Part_11274_33255456.1212906000964" ------=_Part_11274_33255456.1212906000964 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Right , w.r.t my original question in this thread are we allowed (as per spec) to forward Diameter reply messages of out of service AS node to AS node which is taken over. +++ 6.2.2 from RFC 3588 The agent MUST then send the answer to the host that it received the original request from. Regards, Venu On Sat, Jun 7, 2008 at 11:03 PM, Himanshu Rawat wrote: > Hi Venu, > > The scenario that you've described is possible and generally covered under > high availability i.e. HA. Usually the AS should be available 99.999 % for > the service, and if any of the server or node goes down then immediately > other AS should start processing the request. > > The required information to build the request is stored in the common > storage(it can be hardisk or database or any other thing), the other server > should know how to process the request (means in which state were they when > node got down) which were served by the node that got down. This is one of > the ways where other server can start processing the request. > > Please revert if it's not clear. > > Himanshu > > > On Fri, Jun 6, 2008 at 8:56 PM, Venu K wrote: > >> Thank You all, The requirement is because when AS(application server) in a >> cluster fails , another AS node picks up requests served by the >> server that is out of service. The diameter messages to be sent to the out >> of service AS needs to be forwarded to AS node which has picked >> up the requests. >> >> >> >> Regards >> Venu >> >> On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader < >> ralph.loader@eservglobal.com> wrote: >> >>> >>> > This scenario is identical to the scenario wherein there has been a >>> > connection re-establishment between the client and server before the >>> > answer is sent back by the server. If the host name and domain name >>> > of the secondary client are same as that of the primary's then you >>> > can seamlessly send the answer message to the secondary. >>> >>> I don't see how this can work. >>> >>> How is the request/answer matching meant to work if an answer is sent >>> on a connection that the request was not sent on? >>> >>> The hop-by-hop id is only guarenteed unique per-connection, and the >>> end-end id might not unique across client re-boots (or over different >>> clients). >>> >>> So unless the server knows that the clients provide uniqueness >>> guarentees beyond those required by the protocol, sending an answer >>> on a different connection than the request is potentially ambiguous as >>> to what request it matches. >>> >>> Ralph. >>> >>> > >>> > Regards, >>> > Liyaqatali G Nadaf >>> > >>> > Venu K wrote: >>> > > Hi , >>> > > >>> > > If a response is received by a diameter node for Diameter client >>> > > A(from where request had originated) , can the response be >>> > > forwarded to client B in cases where client A is not >>> > > reachable/down. Assuming Client B knows about session and >>> > > hostidentifiers of client A. >>> > > >>> > > Regards, >>> > > Venu >>> > > >>> ------------------------------------------------------------------------ >>> > > >>> > > _______________________________________________ >>> > > DiME mailing list >>> > > DiME@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/dime >>> > > >>> >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > ------=_Part_11274_33255456.1212906000964 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Right , w.r.t my original question in this thread are we allowed (as per spec) to forward Diameter reply messages of out of service AS node
to AS node which is taken over.

+++
6.2.2 from RFC 3588
 The agent MUST then send the answer to the host that it received the
   original request from.

Regards,
Venu


On Sat, Jun 7, 2008 at 11:03 PM, Himanshu Rawat <himanshu.rawat@gmail.com> wrote:
Hi Venu,

The scenario that you've described is possible and generally covered under high availability i.e. HA. Usually the AS should be available 99.999 % for the service, and if any of the server or node goes down then immediately other AS should start processing the request.

The required information to build the request is stored in the common storage(it can be hardisk or database or any other thing), the other server should know how to process the request (means in which state were they when node got down) which were served by the node that got down. This is one of the ways where other server can start processing the request.

Please revert if it's not clear.

Himanshu


On Fri, Jun 6, 2008 at 8:56 PM, Venu K <venugr.k@gmail.com> wrote:
Thank You all, The requirement is because when AS(application server) in a cluster fails , another AS node picks up requests served by the
server that is out of service. The diameter messages to be sent to the out of service AS needs to be forwarded to AS node which has picked
up the requests.



Regards
Venu

On Thu, Jun 5, 2008 at 7:45 AM, Ralph Loader <ralph.loader@eservglobal.com> wrote:

> This scenario is identical to the scenario wherein there has been a
> connection re-establishment between the client and server before the
> answer is sent back by the server. If the host name and domain name
> of the secondary client are same as that of the primary's then you
> can seamlessly send the answer message to the secondary.

I don't see how this can work.

How is the request/answer matching meant to work if an answer is sent
on a connection that the request was not sent on?

The hop-by-hop id is only guarenteed unique per-connection, and the
end-end id might not unique across client re-boots (or over different
clients).

So unless the server knows that the clients provide uniqueness
guarentees beyond those required by the protocol, sending an answer
on a different connection than the request is potentially ambiguous as
to what request it matches.

Ralph.

>
> Regards,
> Liyaqatali G Nadaf
>
> Venu K wrote:
> > Hi ,
> >
> > If a response is received by a diameter node for Diameter client
> > A(from where request had originated) , can the response be
> > forwarded to client B  in cases where client A is not
> > reachable/down. Assuming Client B knows about session and
> > hostidentifiers of client A.
> >
> > Regards,
> > Venu
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >



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






------=_Part_11274_33255456.1212906000964-- --===============0895371618== 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://www.ietf.org/mailman/listinfo/dime --===============0895371618==-- From dime-bounces@ietf.org Sun Jun 8 23:04:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB1793A6A7D; Sun, 8 Jun 2008 23:04:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 568513A6A7D for ; Sun, 8 Jun 2008 23:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK10FSN7NmXd for ; Sun, 8 Jun 2008 23:04:13 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 84A953A686A for ; Sun, 8 Jun 2008 23:04:11 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5963fUe005390 for ; Mon, 9 Jun 2008 01:04:25 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 09:03:52 +0300 Received: from vaebe110.NOE.Nokia.com ([10.160.244.79]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 09:03:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 09:03:44 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [Dime] Diameter failover thread-index: AcjJL8DY3BxQhFoPTgmMQvVtJfYOwwAw66tA References: <48468A09.4010404@motorola.com><20080605141549.66b33a1e@rloader.eservglobal.co.nz><9addac050806071033q26cea75eo3f1e8451fbe290ef@mail.gmail.com> From: To: X-OriginalArrivalTime: 09 Jun 2008 06:03:51.0935 (UTC) FILETIME=[9767A8F0:01C8C9F6] X-Nokia-AV: Clean Subject: Re: [Dime] Diameter failover X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > Right , w.r.t my original question in this thread are we > allowed (as per spec) to forward Diameter reply messages of > out of service AS node to AS node which is taken over. No, you are not allowed to do that according to RFC 3588. If you design and deploy an HA solution that behaves this way you should take into account that "standard" Diameter clients and servers do not support it. Best Regards, Mikko Aittola >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Venu K >Sent: 08 June, 2008 09:20 >To: Himanshu Rawat >Cc: dime@ietf.org >Subject: Re: [Dime] Diameter failover > >Right , w.r.t my original question in this thread are we >allowed (as per spec) to forward Diameter reply messages of >out of service AS node >to AS node which is taken over. > >+++ > >6.2.2 from RFC 3588 > The agent MUST then send the answer to the host that it received the > original request from. > >Regards, >Venu > > > >On Sat, Jun 7, 2008 at 11:03 PM, Himanshu Rawat > wrote: > > > Hi Venu, > > The scenario that you've described is possible and >generally covered under high availability i.e. HA. Usually the >AS should be available 99.999 % for the service, and if any of >the server or node goes down then immediately other AS should >start processing the request. > > The required information to build the request is stored >in the common storage(it can be hardisk or database or any >other thing), the other server should know how to process the >request (means in which state were they when node got down) >which were served by the node that got down. This is one of >the ways where other server can start processing the request. > > Please revert if it's not clear. > > Himanshu > > > On Fri, Jun 6, 2008 at 8:56 PM, Venu K > wrote: > > > Thank You all, The requirement is because when >AS(application server) in a cluster fails , another AS node >picks up requests served by the > server that is out of service. The diameter >messages to be sent to the out of service AS needs to be >forwarded to AS node which has picked > up the requests. > > > > Regards > Venu _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 10 06:01:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735513A6B50; Tue, 10 Jun 2008 06:01:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9CE3A6AA3 for ; Tue, 10 Jun 2008 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjHHh9rr1l-D for ; Tue, 10 Jun 2008 06:01:55 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B09213A6B4E for ; Tue, 10 Jun 2008 06:01:54 -0700 (PDT) Received: (qmail 26319 invoked by uid 0); 10 Jun 2008 13:02:15 -0000 Received: from 195.37.70.39 by www118.gmx.net with HTTP; Tue, 10 Jun 2008 15:02:15 +0200 (CEST) Date: Tue, 10 Jun 2008 15:02:14 +0200 From: SpawnRR@gmx.de Message-ID: <20080610130214.311880@gmx.net> MIME-Version: 1.0 To: dime@ietf.org X-Authenticated: #8754011 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+QNpV0YkCQIoE9cltxqBniyOpLyzKLOIuy9bC0hU M2TeOAbQvvy+NP16mx0CaKKw47/0Ngb/czNQ== X-GMX-UID: MR8mBe8YbHIhSimrvDQ0caQiJihyapCZ Subject: [Dime] Question: Redirect Agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, I've two questions regarding the Diameter Redirect Agent. I would be thanks= full, if you could help me. = If a Diameter node is assigned to act as a Redirect Agent, does it then mea= n, that the Redirect Agent contains in its realm-based routing table only e= ntries with the 'Local Action' field set to 'Redirect', or is it even possi= ble that the Redirect Agent can also perform 'local' action? This question comes up, as the Diameter Base Protocol doesn't mention, if e= very capable diameter node can act as redirect-, relay-, proxy agent at the= same time. I have understood, that the role of a diameter node depends onl= y on the 'Local Action' field in the routing table, and therefore there are= no special software configuration necessary, to assign a diameter node a s= pecial characteristic. What do you think? Second question: Is it thinkable, that a redirect agent can also use other information to se= lect the appropriate server, for example routing could based on the Origin-= Host AVP and the Destination-Realm AVP and not only on the Destination-Real= m AVP? Abstract: MUST a redirect agent only use its realm-based routing table or can it use = other mechanism to make routing decisions? Thank you in advance. Regards, Bernd -- = Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 11 08:12:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4C13A68FD; Wed, 11 Jun 2008 08:12:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E903A68FD for ; Wed, 11 Jun 2008 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiLbcoP9bzeS for ; Wed, 11 Jun 2008 08:12:54 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 8FB0A3A6828 for ; Wed, 11 Jun 2008 08:12:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3A12FC8030 for ; Wed, 11 Jun 2008 11:13:16 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14029-11 for ; Wed, 11 Jun 2008 11:13:15 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 11 Jun 2008 11:13:15 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 11:13:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 20:43:11 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C04BD9E46@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: When Invalid DWR is received what should be done? Thread-Index: AcjL1alu4RDZRhRdQwWZvB7X4EC6Qg== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 11 Jun 2008 15:13:15.0731 (UTC) FILETIME=[AC2F4230:01C8CBD5] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] When Invalid DWR is received what should be done? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0099152719==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0099152719== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CBD5.A9B85D6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CBD5.A9B85D6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Can anybody tell me what should be done when a DWR is received with invalid Origin-Realm? =20 Is there any clue on the same in RFC 3588?=20 =20 If I send DWA for this invalid DWR then what Result-Code value should be put in Result-Code AVP? =20 Thanks, Avinash Gowda =20 ------_=_NextPart_001_01C8CBD5.A9B85D6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Can anybody tell me what should be done when a DWR is received with invalid = Origin-Realm?

 

Is there any clue on the same in RFC 3588? =

 

If I send DWA for this invalid DWR then what = Result-Code value should be put in Result-Code AVP?

 

Thanks,

Avinash Gowda

 

------_=_NextPart_001_01C8CBD5.A9B85D6C-- --===============0099152719== 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://www.ietf.org/mailman/listinfo/dime --===============0099152719==-- From dime-bounces@ietf.org Wed Jun 11 08:25:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD7A3A6919; Wed, 11 Jun 2008 08:25:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44FB3A6919 for ; Wed, 11 Jun 2008 08:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7Sr53ilmRPI for ; Wed, 11 Jun 2008 08:25:37 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 08AF23A6812 for ; Wed, 11 Jun 2008 08:25:36 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ceR71Z0010SCNGk5505A00; Wed, 11 Jun 2008 15:26:01 +0000 Received: from gwzPC ([124.120.229.58]) by OMTA09.westchester.pa.mail.comcast.net with comcast id cfRY1Z0011GEcyc3VfRr0o; Wed, 11 Jun 2008 15:25:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=oYl7L2qMhIkA:10 a=ZS_QdqIdbPkA:10 a=Lvg1kiT6qXEWfw3c_7cA:9 a=I4D_eNtbf5Vism7RlkyoBj96koYA:4 a=50e4U0PicR4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=3FU1Di304AOjDmQD4ZoA:9 a=EBxJgVJOyw2uaPppyyEA:7 a=ATTmAe1hTAEpYqK7f8wV1U26B38A:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Gowda, Avinash'" References: <69FADB84C90B1248A7DE59422771FA0C04BD9E46@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C04BD9E46@exchindia3.starentnetworks.com> Date: Wed, 11 Jun 2008 22:25:19 +0700 Message-ID: <002601c8cbd7$64f6eb50$2ee4c1f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjL1alu4RDZRhRdQwWZvB7X4EC6QgAAYIvw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] When Invalid DWR is received what should be done? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0414403751==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0414403751== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C8CC12.1155EA60" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0027_01C8CC12.1155EA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Can anybody tell me what should be done when a DWR is received with invalid Origin-Realm? Is there any clue on the same in RFC 3588? See section 7. If I send DWA for this invalid DWR then what Result-Code value should be put in Result-Code AVP? DIAMETER_INVALID_AVP_VALUE Thanks, Avinash Gowda ------=_NextPart_000_0027_01C8CC12.1155EA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

Can anybody tell me what should be done when a DWR is received with = invalid Origin-Realm?

 =

Is there any clue on the same in RFC 3588?

 

See section 7.

 =

If I send DWA for this invalid DWR then what Result-Code value should be = put in Result-Code AVP?

 

DIAMETER_INVALID_AVP_VALUE     &n= bsp;  

 =

Thanks,

Avinash Gowda

 

------=_NextPart_000_0027_01C8CC12.1155EA60-- --===============0414403751== 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://www.ietf.org/mailman/listinfo/dime --===============0414403751==-- From dime-bounces@ietf.org Thu Jun 12 00:14:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A833A6817; Thu, 12 Jun 2008 00:14:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B047E3A6843 for ; Thu, 12 Jun 2008 00:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1nlx+UuDdnE for ; Thu, 12 Jun 2008 00:14:32 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 939A03A67AC for ; Thu, 12 Jun 2008 00:14:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id B3470C802D for ; Thu, 12 Jun 2008 03:14:56 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01397-06 for ; Thu, 12 Jun 2008 03:14:56 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 12 Jun 2008 03:14:56 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 03:14:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 12:44:52 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C04BD9EB1@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on H-B-H id and End-To-End id. Thread-Index: AcjMXAIp/Y4VyRneSdahg/CIO7GuRQ== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 12 Jun 2008 07:14:56.0257 (UTC) FILETIME=[0460CF10:01C8CC5C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] Question on H-B-H id and End-To-End id. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0908524437==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0908524437== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CC5C.026D41C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CC5C.026D41C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 H-B-H id and End-To-End id values can be set same? =20 If I set them to same value (Example: Hop2Hop-ID: 5981bef5 End2End-ID: 5981bef5) are there any problems? =20 Thanks, Avinash Gowda =20 ------_=_NextPart_001_01C8CC5C.026D41C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

H-B-H id and End-To-End id values can be set = same?

 

If I set them to same value (Example: Hop2Hop-ID: = 5981bef5 End2End-ID: 5981bef5) are there any = problems?

 

Thanks,

Avinash Gowda

 

------_=_NextPart_001_01C8CC5C.026D41C7-- --===============0908524437== 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://www.ietf.org/mailman/listinfo/dime --===============0908524437==-- From dime-bounces@ietf.org Thu Jun 12 01:50:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5F93A69DC; Thu, 12 Jun 2008 01:50:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0133A69DC for ; Thu, 12 Jun 2008 01:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUEWe+K97e+P for ; Thu, 12 Jun 2008 01:50:46 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id E28E63A69D3 for ; Thu, 12 Jun 2008 01:50:45 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m5C8lRUu013897; Thu, 12 Jun 2008 17:47:27 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m5C8lQ8k025998; Thu, 12 Jun 2008 17:47:26 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m5C8lQ70025995; Thu, 12 Jun 2008 17:47:26 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 92C056E92; Thu, 12 Jun 2008 17:47:26 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 6CCE16E47; Thu, 12 Jun 2008 17:47:26 +0900 (JST) Message-ID: <4850E295.4070707@nict.go.jp> Date: Thu, 12 Jun 2008 17:47:17 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Gowda, Avinash" References: <69FADB84C90B1248A7DE59422771FA0C04BD9EB1@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C04BD9EB1@exchindia3.starentnetworks.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] Question on H-B-H id and End-To-End id. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Since they are unrelated, they can indeed be the same... Gowda, Avinash a =E9crit : > > Hi, > > = > > H-B-H id and End-To-End id values can be set same? > > = > > If I set them to same value (Example: Hop2Hop-ID: 5981bef5 End2End-ID: = > 5981bef5) are there any problems? > > = > > Thanks, > > Avinash Gowda > > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 12 04:09:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CD83A694A; Thu, 12 Jun 2008 04:09:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF903A6878 for ; Thu, 12 Jun 2008 04:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lYYlfJ9EWP4 for ; Thu, 12 Jun 2008 04:09:34 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 73C4E3A6A1C for ; Thu, 12 Jun 2008 04:09:33 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id cyxp1Z00E0b6N64A601L00; Thu, 12 Jun 2008 11:10:01 +0000 Received: from gwzPC ([124.120.222.188]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id cz9X1Z00944VtTQ8Pz9qSY; Thu, 12 Jun 2008 11:09:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=MJu4_wbqv_kA:10 a=T8quK1Dx5uAA:10 a=Ndb5aUdTqBFmfrkgjcUA:9 a=V7P9eAxuvKF6BI3DC3Lfx3z0IiAA:4 a=50e4U0PicR4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=6Pg-cxhGZhnNH5_6eSUA:9 a=o3Rznf-CuT9pDyC_MqEA:7 a=WFVChdPSRbjRr8K9e6dCH9LCEIQA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Gowda, Avinash'" , References: <69FADB84C90B1248A7DE59422771FA0C04BD9EB1@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C04BD9EB1@exchindia3.starentnetworks.com> Date: Thu, 12 Jun 2008 18:09:14 +0700 Message-ID: <009f01c8cc7c$c9c28a80$5d479f80$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjMXAIp/Y4VyRneSdahg/CIO7GuRQAIIhXg Content-Language: en-us Subject: Re: [Dime] Question on H-B-H id and End-To-End id. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0491883603==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0491883603== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01C8CCB7.76216280" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00A0_01C8CCB7.76216280 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, H-B-H id and End-To-End id values can be set same? If I set them to same value (Example: Hop2Hop-ID: 5981bef5 End2End-ID: 5981bef5) are there any problems? I don't think so, as long as the I-D is generated using the E2E algorithm. Thanks, Avinash Gowda ------=_NextPart_000_00A0_01C8CCB7.76216280 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 =

H-B-H id and End-To-End id values can be set same?

 =

If I set them to same value (Example: Hop2Hop-ID: 5981bef5 End2End-ID: = 5981bef5) are there any problems?

I don't think so, as long as the I-D is generated using = the E2E algorithm.

 =

Thanks,

Avinash Gowda

 

------=_NextPart_000_00A0_01C8CCB7.76216280-- --===============0491883603== 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://www.ietf.org/mailman/listinfo/dime --===============0491883603==-- From dime-bounces@ietf.org Thu Jun 12 07:44:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D3B3A6999; Thu, 12 Jun 2008 07:44:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8503A686D for ; Thu, 12 Jun 2008 07:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI-79WAG2JM2 for ; Thu, 12 Jun 2008 07:44:47 -0700 (PDT) Received: from web84307.mail.re1.yahoo.com (web84307.mail.re1.yahoo.com [69.147.74.186]) by core3.amsl.com (Postfix) with SMTP id DFEB33A69DD for ; Thu, 12 Jun 2008 07:44:46 -0700 (PDT) Received: (qmail 54471 invoked by uid 60001); 12 Jun 2008 14:45:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=R35SCNfFxw6PreMKzttQ3HADJfC3Ar+UDsxNORqJlF9IWwg8FfNEbjYErWuxD6ZNU5xkY0MqJfrJe0V9RYL2NhsTPrslZmHoZypWa1CJkyDVMGT90WQf0PSoxPszaBslyYXGkqyi0rS56Nzq7mATPwPfhVpNSVFXmNF5LHCT0pA=; X-YMail-OSG: XYDzuGwVM1luvzQrG7n34y5zucI18Vkn.mlAfSWySeimX8mZwe9.qlrr.0uUNOUdJ8oAUzQ1FjAqsnYEHmRGks1PFElGveKVEAMrVRBnE4wI1VxPggH_oQQ- Received: from [206.16.17.212] by web84307.mail.re1.yahoo.com via HTTP; Thu, 12 Jun 2008 07:45:14 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Thu, 12 Jun 2008 07:45:14 -0700 (PDT) From: Behcet Sarikaya To: SpawnRR@gmx.de MIME-Version: 1.0 Message-ID: <161079.54446.qm@web84307.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1584582055==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1584582055== Content-Type: multipart/alternative; boundary="0-1996331479-1213281914=:54446" --0-1996331479-1213281914=:54446 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rafael,=0A The problem statement draft Problem Statement and Requiremen= ts for Diameter Prefix Delegation Application makes the case for an AAA Pre= fix Delegation application for use with PMIPv6 and many other cases. Curren= tly DHCPv6 PD is defined and many attributes for AAA to carry prefixes (as = you mentioned) but no Diameter/Radius application for PD.=0A Please post y= our comments on this subject to dime list.=0A=0ARegards,=0A=0ABehcet=0A=0A= =0A----- Original Message ----=0AFrom: "SpawnRR@gmx.de" =0A= To: sarikaya@ieee.org=0ASent: Thursday, June 12, 2008 9:00:49 AM=0ASubject:= Diameter Prefix Delegation Application=0A=0AHi Behcet,=0A=0AI hope I don't= disturb you...=0A=0AI have read today your "Problem Statement and Requirem= ents for Diameter Prefix Delegation Application" draft and it is very inter= esting.=0A=0ARegarding prefix delegation for PMIP there exists already a me= ssage exchange between LMA and an AAA server. Draft asdfasdf recommends a n= ew AVP called PMIP-HOME-Prefix AVP which can be used within an AA-Request a= nd AA-Answer message, while a LMA registered a new mobile session (PBU) on = the AAA server. If the AAA server has authorized the mobile node and it has= determined that mobile node=92s HNP is not set, then the AAA server can ac= t as DHCP client and request the DHCP server for a prefix (IA_PD option) an= d send the assigned prefix within a AA-Answer message to the LMA, subsequen= tly.=0A=0AIMHO there is no need for a new Diameter Prefix Delegation applic= ation regarding PMIP, as the mentioned draft defines a good solution to del= egate a prefix from the AAA to the LMA --> AA-Request and the PMIP6-Home-Pr= efix AVP.=0A=0AMay be I=92m wrong and you mean, that there should be a new = Diameter Prefix application with new command types, which can be used ad-ho= c without involving a AAA session registration exchange like the NASREQ app= lication would it do with its AA-Request/Response messages.=0A=0ACan you pr= ovide me some information on this, please? Are there already new Ideas rega= rding a Diameter application for prefix delegation?=0A=0A=0ABR,=0A=0ARafael= .=0A=0A-- =0APsssst! Schon vom neuen GMX MultiMessenger geh=F6rt?=0ADer kan= n`s mit allen: http://www.gmx.net/de/go/multimessenger=0A --0-1996331479-1213281914=:54446 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Rafael,
  The problem statement draft Probl= em Statement and Requirements for Diameter Prefix Delegation Application ma= kes the case for an AAA Prefix Delegation application for use with PMIPv6 a= nd many other cases. Currently DHCPv6 PD is defined and many attributes for= AAA to carry prefixes (as you mentioned) but no Diameter/Radius applicatio= n for PD.
  Please post your comments on this subject to dime list.=

Regards,

Behcet

----- Original Message ----From: "SpawnRR@gmx.de" <SpawnRR@gmx.de>
To: sarikaya@ieee.orgSent: Thursday, June 12, 2008 9:00:49 AM
Subject: Diameter Prefix Delegation Application

Hi Behcet,

I hope I don't disturb you= ...

I have read today your "Problem Statement and Requirements for D= iameter Prefix Delegation Application" draft and it is very interesting.
Regarding prefix delegation for PMIP there exists already a message ex= change between LMA and an AAA server. Draft asdfasdf recommends a new AVP c= alled PMIP-HOME-Prefix AVP which can be used within an AA-Request and AA-An= swer message, while a LMA registered a new mobile session (PBU) on the AAA = server. If the AAA server has authorized the mobile node and it has determi= ned that mobile node=92s HNP is not set, then the AAA server can act as DHC= P client and request the DHCP server for a prefix (IA_PD option) and send t= he assigned prefix within a AA-Answer message to the LMA, subsequently.
=
IMHO there is no need for a new Diameter Prefix Delegation application = regarding PMIP, as the mentioned draft defines a good solution to delegate a prefix from the AAA to the LMA --> AA-Request and the PMIP6-= Home-Prefix AVP.

May be I=92m wrong and you mean, that there should = be a new Diameter Prefix application with new command types, which can be u= sed ad-hoc without involving a AAA session registration exchange like the N= ASREQ application would it do with its AA-Request/Response messages.
Can you provide me some information on this, please? Are there already new= Ideas regarding a Diameter application for prefix delegation?


B= R,

Rafael.

--
Psssst! Schon vom neuen GMX MultiMessenger = geh=F6rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
--0-1996331479-1213281914=:54446-- --===============1584582055== 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://www.ietf.org/mailman/listinfo/dime --===============1584582055==-- From dime-bounces@ietf.org Thu Jun 12 23:13:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0874928C13A; Thu, 12 Jun 2008 23:13:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751F428C13A for ; Thu, 12 Jun 2008 23:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gJF-D1wyS+7 for ; Thu, 12 Jun 2008 23:13:43 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 65D6328C12F for ; Thu, 12 Jun 2008 23:13:42 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 08:14:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 08:14:11 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: mip6-split question regarding multiple coa support Thread-Index: AcjNHLJPWqxbgNAUQgWHtqqB4lz35w== From: To: X-OriginalArrivalTime: 13 Jun 2008 06:14:12.0284 (UTC) FILETIME=[B2D067C0:01C8CD1C] Subject: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, A quick question. This might be a bit forward leaning step but should we add a MIP6-Feature-Vector bit for multiple CoA support? The work on multiple CoA support in MEXT is doing OK and some point of time we will face that someone wants to have this capability.. Or would it be better to place it in a separate I-D with a bunch of other capability bits that folks want to add? Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 00:43:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A1E3A68C2; Fri, 13 Jun 2008 00:43:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881AF3A6778 for ; Fri, 13 Jun 2008 00:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5Nuu06ZHVjB for ; Fri, 13 Jun 2008 00:43:23 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 253403A68C2 for ; Fri, 13 Jun 2008 00:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1213343034; x=1244879034; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[Dime]=20mip6-split=20quest ion=20regarding=20multiple=20coa=20support|Date:=20Fri, =2013=20Jun=202008=2000:43:35=20-0700|Message-ID:=20|In-Reply-To:=20<59D7431DE2527D4CB0F1EFEDA5683ED302C7D 31B@SEHAN021MB.tcad.telia.se>|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[Dime]=20mip6-s plit=20question=20regarding=20multiple=20coa=20support |Thread-Index:=20AcjNHLJPWqxbgNAUQgWHtqqB4lz35wADEgRQ |References:=20<59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@ SEHAN021MB.tcad.telia.se>|From:=20"Giaretta,=20Gerardo" =20|To:=20,=20|X-OriginalArrivalTime:=2013 =20Jun=202008=2007:43:36.0532=20(UTC)=20FILETIME=3D[3027B 140:01C8CD29]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,216 0,5316"=3B=20a=3D"3898393"; bh=MTFaLF/aeHN5Ga7kb4mRl3AxOaeIPSM8Ex88KCKmV6M=; b=EfiagFcgn/EECOO8DwgjPmv2054fXaJQNP2qwjo+jQARO+bqHP3rWIh0 vCPJpFVeYmudv6B9gbRVyf3nfPAJQJjh1LFnBl2SQ1ak2DAiipJ0n5w7N QG9yXoH5tpA2eimyDFY8PxQp1rSoI0/xwEf5hDx9aXgcSqR403aG5l7cw I=; X-IronPort-AV: E=McAfee;i="5200,2160,5316"; a="3898393" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jun 2008 00:43:37 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5D7hbrt007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jun 2008 00:43:37 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5D7hav2020600; Fri, 13 Jun 2008 00:43:36 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 00:43:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 00:43:35 -0700 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] mip6-split question regarding multiple coa support Thread-Index: AcjNHLJPWqxbgNAUQgWHtqqB4lz35wADEgRQ References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> From: "Giaretta, Gerardo" To: , X-OriginalArrivalTime: 13 Jun 2008 07:43:36.0532 (UTC) FILETIME=[3027B140:01C8CD29] Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, As you mentioned the work in MEXT is pretty much complete and I am in favor of adding this bit right now. I don't see any reason why we should wait. The rationale of the bit is the same of other bits we have introduced as the information on authorization of MCoAs is part of the subscriber's profile and should be passed by the AAA to the HA. Thanks Gerardo > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > jouni.korhonen@teliasonera.com > Sent: Thursday, June 12, 2008 11:14 PM > To: dime@ietf.org > Subject: [Dime] mip6-split question regarding multiple coa support > > Hi all, > > A quick question. This might be a bit forward leaning step but > should we add a MIP6-Feature-Vector bit for multiple CoA support? > The work on multiple CoA support in MEXT is doing OK and some point > of time we will face that someone wants to have this capability.. > Or would it be better to place it in a separate I-D with a bunch > of other capability bits that folks want to add? > > Cheers, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 01:08:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE613A690E; Fri, 13 Jun 2008 01:08:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D59C3A68C2 for ; Fri, 13 Jun 2008 01:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWhO-dE75cz2 for ; Fri, 13 Jun 2008 01:08:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DA3023A690E for ; Fri, 13 Jun 2008 01:08:16 -0700 (PDT) Received: (qmail 32647 invoked by uid 0); 13 Jun 2008 08:08:46 -0000 Received: from 195.37.70.39 by www046.gmx.net with HTTP; Fri, 13 Jun 2008 10:08:46 +0200 (CEST) Date: Fri, 13 Jun 2008 10:08:46 +0200 From: SpawnRR@gmx.de Message-ID: <20080613080846.17720@gmx.net> MIME-Version: 1.0 To: dime@ietf.org X-Authenticated: #8754011 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+QSuluxeCQJo8xC79Dbc2C47oQk8wmMcz444Wzrr oZtc/sC0LIwDLW9aTlGlfhz6LZgRAPdb5+rA== X-GMX-UID: Pxl0YMWhLi50NXO372tpLz9rZml1ZJjO Subject: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGkgYWxsLAoKSXMgdGhlcmUgYWxyZWFkeSBhIGRyYWZ0IHJlZ2FyZGluZyBhIG5ldyBEaWFtZXRl ciBQcmVmaXggRGVsZWdhdGlvbiBhcHBsaWNhdGlvbj8gQ291bGQgc29tZWJvZHkgcHJvdmlkZSBt ZSB3aXRoIHNvbWUgbGlua3MgdG8gcmVsYXRlZCBkcmFmdHMsIHBsZWFzZT8gSSBoYXZlIGFscmVh ZHkgcmVhZCB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgKGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNhcmlrYXlhLWRpbWUtcHJlZml4LWRlbGVnYXRpb24tcHMt MDEudHh0KSBidXQgSSBjb3VsZG4ndCBmaW5kIGZ1cnRoZXIgaW5mb3JtYXRpb24uIAoKVGhlIERp YW1ldGVyIFByZWZpeCBEZWxlZ2F0aW9uIGFwcGxpY2F0aW9uIGlzIGEgdmVyeSBpbnRlcmVzdGlu ZyB0aGluZywgYW5kIEnigJltIHRoaW5raW5nIGFib3V0IHRvIHNldCB1cCBhIG93biBkcmFmdCBv biB0aGlzIHRvcGljLgoKQmVzdCByZWdhcmRzLAoKClJhZmFlbAoKLS0gCklzdCBJaHIgQnJvd3Nl ciBWaXN0YS1rb21wYXRpYmVsPyBKZXR6dCBkaWUgbmV1ZXN0ZW4gCkJyb3dzZXItVmVyc2lvbmVu IGRvd25sb2FkZW46IGh0dHA6Ly93d3cuZ214Lm5ldC9kZS9nby9icm93c2VyCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkRpTUUgbWFpbGluZyBsaXN0CkRp TUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Fri Jun 13 02:18:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EFF93A6B51; Fri, 13 Jun 2008 02:18:42 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54DB93A6B51 for ; Fri, 13 Jun 2008 02:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GT+XZcm8kYbK for ; Fri, 13 Jun 2008 02:18:40 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 7A2353A6B4F for ; Fri, 13 Jun 2008 02:18:40 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1522047and.122 for ; Fri, 13 Jun 2008 02:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=6qPEVqcslttbNiEY9nzWG08aZUgOy3uXq8SP65Np81c=; b=Bog+4OKzTCuwLY0Yf39tUlCe7lh3r0erhNehGMs9rCO7wnDVOzvWLClJbUvGymzqO6 ZUai+4Ii9J42qL7xTpzLO2xQ4S41d+u/6Psc74lvbOn24+uxC03PEv2KAJ94Bg8pOXlA VIHJjniAaEUGCxaa1asxt/xG+IeLaTskXY9lA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tjsK3pkJ5S6oVwtNxpfVxcD9PVEpS8f8hKkN5PSdP8iF6bZQmnZFnhOe5nZiZ15rIl ylwq924PWAkNF9J5CHTmO3Ou+ygcGy71LIhxgCn4P5C/p4GeJ8LXovOk/SktGiBO1mFs Pob0BdCtMA/cQNAqG5zQKFpCq7rgIAVlFmNcg= Received: by 10.100.127.18 with SMTP id z18mr3759413anc.79.1213348748868; Fri, 13 Jun 2008 02:19:08 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Fri, 13 Jun 2008 02:19:08 -0700 (PDT) Message-ID: <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> Date: Fri, 13 Jun 2008 11:19:08 +0200 From: "Julien Bournelle" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi jouni, all, could you explain a little bit more the purpose of this bit in the MCoA context ? thanks in advance, Julien On Fri, Jun 13, 2008 at 8:14 AM, wrote: > Hi all, > > A quick question. This might be a bit forward leaning step but > should we add a MIP6-Feature-Vector bit for multiple CoA support? > The work on multiple CoA support in MEXT is doing OK and some point > of time we will face that someone wants to have this capability.. > Or would it be better to place it in a separate I-D with a bunch > of other capability bits that folks want to add? > > Cheers, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 02:22:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0099E3A6B56; Fri, 13 Jun 2008 02:22:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0ECD3A6B56 for ; Fri, 13 Jun 2008 02:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD3SWKxymzpz for ; Fri, 13 Jun 2008 02:22:53 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 6EC783A6A76 for ; Fri, 13 Jun 2008 02:22:52 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 11:23:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 11:23:21 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D323@SEHAN021MB.tcad.telia.se> In-Reply-To: <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] mip6-split question regarding multiple coa support Thread-Index: AcjNNooe21A6I8dYQgCDjvH+n+O2QQAABhQg References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> From: To: X-OriginalArrivalTime: 13 Jun 2008 09:23:22.0526 (UTC) FILETIME=[2015E3E0:01C8CD37] Cc: dime@ietf.org Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien, Another policy & capability feature. The AAA might want to either allow or disallow the use of MCoA based on the subsctiption and operator policy. It could also be used to allow AAA to assign MCoA capable HA to the UE, in a case the HA does not indicate MCoA support but the subscription profile would allow using MCoA features. Cheers, Jouni > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] = > Sent: 13. kes=E4kuuta 2008 12:19 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: dime@ietf.org > Subject: Re: [Dime] mip6-split question regarding multiple coa support > = > = > Hi jouni, all, > = > could you explain a little bit more the purpose of this bit in the > MCoA context ? > = > thanks in advance, > = > Julien > = > On Fri, Jun 13, 2008 at 8:14 AM, = > wrote: > > Hi all, > > > > A quick question. This might be a bit forward leaning step but > > should we add a MIP6-Feature-Vector bit for multiple CoA support? > > The work on multiple CoA support in MEXT is doing OK and some point > > of time we will face that someone wants to have this capability.. > > Or would it be better to place it in a separate I-D with a bunch > > of other capability bits that folks want to add? > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 02:23:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBC33A6B5B; Fri, 13 Jun 2008 02:23:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAA13A6A76 for ; Fri, 13 Jun 2008 02:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOrBMcg5hJWN for ; Fri, 13 Jun 2008 02:23:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DC4AB3A6B5B for ; Fri, 13 Jun 2008 02:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1213349019; x=1244885019; h=x-mimeole:content-class:mime-version:content-type: content-transfer-encoding:subject:date:message-id: in-reply-to:x-ms-has-attach:x-ms-tnef-correlator: thread-topic:thread-index:references:from:to:cc: x-originalarrivaltime:x-ironport-av; z=X-MimeOLE:=20Produced=20By=20Microsoft=20Exchange=20V6.5 |Content-class:=20urn:content-classes:message |MIME-Version:=201.0|Content-Type:=20text/plain=3B=0D=0A =09charset=3D"us-ascii"|Content-Transfer-Encoding:=20quot ed-printable|Subject:=20RE:=20[Dime]=20mip6-split=20quest ion=20regarding=20multiple=20coa=20support|Date:=20Fri, =2013=20Jun=202008=2002:23:37=20-0700|Message-ID:=20|In-Reply-To:=20<5e2406980806130219w2a949027x1d3e5ef73 8ac86fb@mail.gmail.com>|X-MS-Has-Attach:=20 |X-MS-TNEF-Correlator:=20|Thread-Topic:=20[Dime]=20mip6-s plit=20question=20regarding=20multiple=20coa=20support |Thread-Index:=20AcjNNo8Bz0Y5iqCVQSi+dRs6kre35AAAGz5A |References:=20<59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@ SEHAN021MB.tcad.telia.se>=20<5e2406980806130219w2a949027x 1d3e5ef738ac86fb@mail.gmail.com>|From:=20"Giaretta,=20Ger ardo"=20|To:=20"Julien=20Bournelle "=20,=0D=0A=20=20=20=20=20=20 =20=20|Cc:=20|X-OriginalArrivalTime:=2013=20Jun=202008=2009:23:38.0 078=20(UTC)=20FILETIME=3D[295AEFE0:01C8CD37] |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5316"=3B=20 a=3D"3726223"; bh=q0JWuO/eATEVoZmESA7cYSJuc8JFdaQKmvYxzwLwT4w=; b=Xys7Bl/k2Ekb1Re2P7jeSEjVeKCX2sd0fsAGOEi8J5tpYfeG6NIA1D7L iszA/HpA46yjjcVk7HI6W3B9ipYJXIxMV/ACvGcc3Cmmeq6+KWeaOZGwe zs2kqrKtYAkyEGX+DzVu88z3Dp94HzTV95lIuT9Hae+hbVGyFj73dATOy Y=; X-IronPort-AV: E=McAfee;i="5200,2160,5316"; a="3726223" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jun 2008 02:23:39 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5D9Nc74017195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jun 2008 02:23:38 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m5D9Ncav013094; Fri, 13 Jun 2008 02:23:38 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jun 2008 02:23:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 02:23:37 -0700 Message-ID: In-Reply-To: <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] mip6-split question regarding multiple coa support Thread-Index: AcjNNo8Bz0Y5iqCVQSi+dRs6kre35AAAGz5A References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> From: "Giaretta, Gerardo" To: "Julien Bournelle" , X-OriginalArrivalTime: 13 Jun 2008 09:23:38.0078 (UTC) FILETIME=[295AEFE0:01C8CD37] Cc: dime@ietf.org Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien, I think the purpose is to provide authorization information to the HA based on the subscriber's profile. If the UE wants to use MCoAs registration, this should be explicitly authorized by the operator. I see this authorization information similar to the one on RO. Cheers Gerardo > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Julien Bournelle > Sent: Friday, June 13, 2008 2:19 AM > To: jouni.korhonen@teliasonera.com > Cc: dime@ietf.org > Subject: Re: [Dime] mip6-split question regarding multiple coa support > > Hi jouni, all, > > could you explain a little bit more the purpose of this bit in the > MCoA context ? > > thanks in advance, > > Julien > > On Fri, Jun 13, 2008 at 8:14 AM, wrote: > > Hi all, > > > > A quick question. This might be a bit forward leaning step but > > should we add a MIP6-Feature-Vector bit for multiple CoA support? > > The work on multiple CoA support in MEXT is doing OK and some point > > of time we will face that someone wants to have this capability.. > > Or would it be better to place it in a separate I-D with a bunch > > of other capability bits that folks want to add? > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 04:10:06 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251CF3A6890; Fri, 13 Jun 2008 04:10:06 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD683A6890 for ; Fri, 13 Jun 2008 04:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vDnKFNXZ+Xl for ; Fri, 13 Jun 2008 04:10:04 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id BE4D13A6845 for ; Fri, 13 Jun 2008 04:10:03 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1534474and.122 for ; Fri, 13 Jun 2008 04:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=PsgZytC2cW0eVUG+mpPv56K8cAv1j7LvNsVcCbfxyhM=; b=kuLNUhVpyRA1jYpynpLscljlS65+XRmyDeUeUFJYEqIpEDM44hvGL/4QDqAPjrSb5s KSgVL/CAeNqPtLI0i1c2Kk9pvs3QBNQmBmys4XHlzxlXCDGPe8MMV8ZjEa0KDZnDzMxs MvoQ/WA0StkaU2uqBQfFfkVHI2ES+0X8FNfrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=r28xLBcaLPeKpRm09Sfkelan4wFFz5HcVZ2Oa7c+R5eSWxgrFXzID6iVpRq9qEqeDG IemtO8IdCinpaDfw0akDbxqqWCkywJXVTlQHMV4ZWlluTA6N9/Hp5TtsVwQA9ZcXv6JJ 966ivALZU+u0koXD4fQcak5kN7BqKtnG1mYOk= Received: by 10.100.212.6 with SMTP id k6mr3915360ang.142.1213355434874; Fri, 13 Jun 2008 04:10:34 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Fri, 13 Jun 2008 04:10:34 -0700 (PDT) Message-ID: <5e2406980806130410n4e4d44ccjc55c184e7ecdddfd@mail.gmail.com> Date: Fri, 13 Jun 2008 13:10:34 +0200 From: "Julien Bournelle" To: "Giaretta, Gerardo" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> <5e2406980806130219w2a949027x1d3e5ef738ac86fb@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org thanks. Ok, so I'm ok to add this flag. Julien On Fri, Jun 13, 2008 at 11:23 AM, Giaretta, Gerardo wrote: > Hi Julien, > > I think the purpose is to provide authorization information to the HA > based on the subscriber's profile. If the UE wants to use MCoAs > registration, this should be explicitly authorized by the operator. I > see this authorization information similar to the one on RO. > > Cheers > Gerardo > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf > Of >> Julien Bournelle >> Sent: Friday, June 13, 2008 2:19 AM >> To: jouni.korhonen@teliasonera.com >> Cc: dime@ietf.org >> Subject: Re: [Dime] mip6-split question regarding multiple coa support >> >> Hi jouni, all, >> >> could you explain a little bit more the purpose of this bit in the >> MCoA context ? >> >> thanks in advance, >> >> Julien >> >> On Fri, Jun 13, 2008 at 8:14 AM, > wrote: >> > Hi all, >> > >> > A quick question. This might be a bit forward leaning step but >> > should we add a MIP6-Feature-Vector bit for multiple CoA support? >> > The work on multiple CoA support in MEXT is doing OK and some point >> > of time we will face that someone wants to have this capability.. >> > Or would it be better to place it in a separate I-D with a bunch >> > of other capability bits that folks want to add? >> > >> > Cheers, >> > Jouni >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.ietf.org/mailman/listinfo/dime >> > >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 04:37:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A643A6765; Fri, 13 Jun 2008 04:37:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38E03A6765 for ; Fri, 13 Jun 2008 04:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ux24Lbfsdjq for ; Fri, 13 Jun 2008 04:37:14 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 8D4703A66B4 for ; Fri, 13 Jun 2008 04:37:14 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA05.westchester.pa.mail.comcast.net with comcast id dPT41Z0070QuhwU5500V00; Fri, 13 Jun 2008 11:37:45 +0000 Received: from gwzPC ([124.120.222.249]) by OMTA02.westchester.pa.mail.comcast.net with comcast id dPan1Z0055PTu3g3NPd5bH; Fri, 13 Jun 2008 11:37:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=48vgC7mUAAAA:8 a=VVlED5B4AAAA:8 a=jwYYswTqAbSYPBj8PPwA:9 a=JjAZ64N5VXIbiWgwy2YA:7 a=qQbxawX3a1T9NfrA6IOxHIj4FXQA:4 a=lZB815dzVvQA:10 a=PoIT3gU5z9IA:10 From: "Glen Zorn" To: References: <20080613080846.17720@gmx.net> In-Reply-To: <20080613080846.17720@gmx.net> Date: Fri, 13 Jun 2008 18:34:25 +0700 Message-ID: <007b01c8cd49$bf65b6c0$3e312440$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcjNLL/JyDkEQTKxTgqTTDNizFpshQAELyvA Content-Language: en-us Cc: dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org U3Bhd25SUkBnbXguZGUgd3JpdGVzOgoKPiBIaSBhbGwsCj4gCj4gSXMgdGhlcmUgYWxyZWFkeSBh IGRyYWZ0IHJlZ2FyZGluZyBhIG5ldyBEaWFtZXRlciBQcmVmaXggRGVsZWdhdGlvbgo+IGFwcGxp Y2F0aW9uPyBDb3VsZCBzb21lYm9keSBwcm92aWRlIG1lIHdpdGggc29tZSBsaW5rcyB0byByZWxh dGVkCj4gZHJhZnRzLCBwbGVhc2U/IEkgaGF2ZSBhbHJlYWR5IHJlYWQgdGhlIHByb2JsZW0gc3Rh dGVtZW50IGRyYWZ0Cj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXNhcmlrYXlhLWRpbWUtcHJlZml4LQo+IGRlbGVnYXRpb24tcHMtMDEudHh0KSBidXQgSSBjb3Vs ZG4ndCBmaW5kIGZ1cnRoZXIgaW5mb3JtYXRpb24uCgpMb29raW5nIG92ZXIgdGhlIHJlZmVyZW5j ZWQgZHJhZnQsIGl0IHNlZW1zIEFGQUlDVCB0byBiZSBhbiBpbmFwcHJvcHJpYXRlIHVzZSBvZiBE aWFtZXRlci4gIEkgY2FuJ3QgZmluZCBhbnkgZXZpZGVuY2Ugb2YgYWN0dWFsIEFBQSB1c2FnZSBv ciBldmVuIGEgdXNlciAtLSBpdCBzZWVtcyB0aGF0IHRoZSBhdXRob3Igd2FudHMgdG8gdXNlIERp YW1ldGVyIGp1c3QgYXMgYSB0cmFuc3BvcnQgZm9yIGFyYml0cmFyeSBwcmVmaXhlcyAoSSdtIGNl cnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJlY3RlZCBvbiB0aGF0IHBvaW50LCBob3dldmVyKS4g IEknbSBsZWQgdG8gYmVsaWV2ZSB0aGlzIGJlY2F1c2Ugb2YgdGhlIGZvbGxvd2luZyBzdGF0ZW1l bnQgIltSRkM0ODE4XSBkZXNpZ25zIERlbGVnYXRlZC1JUHY2LVByZWZpeCBhdHRyaWJ1dGUgd2hp Y2ggaXMgdXNlZCBmb3IgZGVsZWdhdGluZyBwcmVmaXhlcy4gIEhvd2V2ZXIgaW4gW1JGQzQ4MThd LCB0aGUgcmVjb21tZW5kZWQgdXNhZ2Ugc2NlbmFyaW8gaXMgQUFBIHNlcnZlciBjb25maWd1cmVz IHRoZSBkZWxlZ2F0aW5nIHNlcnZlciB3aXRoIHNvbWUgcHJlZml4ZXMgYW5kIHRoZW4gREhDUCBQ cmVmaXggRGVsZWdhdGlvbiBbUkZDMzYzM10gY2FuIGJlIHVzZWQgdG8gZGVsZWdhdGUgdGhlc2Ug cHJlZml4ZXMgdG8gdGhlIHJlcXVlc3Rpbmcgcm91dGVyLiAgQWxzbyBEZWxlZ2F0ZWQtSVB2Ni1Q cmVmaXggY2FycmllcyBhIG51bWJlciBvZiBwcmVmaXhlcyBvbmx5LiAgTGlmZXRpbWUgdmFsdWVz IGZvciBlYWNoIHByZWZpeCBjYW4gbm90IGJlIGNhcnJpZWQuIiAgSSBjYW4ndCB0aGluayBvZiBh IHJlYXNvbiwgaWYgdGhlIGRlbGVnYXRlZCBwcmVmaXhlcyB3ZXJlIGZvciBhIGh1bWFuIHVzZXIs IHdoeSB0aGUgbGlmZXRpbWUgb2YgdGhlIHByZWZpeGVzIHdvdWxkIG5vdCBiZSBqdXN0IGFzIGxv bmcgYXMgdGhlIHVzZXIgc2Vzc2lvbi4KCj4gCj4gVGhlIERpYW1ldGVyIFByZWZpeCBEZWxlZ2F0 aW9uIGFwcGxpY2F0aW9uIGlzIGEgdmVyeSBpbnRlcmVzdGluZyB0aGluZywKPiBhbmQgSeKAmW0g dGhpbmtpbmcgYWJvdXQgdG8gc2V0IHVwIGEgb3duIGRyYWZ0IG9uIHRoaXMgdG9waWMuCj4gCj4g QmVzdCByZWdhcmRzLAo+IAo+IAo+IFJhZmFlbAo+IAo+IC0tCj4gSXN0IElociBCcm93c2VyIFZp c3RhLWtvbXBhdGliZWw/IEpldHp0IGRpZSBuZXVlc3Rlbgo+IEJyb3dzZXItVmVyc2lvbmVuIGRv d25sb2FkZW46IGh0dHA6Ly93d3cuZ214Lm5ldC9kZS9nby9icm93c2VyCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBEaU1FIG1haWxpbmcgbGlzdAo+ IERpTUVAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp bWUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpEaU1F IG1haWxpbmcgbGlzdApEaU1FQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Fri Jun 13 05:29:06 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6996D3A676A; Fri, 13 Jun 2008 05:29:06 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F369B3A676A for ; Fri, 13 Jun 2008 05:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07F8VbQ35Vf2 for ; Fri, 13 Jun 2008 05:29:04 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.235]) by core3.amsl.com (Postfix) with ESMTP id CF41C3A63CB for ; Fri, 13 Jun 2008 05:29:03 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so2649930wra.17 for ; Fri, 13 Jun 2008 05:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=XWxv0gzRXVdrHcj+bamlvjdfARDrjq6cHh4eOS9Cf40=; b=sK48JvWldnpVbeY84cloEO3gGsEBNStntda6NdYE7OL0sz7qKLiR736RCVXq4F7FFv NsvTeikoTfpYPq7orN6/mXn09cKCOD4XZ8AehKFWFnwdOvqcYCtYxL05A5Yh/h9n8ygT YlEpuwcqw4wrOKa2PSDgy4zPOUAd0b5ASdE/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QoaFva/q0MzD7lrBBC+/7hOnT3q9vTuo91ZUeoPuhhc7+VIDuDFYGsvLRUR+77XRSW KsV/5T0RAOHWPfVLVcHHsvTqHWeBJkAnI9mdCFMqBgvNacXna2En3QiqfYM+v7ctQDrt azHFtiKIA/Vd2G5LC5JYD4X/LSZJJa3tpwbnE= Received: by 10.100.215.5 with SMTP id n5mr4095492ang.99.1213360173144; Fri, 13 Jun 2008 05:29:33 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Fri, 13 Jun 2008 05:29:33 -0700 (PDT) Message-ID: <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> Date: Fri, 13 Jun 2008 14:29:33 +0200 From: "Julien Bournelle" To: "Glen Zorn" In-Reply-To: <007b01c8cd49$bf65b6c0$3e312440$@net> MIME-Version: 1.0 Content-Disposition: inline References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> Cc: SpawnRR@gmx.de, dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org hi all, I second Glen's comments. Moreover, after a quick look to the Problem Statement draft, I think that for section 4.1 (AR) and section 4.2 you can delegate prefix during the network access authentication/authorization phase. For NEMO case, I thought that DHCPv6 or even IKEv2 may be used. Regards, Julien On Fri, Jun 13, 2008 at 1:34 PM, Glen Zorn wrote: > SpawnRR@gmx.de writes: > >> Hi all, >> >> Is there already a draft regarding a new Diameter Prefix Delegation >> application? Could somebody provide me with some links to related >> drafts, please? I have already read the problem statement draft >> (http://www.ietf.org/internet-drafts/draft-sarikaya-dime-prefix- >> delegation-ps-01.txt) but I couldn't find further information. > > Looking over the referenced draft, it seems AFAICT to be an inappropriate use of Diameter. I can't find any evidence of actual AAA usage or even a user -- it seems that the author wants to use Diameter just as a transport for arbitrary prefixes (I'm certainly willing to be corrected on that point, however). I'm led to believe this because of the following statement "[RFC4818] designs Delegated-IPv6-Prefix attribute which is used for delegating prefixes. However in [RFC4818], the recommended usage scenario is AAA server configures the delegating server with some prefixes and then DHCP Prefix Delegation [RFC3633] can be used to delegate these prefixes to the requesting router. Also Delegated-IPv6-Prefix carries a number of prefixes only. Lifetime values for each prefix can not be carried." I can't think of a reason, if the delegated prefixes were for a human user, why the lifetime of the prefixes would not be just as long as the user session. > >> >> The Diameter Prefix Delegation application is a very interesting thing, >> and I'm thinking about to set up a own draft on this topic. >> >> Best regards, >> >> >> Rafael >> >> -- >> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten >> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 06:00:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07A93A6995; Fri, 13 Jun 2008 06:00:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F48D3A6995 for ; Fri, 13 Jun 2008 06:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Xtwk4cA0KqD for ; Fri, 13 Jun 2008 06:00:06 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id A95CB3A69C1 for ; Fri, 13 Jun 2008 06:00:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5DD0Y126432; Fri, 13 Jun 2008 13:00:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jun 2008 07:59:40 -0500 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] mip6-split question regarding multiple coa support Thread-Index: AcjNHLJPWqxbgNAUQgWHtqqB4lz35wAOF90A References: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D31B@SEHAN021MB.tcad.telia.se> From: "Ahmad Muhanna" To: , Subject: Re: [Dime] mip6-split question regarding multiple coa support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, I believe it is a good idea to add it. Regards, Ahmad > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of jouni.korhonen@teliasonera.com > Sent: Friday, June 13, 2008 1:14 AM > To: dime@ietf.org > Subject: [Dime] mip6-split question regarding multiple coa support > > Hi all, > > A quick question. This might be a bit forward leaning step > but should we add a MIP6-Feature-Vector bit for multiple CoA support? > The work on multiple CoA support in MEXT is doing OK and some > point of time we will face that someone wants to have this > capability.. > Or would it be better to place it in a separate I-D with a > bunch of other capability bits that folks want to add? > > Cheers, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 13 08:42:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91433A69AA; Fri, 13 Jun 2008 08:42:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDCE3A69AA for ; Fri, 13 Jun 2008 08:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0spkypSyDPDD for ; Fri, 13 Jun 2008 08:42:11 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 40B8B3A698D for ; Fri, 13 Jun 2008 08:42:11 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2E00FFORN5AF@usaga04-in.huawei.com> for dime@ietf.org; Fri, 13 Jun 2008 10:42:42 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2E0034NRN3Q8@usaga04-in.huawei.com> for dime@ietf.org; Fri, 13 Jun 2008 10:42:41 -0500 (CDT) Date: Fri, 13 Jun 2008 10:42:39 -0500 From: Frank Xia To: Glen Zorn , SpawnRR@gmx.de Message-id: <002201c8cd6c$1d498a60$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> Cc: dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGkgIEdsZW4KClRoYW5rIGZvciB5b3VyIGNvbW1lbnRzLCAgYW5kIHdlIHdpbGwgY29uc2lkZXIK eW91ciBjb25jZXJucyB3aGVuIHVwZGF0aW5nLgoKQXMgdG8gcHJlZml4IG1hbmFnZW1lbnQsIHRo ZXJlIGFyZSB0d28gd2F5cyBpbgp0aGUgaW5kdXN0cnkgKDNHUFAvM0dQUDIvV2lNQVgpLCB0aGF0 IGlzLApESENQKFJGQzM2MzMpIGFuZCBBQUEuCgpIb3dldmVyLCB0aGVyZSBpcyBub3QgYSB3aG9s ZSBwcmVmaXggZGVsZWdhdGlvbgpzb2x1dGlvbiB3aGljaCBpcyBzdXBwb3NlZCB0byBpbmNsdWRl CmFsbG9jYXRpbmcvcmVuZXdpbmcvcmVsZWFzaW5nIG9wZXJhdGlvbi4KRXZlbiB3b3JzZSwgbm8g Y3VycmVudCBBQUEgcHJlZml4IHNvbHV0aW9uCnN1cHBvcnRzICBJUHY2IHJlbnVtYmVyaW5nLgoK U28gd2UgcHJvcG9zZSB0aGUgRGlhbWV0ZXIgcHJlZml4IG1hbmFnZQphcHBsaWNhdGlvbiB0byBk ZWFsIHdpdGggdGhlIHByb2JsZW0uCgpQbGVhc2UgYXNsbyByZWZlciB0byBteSBpbmxpbmUgcmVw bHkuLgoKQlIKRnJhbmsKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gCkZyb206ICJHbGVu IFpvcm4iIDxnbGVuem9ybkBjb21jYXN0Lm5ldD4KVG86IDxTcGF3blJSQGdteC5kZT4KQ2M6IDxk aW1lQGlldGYub3JnPjsgPHNhcmlrYXlhQGllZWUub3JnPjsgPHhpYXlhbmdzb25nQGh1YXdlaS5j b20+OyAKPEpvdW5pLmtvcmhvbmVuQHRlbGlhc29uZXJhLmNvbT4KU2VudDogRnJpZGF5LCBKdW5l IDEzLCAyMDA4IDY6MzQgQU0KU3ViamVjdDogUkU6IFtEaW1lXSBEaWFtZXRlciBQcmVmaXggRGVs ZWdhdGlvbiBBcHBsaWNhdGlvbgoKClNwYXduUlJAZ214LmRlIHdyaXRlczoKCj4gSGkgYWxsLAo+ Cj4gSXMgdGhlcmUgYWxyZWFkeSBhIGRyYWZ0IHJlZ2FyZGluZyBhIG5ldyBEaWFtZXRlciBQcmVm aXggRGVsZWdhdGlvbgo+IGFwcGxpY2F0aW9uPyBDb3VsZCBzb21lYm9keSBwcm92aWRlIG1lIHdp dGggc29tZSBsaW5rcyB0byByZWxhdGVkCj4gZHJhZnRzLCBwbGVhc2U/IEkgaGF2ZSBhbHJlYWR5 IHJlYWQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0Cj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNhcmlrYXlhLWRpbWUtcHJlZml4LQo+IGRlbGVnYXRpb24t cHMtMDEudHh0KSBidXQgSSBjb3VsZG4ndCBmaW5kIGZ1cnRoZXIgaW5mb3JtYXRpb24uCgpMb29r aW5nIG92ZXIgdGhlIHJlZmVyZW5jZWQgZHJhZnQsIGl0IHNlZW1zIEFGQUlDVCB0byBiZSBhbiBp bmFwcHJvcHJpYXRlIAp1c2Ugb2YgRGlhbWV0ZXIuICBJIGNhbid0IGZpbmQgYW55IGV2aWRlbmNl IG9mIGFjdHVhbCBBQUEgdXNhZ2Ugb3IgZXZlbiBhIAp1c2VyIC0tIGl0IHNlZW1zIHRoYXQgdGhl IGF1dGhvciB3YW50cyB0byB1c2UgRGlhbWV0ZXIganVzdCBhcyBhIHRyYW5zcG9ydCAKZm9yIGFy Yml0cmFyeSBwcmVmaXhlcyAoSSdtIGNlcnRhaW5seSB3aWxsaW5nIHRvIGJlIGNvcnJlY3RlZCBv biB0aGF0IHBvaW50LCAKaG93ZXZlcikuCkZyYW5rPT5UaGUgRGlhbWV0ZXIgYXBwbGljYXRpb24g YWxzbyBpbmNsdWRlcyBhbGxvY2F0aW5nL3JlbmV3aW5nL3JlbGVhc2luZyAKcHJlZml4IG9wZXJh dGlvbi4KCkknbSBsZWQgdG8gYmVsaWV2ZSB0aGlzIGJlY2F1c2Ugb2YgdGhlIGZvbGxvd2luZyBz dGF0ZW1lbnQgIltSRkM0ODE4XSAKZGVzaWducyBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXggYXR0cmli dXRlIHdoaWNoIGlzIHVzZWQgZm9yIGRlbGVnYXRpbmcgCnByZWZpeGVzLiAgSG93ZXZlciBpbiBb UkZDNDgxOF0sIHRoZSByZWNvbW1lbmRlZCB1c2FnZSBzY2VuYXJpbyBpcyBBQUEgCnNlcnZlciBj b25maWd1cmVzIHRoZSBkZWxlZ2F0aW5nIHNlcnZlciB3aXRoIHNvbWUgcHJlZml4ZXMgYW5kIHRo ZW4gREhDUCAKUHJlZml4IERlbGVnYXRpb24gW1JGQzM2MzNdIGNhbiBiZSB1c2VkIHRvIGRlbGVn YXRlIHRoZXNlIHByZWZpeGVzIHRvIHRoZSAKcmVxdWVzdGluZyByb3V0ZXIuICBBbHNvIERlbGVn YXRlZC1JUHY2LVByZWZpeCBjYXJyaWVzIGEgbnVtYmVyIG9mIHByZWZpeGVzIApvbmx5LiAgTGlm ZXRpbWUgdmFsdWVzIGZvciBlYWNoIHByZWZpeCBjYW4gbm90IGJlIGNhcnJpZWQuIiAgSSBjYW4n dCB0aGluayAKb2YgYSByZWFzb24sIGlmIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ZXMgd2VyZSBmb3Ig YSBodW1hbiB1c2VyLCB3aHkgdGhlIApsaWZldGltZSBvZiB0aGUgcHJlZml4ZXMgd291bGQgbm90 IGJlIGp1c3QgYXMgbG9uZyBhcyB0aGUgdXNlciBzZXNzaW9uLgpGcmFuaz0+SWYgdGhlIHVzZXIg aXMgYWx3YXlzIG9uIGxpbmUgIGFuZCBpdCBpcyBhbHNvIG5lY2Vzc2FyeSB0bwpyZW51bWJlciB1 c2VyIGFkZHJlc3MgYmVjYXVzZSBvZiAgcmVzb3VyY2Ugb3B0aW1pemF0aW9uLApyZWd1bGF0aW9u IHBvbGljeSBhbmQgc28gb24sIGl0IGlzIGJldHRlciB0byBkZWNvdXBsZSB1c2VyJ3Mgc2Vzc2lv biB0aW1lCmFuZCB1c2VyJ3MgSVAgYWRkcmVzcyBsaWZldGltZQoKPgo+IFRoZSBEaWFtZXRlciBQ cmVmaXggRGVsZWdhdGlvbiBhcHBsaWNhdGlvbiBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgdGhpbmcs Cj4gYW5kIEnigJltIHRoaW5raW5nIGFib3V0IHRvIHNldCB1cCBhIG93biBkcmFmdCBvbiB0aGlz IHRvcGljLgo+Cj4gQmVzdCByZWdhcmRzLAo+Cj4KPiBSYWZhZWwKPgo+IC0tCj4gSXN0IElociBC cm93c2VyIFZpc3RhLWtvbXBhdGliZWw/IEpldHp0IGRpZSBuZXVlc3Rlbgo+IEJyb3dzZXItVmVy c2lvbmVuIGRvd25sb2FkZW46IGh0dHA6Ly93d3cuZ214Lm5ldC9kZS9nby9icm93c2VyCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBEaU1FIG1haWxp bmcgbGlzdAo+IERpTUVAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWUKCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkRpTUUgbWFpbGluZyBsaXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Fri Jun 13 08:58:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30103A69F4; Fri, 13 Jun 2008 08:58:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF16A3A69EC for ; Fri, 13 Jun 2008 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwmTpNTGDGyq for ; Fri, 13 Jun 2008 08:58:24 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 993743A69D0 for ; Fri, 13 Jun 2008 08:58:24 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2E00FO6SE7AF@usaga04-in.huawei.com> for dime@ietf.org; Fri, 13 Jun 2008 10:58:55 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2E0037KSE5Q8@usaga04-in.huawei.com> for dime@ietf.org; Fri, 13 Jun 2008 10:58:55 -0500 (CDT) Date: Fri, 13 Jun 2008 10:58:53 -0500 From: Frank Xia To: Julien Bournelle , Glen Zorn Message-id: <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> Cc: SpawnRR@gmx.de, dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien Thank for your comments! Just as IPv4 address management needs not only DHCPv4 solution but also AAA mechanisms, IPv6 prefix management as an extension of address mangement also needs corresponding facilitis. Please also check my inline reply... BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Glen Zorn" Cc: ; ; Sent: Friday, June 13, 2008 7:29 AM Subject: Re: [Dime] Diameter Prefix Delegation Application > hi all, > > I second Glen's comments. > > Moreover, after a quick look to the Problem Statement draft, I think > that for section 4.1 (AR) and section 4.2 you can delegate prefix > during the network access authentication/authorization phase. For NEMO > case, I thought that DHCPv6 > or even IKEv2 may be used. Frank=>As a complement of NEMO DHCPv6 soution, Diameter can also be used for prefix management. >From AAA perspective, IMHO, prefix mangement is a kind of authorization which is possibly decoupled from authentication. For example, prefix lifetime renew is not supposed to take place during authentication stage. > > Regards, > > Julien > > On Fri, Jun 13, 2008 at 1:34 PM, Glen Zorn wrote: >> SpawnRR@gmx.de writes: >> >>> Hi all, >>> >>> Is there already a draft regarding a new Diameter Prefix Delegation >>> application? Could somebody provide me with some links to related >>> drafts, please? I have already read the problem statement draft >>> (http://www.ietf.org/internet-drafts/draft-sarikaya-dime-prefix- >>> delegation-ps-01.txt) but I couldn't find further information. >> >> Looking over the referenced draft, it seems AFAICT to be an inappropriate >> use of Diameter. I can't find any evidence of actual AAA usage or even a >> user -- it seems that the author wants to use Diameter just as a >> transport for arbitrary prefixes (I'm certainly willing to be corrected >> on that point, however). I'm led to believe this because of the >> following statement "[RFC4818] designs Delegated-IPv6-Prefix attribute >> which is used for delegating prefixes. However in [RFC4818], the >> recommended usage scenario is AAA server configures the delegating server >> with some prefixes and then DHCP Prefix Delegation [RFC3633] can be used >> to delegate these prefixes to the requesting router. Also >> Delegated-IPv6-Prefix carries a number of prefixes only. Lifetime values >> for each prefix can not be carried." I can't think of a reason, if the >> delegated prefixes were for a human user, why the lifetime of the >> prefixes would not be just as long as the user session. >> >>> >>> The Diameter Prefix Delegation application is a very interesting thing, >>> and I'm thinking about to set up a own draft on this topic. >>> >>> Best regards, >>> >>> >>> Rafael >>> >>> -- >>> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten >>> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jun 14 07:25:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6243A68C8; Sat, 14 Jun 2008 07:25:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F273A68C8 for ; Sat, 14 Jun 2008 07:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZFNlVIMbGQB for ; Sat, 14 Jun 2008 07:24:59 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id AFB153A63D2 for ; Sat, 14 Jun 2008 07:24:59 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1685443and.122 for ; Sat, 14 Jun 2008 07:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=3FIW9JIQkbwa2auQ7kJaP+BQN7S3BeVVmdoaqsUAwto=; b=IyF79cjE8k3rV3u2oi3Ujz5QFfWv2Q1PVuas2w+O7p7UohzXRs9EMSet6Tg4ycZ0sT P4K1yK6niGBwEkzLVmKFUmAw69Zgu9E5HQt/FEf/kNV72y+mhavezLfesVcbsfvCL8w1 IEAfoNnr1uhp/PTzlo4nrq5g2O33ZYoGvWpqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rzzKkGuNzqjKLiNe7zdEwHpS9ipR2wajefuM+UPejShURxFeqiA8AUDjImGCXwWz+8 /E3Zt64n0PrHzfihGAl2PQI7xVIB0Eb9vzQYxNi8Em5/8Ivbfz6h81LMtln9DpEetK/q bsmDIBJWxb5zqmwctHjMfzeXyi758o8qoFABQ= Received: by 10.100.105.15 with SMTP id d15mr5657894anc.137.1213453531837; Sat, 14 Jun 2008 07:25:31 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Sat, 14 Jun 2008 07:25:31 -0700 (PDT) Message-ID: <5e2406980806140725h6b4fba27g21eac2fb65b17b5b@mail.gmail.com> Date: Sat, 14 Jun 2008 16:25:31 +0200 From: "Julien Bournelle" To: "Frank Xia" In-Reply-To: <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> Cc: dime@ietf.org, SpawnRR@gmx.de, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Frank, see inline, On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia wrote: > Hi Julien > > Thank for your comments! > > Just as IPv4 address management needs not only > DHCPv4 solution but also AAA mechanisms, > IPv6 prefix management as an extension of > address mangement also needs corresponding > facilitis. we already have some facilities. That was the point of my mail. see below... >> Moreover, after a quick look to the Problem Statement draft, I think >> that for section 4.1 (AR) and section 4.2 you can delegate prefix >> during the network access authentication/authorization phase. For NEMO >> case, I thought that DHCPv6 >> or even IKEv2 may be used. > > Frank=>As a complement of NEMO DHCPv6 soution, > Diameter can also be used for prefix management. > From AAA perspective, IMHO, prefix mangement is a > kind of authorization which is possibly decoupled > from authentication. For example, prefix lifetime renew is > not supposed to take place during authentication stage. IMHO, the prefix lifetime is tied to the session lifetime. I don't see why we would change the allocated prefix during the session. This would break all connections. Maybe you have a specific scenario in mind ? Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jun 14 11:51:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960663A6846; Sat, 14 Jun 2008 11:51:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB4F3A6846 for ; Sat, 14 Jun 2008 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsIS4sZqPWdV for ; Sat, 14 Jun 2008 11:51:34 -0700 (PDT) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by core3.amsl.com (Postfix) with ESMTP id 63C3C3A6805 for ; Sat, 14 Jun 2008 11:51:33 -0700 (PDT) X-ORBL: [70.244.175.188] Received: from X24512z (ppp-70-244-175-188.dsl.rcsntx.swbell.net [70.244.175.188]) by nlpi101.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m5EIq00Q030171; Sat, 14 Jun 2008 13:52:04 -0500 Message-ID: <001601c8ce4f$bbcd47b0$0601a8c0@china.huawei.com> From: "Frank Xia" To: "Julien Bournelle" References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> <5e2406980806140725h6b4fba27g21eac2fb65b17b5b@mail.gmail.com> Date: Sat, 14 Jun 2008 13:51:59 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: dime@ietf.org, SpawnRR@gmx.de, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien Please check my long inline relpy :) ... BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Frank Xia" Cc: "Glen Zorn" ; ; ; Sent: Saturday, June 14, 2008 9:25 AM Subject: Re: [Dime] Diameter Prefix Delegation Application > Hi Frank, > > see inline, > > On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia wrote: >> Hi Julien >> >> Thank for your comments! >> >> Just as IPv4 address management needs not only >> DHCPv4 solution but also AAA mechanisms, >> IPv6 prefix management as an extension of >> address mangement also needs corresponding >> facilitis. > > we already have some facilities. That was the point of my mail. Frank=>Diameter Prefix Delegation application is a complementary not exclusive solution to the current existing facilitis. It is useful for a variety of deployment scenarios which are possible beyond our reasoning imagination. Here is my argument, why do we need AAA solution for IPv4 address management while there is a DHCP method? > > see below... > > >>> Moreover, after a quick look to the Problem Statement draft, I think >>> that for section 4.1 (AR) and section 4.2 you can delegate prefix >>> during the network access authentication/authorization phase. For NEMO >>> case, I thought that DHCPv6 >>> or even IKEv2 may be used. >> >> Frank=>As a complement of NEMO DHCPv6 soution, >> Diameter can also be used for prefix management. >> From AAA perspective, IMHO, prefix mangement is a >> kind of authorization which is possibly decoupled >> from authentication. For example, prefix lifetime renew is >> not supposed to take place during authentication stage. > > IMHO, the prefix lifetime is tied to the session lifetime. I don't see > why we would change the allocated prefix during the session. This would > break all connections. Maybe you have a specific scenario in mind ? Frank=>As for concept session, probably we should differient it's meaning on different layers. In the context we are discussing, I would like to introduce IP session and application session. IP session simply means IP connectivity which is established after successful authentication. Application session, such as SKYPE, should be established on demand. When you are talking about that "prefix lifetime is tied to the session lifetime", I think this session is IP session. When you are talking about that "This would break all connections", I think that the connections mean application sessions. It makes sense that changing an IP address in one IP session. A DHCPv6 server can triger a client to re-configure it ip address. A operator wants to renumber it networks( although this is not a frequent practice). All the subscribers should replace their old prefixes by new advertised prefixes. During renumbering time(a couple of hours or days), old application sessions continue using old IP addresses while new application sessions begin to use new IP addresses The following are some references on renumbering. It is probably helpful to make myself clear. RFC 1916: Enterprise Renumbering: Experience and Information Solicitation RFC2071: Network Renumbering Overview: Why would I want it and what is it anyway? RFC 2072: Router Renumbering Guide RFC2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering . RFC2894: Router Renumbering for IPv6 RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day Have a nice weekend and enjoy Euro Soccer Championship! > > Regards, > > Julien > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 15 00:49:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3AD3A689C; Sun, 15 Jun 2008 00:49:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CE6B3A6938 for ; Sun, 15 Jun 2008 00:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wbi0Mm0omhh for ; Sun, 15 Jun 2008 00:48:57 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 4552C3A68EF for ; Sun, 15 Jun 2008 00:48:55 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA10.westchester.pa.mail.comcast.net with comcast id e7pL1Z0070QuhwU5A00200; Sun, 15 Jun 2008 07:49:31 +0000 Received: from gwzPC ([124.121.211.187]) by OMTA02.westchester.pa.mail.comcast.net with comcast id e7op1Z005438swU3N7pE6J; Sun, 15 Jun 2008 07:49:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=TqFxHlnLKdO6aMk-gmoA:9 a=3b2KaWfgHSyVUyMUqqkA:7 a=EttpfqHEBESWNgxcvG3qPO6q_34A:4 a=hPjdaMEvmhQA:10 a=iYlkOlhu7C0A:10 From: "Glen Zorn" To: "'Frank Xia'" References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> <5e2406980806140725h6b4fba27g21eac2fb65b17b5b@mail.gmail.com> <001601c8ce4f$bbcd47b0$0601a8c0@china.huawei.com> In-Reply-To: <001601c8ce4f$bbcd47b0$0601a8c0@china.huawei.com> Date: Sun, 15 Jun 2008 14:48:15 +0700 Message-ID: <001601c8cebc$38a1a3f0$a9e4ebd0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcjOT75FusXKaok6QM6nUPRgBREvQQAVRFTg Content-Language: en-us Cc: SpawnRR@gmx.de, dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Frank Xia [mailto:xiayangsong@huawei.com] writes: > > Hi Frank, > > > > see inline, > > > > On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia > wrote: > >> Hi Julien > >> > >> Thank for your comments! > >> > >> Just as IPv4 address management needs not only > >> DHCPv4 solution but also AAA mechanisms, > >> IPv6 prefix management as an extension of > >> address mangement also needs corresponding > >> facilitis. > > > > we already have some facilities. That was the point of my mail. > > Frank=>Diameter Prefix Delegation application is a > complementary not exclusive solution to > the current existing facilitis. It is useful for a variety of > deployment > scenarios which are possible beyond our reasoning imagination. > > Here is my argument, why do we need AAA solution for IPv4 > address management while there is a DHCP method? What do you mean by "IPv4 address management"? It is possible for both RADIUS & Diameter to assign IPv4 addresses to user machines but that is hardly "management" as I understand the term. Are there other capabilities of which I am unaware? ... > A operator wants to renumber it networks( although > this is not a frequent practice). All the subscribers should > replace their old prefixes by new advertised prefixes. Just my point: Diameter is _not_ a general purpose network management protocol & shouldn't become one. > During renumbering time(a couple of hours or days), > old application sessions continue using old IP addresses > while new application sessions begin to use new IP addresses > > The following are some references on renumbering. The question isn't whether renumbering is a problem, it's if Diameter is the right solution to that problem. Just because you have a hammer doesn't mean that everything is a nail :-)... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 16 06:10:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B89E3A6A23; Mon, 16 Jun 2008 06:10:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3063A6A1C for ; Mon, 16 Jun 2008 06:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IabkGKUGksCR for ; Mon, 16 Jun 2008 06:10:47 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 6A95D3A6A0B for ; Mon, 16 Jun 2008 06:10:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,652,1204520400"; d="scan'208";a="111392302" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Jun 2008 09:11:26 -0400 X-IronPort-AV: E=Sophos;i="4.27,652,1204520400"; d="scan'208";a="219137141" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Jun 2008 09:11:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 15:11:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-diameter-api Thread-Index: AcjPsnnM0s+OdARhQ3G7S3WiLTt2Kg== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-diameter-api X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Please find below the AD review of draft-ietf-dime-diameter-api. I have divided the comments into Technical and Editorial. Although the document has reached a certain level of maturity it looks like another I-D would be needed before we can go to IETF Last Call. I suggest to address in the revised I-D also comments from other reviewers, I have seen comments from Sebastien Decugis, there may be other. Thanks and Regards, Dan Technical Comments T1. Section 1 - using the term 'standardized API' is not appropriate. The WG charter speaks about 'An informational RFC on a Diameter API' and the document itself targets Informational. It looks like the document should not claim that the API described here is the 'standardized' API. T2. The typedef enum in Section 3.1.12 is copied twice, and never closes - missing probably } AAAReturnCodes; T3. The data types in Section 3.1.14 do not correspond with the data types defined in Section 4.2 of RFC3588 (missing Unsigned32, Unsigned64, Float32, Float64) T4. The list of result codes returned from remote servers in Section 3.1.18 does not seem to match anything from RFC3588. I am looking at Section 7.1. Do I need to look into some other place? Editorial Comments E1 Section 3.1.7 has the wrong title - it should probably be 'Server Identifier' or 'Serving Peer Identifier' E2 - section 3.1.12 - AAA_ERR_NOMEM: This code is returned if the operation caused memory to be exhausted. In reality it is not necessarily this operation that caused memory to be exhausted. I believe that a more accurate description would be 'The code is returned if there is no enough memory to execute the operation'. E3 - section 3.1.20 seems to have borrowed text from 3.1.19. It would also benefit from a short explanation of each field E4 - The descriptions of the various functions in section 3.4 are inconsistent in mentioning when fields refer to pointers (sometimes they do , sometimes the do not) E5 - Section 3.7, pag. 40 - in the first paragraph, third sentence the word 'directly' appears twice _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 16 08:40:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5783A682A; Mon, 16 Jun 2008 08:40:21 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411523A697C for ; Mon, 16 Jun 2008 08:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv+Iw6jSSbej for ; Mon, 16 Jun 2008 08:40:19 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id C113C3A682A for ; Mon, 16 Jun 2008 08:40:18 -0700 (PDT) Received: (qmail 20443 invoked by uid 60001); 16 Jun 2008 15:40:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=q3hGmZ2ABp9IhbBv3+nY1byztyNPyGM3E8+FuokVAIa7lYDQai5MdIAm8w/oAJ2oZsT8AtV7Fy7UjQTrR0TURtAk4k7aznd6SYHsPSYuDsoWXjO26ujbH2shfbKFlTN2DgA2k7u+iKPzgWsZo16tL7ZqmOR1zhzCmLlj6i3edts=; X-YMail-OSG: 4xBK3isVM1nX6Lrv90jA0.N0mVD1kQIo4Bn6qlSidHCIV3FROoYKg55xr_Xa9g09azkevKhkOYN8iNWB_Y7SZ2qoOGi7dfV3niJzPjCZ2Z5dlbNZsnFMMZ7jPFg- Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Mon, 16 Jun 2008 08:40:56 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Mon, 16 Jun 2008 08:40:56 -0700 (PDT) From: Behcet Sarikaya To: dime@ietf.org MIME-Version: 1.0 Message-ID: <300142.18400.qm@web84303.mail.re1.yahoo.com> Subject: [Dime] Fw: Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0752799167==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0752799167== Content-Type: multipart/alternative; boundary="0-1698814402-1213630856=:18400" --0-1698814402-1213630856=:18400 Content-Type: text/plain; charset=us-ascii forwarding to dime list. ----- Forwarded Message ---- From: Behcet Sarikaya To: Glen Zorn Sent: Monday, June 16, 2008 10:36:49 AM Subject: Re: [Dime] Diameter Prefix Delegation Application Hi Glen, Prefixes are used to subnet a given network. The address assignment comes next based on the prefix. Subneting a network is done by the network administration/management. draft-sarikaya-dime-prefix-delegation-ps suggests that AAA can be used in prefix delegation (from a delegating server to a requesting server) just like AAA is currently being used for address assignment. More details like per-MN prefix use in cellular links are in the draft. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: SpawnRR@gmx.de; dime@ietf.org; Jouni.korhonen@teliasonera.com Sent: Sunday, June 15, 2008 2:48:15 AM Subject: Re: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > > Hi Frank, > > > > see inline, > > > > On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia > wrote: > >> Hi Julien > >> > >> Thank for your comments! > >> > >> Just as IPv4 address management needs not only > >> DHCPv4 solution but also AAA mechanisms, > >> IPv6 prefix management as an extension of > >> address mangement also needs corresponding > >> facilitis. > > > > we already have some facilities. That was the point of my mail. > > Frank=>Diameter Prefix Delegation application is a > complementary not exclusive solution to > the current existing facilitis. It is useful for a variety of > deployment > scenarios which are possible beyond our reasoning imagination. > > Here is my argument, why do we need AAA solution for IPv4 > address management while there is a DHCP method? What do you mean by "IPv4 address management"? It is possible for both RADIUS & Diameter to assign IPv4 addresses to user machines but that is hardly "management" as I understand the term. Are there other capabilities of which I am unaware? ... > A operator wants to renumber it networks( although > this is not a frequent practice). All the subscribers should > replace their old prefixes by new advertised prefixes. Just my point: Diameter is _not_ a general purpose network management protocol & shouldn't become one. > During renumbering time(a couple of hours or days), > old application sessions continue using old IP addresses > while new application sessions begin to use new IP addresses > > The following are some references on renumbering. The question isn't whether renumbering is a problem, it's if Diameter is the right solution to that problem. Just because you have a hammer doesn't mean that everything is a nail :-)... ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --0-1698814402-1213630856=:18400 Content-Type: text/html; charset=us-ascii
forwarding to dime list.

----- Forwarded Message ----
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
To: Glen Zorn <glenzorn@comcast.net>
Sent: Monday, June 16, 2008 10:36:49 AM
Subject: Re: [Dime] Diameter Prefix Delegation Application

Hi Glen,
  Prefixes are used to subnet a given network. The address assignment comes next based on the prefix. Subneting a network is done by the network administration/management.
  draft-sarikaya-dime-prefix-delegation-ps suggests that AAA can be used in prefix delegation (from a delegating server to a requesting server) just like AAA is currently being used for address assignment.
  More details like per-MN prefix use in cellular links are in the draft.
Regards,

Behcet
----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: SpawnRR@gmx.de; dime@ietf.org; Jouni.korhonen@teliasonera.com
Sent: Sunday, June 15, 2008 2:48:15 AM
Subject: Re: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> > Hi Frank,
> >
> > see inline,
> >
> > On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia <xiayangsong@huawei.com>
> wrote:
> >> Hi Julien
> >>
> >> Thank for your comments!
> >>
> >> Just as IPv4 address management needs not only
> >> DHCPv4 solution but also AAA mechanisms,
> >> IPv6 prefix management as an extension of
> >> address mangement also needs  corresponding
> >> facilitis.
> >
> > we already have some facilities. That was the point of my mail.
>
> Frank=>Diameter Prefix Delegation application  is a
> complementary not exclusive solution to
> the current existing facilitis.  It is useful for a variety of
> deployment
> scenarios which are possible beyond our reasoning imagination.
>
> Here is my argument,  why do we need AAA solution for IPv4
> address management while there is a DHCP method?

What do you mean by "IPv4 address management"?  It is possible for both
RADIUS & Diameter to assign IPv4 addresses to user machines but that is
hardly "management" as I understand the term.  Are there other capabilities
of which I am unaware?

...

> A operator  wants to renumber it networks( although
> this is not a frequent practice). All the subscribers should
> replace their old prefixes by new advertised prefixes.

Just my point: Diameter is _not_ a general purpose network management
protocol & shouldn't become one.

> During renumbering time(a couple of hours or days),
> old application sessions continue using old IP addresses
> while new application sessions begin to use new IP addresses
>
> The following are some references on renumbering.

The question isn't whether renumbering is a problem, it's if Diameter is the
right solution to that problem.  Just because you have a hammer doesn't mean
that everything is a nail :-)...

...



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--0-1698814402-1213630856=:18400-- --===============0752799167== 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://www.ietf.org/mailman/listinfo/dime --===============0752799167==-- From dime-bounces@ietf.org Mon Jun 16 08:42:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A16423A697D; Mon, 16 Jun 2008 08:42:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074B83A697D for ; Mon, 16 Jun 2008 08:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3b6990AyU6s for ; Mon, 16 Jun 2008 08:42:51 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id EB77E3A682A for ; Mon, 16 Jun 2008 08:42:50 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2K006P8BOJHG@usaga04-in.huawei.com> for dime@ietf.org; Mon, 16 Jun 2008 10:43:31 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2K001JGBOGXI@usaga04-in.huawei.com> for dime@ietf.org; Mon, 16 Jun 2008 10:43:31 -0500 (CDT) Date: Mon, 16 Jun 2008 10:43:28 -0500 From: Frank Xia To: Glen Zorn Message-id: <003801c8cfc7$ba152a90$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> <5e2406980806140725h6b4fba27g21eac2fb65b17b5b@mail.gmail.com> <001601c8ce4f$bbcd47b0$0601a8c0@china.huawei.com> <001601c8cebc$38a1a3f0$a9e4ebd0$@net> Cc: SpawnRR@gmx.de, dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen Please check my inline reply... BR Frank ----- Original Message ----- From: "Glen Zorn" To: "'Frank Xia'" Cc: ; ; ; "'Julien Bournelle'" Sent: Sunday, June 15, 2008 2:48 AM Subject: RE: [Dime] Diameter Prefix Delegation Application > Frank Xia [mailto:xiayangsong@huawei.com] writes: > >> > Hi Frank, >> > >> > see inline, >> > >> > On Fri, Jun 13, 2008 at 5:58 PM, Frank Xia >> wrote: >> >> Hi Julien >> >> >> >> Thank for your comments! >> >> >> >> Just as IPv4 address management needs not only >> >> DHCPv4 solution but also AAA mechanisms, >> >> IPv6 prefix management as an extension of >> >> address mangement also needs corresponding >> >> facilitis. >> > >> > we already have some facilities. That was the point of my mail. >> >> Frank=>Diameter Prefix Delegation application is a >> complementary not exclusive solution to >> the current existing facilitis. It is useful for a variety of >> deployment >> scenarios which are possible beyond our reasoning imagination. >> >> Here is my argument, why do we need AAA solution for IPv4 >> address management while there is a DHCP method? > > What do you mean by "IPv4 address management"? It is possible for both > RADIUS & Diameter to assign IPv4 addresses to user machines but that is > hardly "management" as I understand the term. Are there other > capabilities > of which I am unaware? Frank=>When a user attaches a network, a AAA server allocates (dynamically or statically) a IPv4 address to the user. When the uses detaches the networks, the AAA server reclaims the address. IMHO, the AAA server DOES manage user's address pool. Just as your concerns, AAA address mangement is NOT capable as the DHCP solution, such as lacking of renew/reconfigure mechanism. The deficiency becomes more conspicuous when IPv6 address renumbering is under consideration. This is also the motivation of the draft. > > ... > >> A operator wants to renumber it networks( although >> this is not a frequent practice). All the subscribers should >> replace their old prefixes by new advertised prefixes. > > Just my point: Diameter is _not_ a general purpose network management > protocol & shouldn't become one. > >> During renumbering time(a couple of hours or days), >> old application sessions continue using old IP addresses >> while new application sessions begin to use new IP addresses >> >> The following are some references on renumbering. > > The question isn't whether renumbering is a problem, it's if Diameter is > the > right solution to that problem. Just because you have a hammer doesn't > mean > that everything is a nail :-)... Frank=>In WiMAX, RADIUS is used for prefix managment. Diameter will be used eventually. This is a real requirment not an academic argument. > > ... > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 16 09:40:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7563A69BA; Mon, 16 Jun 2008 09:40:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 297D13A67FD for ; Mon, 16 Jun 2008 09:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fUsaAuKZme9 for ; Mon, 16 Jun 2008 09:40:44 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 296F13A65A5 for ; Mon, 16 Jun 2008 09:40:44 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA07.westchester.pa.mail.comcast.net with comcast id ebeF1Z0020QuhwU570Jb00; Mon, 16 Jun 2008 16:41:25 +0000 Received: from gwzPC ([124.120.216.166]) by OMTA02.westchester.pa.mail.comcast.net with comcast id egg21Z00G3bzGnw3Nggmei; Mon, 16 Jun 2008 16:41:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=PTq4znk913iCw_ETNzkA:9 a=_KfH4Et3zn_DpUMN3TEA:7 a=IiNXBPDK_M4jo1c3QX5DIoG9ADYA:4 a=hPjdaMEvmhQA:10 a=iYlkOlhu7C0A:10 From: "Glen Zorn" To: "'Frank Xia'" References: <20080613080846.17720@gmx.net> <007b01c8cd49$bf65b6c0$3e312440$@net> <5e2406980806130529n7b56949dl2cdb58e804d3d640@mail.gmail.com> <002b01c8cd6e$61608030$5c0c7c0a@china.huawei.com> <5e2406980806140725h6b4fba27g21eac2fb65b17b5b@mail.gmail.com> <001601c8ce4f$bbcd47b0$0601a8c0@china.huawei.com> <001601c8cebc$38a1a3f0$a9e4ebd0$@net> <003801c8cfc7$ba152a90$5c0c7c0a@china.huawei.com> In-Reply-To: <003801c8cfc7$ba152a90$5c0c7c0a@china.huawei.com> Date: Mon, 16 Jun 2008 23:39:20 +0700 Message-ID: <004801c8cfcf$9fd2a060$df77e120$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjPx75oKH8aiCpbS6yJnkZhaHrUagABivTA Content-Language: en-us Cc: SpawnRR@gmx.de, dime@ietf.org, Jouni.korhonen@teliasonera.com Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Frank Xia [mailto:xiayangsong@huawei.com] writes: ... > Just as your concerns, AAA address mangement is NOT capable as the > DHCP > solution, such as lacking of renew/reconfigure mechanism. Actually, that doesn't concern me at all: DHCP seems to work just fine. > The > deficiency > becomes more conspicuous when IPv6 address renumbering is under > consideration. > This is also the motivation of the draft. I just get the feeling that the only reason that Diameter is being considered is that it's handy, not because this actually has anything to do with AAA. > > > > > ... > > > >> A operator wants to renumber it networks( although > >> this is not a frequent practice). All the subscribers should > >> replace their old prefixes by new advertised prefixes. > > > > Just my point: Diameter is _not_ a general purpose network management > > protocol & shouldn't become one. > > > >> During renumbering time(a couple of hours or days), > >> old application sessions continue using old IP addresses > >> while new application sessions begin to use new IP addresses > >> > >> The following are some references on renumbering. > > > > The question isn't whether renumbering is a problem, it's if Diameter > is > > the > > right solution to that problem. Just because you have a hammer > doesn't > > mean > > that everything is a nail :-)... > Frank=>In WiMAX, RADIUS is used for prefix managment. I haven't been paying much attention to WiMAX lately but if that's the case then certainly the same (I was going to say 'lame' here but since I don't really know what it is I'll restrain myself ;-) method can be used with Diameter. > Diameter will be used eventually. I suppose that tools are inevitably misused. The IETF doesn't have to approve the misuse, though. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 16 12:31:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61A93A6AF9; Mon, 16 Jun 2008 12:31:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0B43A6937 for ; Mon, 16 Jun 2008 12:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f-0gGsUwBQg for ; Mon, 16 Jun 2008 12:31:36 -0700 (PDT) Received: from web84304.mail.re1.yahoo.com (web84304.mail.re1.yahoo.com [69.147.74.183]) by core3.amsl.com (Postfix) with SMTP id 849943A6915 for ; Mon, 16 Jun 2008 12:31:36 -0700 (PDT) Received: (qmail 94953 invoked by uid 60001); 16 Jun 2008 19:32:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=HiEnf7P/JrnIiaMbnGqOo9ROg1LfebXb2PSmOb/bdOIi8nrJwl9vhoFbKC55CHDlXlBZTBLIJqwbVV3HUJ28Z9vOynWSnFT8hwFxcJxseIF45Ms77zI5HxkYZFhtAaYyi23iTZeShiKNMkpVvSt5fXE8Ei3zNcIPlQA5+K2ss14=; X-YMail-OSG: 9JUheQUVM1mcpzcnD8qVLCW4kpeJ15JRBw3QwYs3UkQ2aQHkmLkeuj11qTA3H6Vcj9MuJUZwEFfTLpkct.XGe2bLXg0Gd2QhBcPIF7CTEJDWBNtMRgwCJaQ- Received: from [206.16.17.212] by web84304.mail.re1.yahoo.com via HTTP; Mon, 16 Jun 2008 12:32:18 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Mon, 16 Jun 2008 12:32:18 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <286947.94326.qm@web84304.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1200623333==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1200623333== Content-Type: multipart/alternative; boundary="0-917130081-1213644738=:94326" --0-917130081-1213644738=:94326 Content-Type: text/plain; charset=us-ascii see inline, Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: SpawnRR@gmx.de; dime@ietf.org; Jouni.korhonen@teliasonera.com Sent: Monday, June 16, 2008 11:39:20 AM Subject: Re: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: ... > Just as your concerns, AAA address mangement is NOT capable as the > DHCP > solution, such as lacking of renew/reconfigure mechanism. Actually, that doesn't concern me at all: DHCP seems to work just fine. > The > deficiency > becomes more conspicuous when IPv6 address renumbering is under > consideration. > This is also the motivation of the draft. I just get the feeling that the only reason that Diameter is being considered is that it's handy, not because this actually has anything to do with AAA. [behcet] Glen, have you read RFC 4818? AAA has already been given a role in Prefix Delegation. Why not develop an AAA application to get prefixes directly from AAA server? This is what we are proposing. snipped the rest. --0-917130081-1213644738=:94326 Content-Type: text/html; charset=us-ascii

see inline,

Regards,

Behcet
----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: SpawnRR@gmx.de; dime@ietf.org; Jouni.korhonen@teliasonera.com
Sent: Monday, June 16, 2008 11:39:20 AM
Subject: Re: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

...

> Just as your concerns,  AAA address mangement is NOT capable as the
> DHCP
> solution, such as lacking of renew/reconfigure mechanism. 

Actually, that doesn't concern me at all: DHCP seems to work just fine.

> The
> deficiency
> becomes more conspicuous when IPv6 address renumbering is under
> consideration.
> This is also the motivation of the draft.

I just get the feeling that the only reason that Diameter is being
considered is that it's handy, not because this actually has anything to do
with AAA.

[behcet] Glen, have you read RFC 4818? AAA has already been given a role in Prefix Delegation.
Why not develop an AAA application to get prefixes directly from AAA server?
This is what we are proposing.



snipped the rest.


--0-917130081-1213644738=:94326-- --===============1200623333== 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://www.ietf.org/mailman/listinfo/dime --===============1200623333==-- From dime-bounces@ietf.org Tue Jun 17 02:12:06 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CC43A692F; Tue, 17 Jun 2008 02:12:06 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97703A68EF for ; Tue, 17 Jun 2008 02:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+1-tcjmUAUX for ; Tue, 17 Jun 2008 02:12:02 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 966733A6929 for ; Tue, 17 Jun 2008 02:12:02 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id exCJ1Z00H1GXsucA100400; Tue, 17 Jun 2008 09:12:45 +0000 Received: from gwzPC ([124.121.210.8]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id exBc1Z00B0BREGU8TxCEXg; Tue, 17 Jun 2008 09:12:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=goIBmpLZtufqLRcmhwMA:9 a=kpkG_POodYbMDzlwy63U_JcGEQ0A:4 a=y4M8Ahb7xz0A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=8CZiXBpPdUCkHqoPvVMA:9 a=R0Fz-UAcLXCxBFoYTm8A:7 a=CgRUq2kTgWAL4FXe9B18z8-F-zgA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" References: <286947.94326.qm@web84304.mail.re1.yahoo.com> In-Reply-To: <286947.94326.qm@web84304.mail.re1.yahoo.com> Date: Tue, 17 Jun 2008 16:10:48 +0700 Message-ID: <007001c8d05a$1c7060a0$555121e0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjP57AqHPozkqoRSbOvFb/OUmqRJQAcFTsA Content-Language: en-us Cc: dime@ietf.org, Ralph Droms Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1337092890==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1337092890== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C8D094.C8CF38A0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0071_01C8D094.C8CF38A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . [behcet] Glen, have you read RFC 4818? Yes, I have, thank you. AAA has already been given a role in Prefix Delegation. Although 4818 is rather close-mouthed about actual implementation (in the tradition of RADIUS documents), it seems fairly clear that in the intended application the "requesting router" takes the role of the NAS client (user) (perfectly reasonable in many cases (DSL, WiMAX, etc.)) while the "delegating router" has the role of NAS. Obviously, in this case the Session-Lifetime would be identical to the lifetime of the returned prefix(es). Why wouldn't this work in Diameter? Why not develop an AAA application to get prefixes directly from AAA server? Because it's unnecessary? This is what we are proposing. snipped the rest. ------=_NextPart_000_0071_01C8D094.C8CF38A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

…

[behcet] Glen, = have you read RFC 4818?

Yes, I have, thank you. 

AAA has already = been given a role in Prefix Delegation.

Although 4818 is rather close-mouthed about actual = implementation (in the tradition of RADIUS documents), it seems fairly clear that in = the intended application the "requesting router" takes the role of = the NAS client (user) (perfectly reasonable in many cases (DSL, WiMAX, = etc.)) while the "delegating router" has the role of NAS.  Obviously, = in this case the Session-Lifetime would be identical to the lifetime of the = returned prefix(es).  Why wouldn't this work in Diameter?

Why not develop an AAA application to get prefixes directly from AAA = server?

Because it's unnecessary?
This is what we are proposing.

snipped the rest.

------=_NextPart_000_0071_01C8D094.C8CF38A0-- --===============1337092890== 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://www.ietf.org/mailman/listinfo/dime --===============1337092890==-- From dime-bounces@ietf.org Tue Jun 17 07:47:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1939F3A6B08; Tue, 17 Jun 2008 07:47:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B50083A63EC for ; Tue, 17 Jun 2008 07:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2TYACSfGOO9 for ; Tue, 17 Jun 2008 07:47:28 -0700 (PDT) Received: from web84304.mail.re1.yahoo.com (web84304.mail.re1.yahoo.com [69.147.74.183]) by core3.amsl.com (Postfix) with SMTP id 426FB28C113 for ; Tue, 17 Jun 2008 07:47:27 -0700 (PDT) Received: (qmail 53947 invoked by uid 60001); 17 Jun 2008 14:48:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=QkoMHOOm9PLJUKfte6J6wkVhN5/zYXl6AQvewkOdaKUL6rZIbIqA7qqUWW7s3DTflgFcMDCNRDPKrWx9D1N4rQ7noy+vXdt/0htVOoyU6KWuQkW38xRLslzLXJilZADcOw+nF61tepPZLg9M+xYow2pSFsjNglpRpseD7k4ghCA=; X-YMail-OSG: 0GbzhrkVM1mN7r.rH40wKfuZ0ByfDM7pdai8D4Fx6bc4X4KFunxW9mr17vTHiKKPzj32KYUubEWspsFbITjxFQb1eO2gFlulbg-- Received: from [206.16.17.212] by web84304.mail.re1.yahoo.com via HTTP; Tue, 17 Jun 2008 07:48:11 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Tue, 17 Jun 2008 07:48:11 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <174910.53440.qm@web84304.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2068314999==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2068314999== Content-Type: multipart/alternative; boundary="0-2104065059-1213714091=:53440" --0-2104065059-1213714091=:53440 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Glen,=0A The delegated prefixes could be used by the requesting router = in RAs in order to realize per-MN prefixes in cellular networks like WiMAX,= so the use is not much related to Session-Lifetime but rather to IP sessio= n as Frank pointed out.=0A The fact is that AAA is being used in managed n= etworks for address management and in prefix delegation as per 4818. The on= ly missing piece is the PD application. =0A Some people are saying that it= will be nice to define this missing piece.=0ALet's agree on this.=0A=0AReg= ards,=0A=0ABehcet=0A=0A=0A----- Original Message ----=0AFrom: Glen Zorn =0ATo: Behcet Sarikaya =0ACc: dime@ie= tf.org; Ralph Droms ; Joseph Salowey (jsalowey) =0ASent: Tuesday, June 17, 2008 4:10:48 AM=0ASubject: RE: [Dime]= Diameter Prefix Delegation Application=0A=0A =0A=85=0A[behcet] Glen, have = you read=0ARFC 4818?=0AYes, I have, thank you. =0AAAA has already been giv= en a=0Arole in Prefix Delegation.=0AAlthough 4818 is rather close-mouthed a= bout actual implementation=0A(in the tradition of RADIUS documents), it see= ms fairly clear that in the=0Aintended application the "requesting router" = takes the role of the=0ANAS client (user) (perfectly reasonable in many cas= es (DSL, WiMAX, etc.)) while=0Athe "delegating router" has the role of NAS.= Obviously, in this=0Acase the Session-Lifetime would be identical to the = lifetime of the returned=0Aprefix(es). Why wouldn't this work in Diameter?= =0A=0AWhy not develop an AAA application to get prefixes directly from AAA = server?=0ABecause it's unnecessary?=0AThis is what we are proposing.=0A=0As= nipped the rest. --0-2104065059-1213714091=:53440 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Glen,
  The delegated prefixes could be use= d by the requesting router in RAs in order to realize per-MN prefixes in ce= llular networks like WiMAX, so the use is not much related to Session-Lifet= ime but rather to IP session as Frank pointed out.
  The fact is th= at AAA is being used in managed networks for address management and in pref= ix delegation as per 4818. The only missing piece is the PD application.   Some people are saying that it will be nice to define this missing= piece.
Let's agree on this.

Regards,

Behcet

=0A =0A=0A=0A

=85

[behcet] Glen, have you re= ad=0ARFC 4818?

Yes, I have,= thank you. 

AAA has already been given a=0Arole in Prefix Delegation.

Although 4818 is rather clo= se-mouthed about actual implementation=0A(in the tradition of RADIUS docume= nts), it seems fairly clear that in the=0Aintended application the "request= ing router" takes the role of the=0ANAS client (user) (perfectly reasonable= in many cases (DSL, WiMAX, etc.)) while=0Athe "delegating router" has the = role of NAS.  Obviously, in this=0Acase the Session-Lifetime would be = identical to the lifetime of the returned=0Aprefix(es).  Why wouldn't = this work in Diameter?

=0AWhy not develop an AAA application = to get prefixes directly from AAA server?

Because it's unnecessary?
This is what we are prop= osing.

=0Asnipped the rest.

--0-2104065059-1213714091=:53440-- --===============2068314999== 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://www.ietf.org/mailman/listinfo/dime --===============2068314999==-- From dime-bounces@ietf.org Tue Jun 17 08:01:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FF83A6A13; Tue, 17 Jun 2008 08:01:40 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DCA3A6A13 for ; Tue, 17 Jun 2008 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wcCEm8+Rq3e for ; Tue, 17 Jun 2008 08:01:34 -0700 (PDT) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.243]) by core3.amsl.com (Postfix) with ESMTP id 3442C3A69BC for ; Tue, 17 Jun 2008 08:01:34 -0700 (PDT) Received: by hs-out-0708.google.com with SMTP id 4so942995hsl.5 for ; Tue, 17 Jun 2008 08:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=/Lc3VW5W2pm3j+m6748MEp4PntBoiX8d5AyTcppq0nY=; b=G6LoltJWEMXw1S5aCrwjUGoe3rsYL+jerAkUs9CheLNcHQX9OsPG3zd0MDX0Iug8wL Y2+oeYQGMnvSYiBRSP5C14xuCHrOGXPOf1GEKDRKTOP+dSBX0tI1VHSeqnKyZOQtxXms Ns1K0rZ2LOjiDlmrqx62lGbtqlEij7zZ/PDz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xI73R249k2icVamB6FJbKcmPKFnBdWQ9e8mxdcQTlIk73hFcZYPePI/1d96jjmsauK t77zfhazNL3wHZ7uBxNQGZ704zf4Fdu8q7RJox4Ln7TQMU65EqfIrOoURL4aI8EH8sMA 2f3zP69Hz05y6Tle8vj0GTnKX0CSe9CQ7PM4E= Received: by 10.100.227.6 with SMTP id z6mr10899233ang.51.1213714938061; Tue, 17 Jun 2008 08:02:18 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Tue, 17 Jun 2008 08:02:17 -0700 (PDT) Message-ID: <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> Date: Tue, 17 Jun 2008 17:02:17 +0200 From: "Julien Bournelle" To: "Behcet Sarikaya" In-Reply-To: <174910.53440.qm@web84304.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline References: <174910.53440.qm@web84304.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi behcet, all, On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya wrote: > Hi Glen, > The delegated prefixes could be used by the requesting router in RAs in > order to realize per-MN prefixes in cellular networks like WiMAX, so the use > is not much related to Session-Lifetime but rather to IP session as Frank > pointed out. > The fact is that AAA is being used in managed networks for address > management and in prefix delegation as per 4818. The only missing piece is > the PD application. > Some people are saying that it will be nice to define this missing piece. > Let's agree on this. I don't. We already have mechanism for prefix delegation and I'm not convinced by your PS. Defining a whole Diameter Application for this seems a misuse of Diameter to me. Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 08:12:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6612E3A6B22; Tue, 17 Jun 2008 08:12:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C943A6B43 for ; Tue, 17 Jun 2008 08:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKwTV1YmvtGR for ; Tue, 17 Jun 2008 08:12:48 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 0FD003A6B22 for ; Tue, 17 Jun 2008 08:12:47 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id ez8N1Z0060mlR8UA50W600; Tue, 17 Jun 2008 15:13:32 +0000 Received: from gwzPC ([124.121.210.8]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id f3Cc1Z00S0BREGU8X3D8GB; Tue, 17 Jun 2008 15:13:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=eFMaryDytXtoYF2jTooA:9 a=XS7yRKge94Ko7eUsYSkA:7 a=WAERj1vskgtGtklHSvvpKtXICkEA:4 a=rC2wZJ5BpNYA:10 a=si9q_4b84H0A:10 a=ZrMMMnaxNC4A:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=zoKOyUDlhksA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=2BoZJs76gbkX3WKC9kMA:9 a=J5YiMoUT5skaNgYGo8gA:7 a=U6TDckr-3hFc0e_6KsZhzpeuGhoA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" References: <174910.53440.qm@web84304.mail.re1.yahoo.com> In-Reply-To: <174910.53440.qm@web84304.mail.re1.yahoo.com> Date: Tue, 17 Jun 2008 22:12:34 +0700 Message-ID: <00b301c8d08c$a20981b0$e61c8510$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjQiSr3MlksQbUOSPS7q7d79hVfVgAAPNsA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1641446124==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1641446124== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01C8D0C7.4E6859B0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00B4_01C8D0C7.4E6859B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: Hi Glen, The delegated prefixes could be used by the requesting router in RAs in order to realize per-MN prefixes in cellular networks like WiMAX, so the use is not much related to Session-Lifetime but rather to IP session as Frank pointed out. The fact is that AAA is being used in managed networks for address management and in prefix delegation as per 4818. The only missing piece is the PD application. Some people are saying that it will be nice to define this missing piece. Let's agree on this. I'd just love to agree on something. In order to do that, though, I'd need someone to a) actually answer my questions or, if that's really not possible, b) write a problem statement that actually describes a problem (without assuming a solution) and then tell me how that relates to user authentication or user authorization or even user accounting. So far, though, all I've gotten is talk of undefined (& quite possibly indefinable) marketing terms ("IP session") and statements that it's already being done. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya Cc: dime@ietf.org; Ralph Droms ; Joseph Salowey (jsalowey) Sent: Tuesday, June 17, 2008 4:10:48 AM Subject: RE: [Dime] Diameter Prefix Delegation Application . [behcet] Glen, have you read RFC 4818? Yes, I have, thank you. AAA has already been given a role in Prefix Delegation. Although 4818 is rather close-mouthed about actual implementation (in the tradition of RADIUS documents), it seems fairly clear that in the intended application the "requesting router" takes the role of the NAS client (user) (perfectly reasonable in many cases (DSL, WiMAX, etc.)) while the "delegating router" has the role of NAS. Obviously, in this case the Session-Lifetime would be identical to the lifetime of the returned prefix(es). Why wouldn't this work in Diameter? Why not develop an AAA application to get prefixes directly from AAA server? Because it's unnecessary? This is what we are proposing. snipped the rest. ------=_NextPart_000_00B4_01C8D0C7.4E6859B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes:

Hi Glen,
  The delegated prefixes could be used by the requesting router in = RAs in order to realize per-MN prefixes in cellular networks like WiMAX, so the = use is not much related to Session-Lifetime but rather to IP session as Frank = pointed out.
  The fact is that AAA is being used in managed networks for = address management and in prefix delegation as per 4818. The only missing piece = is the PD application.
  Some people are saying that it will be nice to define this = missing piece.
Let's agree on this.

I'd just love to agree on = something.  In order to do that, though, I'd need someone to a) actually answer my = questions or, if that's really not possible, b) write a problem statement that = actually describes a problem (without assuming a solution) and then tell me how = that relates to user authentication or user authorization or even user = accounting.  So far, though, all I've gotten is talk of undefined (& quite = possibly indefinable) marketing terms ("IP session") and statements that it's = already being done.



Regards,

Behcet

----- Original = Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org; Ralph Droms <rdroms@cisco.com>; Joseph Salowey (jsalowey) <jsalowey@cisco.com>
Sent: Tuesday, June 17, 2008 4:10:48 AM
Subject: RE: [Dime] Diameter Prefix Delegation = Application

…<= /o:p>

[behcet] Glen, = have you read RFC 4818?

Yes, I have, thank you. 

AAA has already = been given a role in Prefix Delegation.

Although 4818 is rather close-mouthed about actual implementation (in the tradition of RADIUS documents), it seems fairly = clear that in the intended application the "requesting router" takes = the role of the NAS client (user) (perfectly reasonable in many cases (DSL, = WiMAX, etc.)) while the "delegating router" has the role of = NAS.  Obviously, in this case the Session-Lifetime would be identical to the = lifetime of the returned prefix(es).  Why wouldn't this work in = Diameter?

Why not develop an AAA application to get prefixes directly from AAA = server?

Because it's unnecessary?
This is what we are proposing.

snipped the rest.

------=_NextPart_000_00B4_01C8D0C7.4E6859B0-- --===============1641446124== 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://www.ietf.org/mailman/listinfo/dime --===============1641446124==-- From dime-bounces@ietf.org Tue Jun 17 08:19:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C7A3A6A80; Tue, 17 Jun 2008 08:19:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B765E3A6B43 for ; Tue, 17 Jun 2008 08:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn+ccU-hnLd7 for ; Tue, 17 Jun 2008 08:19:26 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B60273A69AE for ; Tue, 17 Jun 2008 08:19:26 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2M0094559NDT@usaga04-in.huawei.com> for dime@ietf.org; Tue, 17 Jun 2008 10:20:11 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2M00DEI59M7T@usaga04-in.huawei.com> for dime@ietf.org; Tue, 17 Jun 2008 10:20:11 -0500 (CDT) Date: Tue, 17 Jun 2008 10:20:12 -0500 From: Frank Xia To: Julien Bournelle , Glen Zorn Message-id: <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <174910.53440.qm@web84304.mail.re1.yahoo.com> <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien and Glen I will appreciate you guys insightful view, If you give me your understanding about essence of Diameter application and does not just assert that " this is the misusing of Diameter". IMHO, Diameter as a AAA protocol can be used in dynamically authorization. Address management(including prefix delegation) is a kind of authorization. BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Behcet Sarikaya" Cc: Sent: Tuesday, June 17, 2008 10:02 AM Subject: Re: [Dime] Diameter Prefix Delegation Application > Hi behcet, all, > > On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya > wrote: >> Hi Glen, >> The delegated prefixes could be used by the requesting router in RAs in >> order to realize per-MN prefixes in cellular networks like WiMAX, so the >> use >> is not much related to Session-Lifetime but rather to IP session as Frank >> pointed out. >> The fact is that AAA is being used in managed networks for address >> management and in prefix delegation as per 4818. The only missing piece >> is >> the PD application. >> Some people are saying that it will be nice to define this missing >> piece. >> Let's agree on this. > > I don't. We already have mechanism for prefix delegation and I'm not > convinced by your > PS. Defining a whole Diameter Application for this seems a misuse of > Diameter to me. > > Regards, > > Julien > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 08:28:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96D23A6928; Tue, 17 Jun 2008 08:28:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079FF3A6928 for ; Tue, 17 Jun 2008 08:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_00=-2.599, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSWMYT7DLQv6 for ; Tue, 17 Jun 2008 08:28:50 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id D390E3A685A for ; Tue, 17 Jun 2008 08:28:49 -0700 (PDT) Received: (qmail 4918 invoked by uid 60001); 17 Jun 2008 15:29:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Rr7DhVOA0piDjEDMD/vV7zA+byOO5cKoFX85ZIWYcGaeg8b2pnNp5LesqxyYePaGZwuQwuKAgxvTYGgBqD7xkAfbeT9K1gM0SiVvm3rNfFzEReRfEa72UHjazCcBKsg83r4Kdqr72PAHpKnm6urw0hmBbtlnNRbIm3ZXbTDDcOE=; X-YMail-OSG: AF5hwgEVM1m_XdqYDb3cR2lt2gN3IFzEms.0L9Bu8ivAKeDJ_MRxFM4.pmC4tUDec5QvW4QFrV.qwmBYBkp1WaoLModlofWQVotmiCQeo50W5ZtTCJmlJmc- Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Tue, 17 Jun 2008 08:29:33 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Tue, 17 Jun 2008 08:29:33 -0700 (PDT) From: Behcet Sarikaya To: Julien Bournelle MIME-Version: 1.0 Message-ID: <852830.4379.qm@web84303.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1852682495==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1852682495== Content-Type: multipart/alternative; boundary="0-1869981110-1213716573=:4379" --0-1869981110-1213716573=:4379 Content-Type: text/plain; charset=us-ascii Glen, Julien, This is what I wrote: some people (like myself, etc.) are saying that it will be nice to define this missing piece. Is it so difficult to agree with this statement ? BTW, I disagree with your claim that it will be misuse of Diameter but if you state is like above I could agree. Regards, Behcet ----- Original Message ---- From: Julien Bournelle To: Behcet Sarikaya Cc: Glen Zorn ; dime@ietf.org Sent: Tuesday, June 17, 2008 10:02:17 AM Subject: Re: [Dime] Diameter Prefix Delegation Application Hi behcet, all, On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya wrote: > Hi Glen, > The delegated prefixes could be used by the requesting router in RAs in > order to realize per-MN prefixes in cellular networks like WiMAX, so the use > is not much related to Session-Lifetime but rather to IP session as Frank > pointed out. > The fact is that AAA is being used in managed networks for address > management and in prefix delegation as per 4818. The only missing piece is > the PD application. > Some people are saying that it will be nice to define this missing piece. > Let's agree on this. I don't. We already have mechanism for prefix delegation and I'm not convinced by your PS. Defining a whole Diameter Application for this seems a misuse of Diameter to me. Regards, Julien --0-1869981110-1213716573=:4379 Content-Type: text/html; charset=us-ascii
Glen, Julien,
 This is what I wrote: some people (like myself, etc.) are saying that it will be nice to define this missing piece.
  Is it so difficult to agree with this statement ?
BTW, I disagree with your claim that it will be misuse of Diameter but if you state is like above I could agree.
Regards,

Behcet

----- Original Message ----
From: Julien Bournelle <julien.bournelle@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Glen Zorn <glenzorn@comcast.net>; dime@ietf.org
Sent: Tuesday, June 17, 2008 10:02:17 AM
Subject: Re: [Dime] Diameter Prefix Delegation Application

Hi behcet, all,

On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi Glen,
>  The delegated prefixes could be used by the requesting router in RAs in
> order to realize per-MN prefixes in cellular networks like WiMAX, so the use
> is not much related to Session-Lifetime but rather to IP session as Frank
> pointed out.
>  The fact is that AAA is being used in managed networks for address
> management and in prefix delegation as per 4818. The only missing piece is
> the PD application.
>  Some people are saying that it will be nice to define this missing piece.
> Let's agree on this.

I don't. We already have mechanism for prefix delegation and I'm not
convinced by your
PS. Defining a whole Diameter Application for this seems a misuse of
Diameter to me.

Regards,

Julien
--0-1869981110-1213716573=:4379-- --===============1852682495== 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://www.ietf.org/mailman/listinfo/dime --===============1852682495==-- From dime-bounces@ietf.org Tue Jun 17 08:32:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B63A33A6991; Tue, 17 Jun 2008 08:32:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395CC3A697F for ; Tue, 17 Jun 2008 08:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMeWaYH-p9RQ for ; Tue, 17 Jun 2008 08:32:46 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 37F8D3A685A for ; Tue, 17 Jun 2008 08:32:46 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id f0g91Z00317dt5G540HE00; Tue, 17 Jun 2008 15:33:29 +0000 Received: from gwzPC ([124.121.210.8]) by OMTA13.westchester.pa.mail.comcast.net with comcast id f3YH1Z00H0BREGU3Z3YwqP; Tue, 17 Jun 2008 15:33:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=48vgC7mUAAAA:8 a=1vw1R2v28eGrHsL7XEYA:9 a=rF6HgVMh38N-jmPOZBMA:7 a=4bICX_FLbuHy5iAZfxWevkMez-sA:4 a=MSl-tDqOz04A:10 a=ZrMMMnaxNC4A:10 a=lZB815dzVvQA:10 a=rC2wZJ5BpNYA:10 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Frank Xia'" , "'Julien Bournelle'" References: <174910.53440.qm@web84304.mail.re1.yahoo.com> <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> In-Reply-To: <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> Date: Tue, 17 Jun 2008 22:32:14 +0700 Message-ID: <00c401c8d08f$674f4c50$35ede4f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjQja/kz+iHncG2T+qUJuR5krO/VQAAIyew Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > I will appreciate you guys insightful view, > If you give me your understanding about > essence of Diameter application and does > not just assert that " this is the misusing of > Diameter". I have asserted that it is a misuse of Diameter _because_ (I thought that I made this pretty clear, but apparently not)it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that. What I've also said repeatedly is that it appears to me that you just want to use Diameter (as nothing more than a transport, actually) just because it happens to be handy. _That_ is a misuse of the protocol. > > IMHO, Diameter as a AAA protocol > can be used in dynamically authorization. Of _users_. > Address management(including prefix > delegation) is a kind of authorization. > > BR > Frank > > > > ----- Original Message ----- > From: "Julien Bournelle" > To: "Behcet Sarikaya" > Cc: > Sent: Tuesday, June 17, 2008 10:02 AM > Subject: Re: [Dime] Diameter Prefix Delegation Application > > > > Hi behcet, all, > > > > On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya > > wrote: > >> Hi Glen, > >> The delegated prefixes could be used by the requesting router in > RAs in > >> order to realize per-MN prefixes in cellular networks like WiMAX, so > the > >> use > >> is not much related to Session-Lifetime but rather to IP session as > Frank > >> pointed out. > >> The fact is that AAA is being used in managed networks for address > >> management and in prefix delegation as per 4818. The only missing > piece > >> is > >> the PD application. > >> Some people are saying that it will be nice to define this missing > >> piece. > >> Let's agree on this. > > > > I don't. We already have mechanism for prefix delegation and I'm not > > convinced by your > > PS. Defining a whole Diameter Application for this seems a misuse of > > Diameter to me. > > > > Regards, > > > > Julien > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 11:12:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E7F3A6ABA; Tue, 17 Jun 2008 11:12:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCBC3A6B08 for ; Tue, 17 Jun 2008 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.081 X-Spam-Level: X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYOLknTSZ7CO for ; Tue, 17 Jun 2008 11:12:05 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E8D2E3A6A04 for ; Tue, 17 Jun 2008 11:12:04 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K2M00GIMD9AO3@usaga04-in.huawei.com> for dime@ietf.org; Tue, 17 Jun 2008 13:12:47 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K2M0085WD99MA@usaga04-in.huawei.com> for dime@ietf.org; Tue, 17 Jun 2008 13:12:46 -0500 (CDT) Date: Tue, 17 Jun 2008 13:12:44 -0500 From: Frank Xia To: Glen Zorn , 'Julien Bournelle' Message-id: <003201c8d0a5$be58efe0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <174910.53440.qm@web84304.mail.re1.yahoo.com> <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> <00c401c8d08f$674f4c50$35ede4f0$@net> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Glen Please check my inline clarification... BR Frank ----- Original Message ----- From: "Glen Zorn" To: "'Frank Xia'" ; "'Julien Bournelle'" Cc: ; "'Behcet Sarikaya'" Sent: Tuesday, June 17, 2008 10:32 AM Subject: RE: [Dime] Diameter Prefix Delegation Application >> I will appreciate you guys insightful view, >> If you give me your understanding about >> essence of Diameter application and does >> not just assert that " this is the misusing of >> Diameter". > > I have asserted that it is a misuse of Diameter _because_ (I thought that > I > made this pretty clear, but apparently not)it appears that the single > application that is being discussed and cannot be handled in Diameter > NASREQ > right now _has nothing to do with _user authorization__. As I stated in > my > original message, I'd be happy to be told that I'm mistaken about this but > nobody's done that. What I've also said repeatedly is that it appears to > me > that you just want to use Diameter (as nothing more than a transport, > actually) just because it happens to be handy. _That_ is a misuse of the > protocol. > >> >> IMHO, Diameter as a AAA protocol >> can be used in dynamically authorization. > > Of _users_. Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. > >> Address management(including prefix >> delegation) is a kind of authorization. >> >> BR >> Frank >> >> >> >> ----- Original Message ----- >> From: "Julien Bournelle" >> To: "Behcet Sarikaya" >> Cc: >> Sent: Tuesday, June 17, 2008 10:02 AM >> Subject: Re: [Dime] Diameter Prefix Delegation Application >> >> >> > Hi behcet, all, >> > >> > On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya >> > wrote: >> >> Hi Glen, >> >> The delegated prefixes could be used by the requesting router in >> RAs in >> >> order to realize per-MN prefixes in cellular networks like WiMAX, so >> the >> >> use >> >> is not much related to Session-Lifetime but rather to IP session as >> Frank >> >> pointed out. >> >> The fact is that AAA is being used in managed networks for address >> >> management and in prefix delegation as per 4818. The only missing >> piece >> >> is >> >> the PD application. >> >> Some people are saying that it will be nice to define this missing >> >> piece. >> >> Let's agree on this. >> > >> > I don't. We already have mechanism for prefix delegation and I'm not >> > convinced by your >> > PS. Defining a whole Diameter Application for this seems a misuse of >> > Diameter to me. >> > >> > Regards, >> > >> > Julien >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.ietf.org/mailman/listinfo/dime >> > >> > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 12:11:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2546F3A6B4F; Tue, 17 Jun 2008 12:11:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080B73A6A6D for ; Tue, 17 Jun 2008 12:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQSZjBkI1uu for ; Tue, 17 Jun 2008 12:11:49 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 49E353A6805 for ; Tue, 17 Jun 2008 12:11:49 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id f4Pb1Z03W0lTkoCAA05r00; Tue, 17 Jun 2008 19:12:34 +0000 Received: from gwzPC ([124.121.210.8]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id f7BN1Z00J0BREGU8Q7C161; Tue, 17 Jun 2008 19:12:28 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=w-CLL1R7zIoJLP2Qg88A:9 a=Ih-rRlfNF5Me1g_nJztFKf0nZjsA:4 a=hPjdaMEvmhQA:10 a=iYlkOlhu7C0A:10 From: "Glen Zorn" To: "'Frank Xia'" References: <174910.53440.qm@web84304.mail.re1.yahoo.com> <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> <00c401c8d08f$674f4c50$35ede4f0$@net> <003201c8d0a5$be58efe0$5c0c7c0a@china.huawei.com> In-Reply-To: <003201c8d0a5$be58efe0$5c0c7c0a@china.huawei.com> Date: Wed, 18 Jun 2008 02:11:19 +0700 Message-ID: <011701c8d0ae$00e76230$02b62690$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjQpc+Hx5hw0GzETUOxMLEW/MHyIgAB4G3g Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 12:25:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DB13A6AB3; Tue, 17 Jun 2008 12:25:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DC53A6AB3 for ; Tue, 17 Jun 2008 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekptftggcgnc for ; Tue, 17 Jun 2008 12:25:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DCF623A699A for ; Tue, 17 Jun 2008 12:25:35 -0700 (PDT) Received: (qmail invoked by alias); 17 Jun 2008 19:26:19 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp058) with SMTP; 17 Jun 2008 21:26:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/balALtjHbtpsHCl+igQdCMQwMVGFzcals86zGd7 B4HxZ4m12v9DmJ Message-ID: <48580FD9.2030909@gmx.net> Date: Tue, 17 Jun 2008 22:26:17 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Request for Agenda Items X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, we need to prepare the agenda for the meeting. Please let me know what you believe we should definitely discuss or shouldn't discuss anymore. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 17 23:40:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AF83A68A4; Tue, 17 Jun 2008 23:40:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 650373A68A4 for ; Tue, 17 Jun 2008 23:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsvF8WzV3fyP for ; Tue, 17 Jun 2008 23:40:32 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id DFD183A67E7 for ; Tue, 17 Jun 2008 23:40:31 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 4E66690007 for ; Wed, 18 Jun 2008 02:41:11 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31386-06 for ; Wed, 18 Jun 2008 02:41:10 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 18 Jun 2008 02:41:10 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 02:41:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 12:11:06 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559A9AD@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on DPR. Thread-Index: AcjRDklNyQWZwGNLT4uyG2prKBDQsQ== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 18 Jun 2008 06:41:10.0812 (UTC) FILETIME=[4B98EDC0:01C8D10E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] Question on DPR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1205113172==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1205113172== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D10E.497FCD48" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D10E.497FCD48 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question on DPR (Disconnect-Peer-Request). =20 If a DPR is sent with unsupported Disconnect-Cause AVP value (For example: 3, which is not defined in RFC3588) then DPA Result-Code will be SUCCESS or DIAMETER_INVALID_AVP_VALUE? =20 IANA says other than 0 (REBOOTING), 1 (BUSY) and 2 (DO_NOT_WANT_TO_TALK_TO_YOU) rest all are unassigned. =20 This created little confusion in me. Please clear my confusion. =20 Thanks, Avinash Gowda =20 ------_=_NextPart_001_01C8D10E.497FCD48 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question on DPR = (Disconnect-Peer-Request).

 

If a DPR is sent with unsupported Disconnect-Cause = AVP value (For example: 3, which is not defined in RFC3588) then DPA = Result-Code will be SUCCESS or = DIAMETER_INVALID_AVP_VALUE?=

 

IANA says other than 0 =
(REBOOTING), 1 (BUSY) and 2 (DO_NOT_WANT_TO_TALK_TO_YOU) rest all are =
unassigned.
 
This created little =
confusion in me. Please clear my =
confusion.

 

Thanks,

Avinash Gowda

 

------_=_NextPart_001_01C8D10E.497FCD48-- --===============1205113172== 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://www.ietf.org/mailman/listinfo/dime --===============1205113172==-- From dime-bounces@ietf.org Wed Jun 18 06:56:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAA83A680D; Wed, 18 Jun 2008 06:56:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D76233A6A10 for ; Wed, 18 Jun 2008 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWDrSIU5jKJM for ; Wed, 18 Jun 2008 06:56:38 -0700 (PDT) Received: from mail.alcatel-sbell.com.cn (cnrelay03.alcatel-sbell.com.cn [211.144.215.19]) by core3.amsl.com (Postfix) with ESMTP id C82953A67E2 for ; Wed, 18 Jun 2008 06:56:36 -0700 (PDT) Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id m5IDuBkL020805; Wed, 18 Jun 2008 21:56:12 +0800 Received: from CNSHGSMBS04.ad4.ad.alcatel.com ([172.24.146.177]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Jun 2008 21:57:21 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Jun 2008 21:57:21 +0800 Message-ID: <198A33EB1E9E344EBC566802C7761D6B01236DF6@CNSHGSMBS04.ad4.ad.alcatel.com> In-Reply-To: <48580FD9.2030909@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-asveren-dime-cong-02 Thread-Index: AcjQsAyLgs66WJYCQlGGuQ8WIu5PJwALT6UA References: <48580FD9.2030909@gmx.net> From: "TANG Alan" To: X-OriginalArrivalTime: 18 Jun 2008 13:57:21.0750 (UTC) FILETIME=[3AB12760:01C8D14B] X-imss-version: 2.050 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) Subject: [Dime] draft-asveren-dime-cong-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Diameter Gurus: I see that the following draft has expired. http://tools.ietf.org/html/draft-asveren-dime-cong-02 It was said that this draft work has been suspended. As overload control mechanism is very essential for the commercialization of the Diameter products, would it be possible to have this draft work re-started and re-prioritized? Thanks in advance! Regards, Alan Tang Alcatel-Lucent Tel: +86 532 8861 5363 Fax: +86 532 8861 9276 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 18 08:29:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9983A3A6AF3; Wed, 18 Jun 2008 08:29:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F02828C1C2 for ; Wed, 18 Jun 2008 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtKFyCdDUXRm for ; Wed, 18 Jun 2008 08:29:45 -0700 (PDT) Received: from web84305.mail.re1.yahoo.com (web84305.mail.re1.yahoo.com [69.147.74.184]) by core3.amsl.com (Postfix) with SMTP id 251553A6AD8 for ; Wed, 18 Jun 2008 08:29:45 -0700 (PDT) Received: (qmail 23898 invoked by uid 60001); 18 Jun 2008 15:30:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=C4ylDp810FY0nOAdxFrKrDjFghU1weFQDBuPh/u7mQkzmqoMdXBzQ9faOgzEPw/do9H2q7qpfmPHB5jivZkE5zncTmO5TM/qd82wjLRLFGxHDr0lcJjQq2A6Rmu6o55JBaSkHD038abUopRzCMPycXzZqfUahHQGEuhAZe2ReCc=; X-YMail-OSG: xBWr_m0VM1mRCcob3CQIjUqWk8EA9wOrfkio_dmbNc0QbklDwmr06pOMQ0gRtY_x8Q-- Received: from [206.16.17.212] by web84305.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 08:30:32 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 08:30:32 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <621094.23757.qm@web84305.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1690357706==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1690357706== Content-Type: multipart/alternative; boundary="0-535628525-1213803032=:23757" --0-535628525-1213803032=:23757 Content-Type: text/plain; charset=us-ascii Glen, In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement? it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: dime@ietf.org; Behcet Sarikaya ; Julien Bournelle Sent: Tuesday, June 17, 2008 2:11:19 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... --0-535628525-1213803032=:23757 Content-Type: text/html; charset=us-ascii
Glen,
  In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement?
it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization

BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius.
 
Regards,

Behcet
----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Julien Bournelle <julien.bournelle@gmail.com>
Sent: Tuesday, June 17, 2008 2:11:19 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> Hi Glen
>
> Please check my inline clarification...
>
...

> >>
> >> IMHO,  Diameter as a AAA protocol
> >> can be used in dynamically authorization.
> >
> > Of _users_.
> Frank=>Most of cases in the diameter PS  are users' authorization related,
such as LMA requesting prefix for it's PMIPv6 user,  access routers asking
for prefix for the mobile nodes attached.

I wrote: "it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization__.  As I stated in my original message, I'd be happy to be
told that I'm mistaken about this but nobody's done that."  Still true.

...



--0-535628525-1213803032=:23757-- --===============1690357706== 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://www.ietf.org/mailman/listinfo/dime --===============1690357706==-- From dime-bounces@ietf.org Wed Jun 18 08:42:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ACBD3A6A22; Wed, 18 Jun 2008 08:42:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F30E3A6A22 for ; Wed, 18 Jun 2008 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1EVEORT1o-F for ; Wed, 18 Jun 2008 08:42:25 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id E220C3A6A10 for ; Wed, 18 Jun 2008 08:42:24 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so113279and.122 for ; Wed, 18 Jun 2008 08:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=iXWOv+A8cyuYxnmi7gZqLEMxMcbXcnEzCQz9tL9l/A0=; b=PmwPgtMRupPt7Jtu20RLGJwYVcrSjEUox6gzFk0eY1G2czpc7IpOOBmmtz/Gu+2Aqk cLUklhdu1dUH7m5fA1ORjCrfIQNDC+7hDjI25ozKDRl0jVwJVAf+wh3x7Mv1zQQpB0fj qmEuCDz+0wO4vCbXaZ7vshZOzbh5cotzjpeMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wRo+4ROaCCiRKhZqj+AND77rKQUi9V5oNb3VDWgryBgrMHT9n42lJ5RDWIr50XXMSB ysF+/NnIaWzeswqYkogBjo1GKpxGGKoTX89Dpm0WFmePfGy6+ZStzjIuel6fTn1KSLlX obt/mhSrWrt9RmvfBCF/qnQSFTQ870vYYIdWA= Received: by 10.100.119.17 with SMTP id r17mr1295205anc.7.1213803778031; Wed, 18 Jun 2008 08:42:58 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Wed, 18 Jun 2008 08:42:57 -0700 (PDT) Message-ID: <5e2406980806180842i110346fbh51103bab8532a8f9@mail.gmail.com> Date: Wed, 18 Jun 2008 17:42:57 +0200 From: "Julien Bournelle" To: "Frank Xia" In-Reply-To: <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <174910.53440.qm@web84304.mail.re1.yahoo.com> <5e2406980806170802p3f39465an80b160c3062494b@mail.gmail.com> <006301c8d08d$a38270a0$5c0c7c0a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Tue, Jun 17, 2008 at 5:20 PM, Frank Xia wrote: > Hi Julien and Glen > > I will appreciate you guys insightful view, > If you give me your understanding about > essence of Diameter application and does > not just assert that " this is the misusing of > Diameter". > > IMHO, Diameter as a AAA protocol > can be used in dynamically authorization. > Address management(including prefix > delegation) is a kind of authorization. hmm, AAA is Authentication, Authorization and Accounting. The authorization part of the process is tied to the authentication. You authenticate a user and based on this authentication you authorize a service. And then, you perform accouting. At least this is my understanding. Diameter is a AAA protocol. So I don't see how Diameter for Prefix Delegation has to do with authentication and as you mentionned it is a "kind of authorization". What exactly the Diameter server will authorize in your application ? Regards, Julien > > BR > Frank > > > > ----- Original Message ----- From: "Julien Bournelle" > > To: "Behcet Sarikaya" > Cc: > Sent: Tuesday, June 17, 2008 10:02 AM > Subject: Re: [Dime] Diameter Prefix Delegation Application > > >> Hi behcet, all, >> >> On Tue, Jun 17, 2008 at 4:48 PM, Behcet Sarikaya >> wrote: >>> >>> Hi Glen, >>> The delegated prefixes could be used by the requesting router in RAs in >>> order to realize per-MN prefixes in cellular networks like WiMAX, so the >>> use >>> is not much related to Session-Lifetime but rather to IP session as Frank >>> pointed out. >>> The fact is that AAA is being used in managed networks for address >>> management and in prefix delegation as per 4818. The only missing piece >>> is >>> the PD application. >>> Some people are saying that it will be nice to define this missing >>> piece. >>> Let's agree on this. >> >> I don't. We already have mechanism for prefix delegation and I'm not >> convinced by your >> PS. Defining a whole Diameter Application for this seems a misuse of >> Diameter to me. >> >> Regards, >> >> Julien >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 18 09:10:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276173A69E8; Wed, 18 Jun 2008 09:10:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73E093A6964 for ; Wed, 18 Jun 2008 09:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PMCQ5ziakGd for ; Wed, 18 Jun 2008 09:10:17 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 515F83A6990 for ; Wed, 18 Jun 2008 09:10:17 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id fPqz1Z0010QkzPwA70TQ00; Wed, 18 Jun 2008 16:11:04 +0000 Received: from gwzPC ([124.121.210.158]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id fUAg1Z00E3Rc4wU8NUAv3n; Wed, 18 Jun 2008 16:11:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=Mm90216uv4x9YanVvzcA:9 a=vHegnh4ys5HsuGuaD2GAVEB15nUA:4 a=rC2wZJ5BpNYA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=ZrMMMnaxNC4A:10 a=MSl-tDqOz04A:10 a=zoKOyUDlhksA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=vvx0V1t6xTHZjbFUXcUA:9 a=iSrikyfJS1-cnIyPPUsA:7 a=UyQd8_IE10G15BIh7TFW3ir3e8sA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" References: <621094.23757.qm@web84305.mail.re1.yahoo.com> In-Reply-To: <621094.23757.qm@web84305.mail.re1.yahoo.com> Date: Wed, 18 Jun 2008 23:10:31 +0700 Message-ID: <004501c8d15d$dbdac350$939049f0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjRWD69M34ys+v+TeO8qt9uug4hHgABVCxg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0509539663==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0509539663== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C8D198.88399B50" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0046_01C8D198.88399B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: Glen, In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement? it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization I don't understand the question. BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius. I'm aware of that. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: dime@ietf.org; Behcet Sarikaya ; Julien Bournelle Sent: Tuesday, June 17, 2008 2:11:19 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... ------=_NextPart_000_0046_01C8D198.88399B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] = writes:


Glen,
  In your gut feeling, can you please assess RFC 4818 of which none = of us are coauthors vis-a-vis your statement?
it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with = _user
authorization

 

I don't understand the = question.



BTW, RFC 4818 applies to Diameter as well although the title mentions = only Radius.

I'm aware of that.


 
Regards,

Behcet

----- Original = Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Julien = Bournelle <julien.bournelle@gmail.com>
Sent: Tuesday, June 17, 2008 2:11:19 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> Hi Glen
>
> Please check my inline clarification...
>
...

> >>
> >> IMHO,  Diameter as a AAA protocol
> >> can be used in dynamically authorization.
> >
> > Of _users_.
> Frank=3D>Most of cases in the diameter PS  are users' = authorization related,
such as LMA requesting prefix for it's PMIPv6 user,  access routers = asking
for prefix for the mobile nodes attached.

I wrote: "it appears that the single application that is being = discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with = _user
authorization__.  As I stated in my original message, I'd be happy = to be
told that I'm mistaken about this but nobody's done that."  = Still true.

...


------=_NextPart_000_0046_01C8D198.88399B50-- --===============0509539663== 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://www.ietf.org/mailman/listinfo/dime --===============0509539663==-- From dime-bounces@ietf.org Wed Jun 18 09:38:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6DF3A6887; Wed, 18 Jun 2008 09:38:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0783A6A28 for ; Wed, 18 Jun 2008 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVci3Bbfoyis for ; Wed, 18 Jun 2008 09:38:12 -0700 (PDT) Received: from web84302.mail.re1.yahoo.com (web84302.mail.re1.yahoo.com [69.147.74.181]) by core3.amsl.com (Postfix) with SMTP id 2A3CD3A6887 for ; Wed, 18 Jun 2008 09:38:12 -0700 (PDT) Received: (qmail 78421 invoked by uid 60001); 18 Jun 2008 16:38:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=zldap3K1IFMNj+pjXHF0z8AxTy0E2wRh/yCYE5VYZnVca2MUa//VrOmoc0fmApqbN9eSy+5KxSzv6cHor4ApHbJhvCklHQUJzlTSrgKSwbSAN2Vm2TNoS5kvf6BvVDCG+k1UEHm/Wty5lzSrK7mCeTo4URPK89ZDCq7BufVaIDc=; X-YMail-OSG: gw5Ql44VM1lIklEblq6MPc013e7SdRm0yDW0rxbXpN5buAIP7OrOQcM1nXm5MMW94A-- Received: from [206.16.17.212] by web84302.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 09:38:59 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 09:38:59 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <743225.77745.qm@web84302.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1018714948==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1018714948== Content-Type: multipart/alternative; boundary="0-1391794609-1213807139=:77745" --0-1391794609-1213807139=:77745 Content-Type: text/plain; charset=us-ascii RFC 4818 defines an application (a mini application) by which the delegating router gets a bunch of delegated prefixes from AAA server that has them. The question is this: can you qualify this "application" as a valid AAA application according to your qualification? In my opinion it is because AAA server authorizes the use the prefixes by AAA client. ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya Cc: dime@ietf.org Sent: Wednesday, June 18, 2008 11:10:31 AM Subject: RE: [Dime] Diameter Prefix Delegation Application Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: Glen, In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement? it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization I don't understand the question. BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius. I'm aware of that. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: dime@ietf.org; Behcet Sarikaya ; Julien Bournelle Sent: Tuesday, June 17, 2008 2:11:19 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... --0-1391794609-1213807139=:77745 Content-Type: text/html; charset=us-ascii
RFC 4818 defines an application (a mini application) by which the delegating router gets a bunch of delegated prefixes from AAA server that has them. The question is this: can you qualify this "application" as a valid AAA application according to your qualification?

In my opinion it is because AAA server authorizes the use the prefixes by AAA client.

----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org
Sent: Wednesday, June 18, 2008 11:10:31 AM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes:


Glen,
  In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement?
it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization

 

I don't understand the question.



BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius.

I'm aware of that.


 
Regards,

Behcet

----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Julien Bournelle <julien.bournelle@gmail.com>
Sent: Tuesday, June 17, 2008 2:11:19 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> Hi Glen
>
> Please check my inline clarification...
>
...

> >>
> >> IMHO,  Diameter as a AAA protocol
> >> can be used in dynamically authorization.
> >
> > Of _users_.
> Frank=>Most of cases in the diameter PS  are users' authorization related,
such as LMA requesting prefix for it's PMIPv6 user,  access routers asking
for prefix for the mobile nodes attached.

I wrote: "it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization__.  As I stated in my original message, I'd be happy to be
told that I'm mistaken about this but nobody's done that."  Still true.

...


--0-1391794609-1213807139=:77745-- --===============1018714948== 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://www.ietf.org/mailman/listinfo/dime --===============1018714948==-- From dime-bounces@ietf.org Wed Jun 18 10:54:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01C83A687E; Wed, 18 Jun 2008 10:54:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAF23A687E for ; Wed, 18 Jun 2008 10:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0TfP37uxgle for ; Wed, 18 Jun 2008 10:54:04 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id B94B63A6858 for ; Wed, 18 Jun 2008 10:54:03 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA04.westchester.pa.mail.comcast.net with comcast id fS1Z1Z0060Fqzac540MM00; Wed, 18 Jun 2008 17:54:51 +0000 Received: from gwzPC ([124.121.210.158]) by OMTA08.westchester.pa.mail.comcast.net with comcast id fVuN1Z00E3Rc4wU3UVuhTU; Wed, 18 Jun 2008 17:54:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=v8YAdZnhBq4sdVIfy18A:9 a=swJBrQC_xK7SQ7SQaYEA:7 a=Pcw4ZDTQiGj0HpMw3-LqFone95AA:4 a=rC2wZJ5BpNYA:10 a=si9q_4b84H0A:10 a=ZrMMMnaxNC4A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=MSl-tDqOz04A:10 a=zoKOyUDlhksA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=imtrvfTCOVAZu186RxgA:9 a=SRgmz_rb7_Z6OaeImIoA:7 a=BfcYizEEIXF6W47_fhQyRK_f9fcA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" References: <743225.77745.qm@web84302.mail.re1.yahoo.com> In-Reply-To: <743225.77745.qm@web84302.mail.re1.yahoo.com> Date: Thu, 19 Jun 2008 00:54:12 +0700 Message-ID: <00b801c8d16c$59932db0$0cb98910$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjRYc9MbPQYwTzpRHOdlPDGXy61UAACNwaQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============0608325921==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0608325921== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01C8D1A7.05F205B0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_00B9_01C8D1A7.05F205B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: RFC 4818 defines an application (a mini application) by which the delegating router gets a bunch of delegated prefixes from AAA server that has them. RFC 4818 says nothing about a "bunch" of prefixes, it says that "The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and can appear multiple times." The question is this: can you qualify this "application" as a valid AAA application according to your qualification? In my opinion it is because AAA server authorizes the use the prefixes by AAA client. I'm not sure where you get either of these ideas. The AAA server is authorizing the use of the prefixes by the requesting router, in this case taking the role of a NAS client; it is not, as you seem to think, simply handing out a bunch of prefixes for the RADIUS client to delegate as it may please. Please see RFC 3633 for details on the operation of prefix delegation in DHCP. ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya Cc: dime@ietf.org Sent: Wednesday, June 18, 2008 11:10:31 AM Subject: RE: [Dime] Diameter Prefix Delegation Application Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: Glen, In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement? it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization I don't understand the question. BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius. I'm aware of that. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: dime@ietf.org; Behcet Sarikaya ; Julien Bournelle Sent: Tuesday, June 17, 2008 2:11:19 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... ------=_NextPart_000_00B9_01C8D1A7.05F205B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes:


RFC 4818 defines an application = (a mini application) by which the delegating router gets a bunch of delegated = prefixes from AAA server that has them.

RFC 4818 says nothing about a "bunch" of prefixes, it says that "The = Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and  can appear multiple = times."

The question is this: can you qualify this "application" as a = valid AAA application according to your qualification?

In my opinion it is because AAA server authorizes the use the prefixes = by AAA client.

I'm not sure where you get either = of these ideas.  The AAA server is authorizing the use of the prefixes by = the requesting router, in this case taking the role of a NAS client; it is = not, as you seem to think, simply handing out a bunch of prefixes for the = RADIUS client to delegate as it may please.   Please see RFC 3633 for details on the operation of prefix delegation in = DHCP.

----- Original = Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org
Sent: Wednesday, June 18, 2008 11:10:31 AM
Subject: RE: [Dime] Diameter Prefix Delegation = Application

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] = writes:


Glen,
  In your gut feeling, can you please assess RFC 4818 of which none = of us are coauthors vis-a-vis your statement?
it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with = _user
authorization

 

I don't understand the = question.



BTW, RFC 4818 applies to Diameter as well although the title mentions = only Radius.

I'm aware of that.


 
Regards,

Behcet

----- Original = Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Julien = Bournelle <julien.bournelle@gmail.com>
Sent: Tuesday, June 17, 2008 2:11:19 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> Hi Glen
>
> Please check my inline clarification...
>
...

> >>
> >> IMHO,  Diameter as a AAA protocol
> >> can be used in dynamically authorization.
> >
> > Of _users_.
> Frank=3D>Most of cases in the diameter PS  are users' = authorization related,
such as LMA requesting prefix for it's PMIPv6 user,  access routers = asking
for prefix for the mobile nodes attached.

I wrote: "it appears that the single application that is being = discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with = _user
authorization__.  As I stated in my original message, I'd be happy = to be
told that I'm mistaken about this but nobody's done that."  = Still true.

...

------=_NextPart_000_00B9_01C8D1A7.05F205B0-- --===============0608325921== 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://www.ietf.org/mailman/listinfo/dime --===============0608325921==-- From dime-bounces@ietf.org Wed Jun 18 12:40:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B533A6A32; Wed, 18 Jun 2008 12:40:42 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564CD3A693F for ; Wed, 18 Jun 2008 12:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBIAX-Mt3I9H for ; Wed, 18 Jun 2008 12:40:38 -0700 (PDT) Received: from web84302.mail.re1.yahoo.com (web84302.mail.re1.yahoo.com [69.147.74.181]) by core3.amsl.com (Postfix) with SMTP id 66B053A687E for ; Wed, 18 Jun 2008 12:40:38 -0700 (PDT) Received: (qmail 18345 invoked by uid 60001); 18 Jun 2008 19:41:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=QlFUXGYmy3cUk7Vltal80zg2yPzEdRtc7GqXRlJKvDf808xF5s8Uz+gN4tLIy7e0VjkdGofPmmlir3TzmmbdFBds3G7iEi3+H0gIePC6yZQmCRSAcaHZsmw7zDcvoQt7Imzq/J2hkLcyUDiLWZR3CHRYrVcFRfAUD8x+n7YAeDQ=; X-YMail-OSG: Kbp954sVM1nHG7QJ2s3nY5mT_IDQ8yT7Oj2VbA7INJcdPLL6ILdCtLFmWWuMpxFt3cUwvAM4bQ8eOmSrYjgAWIESK70epXBaWlccjXXfDMaikdrqEcl45cc- Received: from [206.16.17.212] by web84302.mail.re1.yahoo.com via HTTP; Wed, 18 Jun 2008 12:41:26 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Wed, 18 Jun 2008 12:41:26 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <594049.14900.qm@web84302.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1285912059==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1285912059== Content-Type: multipart/alternative; boundary="0-1982558794-1213818086=:14900" --0-1982558794-1213818086=:14900 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya Cc: dime@ietf.org Sent: Wednesday, June 18, 2008 12:54:12 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: RFC 4818 defines an application (a mini application) by which the delegating router gets a bunch of delegated prefixes from AAA server that has them. RFC 4818 says nothing about a "bunch" of prefixes, it says that "The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and can appear multiple times." OK, Multiple number of prefixes. The question is this: can you qualify this "application" as a valid AAA application according to your qualification? In my opinion it is because AAA server authorizes the use the prefixes by AAA client. I'm not sure where you get either of these ideas. The AAA server is authorizing the use of the prefixes by the requesting router, in this case taking the role of a NAS client; OK the AAA server is AUTHORIZING the use of the prefixes by a NAS client. it is not, as you seem to think, simply handing out a bunch of prefixes for the RADIUS client to delegate as it may please. Please see RFC 3633 for details on the operation of prefix delegation in DHCP. I know RFC 3633. I am hoping that we are now in agreement more than we were before. ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya Cc: dime@ietf.org Sent: Wednesday, June 18, 2008 11:10:31 AM Subject: RE: [Dime] Diameter Prefix Delegation Application Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: Glen, In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement? it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization I don't understand the question. BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius. I'm aware of that. Regards, Behcet ----- Original Message ---- From: Glen Zorn To: Frank Xia Cc: dime@ietf.org; Behcet Sarikaya ; Julien Bournelle Sent: Tuesday, June 17, 2008 2:11:19 PM Subject: RE: [Dime] Diameter Prefix Delegation Application Frank Xia [mailto:xiayangsong@huawei.com] writes: > Hi Glen > > Please check my inline clarification... > ... > >> > >> IMHO, Diameter as a AAA protocol > >> can be used in dynamically authorization. > > > > Of _users_. > Frank=>Most of cases in the diameter PS are users' authorization related, such as LMA requesting prefix for it's PMIPv6 user, access routers asking for prefix for the mobile nodes attached. I wrote: "it appears that the single application that is being discussed and cannot be handled in Diameter NASREQ right now _has nothing to do with _user authorization__. As I stated in my original message, I'd be happy to be told that I'm mistaken about this but nobody's done that." Still true. ... --0-1982558794-1213818086=:14900 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org
Sent: Wednesday, June 18, 2008 12:54:12 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes:


RFC 4818 defines an application (a mini application) by which the delegating router gets a bunch of delegated prefixes from AAA server that has them.

RFC 4818 says nothing about a "bunch" of prefixes, it says that "The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and  can appear multiple times."

OK, Multiple number of prefixes.

The question is this: can you qualify this "application" as a valid AAA application according to your qualification?

In my opinion it is because AAA server authorizes the use the prefixes by AAA client.

I'm not sure where you get either of these ideas.  The AAA server is authorizing the use of the prefixes by the requesting router, in this case taking the role of a NAS client;


OK the AAA server is AUTHORIZING the use of the prefixes by a NAS client.


it is not, as you seem to think, simply handing out a bunch of prefixes for the RADIUS client to delegate as it may please.   Please see RFC 3633 for details on the operation of prefix delegation in DHCP.


I know RFC 3633.

I am hoping that we are now in agreement more than we were before.


----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org
Sent: Wednesday, June 18, 2008 11:10:31 AM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes:


Glen,
  In your gut feeling, can you please assess RFC 4818 of which none of us are coauthors vis-a-vis your statement?
it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization

 

I don't understand the question.



BTW, RFC 4818 applies to Diameter as well although the title mentions only Radius.

I'm aware of that.


 
Regards,

Behcet

----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org; Behcet Sarikaya <sarikaya@ieee.org>; Julien Bournelle <julien.bournelle@gmail.com>
Sent: Tuesday, June 17, 2008 2:11:19 PM
Subject: RE: [Dime] Diameter Prefix Delegation Application

Frank Xia [mailto:xiayangsong@huawei.com] writes:

> Hi Glen
>
> Please check my inline clarification...
>
...

> >>
> >> IMHO,  Diameter as a AAA protocol
> >> can be used in dynamically authorization.
> >
> > Of _users_.
> Frank=>Most of cases in the diameter PS  are users' authorization related,
such as LMA requesting prefix for it's PMIPv6 user,  access routers asking
for prefix for the mobile nodes attached.

I wrote: "it appears that the single application that is being discussed and
cannot be handled in Diameter NASREQ right now _has nothing to do with _user
authorization__.  As I stated in my original message, I'd be happy to be
told that I'm mistaken about this but nobody's done that."  Still true.

...

--0-1982558794-1213818086=:14900-- --===============1285912059== 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://www.ietf.org/mailman/listinfo/dime --===============1285912059==-- From dime-bounces@ietf.org Wed Jun 18 13:47:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3E73A6B72; Wed, 18 Jun 2008 13:47:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F03C28C1D3 for ; Wed, 18 Jun 2008 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kT1sC36LB8q for ; Wed, 18 Jun 2008 13:47:38 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 1E8243A6B8A for ; Wed, 18 Jun 2008 13:47:37 -0700 (PDT) Received: from [88.112.143.165] (a88-112-143-165.elisa-laajakaista.fi [88.112.143.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 7FC482163B9; Wed, 18 Jun 2008 23:48:18 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> From: Jouni Korhonen Date: Wed, 18 Jun 2008 23:48:08 +0300 To: dime@ietf.org X-Mailer: Apple Mail (2.753.1) Cc: Hannes Tschofenig Subject: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, A proposal related to the MIP6-Agent-Info AVP. Currently the AVP contains only the address information of the HA, which is OK in the scope of the integrated scenario. However, having a slight wider look at the possible uses for the MIP6-Agent-Info AVP it might be beneficial to include an AVP describing the "flavor" of the HA. What I am proposing is to add an enumerated MIP-Agent-Type AVP inside the group. ::= < AVP Header: TBD > [ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ] [ MIP-Agent-Type ] * [ AVP ] The initial values would include: MIP6_HA (0) MIP6_LMA (1) MIP6_DSMIP_HA (2) As a side note.. this discussion has been gone through at least once. At that time I thought using FQDN piggypack agent flavor information would be enough.. but having a separate AVP would actually be nicer imho. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 18 13:59:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F783A693F; Wed, 18 Jun 2008 13:59:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334C23A693F for ; Wed, 18 Jun 2008 13:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0Qf3FtJLjdo for ; Wed, 18 Jun 2008 13:59:05 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by core3.amsl.com (Postfix) with ESMTP id 433CA3A682C for ; Wed, 18 Jun 2008 13:59:05 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so269582pyg.24 for ; Wed, 18 Jun 2008 13:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=HTeC3AkoK8TNRC47ksfsotaEc+Knbd2xI3v892CgX4w=; b=M5kr9HE8NwXAxOdSnAo6RBsHK/MCO/zuZIxN/1GKwKUFFg3F+MMjEe8E0vc4fqD/3/ T8UkqhmecMrrgxs78x5FQzvHh4j1BbTOblWaB4rbWowQYyyhUjM5KqY+hl4g2t4x7MIL DTwo5XkOqht7Vo4JO8frtyJF2bdvrqIA6xSdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Hk85cdxqcL0SI35o8TXcKf+IYVZRH6ZO704Z/O/h1I/vnxPsMiNvpkYO4APt4O44Fu kq5iSW1CeAJ0XpbVv5RhhP5IMKC9FKN30Kfa3Dioqvop1cthbndOppsggUCKNgcxY1eC ZPlz2Rt+smUDaOLqqvPxRT6kN8KqaXYiy/wUE= Received: by 10.142.125.9 with SMTP id x9mr582400wfc.66.1213822791231; Wed, 18 Jun 2008 13:59:51 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Wed, 18 Jun 2008 13:59:51 -0700 (PDT) Message-ID: Date: Wed, 18 Jun 2008 13:59:51 -0700 From: "Vijay Devarapallli" To: "Jouni Korhonen" In-Reply-To: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, What is the need to differentiate between a MIPv6 and DS-MIPv6 HA? Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would someone deploy separate MIPv6 HA and DS-MIPv6 HA? If the discovered HA does not support IPv4 Home Address assignment, the mobile node gets to know about it anyway after the BU/BAck exchange. On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen wrote: > Hi all, > > A proposal related to the MIP6-Agent-Info AVP. Currently > the AVP contains only the address information of the HA, > which is OK in the scope of the integrated scenario. However, > having a slight wider look at the possible uses for the > MIP6-Agent-Info AVP it might be beneficial to include an > AVP describing the "flavor" of the HA. What I am proposing > is to add an enumerated MIP-Agent-Type AVP inside the group. > > ::= < AVP Header: TBD > > [ MIP-Home-Agent-Address ] > [ MIP-Home-Agent-Host ] > [ MIP-Agent-Type ] > * [ AVP ] > > > The initial values would include: > > MIP6_HA (0) > MIP6_LMA (1) > MIP6_DSMIP_HA (2) What is the MIPv6 HA and PMIPv6 LMA are co-located? Its not clear to me what the above actually is trying to achieve. For my benefit, can you please describe the scenario where such an enumerated AVP would help? I could be missing something. Vijay > > As a side note.. this discussion has been gone through at least > once. At that time I thought using FQDN piggypack agent flavor > information would be enough.. but having a separate AVP would > actually be nicer imho. > > Cheers, > Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 18 14:25:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432683A6B5E; Wed, 18 Jun 2008 14:25:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9BD3A69D8 for ; Wed, 18 Jun 2008 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ve+L-5+Mqk3r for ; Wed, 18 Jun 2008 14:25:08 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id 121ED3A6914 for ; Wed, 18 Jun 2008 14:25:08 -0700 (PDT) Received: from [88.112.143.165] (a88-112-143-165.elisa-laajakaista.fi [88.112.143.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 0582A1515A5; Thu, 19 Jun 2008 00:25:51 +0300 (EEST) In-Reply-To: References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <96BE5549-EB82-4F45-8DDD-BCDAD6C9415B@iki.fi> From: Jouni Korhonen Date: Thu, 19 Jun 2008 00:25:49 +0300 To: "Vijay Devarapallli" X-Mailer: Apple Mail (2.753.1) Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Vijay, On Jun 18, 2008, at 11:59 PM, Vijay Devarapallli wrote: > Hi Jouni, > > What is the need to differentiate between a MIPv6 and DS-MIPv6 HA? > Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would > someone deploy separate MIPv6 HA and DS-MIPv6 HA? If the discovered HA Nothing prevents anyone deploying plain MIP6 HA. > does not support IPv4 Home Address assignment, the mobile node gets to > know about it anyway after the BU/BAck exchange. You could definitely do that in this way. What I was thinking is more like that in DSMIP6 you can manage the IP4-HoA assignment via a subscription policy, where as in MIP6 you just don't have that capability at all. It might be better to be explicit here..? Cheers, Jouni > > On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen > wrote: >> Hi all, >> >> A proposal related to the MIP6-Agent-Info AVP. Currently >> the AVP contains only the address information of the HA, >> which is OK in the scope of the integrated scenario. However, >> having a slight wider look at the possible uses for the >> MIP6-Agent-Info AVP it might be beneficial to include an >> AVP describing the "flavor" of the HA. What I am proposing >> is to add an enumerated MIP-Agent-Type AVP inside the group. >> >> ::= < AVP Header: TBD > >> [ MIP-Home-Agent-Address ] >> [ MIP-Home-Agent-Host ] >> [ MIP-Agent-Type ] >> * [ AVP ] >> >> >> The initial values would include: >> >> MIP6_HA (0) >> MIP6_LMA (1) >> MIP6_DSMIP_HA (2) > > What is the MIPv6 HA and PMIPv6 LMA are co-located? > > Its not clear to me what the above actually is trying to achieve. For > my benefit, can you please describe the scenario where such an > enumerated AVP would help? I could be missing something. > > Vijay > >> >> As a side note.. this discussion has been gone through at least >> once. At that time I thought using FQDN piggypack agent flavor >> information would be enough.. but having a separate AVP would >> actually be nicer imho. >> >> Cheers, >> Jouni >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 19 08:24:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304423A6B8F; Thu, 19 Jun 2008 08:24:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817123A6B8F for ; Thu, 19 Jun 2008 08:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRrd3D1HhyLd for ; Thu, 19 Jun 2008 08:24:43 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 3DBBB3A6AD0 for ; Thu, 19 Jun 2008 08:24:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0338E90010 for ; Thu, 19 Jun 2008 11:25:31 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06462-11 for ; Thu, 19 Jun 2008 11:25:30 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 19 Jun 2008 11:25:30 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 11:25:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 11:25:29 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dime-mip6-integrated and the type of home agent Thread-Index: AcjRhK2ivlHIaMtySbWcOurgVmrXrgAmxx/Q References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> From: "Chowdhury, Kuntal" To: "Jouni Korhonen" , X-OriginalArrivalTime: 19 Jun 2008 15:25:30.0204 (UTC) FILETIME=[B544F1C0:01C8D220] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Hannes Tschofenig Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, I agree with you that having an explicit AVP for this is better than overloading some other parameter. A few clarifications: " MIP-Home-Agent-Host" - is this FQDN of the home agent? If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 LMA, how can we encode the type field? Should we encode it as bitmask? -Kuntal > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] > Sent: Wednesday, June 18, 2008 3:48 PM > To: dime@ietf.org > Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal > Subject: dime-mip6-integrated and the type of home agent > > Hi all, > > A proposal related to the MIP6-Agent-Info AVP. Currently > the AVP contains only the address information of the HA, > which is OK in the scope of the integrated scenario. However, > having a slight wider look at the possible uses for the > MIP6-Agent-Info AVP it might be beneficial to include an > AVP describing the "flavor" of the HA. What I am proposing > is to add an enumerated MIP-Agent-Type AVP inside the group. > > ::= < AVP Header: TBD > > [ MIP-Home-Agent-Address ] > [ MIP-Home-Agent-Host ] > [ MIP-Agent-Type ] > * [ AVP ] > > > The initial values would include: > > MIP6_HA (0) > MIP6_LMA (1) > MIP6_DSMIP_HA (2) > > As a side note.. this discussion has been gone through at least > once. At that time I thought using FQDN piggypack agent flavor > information would be enough.. but having a separate AVP would > actually be nicer imho. > > Cheers, > Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 19 11:27:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093863A697D; Thu, 19 Jun 2008 11:27:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B314528C119 for ; Thu, 19 Jun 2008 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI5M81GxYWSn for ; Thu, 19 Jun 2008 11:27:21 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by core3.amsl.com (Postfix) with ESMTP id 69EC53A697D for ; Thu, 19 Jun 2008 11:27:21 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so417638pyg.24 for ; Thu, 19 Jun 2008 11:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=F80528NacDb+ib0jD8MJc5LW7buVVUuw0EvfhB9m8zo=; b=HknParj/ew7u1PNJPWHXONW3c35+GYBkhap2FQc4GPzrgCfHh7Swo0BbrUPVFhvMGF BhZYgeBJgYZVUTHTOT4zaTQKTSCPpaxR4oWo8Dki2pRxUP71zV9/sVfqywXdTfU4RlrG WwCmEZH5U7DzQ2520EyrRoXtWjnTzFf4+lGmY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ikqTydfFP/diWAJ9skSW2AKWH3ckvkzMjS3VJRE3aasvqLcSkom3Jzatom/tlVLv1D 6DfkE5tvhYqJmxHmERDCfZdAC6tEeYtQjUhEDfu2FzUSKaAi8ZoFu7/c+VzNMSwLZfW5 oAblOOVIgfhSQoTm7pQhfeCDcRNV0wdjGnYtc= Received: by 10.141.198.2 with SMTP id a2mr1829122rvq.219.1213900091981; Thu, 19 Jun 2008 11:28:11 -0700 (PDT) Received: by 10.140.144.4 with HTTP; Thu, 19 Jun 2008 11:28:11 -0700 (PDT) Message-ID: Date: Thu, 19 Jun 2008 11:28:11 -0700 From: "Vijay Devarapallli" To: "Chowdhury, Kuntal" In-Reply-To: <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> MIME-Version: 1.0 Content-Disposition: inline References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Thu, Jun 19, 2008 at 8:25 AM, Chowdhury, Kuntal wrote: > Jouni, > > I agree with you that having an explicit AVP for this is better than > overloading some other parameter. I am not too comfortable with overloading the home agent AVP to tell the MAG/Access router which mobility protocol to use for a particular session. Why can't we define a separate AVP that tells the MAG/Access router which mobility protocol is being used for an ongoing session instead of the MAG/Access router figuring this out from the "type" of the home agent? Vijay > > A few clarifications: > > " MIP-Home-Agent-Host" - is this FQDN of the home agent? > > If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 LMA, > how can we encode the type field? Should we encode it as bitmask? > > -Kuntal > > >> -----Original Message----- >> From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] >> Sent: Wednesday, June 18, 2008 3:48 PM >> To: dime@ietf.org >> Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal >> Subject: dime-mip6-integrated and the type of home agent >> >> Hi all, >> >> A proposal related to the MIP6-Agent-Info AVP. Currently >> the AVP contains only the address information of the HA, >> which is OK in the scope of the integrated scenario. However, >> having a slight wider look at the possible uses for the >> MIP6-Agent-Info AVP it might be beneficial to include an >> AVP describing the "flavor" of the HA. What I am proposing >> is to add an enumerated MIP-Agent-Type AVP inside the group. >> >> ::= < AVP Header: TBD > >> [ MIP-Home-Agent-Address ] >> [ MIP-Home-Agent-Host ] >> [ MIP-Agent-Type ] >> * [ AVP ] >> >> >> The initial values would include: >> >> MIP6_HA (0) >> MIP6_LMA (1) >> MIP6_DSMIP_HA (2) >> >> As a side note.. this discussion has been gone through at least >> once. At that time I thought using FQDN piggypack agent flavor >> information would be enough.. but having a separate AVP would >> actually be nicer imho. >> >> Cheers, >> Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 19 15:01:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607CD3A69A0; Thu, 19 Jun 2008 15:01:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23B313A69B6 for ; Thu, 19 Jun 2008 15:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdDiStuhKzAb for ; Thu, 19 Jun 2008 15:01:32 -0700 (PDT) Received: from female.eservglobal.co.nz (mail.eservglobal.co.nz [125.236.61.195]) by core3.amsl.com (Postfix) with ESMTP id 24C693A69A0 for ; Thu, 19 Jun 2008 15:01:31 -0700 (PDT) Received: from rloader.eservglobal.co.nz (rloader.eservglobal.co.nz [192.168.7.230]) by female.eservglobal.co.nz (8.13.8/8.13.8/Debian-3) with ESMTP id m5JM1LRx031384 for ; Fri, 20 Jun 2008 10:01:22 +1200 Date: Fri, 20 Jun 2008 10:01:21 +1200 From: Ralph Loader To: dime@ietf.org Message-ID: <20080620100121.458fcad8@rloader.eservglobal.co.nz> Organization: eServGlobal X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 X-Virus-Scanned: ClamAV 0.93.1/7508/Fri Jun 20 07:34:25 2008 on smtp.eservglobal.co.nz X-Virus-Status: Clean Subject: [Dime] Meaning of '*{...}'? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, What is the exact meaning of '*{...}' in a grammar: 0 or more occurrences or 1 or more occurrences? + If you read the quantifier '*' to override the 'must-occur' quantification implicit in '{...}', then it means 0-or-more. + If you read '*{...}' to require both the quantifier '*' and the implicit quantification in '{...}' be satisfied, then it means 1-or-more. Reading RFC 3588, I believe that the intent might have been the first (e.g., note the text on 0*1fixed and also various usages of '{...}' with an explicit quantifier in RFC 3588. [This is also the RFC 2234 meaing of '*']. Reading RFC 3588 strictly, the MUST in the definition of required doesn't seem to have any exceptions, which suggests the second interpretation? 3gpp specs use '*{...}' in at least one place where the context makes me suspect they mean 1-or-more. Ralph. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 20 09:48:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606443A685A; Fri, 20 Jun 2008 09:48:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393653A685A for ; Fri, 20 Jun 2008 09:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIBSFm+xPo3q for ; Fri, 20 Jun 2008 09:48:38 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 16AFB3A6407 for ; Fri, 20 Jun 2008 09:48:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2F535C803D for ; Fri, 20 Jun 2008 12:48:33 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05055-16 for ; Fri, 20 Jun 2008 12:48:32 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 20 Jun 2008 12:48:32 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jun 2008 12:48:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 12:48:31 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266601512B64@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-mip6-integrated and the type of home agent Thread-Index: AcjSOkBuI3RaM70ITZSzBn7N/dvyTAAus+fA References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> From: "Chowdhury, Kuntal" To: "Vijay Devarapallli" X-OriginalArrivalTime: 20 Jun 2008 16:48:32.0185 (UTC) FILETIME=[792CAA90:01C8D2F5] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Vijay, Even if we define a new AVP for the protocol-type, we will have to always group it with the home agent AVP. In that case, what is the advantage of having a separate standalone AVP? -Kuntal > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Thursday, June 19, 2008 1:28 PM > To: Chowdhury, Kuntal > Cc: Jouni Korhonen; dime@ietf.org; Hannes Tschofenig > Subject: Re: [Dime] dime-mip6-integrated and the type of home agent > > On Thu, Jun 19, 2008 at 8:25 AM, Chowdhury, Kuntal > wrote: > > Jouni, > > > > I agree with you that having an explicit AVP for this is better than > > overloading some other parameter. > > I am not too comfortable with overloading the home agent AVP to tell > the MAG/Access router which mobility protocol to use for a particular > session. Why can't we define a separate AVP that tells the MAG/Access > router which mobility protocol is being used for an ongoing session > instead of the MAG/Access router figuring this out from the "type" of > the home agent? > > Vijay > > > > > A few clarifications: > > > > " MIP-Home-Agent-Host" - is this FQDN of the home agent? > > > > If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 LMA, > > how can we encode the type field? Should we encode it as bitmask? > > > > -Kuntal > > > > > >> -----Original Message----- > >> From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] > >> Sent: Wednesday, June 18, 2008 3:48 PM > >> To: dime@ietf.org > >> Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal > >> Subject: dime-mip6-integrated and the type of home agent > >> > >> Hi all, > >> > >> A proposal related to the MIP6-Agent-Info AVP. Currently > >> the AVP contains only the address information of the HA, > >> which is OK in the scope of the integrated scenario. However, > >> having a slight wider look at the possible uses for the > >> MIP6-Agent-Info AVP it might be beneficial to include an > >> AVP describing the "flavor" of the HA. What I am proposing > >> is to add an enumerated MIP-Agent-Type AVP inside the group. > >> > >> ::= < AVP Header: TBD > > >> [ MIP-Home-Agent-Address ] > >> [ MIP-Home-Agent-Host ] > >> [ MIP-Agent-Type ] > >> * [ AVP ] > >> > >> > >> The initial values would include: > >> > >> MIP6_HA (0) > >> MIP6_LMA (1) > >> MIP6_DSMIP_HA (2) > >> > >> As a side note.. this discussion has been gone through at least > >> once. At that time I thought using FQDN piggypack agent flavor > >> information would be enough.. but having a separate AVP would > >> actually be nicer imho. > >> > >> Cheers, > >> Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 20 09:54:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57AD3A697D; Fri, 20 Jun 2008 09:54:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC423A68D9 for ; Fri, 20 Jun 2008 09:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oadmlyVgq7RN for ; Fri, 20 Jun 2008 09:54:55 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id 943623A697D for ; Fri, 20 Jun 2008 09:54:55 -0700 (PDT) Received: (qmail 85309 invoked by uid 60001); 20 Jun 2008 16:54:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=uk7ZULBamJ+N5xyf/whR+Dq/YavAjWdlz3ILWz+2qs8lcVEibhUvg37471fno8pLLRKe939lKstjLpRFjLJOGRhFNXI9tmuYqdDOAZ4++mnnUEaDGgbe/KacciJwi3Mpzm5Nw9qPvESWWkOXg7iL0zAw4zjh/1NBEUMsvf5pW48=; X-YMail-OSG: t_cwXDQVM1kAdPuMEUn_KNQObc.S.yn1P3R.uCL5BlpcJViunFAIwig9SnCLHNESdQ6NesNP3sIjpOARbRAgPAYlyiV80I.Ddg-- Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Fri, 20 Jun 2008 09:54:56 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.185 Date: Fri, 20 Jun 2008 09:54:56 -0700 (PDT) From: Behcet Sarikaya To: Ralph Droms , dime@ietf.org MIME-Version: 1.0 Message-ID: <911623.85208.qm@web84303.mail.re1.yahoo.com> Cc: Droms Ralph Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1866350079==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1866350079== Content-Type: multipart/alternative; boundary="0-1531264856-1213980896=:85208" --0-1531264856-1213980896=:85208 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Ralph Droms To: dime@ietf.org Cc: Droms Ralph ; Behcet Sarikaya ; Joseph Salowey (jsalowey) ; Glen Zorn Sent: Friday, June 20, 2008 4:49:33 AM Subject: Re: [Dime] Diameter Prefix Delegation Application The intent for the Delegated-IPv6-Prefix attribute is that it be returned to the AAA client at the time the user is authenticated, perhaps along with similar attributes like Framed-IPv6-Prefix and Framed-Interface-ID. As shown in the diagram in the Introduction of RFC 4818, the Delegated-IPv6-Prefix can be returned to the Delegating Router (DR), which then returns the prefix to the Requesting Router (RR) as part of DHCPv6 prefix delegation (this diagram might have been clarified with a more detailed description of the Delegated-IPv6- Prefix as returned as part of the user authentication Request message exchange along with the indication of authentication and other user attributes): This document defines the Delegated-IPv6-Prefix attribute as a RADIUS [1] attribute that carries an IPv6 prefix to be delegated to the user, for use in the user's network. For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. The Delegated-IPv6-Prefix attribute can be used in DHCP Prefix Delegation between the delegating router and a RADIUS server, as illustrated in the following message sequence. Requesting Router Delegating Router RADIUS Server | | | |-Solicit------------>| | | |-Request------------------------>| | |<--Accept(Delegated-IPv6-Prefix)-| |<--Advertise(Prefix)-| | |-Request(Prefix)---->| | |<--Reply(Prefix)-----| | | | | DHCP PD RADIUS [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. If I understand the proposal to "develop an AAA application to get prefixes directly from AAA server?", it would be similar to an application that would perform a AAA transaction to obtain a Framed-IP- Address, Framed-IP-Netmask, Framed-IPv6-Prefix or a Framed-Interface- ID directly from the AAA server. [behcet] Yes, kind of. Anyways, we are revising the PS draft and hopefully will be able better explain the problem. Regards, Behcet snipped the rest. --0-1531264856-1213980896=:85208 Content-Type: text/html; charset=us-ascii
----- Original Message ----
From: Ralph Droms <rdroms@cisco.com>
To: dime@ietf.org
Cc: Droms Ralph <rdroms@cisco.com>; Behcet Sarikaya <sarikaya@ieee.org>; Joseph Salowey (jsalowey) <jsalowey@cisco.com>; Glen Zorn <glenzorn@comcast.net>
Sent: Friday, June 20, 2008 4:49:33 AM
Subject: Re: [Dime] Diameter Prefix Delegation Application

The intent for the Delegated-IPv6-Prefix attribute is that it be 
returned to the AAA client at the time the user is authenticated, 
perhaps along with similar attributes like Framed-IPv6-Prefix and 
Framed-Interface-ID.  As shown in the diagram in the Introduction of 
RFC 4818, the Delegated-IPv6-Prefix can be returned to the Delegating 
Router (DR), which then returns the prefix to the Requesting Router 
(RR) as part of DHCPv6 prefix delegation (this diagram might have been 
clarified with a more detailed description of the Delegated-IPv6-
Prefix as returned as part of the user authentication Request message 
exchange along with the indication of authentication and other user 
attributes):

    This document defines the Delegated-IPv6-Prefix attribute as a 
RADIUS
    [1] attribute that carries an IPv6 prefix to be delegated to the
    user, for use in the user's network.  For example, the prefix in a
    Delegated-IPv6-Prefix attribute can be delegated to another node
    through DHCP Prefix Delegation [2].

    The Delegated-IPv6-Prefix attribute can be used in DHCP Prefix
    Delegation between the delegating router and a RADIUS server, as
    illustrated in the following message sequence.


    Requesting Router  Delegating Router                  RADIUS 
Server
          |                    |                                |
          |-Solicit------------>|                                |
          |                    |-Request------------------------>|
          |                    |<--Accept(Delegated-IPv6-Prefix)-|
          |<--Advertise(Prefix)-|                                |
          |-Request(Prefix)---->|                                |
          |<--Reply(Prefix)-----|                                |
          |                    |                                |
                DHCP PD                      RADIUS

    [1]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2865, June
        2000.

    [2]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
        Configuration Protocol (DHCP) version 6", RFC 3633, December
        2003.

If I understand the proposal to "develop an AAA application to get 
prefixes directly from AAA server?", it would be similar to an 
application that would perform a AAA transaction to obtain a Framed-IP-
Address, Framed-IP-Netmask, Framed-IPv6-Prefix or a Framed-Interface-
ID directly from the AAA server.

[behcet] Yes, kind of. Anyways, we are revising the PS draft and hopefully will be able better explain the problem.

Regards,

Behcet


snipped the rest.
--0-1531264856-1213980896=:85208-- --===============1866350079== 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://www.ietf.org/mailman/listinfo/dime --===============1866350079==-- From dime-bounces@ietf.org Fri Jun 20 10:35:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBC63A685A; Fri, 20 Jun 2008 10:35:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFB13A685A for ; Fri, 20 Jun 2008 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXCRVySfBW+Z for ; Fri, 20 Jun 2008 10:35:46 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 31E443A63EC for ; Fri, 20 Jun 2008 10:35:46 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id gD0j1Z0070b6N64A70Ef00; Fri, 20 Jun 2008 17:35:47 +0000 Received: from gwzPC ([124.120.228.43]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id gHb91Z0010wpDiL8PHbY98; Fri, 20 Jun 2008 17:35:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=FOmgcpI-EsUA:10 a=Ka3iKFTZHl8A:10 a=ljocgtf3FKjhJK3uYo4A:9 a=wd_YTpA8k1y687lTH7hdwkuDa98A:4 a=rC2wZJ5BpNYA:10 a=zoKOyUDlhksA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=h7nMSrqla0YZHh62HIsA:7 a=9Dzg-5eZYkmdFom4XYR_tmznnLMA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" References: <911623.85208.qm@web84303.mail.re1.yahoo.com> In-Reply-To: <911623.85208.qm@web84303.mail.re1.yahoo.com> Date: Sat, 21 Jun 2008 00:34:45 +0700 Message-ID: <007b01c8d2fb$fa105de0$ee3119a0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjS9l6KA1d/WWaVQsmV0eEY1v83qQABPseA Content-Language: en-us Cc: dime@ietf.org, 'Ralph Droms' Subject: Re: [Dime] Diameter Prefix Delegation Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1169033213==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1169033213== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C8D336.A66F5CF0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_007C_01C8D336.A66F5CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] writes: . If I understand the proposal to "develop an AAA application to get prefixes directly from AAA server?", it would be similar to an application that would perform a AAA transaction to obtain a Framed-IP- Address, Framed-IP-Netmask, Framed-IPv6-Prefix or a Framed-Interface- ID directly from the AAA server. [behcet] Yes, kind of. Anyways, we are revising the PS draft and hopefully will be able better explain the problem. That should be interesting, since thus far the only problems you have described are either a) already solved in existing Diameter applications or b) outside the scope of AAA altogether. Regards, Behcet snipped the rest. ------=_NextPart_000_007C_01C8D336.A66F5CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] = writes:


…
If I understand the proposal to "develop an AAA = application to get 
prefixes directly from AAA server?", it would be similar to = an 
application that would perform a AAA transaction to obtain a Framed-IP- =
Address, Framed-IP-Netmask, Framed-IPv6-Prefix or a Framed-Interface- =
ID directly from the AAA server.

[behcet] Yes, kind of. Anyways, we are = revising the PS draft and hopefully will be able better explain the = problem.

 

That should be interesting, since thus far the only = problems you have described are either a) already solved in existing Diameter = applications or b) outside the scope of AAA = altogether…



Regards,

Behcet


snipped the rest.

------=_NextPart_000_007C_01C8D336.A66F5CF0-- --===============1169033213== 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://www.ietf.org/mailman/listinfo/dime --===============1169033213==-- From dime-bounces@ietf.org Fri Jun 20 11:38:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8267F28C111; Fri, 20 Jun 2008 11:38:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C973A6A3B for ; Fri, 20 Jun 2008 11:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0EUl8Cpnwny for ; Fri, 20 Jun 2008 11:38:29 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id 2F45F3A6989 for ; Fri, 20 Jun 2008 11:38:29 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m36so209362rnd.18 for ; Fri, 20 Jun 2008 11:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=kf9YuPblkBVK1+nGxsQQlO6NrZSEBxhAV9BcEh8kabs=; b=wnp3O3q5iZqBXQ5gflyZ/aFFOLoYRuDl4kvguaBNzWbtkw42mKKPmqqv3PcDm/sBc4 adrNMa6gLffNXDOAogTgHgPUziIGbVaV4RgN3mdvaC81mROYGAL6usYjC+k4sHx+P1o4 wu0aQ7povUuWMHn+7pDn486Vzot0CgfC+UI5E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ChwSRk9D/o1EFM+wj6BTwwCL7lfxZDfgnK0pzvNejDFCsBXnNhwWL9bEj/1Hfo1BSP xRIHWkszsme8y8AmujV8Sv9Fcx7/S7S06+9YqH1Mkqh/+jpJBFH5s+NQfjMLgSm4A4Zt twoxy4YTmDHlruf8Lkf6ex/hZvlww0nBAjnoM= Received: by 10.142.127.10 with SMTP id z10mr1685280wfc.169.1213987110186; Fri, 20 Jun 2008 11:38:30 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Fri, 20 Jun 2008 11:38:30 -0700 (PDT) Message-ID: Date: Fri, 20 Jun 2008 11:38:30 -0700 From: "Vijay Devarapallli" To: "Chowdhury, Kuntal" In-Reply-To: <4D35478224365146822AE9E3AD4A266601512B64$0001@exchtewks3.starentnetworks.com> MIME-Version: 1.0 Content-Disposition: inline References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266601512B64$0001@exchtewks3.starentnetworks.com> Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Fri, Jun 20, 2008 at 9:48 AM, Chowdhury, Kuntal wrote: > Vijay, > > Even if we define a new AVP for the protocol-type, we will have to > always group it with the home agent AVP. In that case, what is the > advantage of having a separate standalone AVP? Don't you see the advantage? I think it makes sense not to overload the home agent AVP. Rather we should define an explicit AVP that indicates which mobility protocol (DS-MIPv6 or PMIPv6) is being used for an on-going session. This can be sent along with the Home Agent information (which would just contain the IP address of the home agent/LMA). Ideally, there shouldn't be a need for the MAG/Access router to be told which mobility protocol to use. But never mind. :) Vijay > > -Kuntal > > >> -----Original Message----- >> From: Vijay Devarapallli [mailto:dvijay@gmail.com] >> Sent: Thursday, June 19, 2008 1:28 PM >> To: Chowdhury, Kuntal >> Cc: Jouni Korhonen; dime@ietf.org; Hannes Tschofenig >> Subject: Re: [Dime] dime-mip6-integrated and the type of home agent >> >> On Thu, Jun 19, 2008 at 8:25 AM, Chowdhury, Kuntal >> wrote: >> > Jouni, >> > >> > I agree with you that having an explicit AVP for this is better than >> > overloading some other parameter. >> >> I am not too comfortable with overloading the home agent AVP to tell >> the MAG/Access router which mobility protocol to use for a particular >> session. Why can't we define a separate AVP that tells the MAG/Access >> router which mobility protocol is being used for an ongoing session >> instead of the MAG/Access router figuring this out from the "type" of >> the home agent? >> >> Vijay >> >> > >> > A few clarifications: >> > >> > " MIP-Home-Agent-Host" - is this FQDN of the home agent? >> > >> > If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 > LMA, >> > how can we encode the type field? Should we encode it as bitmask? >> > >> > -Kuntal >> > >> > >> >> -----Original Message----- >> >> From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] >> >> Sent: Wednesday, June 18, 2008 3:48 PM >> >> To: dime@ietf.org >> >> Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal >> >> Subject: dime-mip6-integrated and the type of home agent >> >> >> >> Hi all, >> >> >> >> A proposal related to the MIP6-Agent-Info AVP. Currently >> >> the AVP contains only the address information of the HA, >> >> which is OK in the scope of the integrated scenario. However, >> >> having a slight wider look at the possible uses for the >> >> MIP6-Agent-Info AVP it might be beneficial to include an >> >> AVP describing the "flavor" of the HA. What I am proposing >> >> is to add an enumerated MIP-Agent-Type AVP inside the group. >> >> >> >> ::= < AVP Header: TBD > >> >> [ MIP-Home-Agent-Address ] >> >> [ MIP-Home-Agent-Host ] >> >> [ MIP-Agent-Type ] >> >> * [ AVP ] >> >> >> >> >> >> The initial values would include: >> >> >> >> MIP6_HA (0) >> >> MIP6_LMA (1) >> >> MIP6_DSMIP_HA (2) >> >> >> >> As a side note.. this discussion has been gone through at least >> >> once. At that time I thought using FQDN piggypack agent flavor >> >> information would be enough.. but having a separate AVP would >> >> actually be nicer imho. >> >> >> >> Cheers, >> >> Jouni >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.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://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jun 20 23:22:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74C73A6844; Fri, 20 Jun 2008 23:22:32 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701BA3A6847 for ; Fri, 20 Jun 2008 23:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcCKLjSl+uVX for ; Fri, 20 Jun 2008 23:22:27 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 1FD0B3A67F2 for ; Fri, 20 Jun 2008 23:22:25 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id gVAN1Z00B0vp7WLA404x00; Sat, 21 Jun 2008 06:22:28 +0000 Received: from gwzPC ([124.120.216.209]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id gWMz1Z0064XfBKQ8RWNJfo; Sat, 21 Jun 2008 06:22:26 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=p3Aa3uIHmUPb4GWaGLsA:9 a=o9BcZMSKuzfRsOtjXaFhs3VmuTIA:4 a=BFDKbZatV3MA:10 a=lZB815dzVvQA:10 a=2uiCRmbCp6AA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" References: <48580FD9.2030909@gmx.net> In-Reply-To: <48580FD9.2030909@gmx.net> Date: Sat, 21 Jun 2008 13:21:28 +0700 Message-ID: <000001c8d367$12f4e270$38dea750$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjQsAldL/loWCSGSQSrtLl+V6X7zgCtrV/w Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Request for Agenda Items X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig writes: > Hi all, > > we need to prepare the agenda for the meeting. Please let me know what > you believe we should definitely discuss or shouldn't discuss anymore. I could use a slot to talk about changes to the MIBs. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jun 21 10:14:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530003A695B; Sat, 21 Jun 2008 10:14:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6BB3A6981 for ; Sat, 21 Jun 2008 10:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCb8ieEsbWCg for ; Sat, 21 Jun 2008 10:14:56 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id DE7673A695B for ; Sat, 21 Jun 2008 10:14:55 -0700 (PDT) Received: from [88.114.173.194] (a88-114-173-194.elisa-laajakaista.fi [88.114.173.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id ECCD213967D; Sat, 21 Jun 2008 20:14:52 +0300 (EEST) In-Reply-To: <4D35478224365146822AE9E3AD4A266601512B41$0001@exchtewks3.starentnetworks.com> References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <4D35478224365146822AE9E3AD4A266601512B41$0001@exchtewks3.starentnetworks.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Jouni Korhonen Date: Sat, 21 Jun 2008 20:14:50 +0300 To: "Chowdhury, Kuntal" X-Mailer: Apple Mail (2.753.1) Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Kuntal, On Jun 19, 2008, at 6:25 PM, Chowdhury, Kuntal wrote: > Jouni, > > I agree with you that having an explicit AVP for this is better than > overloading some other parameter. > > A few clarifications: > > " MIP-Home-Agent-Host" - is this FQDN of the home agent? Contains the FQDN of the HA.. as well as the realm ;) > > If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 LMA, > how can we encode the type field? Should we encode it as bitmask? You could have 1) multiple instances of MIP6-Agent-Info or 2) use bitmask.. Latter could be more efficient. In case of bitmask one could also dedicate a bit for local/home allocation information as well (though the MIP-Home-Agent-Host already contains the realm information for that purpose). Cheers, Jouni > > -Kuntal > > >> -----Original Message----- >> From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] >> Sent: Wednesday, June 18, 2008 3:48 PM >> To: dime@ietf.org >> Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal >> Subject: dime-mip6-integrated and the type of home agent >> >> Hi all, >> >> A proposal related to the MIP6-Agent-Info AVP. Currently >> the AVP contains only the address information of the HA, >> which is OK in the scope of the integrated scenario. However, >> having a slight wider look at the possible uses for the >> MIP6-Agent-Info AVP it might be beneficial to include an >> AVP describing the "flavor" of the HA. What I am proposing >> is to add an enumerated MIP-Agent-Type AVP inside the group. >> >> ::= < AVP Header: TBD > >> [ MIP-Home-Agent-Address ] >> [ MIP-Home-Agent-Host ] >> [ MIP-Agent-Type ] >> * [ AVP ] >> >> >> The initial values would include: >> >> MIP6_HA (0) >> MIP6_LMA (1) >> MIP6_DSMIP_HA (2) >> >> As a side note.. this discussion has been gone through at least >> once. At that time I thought using FQDN piggypack agent flavor >> information would be enough.. but having a separate AVP would >> actually be nicer imho. >> >> Cheers, >> Jouni > > > "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://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jun 22 13:58:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8373A67F3; Sun, 22 Jun 2008 13:58:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0483A6832 for ; Sun, 22 Jun 2008 13:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qk-lTcTs+E9 for ; Sun, 22 Jun 2008 13:57:58 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 33A113A67D8 for ; Sun, 22 Jun 2008 13:57:57 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Jun 2008 22:58:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 22 Jun 2008 22:58:02 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D3D7@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-mip6-integrated and the type of home agent Thread-Index: AcjRhkUiCqSnu46NRW+9/CjzCCVVHwC55a7g References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> From: To: , X-OriginalArrivalTime: 22 Jun 2008 20:58:02.0735 (UTC) FILETIME=[A924CFF0:01C8D4AA] Cc: hannes.Tschofenig@gmx.net, dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > Hi Jouni, > > What is the need to differentiate between a MIPv6 and DS-MIPv6 HA? > Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would > someone deploy separate MIPv6 HA and DS-MIPv6 HA? If the discovered HA > does not support IPv4 Home Address assignment, the mobile node gets to > know about it anyway after the BU/BAck exchange. On a related issue, we should actually have two instances of IP addresses. One for IPv6 and one for IPv4. I.e.: ::= < AVP Header: TBD > *2[ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ] [ MIP-Agent-Type ] * [ AVP ] ..as it is assumed that both DSMIP6 and PMIP6 will have deployments that need the IPv4 address as well. Cheers, Jouni > > On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen > wrote: > > Hi all, > > > > A proposal related to the MIP6-Agent-Info AVP. Currently > > the AVP contains only the address information of the HA, > > which is OK in the scope of the integrated scenario. However, > > having a slight wider look at the possible uses for the > > MIP6-Agent-Info AVP it might be beneficial to include an > > AVP describing the "flavor" of the HA. What I am proposing > > is to add an enumerated MIP-Agent-Type AVP inside the group. > > > > ::= < AVP Header: TBD > > > [ MIP-Home-Agent-Address ] > > [ MIP-Home-Agent-Host ] > > [ MIP-Agent-Type ] > > * [ AVP ] > > > > > > The initial values would include: > > > > MIP6_HA (0) > > MIP6_LMA (1) > > MIP6_DSMIP_HA (2) > > What is the MIPv6 HA and PMIPv6 LMA are co-located? > > Its not clear to me what the above actually is trying to achieve. For > my benefit, can you please describe the scenario where such an > enumerated AVP would help? I could be missing something. > > Vijay > > > > > As a side note.. this discussion has been gone through at least > > once. At that time I thought using FQDN piggypack agent flavor > > information would be enough.. but having a separate AVP would > > actually be nicer imho. > > > > Cheers, > > Jouni > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 02:49:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0303A690F; Mon, 23 Jun 2008 02:49:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9113A68C2 for ; Mon, 23 Jun 2008 02:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTGtP6yt9GiX for ; Mon, 23 Jun 2008 02:48:58 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 3B2FC3A67FE for ; Mon, 23 Jun 2008 02:48:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C726D9001E for ; Mon, 23 Jun 2008 05:48:54 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06624-05 for ; Mon, 23 Jun 2008 05:48:54 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 23 Jun 2008 05:48:54 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 05:48:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 15:18:50 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One question on DWR. Thread-Index: AcjVFlcWaxDPk6ZAQ6+/UIsK4vUnTg== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 23 Jun 2008 09:48:54.0329 (UTC) FILETIME=[593DFA90:01C8D516] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: "Ranjan Rath, Rashmi" , "Krishnamoorthy, Balachandar" , "Sarkar, Biplab" Subject: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1265689028==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1265689028== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D516.5758B94F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D516.5758B94F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 When a DWR is sent with wrong version (For E.g.: 10) from Server to Client then DWA is sent by Client with Result-Code set to DIAMETER_UNSUPPORTED_VERSION. =20 After this DWR/DWA exchange does Client need to close the connection and establish a new connection? =20 Thanks in advance, Avinash Gowda =20 ------_=_NextPart_001_01C8D516.5758B94F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When a DWR is sent with wrong version (For E.g.: = 10) from Server to Client then DWA is sent by Client with Result-Code set to DIAMETER_UNSUPPORTED_VERSION.

 =

After this DWR/DWA exchange does Client need to = close the connection and establish a new connection?<= /p>

 

Thanks in advance,

Avinash Gowda

 

------_=_NextPart_001_01C8D516.5758B94F-- --===============1265689028== 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://www.ietf.org/mailman/listinfo/dime --===============1265689028==-- From dime-bounces@ietf.org Mon Jun 23 10:07:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2C93A6A2C; Mon, 23 Jun 2008 10:07:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDF5B3A6A24 for ; Mon, 23 Jun 2008 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ippyB3BOB3JU for ; Mon, 23 Jun 2008 10:07:15 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id C52323A6A2C for ; Mon, 23 Jun 2008 10:07:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id D6C21C8024 for ; Mon, 23 Jun 2008 13:07:04 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17397-06 for ; Mon, 23 Jun 2008 13:07:04 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 23 Jun 2008 13:07:04 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 13:07:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 22:37:00 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVFlcWaxDPk6ZAQ6+/UIsK4vUnTgAPRJwA References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com> From: "Gowda, Avinash" To: X-OriginalArrivalTime: 23 Jun 2008 17:07:04.0329 (UTC) FILETIME=[8F4D9F90:01C8D553] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============1500612723==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1500612723== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D553.8D709DDF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D553.8D709DDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can anybody help me in this issue?? Please.......... =20 Thanks, Avinash Gowda ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash Sent: Monday, June 23, 2008 3:19 PM To: dime@ietf.org Cc: Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab Subject: [Dime] One question on DWR. =20 Hi, =20 When a DWR is sent with wrong version (For E.g.: 10) from Server to Client then DWA is sent by Client with Result-Code set to DIAMETER_UNSUPPORTED_VERSION. =20 After this DWR/DWA exchange does Client need to close the connection and establish a new connection? =20 Thanks in advance, Avinash Gowda =20 ------_=_NextPart_001_01C8D553.8D709DDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can anybody help me in this = issue?? Please……….

 

Thanks,

Avinash = Gowda

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash
Sent: Monday, June 23, = 2008 3:19 PM
To: dime@ietf.org
Cc: Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; = Sarkar, Biplab
Subject: [Dime] One = question on DWR.

 

Hi,

 

When a DWR is sent with wrong version (For E.g.: = 10) from Server to Client then DWA is sent by Client with Result-Code set to = DIAMETER_UNSUPPORTED_VERSION.

 =

After this DWR/DWA exchange does Client need to = close the connection and establish a new connection?

 

Thanks in advance,

Avinash Gowda

 

------_=_NextPart_001_01C8D553.8D709DDF-- --===============1500612723== 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://www.ietf.org/mailman/listinfo/dime --===============1500612723==-- From dime-bounces@ietf.org Mon Jun 23 10:59:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDAA3A6A65; Mon, 23 Jun 2008 10:59:21 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B833A69BE for ; Mon, 23 Jun 2008 10:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7OB1uw2+KHt for ; Mon, 23 Jun 2008 10:59:19 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by core3.amsl.com (Postfix) with ESMTP id 2745B3A6A65 for ; Mon, 23 Jun 2008 10:59:18 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so1091478pyg.24 for ; Mon, 23 Jun 2008 10:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=cSrVzU/jt8VnGKgMBkonDxlIrKG+KwYkxegS2yDbjAE=; b=EFuaPvac6pAUMokX2lYQO2DLAwo44jF3YK9aWBQ1htF6yqkamiQvMJo4QZXQffmzLm SsHvJD+KBwx9iyX77PhTOFzKimzr0NvWiml/HDrIUW8C4GIg6lM1NMURcTeyycuAkA6s /zJ0hEqfuKV3NqDbZnuHa+dfAKTzUQQ5TH/Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MsTWgaB5ACuXHkTsFEwTeZybKUyVTNOpeGFHx8ogFHrX+NZHWPo1SOrwWwMeldNIQw EuuDWTVC6P1GLyQA5uXLIGgXrPzNB0sDuCkk9ypw91kiwBYy/fjUS5VjWkPrr51RiqTc PPZCozc5fj1MHihGXBqzIuz+mf4GXVUojiSbc= Received: by 10.142.254.8 with SMTP id b8mr4215767wfi.58.1214243958434; Mon, 23 Jun 2008 10:59:18 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Mon, 23 Jun 2008 10:59:17 -0700 (PDT) Message-ID: Date: Mon, 23 Jun 2008 10:59:17 -0700 From: "Vijay Devarapallli" To: "Chowdhury, Kuntal" , "Jouni Korhonen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <4D35478224365146822AE9E3AD4A266601512B41@exchtewks3.starentnetworks.com> <4D35478224365146822AE9E3AD4A266601512B64$0001@exchtewks3.starentnetworks.com> Cc: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Adding to what I wrote before... 3GPP kind of messed it up by having the PMIPv6 LMA, MIPv6 HA, DS-MIPv6 HA and MIPv4 HA all on the same network entity. Strictly speaking, this extension (for figuring out what kind of mobility protocol is being used for an on-going session) is only required for 3GPP. For deployments that use only one type of mobility protocol, the MAG or the access router would just need the IP address of LMA or the home agent. They wouldn't need to know what kind of home agent it is. So I think we should define the Home Agent AVP to just contain the IP address or the FQDN and have a separate AVP (optional) that indicates what kind of mobility protocol is being used for an on-going session. Vijay On Fri, Jun 20, 2008 at 11:38 AM, Vijay Devarapallli wrote: > On Fri, Jun 20, 2008 at 9:48 AM, Chowdhury, Kuntal > wrote: >> Vijay, >> >> Even if we define a new AVP for the protocol-type, we will have to >> always group it with the home agent AVP. In that case, what is the >> advantage of having a separate standalone AVP? > > Don't you see the advantage? I think it makes sense not to overload > the home agent AVP. Rather we should define an explicit AVP that > indicates which mobility protocol (DS-MIPv6 or PMIPv6) is being used > for an on-going session. This can be sent along with the Home Agent > information (which would just contain the IP address of the home > agent/LMA). > > Ideally, there shouldn't be a need for the MAG/Access router to be > told which mobility protocol to use. But never mind. :) > > Vijay > >> >> -Kuntal >> >> >>> -----Original Message----- >>> From: Vijay Devarapallli [mailto:dvijay@gmail.com] >>> Sent: Thursday, June 19, 2008 1:28 PM >>> To: Chowdhury, Kuntal >>> Cc: Jouni Korhonen; dime@ietf.org; Hannes Tschofenig >>> Subject: Re: [Dime] dime-mip6-integrated and the type of home agent >>> >>> On Thu, Jun 19, 2008 at 8:25 AM, Chowdhury, Kuntal >>> wrote: >>> > Jouni, >>> > >>> > I agree with you that having an explicit AVP for this is better than >>> > overloading some other parameter. >>> >>> I am not too comfortable with overloading the home agent AVP to tell >>> the MAG/Access router which mobility protocol to use for a particular >>> session. Why can't we define a separate AVP that tells the MAG/Access >>> router which mobility protocol is being used for an ongoing session >>> instead of the MAG/Access router figuring this out from the "type" of >>> the home agent? >>> >>> Vijay >>> >>> > >>> > A few clarifications: >>> > >>> > " MIP-Home-Agent-Host" - is this FQDN of the home agent? >>> > >>> > If the Agent has more than one function, e.g. DSMIP6 HA and PMIP6 >> LMA, >>> > how can we encode the type field? Should we encode it as bitmask? >>> > >>> > -Kuntal >>> > >>> > >>> >> -----Original Message----- >>> >> From: Jouni Korhonen [mailto:jouni.korhonen@iki.fi] >>> >> Sent: Wednesday, June 18, 2008 3:48 PM >>> >> To: dime@ietf.org >>> >> Cc: Julien Bournelle; Hannes Tschofenig; Chowdhury, Kuntal >>> >> Subject: dime-mip6-integrated and the type of home agent >>> >> >>> >> Hi all, >>> >> >>> >> A proposal related to the MIP6-Agent-Info AVP. Currently >>> >> the AVP contains only the address information of the HA, >>> >> which is OK in the scope of the integrated scenario. However, >>> >> having a slight wider look at the possible uses for the >>> >> MIP6-Agent-Info AVP it might be beneficial to include an >>> >> AVP describing the "flavor" of the HA. What I am proposing >>> >> is to add an enumerated MIP-Agent-Type AVP inside the group. >>> >> >>> >> ::= < AVP Header: TBD > >>> >> [ MIP-Home-Agent-Address ] >>> >> [ MIP-Home-Agent-Host ] >>> >> [ MIP-Agent-Type ] >>> >> * [ AVP ] >>> >> >>> >> >>> >> The initial values would include: >>> >> >>> >> MIP6_HA (0) >>> >> MIP6_LMA (1) >>> >> MIP6_DSMIP_HA (2) >>> >> >>> >> As a side note.. this discussion has been gone through at least >>> >> once. At that time I thought using FQDN piggypack agent flavor >>> >> information would be enough.. but having a separate AVP would >>> >> actually be nicer imho. >>> >> >>> >> Cheers, >>> >> Jouni >>> > _______________________________________________ >>> > DiME mailing list >>> > DiME@ietf.org >>> > https://www.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://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 11:08:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E17D3A6991; Mon, 23 Jun 2008 11:08:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1033A6991 for ; Mon, 23 Jun 2008 11:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5QZCG2k1EOl for ; Mon, 23 Jun 2008 11:08:50 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 1C6443A6838 for ; Mon, 23 Jun 2008 11:08:49 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1680024tib.25 for ; Mon, 23 Jun 2008 11:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=Gdc9cjBj46HptNO6YqlpqhtD5DOPeVsJ4dNc/+LdwEo=; b=JkAhcqFza5Ly7OJ3ptaZIcEalcVL51bJG71hhbbcsSSfLFHL0P1fphVzLe3ZqoP/N6 JbGIJkC0m/jCRuROGaXlM5pllLaYiB8DM8Bu7tOPPORV0LlJgdCq+jL0+3jm3MhoY1H7 gme8A2F4gKVxlgncytHXwBV9xZcDUCQ2AkzdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=kpdTt3Z/LjlT1V5LlxEuiNGv3JfdjAP7B6G4rFJH4HcyGzWyNsueH8Nsqs4H9mqgfm hryt12ov6/4MDbH+JBGrKbqqm/8MaNYhyQQ77waJ9EQElrMTF8DrSH1BHecyjS7g5bzI IaTF0EA7YI1h4ThmqZGLv4D5hOFrmESv/F7/4= Received: by 10.142.70.16 with SMTP id s16mr4241211wfa.120.1214244528903; Mon, 23 Jun 2008 11:08:48 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Mon, 23 Jun 2008 11:08:48 -0700 (PDT) Message-ID: Date: Mon, 23 Jun 2008 11:08:48 -0700 From: "Vijay Devarapalli" To: jouni.korhonen@teliasonera.com In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D3D7@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Disposition: inline References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D3D7@SEHAN021MB.tcad.telia.se> Cc: hannes.Tschofenig@gmx.net, dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, On Sun, Jun 22, 2008 at 1:58 PM, wrote: > Hi, > >> Hi Jouni, >> >> What is the need to differentiate between a MIPv6 and DS-MIPv6 HA? >> Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would >> someone deploy separate MIPv6 HA and DS-MIPv6 HA? If the discovered HA >> does not support IPv4 Home Address assignment, the mobile node gets to >> know about it anyway after the BU/BAck exchange. > > On a related issue, we should actually have two instances of > IP addresses. One for IPv6 and one for IPv4. I.e.: > > ::= < AVP Header: TBD > > *2[ MIP-Home-Agent-Address ] > [ MIP-Home-Agent-Host ] > [ MIP-Agent-Type ] > * [ AVP ] > > ..as it is assumed that both DSMIP6 and PMIP6 will have deployments > that need the IPv4 address as well. Agree. Would the MAG or the access router have to know that they also need the IPv4 address in addition to the IPv6 address and request for both? Or will both addresses be returned, irrespective of what the MAG or the access router asked for? Vijay > > Cheers, > Jouni > > >> >> On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen >> wrote: >> > Hi all, >> > >> > A proposal related to the MIP6-Agent-Info AVP. Currently >> > the AVP contains only the address information of the HA, >> > which is OK in the scope of the integrated scenario. However, >> > having a slight wider look at the possible uses for the >> > MIP6-Agent-Info AVP it might be beneficial to include an >> > AVP describing the "flavor" of the HA. What I am proposing >> > is to add an enumerated MIP-Agent-Type AVP inside the group. >> > >> > ::= < AVP Header: TBD > >> > [ MIP-Home-Agent-Address ] >> > [ MIP-Home-Agent-Host ] >> > [ MIP-Agent-Type ] >> > * [ AVP ] >> > >> > >> > The initial values would include: >> > >> > MIP6_HA (0) >> > MIP6_LMA (1) >> > MIP6_DSMIP_HA (2) >> >> What is the MIPv6 HA and PMIPv6 LMA are co-located? >> >> Its not clear to me what the above actually is trying to achieve. For >> my benefit, can you please describe the scenario where such an >> enumerated AVP would help? I could be missing something. >> >> Vijay >> >> > >> > As a side note.. this discussion has been gone through at least >> > once. At that time I thought using FQDN piggypack agent flavor >> > information would be enough.. but having a separate AVP would >> > actually be nicer imho. >> > >> > Cheers, >> > Jouni >> > _______________________________________________ >> > DiME mailing list >> > DiME@ietf.org >> > https://www.ietf.org/mailman/listinfo/dime >> > >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 17:57:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977D23A683E; Mon, 23 Jun 2008 17:57:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70E33A683E for ; Mon, 23 Jun 2008 17:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaKeMcJxfGIe for ; Mon, 23 Jun 2008 17:57:43 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id F2DC13A67B2 for ; Mon, 23 Jun 2008 17:57:42 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m5O0vf5L014921 for ; Tue, 24 Jun 2008 09:57:41 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m5O0vedo029887 for ; Tue, 24 Jun 2008 09:57:40 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m5O0veIS029884 for ; Tue, 24 Jun 2008 09:57:40 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 909576E47 for ; Tue, 24 Jun 2008 09:57:40 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 6F1F26E5C for ; Tue, 24 Jun 2008 09:57:40 +0900 (JST) Message-ID: <4860466B.9020800@nict.go.jp> Date: Tue, 24 Jun 2008 09:57:15 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com> <69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGksCgpJIHRoaW5rIGl0IGlzIG9kZCB0aGF0IHRoZSBEV1IgaGFzIGEgd3JvbmcgdmVyc2lvbiBu dW1iZXIuIElmIGEgRFdSIGlzIApzZW50IGF0IGFsbCwgaXQgbWVhbnMgdGhhdCBhIHByZXZpb3Vz IENFUi9DRUEgZXhjaGFuZ2Ugd2FzIHN1Y2Nlc3NmdWwgCihhbmQgdGhlcmVmb3JlIHRoZSB2ZXJz aW9uIG51bWJlciB3YXMgY29ycmVjdCkuIFdoeSB3b3VsZCB0aGUgcHJvdG9jb2wgCnZlcnNpb24g Y2hhbmdlIGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIGNvbm5leGlvbj8KCkFueXdheSwgSSB0 aGluayB0aGF0IHRoZSBiYWQgRFdSIHNob3VsZCByZXN1bHQgaXMgc2ltaWxhciBwcm9jZXNzIGFz IGlmIAppdCBoYWQgbm90IGJlZW4gcmVjZWl2ZWQuIEJ1dCB0ZXJtaW5hdGluZyB0aGUgY29ubmV4 aW9uIGlzIHByb2JhYmx5IE9LIHRvby4KCkhvcGUgdGhpcyBoZWxwcywKU2ViYXN0aWVuLgoKCgpH b3dkYSwgQXZpbmFzaCBhIMOpY3JpdCA6Cj4KPiBDYW4gYW55Ym9keSBoZWxwIG1lIGluIHRoaXMg aXNzdWU/PyBQbGVhc2XigKbigKbigKYuCj4KPiAgCj4KPiBUaGFua3MsCj4KPiBBdmluYXNoIEdv d2RhCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+ICpGcm9tOiogZGltZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSAqT24gCj4gQmVoYWxmIE9mICpHb3dkYSwg QXZpbmFzaAo+ICpTZW50OiogTW9uZGF5LCBKdW5lIDIzLCAyMDA4IDM6MTkgUE0KPiAqVG86KiBk aW1lQGlldGYub3JnCj4gKkNjOiogUmFuamFuIFJhdGgsIFJhc2htaTsgS3Jpc2huYW1vb3J0aHks IEJhbGFjaGFuZGFyOyBTYXJrYXIsIEJpcGxhYgo+ICpTdWJqZWN0OiogW0RpbWVdIE9uZSBxdWVz dGlvbiBvbiBEV1IuCj4KPiAgCj4KPiBIaSwKPgo+ICAKPgo+IFdoZW4gYSBEV1IgaXMgc2VudCB3 aXRoIHdyb25nIHZlcnNpb24gKEZvciBFLmcuOiAxMCkgZnJvbSBTZXJ2ZXIgdG8gCj4gQ2xpZW50 IHRoZW4gRFdBIGlzIHNlbnQgYnkgQ2xpZW50IHdpdGggUmVzdWx0LUNvZGUgc2V0IHRvIAo+ICpE SUFNRVRFUl9VTlNVUFBPUlRFRF9WRVJTSU9OLioKPgo+ICogKgo+Cj4gQWZ0ZXIgdGhpcyBEV1Iv RFdBIGV4Y2hhbmdlIGRvZXMgQ2xpZW50IG5lZWQgdG8gY2xvc2UgdGhlIGNvbm5lY3Rpb24gCj4g YW5kIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uPwo+Cj4gIAo+Cj4gVGhhbmtzIGluIGFkdmFu Y2UsCj4KPiBBdmluYXNoIEdvd2RhCj4KPiAgCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRGlNRSBtYWlsaW5n IGxpc3QKPiBEaU1FQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaW1lCj4gICAKCi0tIApTZWJhc3RpZW4gRGVjdWdpcwpSZXNlYXJjaCBmZWxsb3cKTmV0 d29yayBBcmNoaXRlY3R1cmUgR3JvdXAKTklDVCAobmljdC5nby5qcCkKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkRpTUUgbWFpbGluZyBsaXN0CkRpTUVA aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCg== From dime-bounces@ietf.org Mon Jun 23 20:01:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C016B3A680A; Mon, 23 Jun 2008 20:01:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5973A680A for ; Mon, 23 Jun 2008 20:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SzAyYLTHzWV for ; Mon, 23 Jun 2008 20:01:42 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 08F273A676A for ; Mon, 23 Jun 2008 20:01:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 42C45C801A for ; Mon, 23 Jun 2008 23:01:39 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32157-15 for ; Mon, 23 Jun 2008 23:01:35 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 23 Jun 2008 23:01:35 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 23:01:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 08:31:31 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559ABB7@exchindia3.starentnetworks.com> In-Reply-To: <4860466B.9020800@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVlVgMOPo9GmV5RqWwhFRQjDdUyAAEB7CA References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> <4860466B.9020800@nict.go.jp> From: "Gowda, Avinash" To: "Sebastien Decugis" , X-OriginalArrivalTime: 24 Jun 2008 03:01:35.0244 (UTC) FILETIME=[9CD34CC0:01C8D5A6] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Sebastien, I got your explanation. It was just a testing of negative scenario. = I have one more query. :) When a DWR is sent with wrong version from server then is it must for clien= t to send DWA back?? Thanks, Avinash Gowda -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Seb= astien Decugis Sent: Tuesday, June 24, 2008 6:27 AM To: dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi, I think it is odd that the DWR has a wrong version number. If a DWR is = sent at all, it means that a previous CER/CEA exchange was successful = (and therefore the version number was correct). Why would the protocol = version change during the lifetime of the connexion? Anyway, I think that the bad DWR should result is similar process as if = it had not been received. But terminating the connexion is probably OK too. Hope this helps, Sebastien. Gowda, Avinash a =E9crit : > > Can anybody help me in this issue?? Please.......... > > = > > Thanks, > > Avinash Gowda > > ------------------------------------------------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On = > Behalf Of *Gowda, Avinash > *Sent:* Monday, June 23, 2008 3:19 PM > *To:* dime@ietf.org > *Cc:* Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab > *Subject:* [Dime] One question on DWR. > > = > > Hi, > > = > > When a DWR is sent with wrong version (For E.g.: 10) from Server to = > Client then DWA is sent by Client with Result-Code set to = > *DIAMETER_UNSUPPORTED_VERSION.* > > * * > > After this DWR/DWA exchange does Client need to close the connection = > and establish a new connection? > > = > > Thanks in advance, > > Avinash Gowda > > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 20:17:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7A53A6804; Mon, 23 Jun 2008 20:17:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3073A6804 for ; Mon, 23 Jun 2008 20:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gORrTzEzNMKw for ; Mon, 23 Jun 2008 20:16:59 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id 20C043A679C for ; Mon, 23 Jun 2008 20:16:57 -0700 (PDT) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m5O3GtKt020374; Tue, 24 Jun 2008 12:16:55 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m5O3GtjT001115; Tue, 24 Jun 2008 12:16:55 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m5O3GtFl001112; Tue, 24 Jun 2008 12:16:55 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id EC3FF6E82; Tue, 24 Jun 2008 12:16:54 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id C06586E47; Tue, 24 Jun 2008 12:16:54 +0900 (JST) Message-ID: <4860670B.8000300@nict.go.jp> Date: Tue, 24 Jun 2008 12:16:27 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Gowda, Avinash" References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> <4860466B.9020800@nict.go.jp> <69FADB84C90B1248A7DE59422771FA0C0559ABB8$0001@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0559ABB8$0001@exchindia3.starentnetworks.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, I am not sure what should be the correct behavior. In my opinion, when a = message with an incorrect version number is received, it should just be = discarded. Since the version has changed, we can not assume anything = about the format of the message, so how can one be sure that the message = is really a DWR for example? I don't understand the use for the = "DIAMETER_UNSUPPORTED_VERSION" error code with this respect. Anyway I am also beginner in Diameter protocol so maybe someone with = more experience can provide more information on how a mismatching = version number may be handled (can we assume forward compatibility of = the message with future versions?) Thanks, Sebastien. Gowda, Avinash a =E9crit : > Hi Sebastien, > > I got your explanation. It was just a testing of negative scenario. = > > I have one more query. :) > > When a DWR is sent with wrong version from server then is it must for cli= ent to send DWA back?? > > Thanks, > Avinash Gowda > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of S= ebastien Decugis > Sent: Tuesday, June 24, 2008 6:27 AM > To: dime@ietf.org > Subject: Re: [Dime] One question on DWR. > > Hi, > > I think it is odd that the DWR has a wrong version number. If a DWR is = > sent at all, it means that a previous CER/CEA exchange was successful = > (and therefore the version number was correct). Why would the protocol = > version change during the lifetime of the connexion? > > Anyway, I think that the bad DWR should result is similar process as if = > it had not been received. But terminating the connexion is probably OK to= o. > > Hope this helps, > Sebastien. > > > > Gowda, Avinash a =E9crit : > = >> Can anybody help me in this issue?? Please.......... >> >> = >> >> Thanks, >> >> Avinash Gowda >> >> ------------------------------------------------------------------------ >> >> *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On = >> Behalf Of *Gowda, Avinash >> *Sent:* Monday, June 23, 2008 3:19 PM >> *To:* dime@ietf.org >> *Cc:* Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab >> *Subject:* [Dime] One question on DWR. >> >> = >> >> Hi, >> >> = >> >> When a DWR is sent with wrong version (For E.g.: 10) from Server to = >> Client then DWA is sent by Client with Result-Code set to = >> *DIAMETER_UNSUPPORTED_VERSION.* >> >> * * >> >> After this DWR/DWA exchange does Client need to close the connection = >> and establish a new connection? >> >> = >> >> Thanks in advance, >> >> Avinash Gowda >> >> = >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> = >> = > > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 20:19:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0A53A67DB; Mon, 23 Jun 2008 20:19:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8723F3A67DB for ; Mon, 23 Jun 2008 20:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6RlImbO82fa for ; Mon, 23 Jun 2008 20:19:34 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 820813A679C for ; Mon, 23 Jun 2008 20:19:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 79050C802A for ; Mon, 23 Jun 2008 23:01:40 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31668-07 for ; Mon, 23 Jun 2008 23:01:40 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 23 Jun 2008 23:01:40 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 23:01:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 08:31:31 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559ABB8@exchindia3.starentnetworks.com> In-Reply-To: <4860466B.9020800@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVlVgMOPo9GmV5RqWwhFRQjDdUyAAEB7CA References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> <4860466B.9020800@nict.go.jp> From: "Gowda, Avinash" To: "Sebastien Decugis" , X-OriginalArrivalTime: 24 Jun 2008 03:01:37.0088 (UTC) FILETIME=[9DECAC00:01C8D5A6] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Sebastien, I got your explanation. It was just a testing of negative scenario. = I have one more query. :) When a DWR is sent with wrong version from server then is it must for clien= t to send DWA back?? Thanks, Avinash Gowda -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Seb= astien Decugis Sent: Tuesday, June 24, 2008 6:27 AM To: dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi, I think it is odd that the DWR has a wrong version number. If a DWR is = sent at all, it means that a previous CER/CEA exchange was successful = (and therefore the version number was correct). Why would the protocol = version change during the lifetime of the connexion? Anyway, I think that the bad DWR should result is similar process as if = it had not been received. But terminating the connexion is probably OK too. Hope this helps, Sebastien. Gowda, Avinash a =E9crit : > > Can anybody help me in this issue?? Please.......... > > = > > Thanks, > > Avinash Gowda > > ------------------------------------------------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On = > Behalf Of *Gowda, Avinash > *Sent:* Monday, June 23, 2008 3:19 PM > *To:* dime@ietf.org > *Cc:* Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab > *Subject:* [Dime] One question on DWR. > > = > > Hi, > > = > > When a DWR is sent with wrong version (For E.g.: 10) from Server to = > Client then DWA is sent by Client with Result-Code set to = > *DIAMETER_UNSUPPORTED_VERSION.* > > * * > > After this DWR/DWA exchange does Client need to close the connection = > and establish a new connection? > > = > > Thanks in advance, > > Avinash Gowda > > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jun 23 22:14:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B3C3A6836; Mon, 23 Jun 2008 22:14:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A5C3A6836 for ; Mon, 23 Jun 2008 22:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H0b+Defja5I for ; Mon, 23 Jun 2008 22:14:00 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 143CB3A67E6 for ; Mon, 23 Jun 2008 22:13:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 715A5C8038 for ; Tue, 24 Jun 2008 01:13:57 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02226-12 for ; Tue, 24 Jun 2008 01:13:55 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 24 Jun 2008 01:13:55 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 01:13:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 10:43:51 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559ABC7@exchindia3.starentnetworks.com> In-Reply-To: <4860670B.8000300@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVqMs69B9fVs8uRvCpKXmuHRDZqgAEBSkQ References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com> <4860466B.9020800@nict.go.jp> <69FADB84C90B1248A7DE59422771FA0C0559ABB8$0001@exchindia3.starentnetworks.com> <4860670B.8000300@nict.go.jp> From: "Gowda, Avinash" To: "Sebastien Decugis" X-OriginalArrivalTime: 24 Jun 2008 05:13:55.0402 (UTC) FILETIME=[198742A0:01C8D5B9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks a lot for your feedback on this issue. Will wait for somebody to rep= ly on this. Let's see what will be their opinion. Thanks, Avinash Gowda -----Original Message----- From: Sebastien Decugis [mailto:sdecugis@nict.go.jp] = Sent: Tuesday, June 24, 2008 8:46 AM To: Gowda, Avinash Cc: dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi, I am not sure what should be the correct behavior. In my opinion, when a = message with an incorrect version number is received, it should just be = discarded. Since the version has changed, we can not assume anything = about the format of the message, so how can one be sure that the message = is really a DWR for example? I don't understand the use for the = "DIAMETER_UNSUPPORTED_VERSION" error code with this respect. Anyway I am also beginner in Diameter protocol so maybe someone with = more experience can provide more information on how a mismatching = version number may be handled (can we assume forward compatibility of = the message with future versions?) Thanks, Sebastien. Gowda, Avinash a =E9crit : > Hi Sebastien, > > I got your explanation. It was just a testing of negative scenario. = > > I have one more query. :) > > When a DWR is sent with wrong version from server then is it must for cli= ent to send DWA back?? > > Thanks, > Avinash Gowda > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of S= ebastien Decugis > Sent: Tuesday, June 24, 2008 6:27 AM > To: dime@ietf.org > Subject: Re: [Dime] One question on DWR. > > Hi, > > I think it is odd that the DWR has a wrong version number. If a DWR is = > sent at all, it means that a previous CER/CEA exchange was successful = > (and therefore the version number was correct). Why would the protocol = > version change during the lifetime of the connexion? > > Anyway, I think that the bad DWR should result is similar process as if = > it had not been received. But terminating the connexion is probably OK to= o. > > Hope this helps, > Sebastien. > > > > Gowda, Avinash a =E9crit : > = >> Can anybody help me in this issue?? Please.......... >> >> = >> >> Thanks, >> >> Avinash Gowda >> >> ------------------------------------------------------------------------ >> >> *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On = >> Behalf Of *Gowda, Avinash >> *Sent:* Monday, June 23, 2008 3:19 PM >> *To:* dime@ietf.org >> *Cc:* Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab >> *Subject:* [Dime] One question on DWR. >> >> = >> >> Hi, >> >> = >> >> When a DWR is sent with wrong version (For E.g.: 10) from Server to = >> Client then DWA is sent by Client with Result-Code set to = >> *DIAMETER_UNSUPPORTED_VERSION.* >> >> * * >> >> After this DWR/DWA exchange does Client need to close the connection = >> and establish a new connection? >> >> = >> >> Thanks in advance, >> >> Avinash Gowda >> >> = >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> = >> = > > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 06:32:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88333A6986; Tue, 24 Jun 2008 06:32:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7AA3A693C for ; Tue, 24 Jun 2008 06:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTe4eND-yWWR for ; Tue, 24 Jun 2008 06:32:14 -0700 (PDT) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id DDE843A6986 for ; Tue, 24 Jun 2008 06:32:13 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 15:32:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 15:32:10 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D410@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-mip6-integrated and the type of home agent Thread-Index: AcjVXDKOmP7kYJ/oRKOaY59ud/VHswAoOzxA References: <610D7775-D99A-476D-8B35-6B004D672BC2@iki.fi> <59D7431DE2527D4CB0F1EFEDA5683ED302C7D3D7@SEHAN021MB.tcad.telia.se> From: To: X-OriginalArrivalTime: 24 Jun 2008 13:32:10.0740 (UTC) FILETIME=[B489D340:01C8D5FE] Cc: hannes.Tschofenig@gmx.net, dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Vijay, [snip] > > > > On a related issue, we should actually have two instances of > > IP addresses. One for IPv6 and one for IPv4. I.e.: > > > > ::= < AVP Header: TBD > > > *2[ MIP-Home-Agent-Address ] > > [ MIP-Home-Agent-Host ] > > [ MIP-Agent-Type ] > > * [ AVP ] > > > > ..as it is assumed that both DSMIP6 and PMIP6 will have deployments > > that need the IPv4 address as well. > > Agree. > > Would the MAG or the access router have to know that they also need > the IPv4 address in addition to the IPv6 address and request for both? > Or will both addresses be returned, irrespective of what the MAG or > the access router asked for? IMHO it would be simpler if both addresses are just returned, if available or allowed by the subscription policy. If capability exchange is really needed, the MIP6-Feature-Vector could be used. CHeers, Jouni > > Vijay > > > > > Cheers, > > Jouni > > > > > >> > >> On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen > >> wrote: > >> > Hi all, > >> > > >> > A proposal related to the MIP6-Agent-Info AVP. Currently > >> > the AVP contains only the address information of the HA, > >> > which is OK in the scope of the integrated scenario. However, > >> > having a slight wider look at the possible uses for the > >> > MIP6-Agent-Info AVP it might be beneficial to include an > >> > AVP describing the "flavor" of the HA. What I am proposing > >> > is to add an enumerated MIP-Agent-Type AVP inside the group. > >> > > >> > ::= < AVP Header: TBD > > >> > [ MIP-Home-Agent-Address ] > >> > [ MIP-Home-Agent-Host ] > >> > [ MIP-Agent-Type ] > >> > * [ AVP ] > >> > > >> > > >> > The initial values would include: > >> > > >> > MIP6_HA (0) > >> > MIP6_LMA (1) > >> > MIP6_DSMIP_HA (2) > >> > >> What is the MIPv6 HA and PMIPv6 LMA are co-located? > >> > >> Its not clear to me what the above actually is trying to > achieve. For > >> my benefit, can you please describe the scenario where such an > >> enumerated AVP would help? I could be missing something. > >> > >> Vijay > >> > >> > > >> > As a side note.. this discussion has been gone through at least > >> > once. At that time I thought using FQDN piggypack agent flavor > >> > information would be enough.. but having a separate AVP would > >> > actually be nicer imho. > >> > > >> > Cheers, > >> > Jouni > >> > _______________________________________________ > >> > DiME mailing list > >> > DiME@ietf.org > >> > https://www.ietf.org/mailman/listinfo/dime > >> > > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 07:41:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFD43A69E9; Tue, 24 Jun 2008 07:41:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64623A69B2 for ; Tue, 24 Jun 2008 07:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDNUuFhjrURb for ; Tue, 24 Jun 2008 07:40:58 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id AA9DB3A6929 for ; Tue, 24 Jun 2008 07:40:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,696,1204520400"; d="scan'208";a="124675244" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 24 Jun 2008 10:40:58 -0400 X-IronPort-AV: E=Sophos;i="4.27,696,1204520400"; d="scan'208";a="223197617" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2008 10:40:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 16:40:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-sun-dime-itu-t-rw-00.txt Thread-Index: AcjWCE4QZKGmlyHHRYO8OUF3ezBJYA== From: "Romascanu, Dan (Dan)" To: "Sun, Dong (Dong)" Cc: dime@ietf.org Subject: [Dime] AD Review of draft-sun-dime-itu-t-rw-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is the Area Director Review of draft-sun-dime-itu-t-rw-00.txt. I have divided the commented in Technical and Editorial. A Revised-ID is needed before sending the document to IETF Last Call. T1. RFC 2434 was obsoleted by RFC 5226 T2.Section 4.1 - I do not believe that the document should ask IANA for the allocation of 'the next value' (probably the next available value), but rather just for the allocation of a value in the specified range. T3. Section 4.3 needs to be re-written.- The nine values of the AVP codes should be TBD and assignment be required from IANA at the recommended values. The values in Table 1/Q.3303.3 in Section 7.3.1 of [Q.3303.3] can be recommended but the final assignment should be made by IANA after the document is approved (rationale - another ITU-T SG may have already asked for the assignment of the same values) E1. I suggest that the title of the document should be consistent with the title of RFC5224 so instead of 'Diameter Policy Enforcement Interface: ITU-T Rw' rather 'Diameter ITU-T Rw Policy Enforcement Interface Application' E2. In the Introduction Section s/to send a request and receiving a response/to send a request and receive a response/ E3. Section 2 Additionally, the terms and acronyms defined in Section 4 of [Q.3303.3] are used in this document. Actually in [Q.3303.3] Section 3 defines terms and section 4 acronyms. E4. I find section 3 pointless as it stands now. A one-two executive summary paragraph placing the interface described in the document in the context of Q.3303.1 and ITU-T Y.2111 and mentioning that the scope of the interface is to control policy enforcement functions in the transport devices, including QoS resource control, NAPT/NAT traversal control, etc. would be appropriate. E5. Section 4.1 - the reference is incorrect s/Section 3/[Q.3303.3] Section 7.2.1 E6. Section 7.4.2 - the references are incomplete - add to each that they refer to [Q.3303.3] Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 07:44:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0893A68D3; Tue, 24 Jun 2008 07:44:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C00D3A6899 for ; Tue, 24 Jun 2008 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNxUv77fiw8N for ; Tue, 24 Jun 2008 07:44:48 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 781893A681F for ; Tue, 24 Jun 2008 07:44:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 231CDC803F for ; Tue, 24 Jun 2008 10:44:46 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15590-14 for ; Tue, 24 Jun 2008 10:44:45 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 24 Jun 2008 10:44:45 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 10:44:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 20:14:39 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559AC67@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0559ABB8@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVlVgMOPo9GmV5RqWwhFRQjDdUyAAEB7CAABjQiiA= References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com><4860466B.9020800@nict.go.jp> <69FADB84C90B1248A7DE59422771FA0C0559ABB8@exchindia3.starentnetworks.com> From: "Gowda, Avinash" To: "Gowda, Avinash" , "Sebastien Decugis" , X-OriginalArrivalTime: 24 Jun 2008 14:44:45.0069 (UTC) FILETIME=[D7EBB3D0:01C8D608] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Please anybody comment on this e-mail thread. We want to understand this be= havior very clearly. Thanks, Avinash Gowda -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gow= da, Avinash Sent: Tuesday, June 24, 2008 8:32 AM To: Sebastien Decugis; dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi Sebastien, I got your explanation. It was just a testing of negative scenario. = I have one more query. :) When a DWR is sent with wrong version from server then is it must for clien= t to send DWA back?? Thanks, Avinash Gowda -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Seb= astien Decugis Sent: Tuesday, June 24, 2008 6:27 AM To: dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi, I think it is odd that the DWR has a wrong version number. If a DWR is = sent at all, it means that a previous CER/CEA exchange was successful = (and therefore the version number was correct). Why would the protocol = version change during the lifetime of the connexion? Anyway, I think that the bad DWR should result is similar process as if = it had not been received. But terminating the connexion is probably OK too. Hope this helps, Sebastien. Gowda, Avinash a =E9crit : > > Can anybody help me in this issue?? Please.......... > > = > > Thanks, > > Avinash Gowda > > ------------------------------------------------------------------------ > > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On = > Behalf Of *Gowda, Avinash > *Sent:* Monday, June 23, 2008 3:19 PM > *To:* dime@ietf.org > *Cc:* Ranjan Rath, Rashmi; Krishnamoorthy, Balachandar; Sarkar, Biplab > *Subject:* [Dime] One question on DWR. > > = > > Hi, > > = > > When a DWR is sent with wrong version (For E.g.: 10) from Server to = > Client then DWA is sent by Client with Result-Code set to = > *DIAMETER_UNSUPPORTED_VERSION.* > > * * > > After this DWR/DWA exchange does Client need to close the connection = > and establish a new connection? > > = > > Thanks in advance, > > Avinash Gowda > > = > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > = -- = Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 13:50:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84B43A69FE; Tue, 24 Jun 2008 13:50:59 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2383A69FE for ; Tue, 24 Jun 2008 13:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dty+Zot+3saC for ; Tue, 24 Jun 2008 13:50:57 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 9A0EB3A69F6 for ; Tue, 24 Jun 2008 13:50:57 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m5OKop95013274; Tue, 24 Jun 2008 15:50:53 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 15:50:46 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 24 Jun 2008 15:50:44 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01A352F5@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-sun-dime-itu-t-rw-00.txt Thread-Index: AcjWCE4QZKGmlyHHRYO8OUF3ezBJYAAM5pEw References: From: "Sun, Dong \(Dong\)" To: "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 24 Jun 2008 20:50:46.0631 (UTC) FILETIME=[FA081F70:01C8D63B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-sun-dime-itu-t-rw-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dan, Thanks for the review. I will update the draft accordingly. Rgs, Dong -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, June 24, 2008 10:41 AM To: Sun, Dong (Dong) Cc: Hannes Tschofenig; dime@ietf.org Subject: AD Review of draft-sun-dime-itu-t-rw-00.txt Here is the Area Director Review of draft-sun-dime-itu-t-rw-00.txt. I have divided the commented in Technical and Editorial. A Revised-ID is needed before sending the document to IETF Last Call. T1. RFC 2434 was obsoleted by RFC 5226 T2.Section 4.1 - I do not believe that the document should ask IANA for the allocation of 'the next value' (probably the next available value), but rather just for the allocation of a value in the specified range. T3. Section 4.3 needs to be re-written.- The nine values of the AVP codes should be TBD and assignment be required from IANA at the recommended values. The values in Table 1/Q.3303.3 in Section 7.3.1 of [Q.3303.3] can be recommended but the final assignment should be made by IANA after the document is approved (rationale - another ITU-T SG may have already asked for the assignment of the same values) E1. I suggest that the title of the document should be consistent with the title of RFC5224 so instead of 'Diameter Policy Enforcement Interface: ITU-T Rw' rather 'Diameter ITU-T Rw Policy Enforcement Interface Application' E2. In the Introduction Section s/to send a request and receiving a response/to send a request and receive a response/ E3. Section 2 Additionally, the terms and acronyms defined in Section 4 of [Q.3303.3] are used in this document. Actually in [Q.3303.3] Section 3 defines terms and section 4 acronyms. E4. I find section 3 pointless as it stands now. A one-two executive summary paragraph placing the interface described in the document in the context of Q.3303.1 and ITU-T Y.2111 and mentioning that the scope of the interface is to control policy enforcement functions in the transport devices, including QoS resource control, NAPT/NAT traversal control, etc. would be appropriate. E5. Section 4.1 - the reference is incorrect s/Section 3/[Q.3303.3] Section 7.2.1 E6. Section 7.4.2 - the references are incomplete - add to each that they refer to [Q.3303.3] Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 16:20:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A0628C0F1; Tue, 24 Jun 2008 16:20:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFCF28C0E0 for ; Tue, 24 Jun 2008 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGe3SIBFg0NC for ; Tue, 24 Jun 2008 16:20:42 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id CB8C328C0F8 for ; Tue, 24 Jun 2008 16:20:42 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2943006wfd.31 for ; Tue, 24 Jun 2008 16:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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; bh=5X47oc6UKbfl8Uy1XEl5zBBy7OapNUn0rv0DU/lUPPU=; b=GKUUMUJuGMy/JRbUwQNatQW9e8b0mAkkroPUDUQSFmvPQLEOJaItU4FhFTXfytFdF7 eDNH4JMubXyIeqcnwu9GdtZhuuZ9bfUs0tOnoYufk0LeSRTooO7x1ynvXTwyg6CPj3LZ RXWOezXzgqXYQCZrFZlIWvE7oHruRAMRsQPUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YI2rHkwP2ViTl9VPgO36vTKn18F7nWZY8/5wqWdb80svp4uYf/7j2+eHRQW/863n0w HoCvzBVoJodBuyx4r+4EV5XxNjM5XQ3B2xkA2qCROQKjwm/8T+x4W3sjzQ6ONFGvSZZi 0XIXvMlpo0xfHSLfN9bUAxhVRTMJ6vWGpylew= Received: by 10.142.127.10 with SMTP id z10mr6405663wfc.263.1214349644308; Tue, 24 Jun 2008 16:20:44 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Tue, 24 Jun 2008 16:20:44 -0700 (PDT) Message-ID: Date: Tue, 24 Jun 2008 16:20:44 -0700 From: "Vijay Devarapalli" To: ron.kehno@kolumbus.fi In-Reply-To: <14184693.261841214294663220.JavaMail.ron.kehno@kolumbus.fi> MIME-Version: 1.0 Content-Disposition: inline References: <14184693.261841214294663220.JavaMail.ron.kehno@kolumbus.fi> Cc: hannes.Tschofenig@gmx.net, dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Tue, Jun 24, 2008 at 1:04 AM, wrote: > > So.. the following revision of the MIP6-Agent-Info would be OK so far: > > ::= < AVP Header: TBD > > *2[ MIP-Home-Agent-Address ] > [ MIP-Home-Agent-Host ] > * [ AVP ] Ok. > > If some SDO would need the agent type.. that could be done in two ways: > 1) decorating the FQDN > 2) adding an optional AVP using the *[AVP] approach > > Comments? I would prefer 2). Vijay > > Cheers, > Jouni > > > Vijay Devarapalli kirjoitti: >> >> Hi Jouni, >> >> On Sun, Jun 22, 2008 at 1:58 PM, wrote: >> > Hi, >> > >> >> Hi Jouni, >> >> >> >> What is the need to differentiate between a MIPv6 and DS-MIPv6 HA? >> >> Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would >> >> someone deploy separate MIPv6 HA and DS-MIPv6 HA? If the discovered HA >> >> does not support IPv4 Home Address assignment, the mobile node gets to >> >> know about it anyway after the BU/BAck exchange. >> > >> > On a related issue, we should actually have two instances of >> > IP addresses. One for IPv6 and one for IPv4. I.e.: >> > >> > ::= < AVP Header: TBD > >> > *2[ MIP-Home-Agent-Address ] >> > [ MIP-Home-Agent-Host ] >> > [ MIP-Agent-Type ] >> > * [ AVP ] >> > >> > ..as it is assumed that both DSMIP6 and PMIP6 will have deployments >> > that need the IPv4 address as well. >> >> Agree. >> >> Would the MAG or the access router have to know that they also need >> the IPv4 address in addition to the IPv6 address and request for both? >> Or will both addresses be returned, irrespective of what the MAG or >> the access router asked for? >> >> Vijay >> >> > >> > Cheers, >> > Jouni >> > >> > >> >> >> >> On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen >> >> wrote: >> >> > Hi all, >> >> > >> >> > A proposal related to the MIP6-Agent-Info AVP. Currently >> >> > the AVP contains only the address information of the HA, >> >> > which is OK in the scope of the integrated scenario. However, >> >> > having a slight wider look at the possible uses for the >> >> > MIP6-Agent-Info AVP it might be beneficial to include an >> >> > AVP describing the "flavor" of the HA. What I am proposing >> >> > is to add an enumerated MIP-Agent-Type AVP inside the group. >> >> > >> >> > ::= < AVP Header: TBD > >> >> > [ MIP-Home-Agent-Address ] >> >> > [ MIP-Home-Agent-Host ] >> >> > [ MIP-Agent-Type ] >> >> > * [ AVP ] >> >> > >> >> > >> >> > The initial values would include: >> >> > >> >> > MIP6_HA (0) >> >> > MIP6_LMA (1) >> >> > MIP6_DSMIP_HA (2) >> >> >> >> What is the MIPv6 HA and PMIPv6 LMA are co-located? >> >> >> >> Its not clear to me what the above actually is trying to achieve. For >> >> my benefit, can you please describe the scenario where such an >> >> enumerated AVP would help? I could be missing something. >> >> >> >> Vijay >> >> >> >> > >> >> > As a side note.. this discussion has been gone through at least >> >> > once. At that time I thought using FQDN piggypack agent flavor >> >> > information would be enough.. but having a separate AVP would >> >> > actually be nicer imho. >> >> > >> >> > Cheers, >> >> > Jouni >> >> > _______________________________________________ >> >> > DiME mailing list >> >> > DiME@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/dime >> >> > >> >> _______________________________________________ >> >> DiME mailing list >> >> DiME@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dime >> >> >> > >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jun 24 23:30:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BDB3A6859; Tue, 24 Jun 2008 23:30:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED5A3A698C for ; Tue, 24 Jun 2008 23:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTKAEcEinMaq for ; Tue, 24 Jun 2008 23:30:45 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 2BBBB3A682B for ; Tue, 24 Jun 2008 23:30:44 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 08:30:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 08:30:44 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED302C7D414@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] dime-mip6-integrated and the type of home agent Thread-Index: AcjWUO+YR7THmwddTxePm9aUXhkNDgAO08uw References: <14184693.261841214294663220.JavaMail.ron.kehno@kolumbus.fi> From: To: X-OriginalArrivalTime: 25 Jun 2008 06:30:44.0349 (UTC) FILETIME=[FF1682D0:01C8D68C] Cc: hannes.Tschofenig@gmx.net, dime@ietf.org Subject: Re: [Dime] dime-mip6-integrated and the type of home agent X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Vijay, Good.. As far as I know the integrated draft is about to move forward, so this rather small change can be done during the auth48 stage. Cheers, Jouni > -----Original Message----- > From: Vijay Devarapalli [mailto:dvijay@gmail.com] = > Sent: 25. kes=E4kuuta 2008 2:21 > To: ron.kehno@kolumbus.fi > Cc: Korhonen, Jouni /TeliaSonera Finland Oyj; dime@ietf.org; = > hannes.Tschofenig@gmx.net; jouni.korhonen@iki.fi > Subject: Re: [Dime] dime-mip6-integrated and the type of home agent > = > = > On Tue, Jun 24, 2008 at 1:04 AM, wrote: > > > > So.. the following revision of the MIP6-Agent-Info would be = > OK so far: > > > > ::=3D < AVP Header: TBD > > > *2[ MIP-Home-Agent-Address ] > > [ MIP-Home-Agent-Host ] > > * [ AVP ] > = > Ok. > = > > > > If some SDO would need the agent type.. that could be done = > in two ways: > > 1) decorating the FQDN > > 2) adding an optional AVP using the *[AVP] approach > > > > Comments? > = > I would prefer 2). > = > Vijay > = > > > > Cheers, > > Jouni > > > > > > Vijay Devarapalli kirjoitti: > >> > >> Hi Jouni, > >> > >> On Sun, Jun 22, 2008 at 1:58 PM, = > wrote: > >> > Hi, > >> > > >> >> Hi Jouni, > >> >> > >> >> What is the need to differentiate between a MIPv6 and = > DS-MIPv6 HA? > >> >> Since the DS-MIPv6 HA functionality includes MIPv6 HA, why would > >> >> someone deploy separate MIPv6 HA and DS-MIPv6 HA? If = > the discovered HA > >> >> does not support IPv4 Home Address assignment, the = > mobile node gets to > >> >> know about it anyway after the BU/BAck exchange. > >> > > >> > On a related issue, we should actually have two instances of > >> > IP addresses. One for IPv6 and one for IPv4. I.e.: > >> > > >> > ::=3D < AVP Header: TBD > > >> > *2[ MIP-Home-Agent-Address ] > >> > [ MIP-Home-Agent-Host ] > >> > [ MIP-Agent-Type ] > >> > * [ AVP ] > >> > > >> > ..as it is assumed that both DSMIP6 and PMIP6 will have = > deployments > >> > that need the IPv4 address as well. > >> > >> Agree. > >> > >> Would the MAG or the access router have to know that they also need > >> the IPv4 address in addition to the IPv6 address and = > request for both? > >> Or will both addresses be returned, irrespective of what the MAG or > >> the access router asked for? > >> > >> Vijay > >> > >> > > >> > Cheers, > >> > Jouni > >> > > >> > > >> >> > >> >> On Wed, Jun 18, 2008 at 1:48 PM, Jouni Korhonen > >> >> wrote: > >> >> > Hi all, > >> >> > > >> >> > A proposal related to the MIP6-Agent-Info AVP. Currently > >> >> > the AVP contains only the address information of the HA, > >> >> > which is OK in the scope of the integrated scenario. However, > >> >> > having a slight wider look at the possible uses for the > >> >> > MIP6-Agent-Info AVP it might be beneficial to include an > >> >> > AVP describing the "flavor" of the HA. What I am proposing > >> >> > is to add an enumerated MIP-Agent-Type AVP inside the group. > >> >> > > >> >> > ::=3D < AVP Header: TBD > > >> >> > [ MIP-Home-Agent-Address ] > >> >> > [ MIP-Home-Agent-Host ] > >> >> > [ MIP-Agent-Type ] > >> >> > * [ AVP ] > >> >> > > >> >> > > >> >> > The initial values would include: > >> >> > > >> >> > MIP6_HA (0) > >> >> > MIP6_LMA (1) > >> >> > MIP6_DSMIP_HA (2) > >> >> > >> >> What is the MIPv6 HA and PMIPv6 LMA are co-located? > >> >> > >> >> Its not clear to me what the above actually is trying = > to achieve. For > >> >> my benefit, can you please describe the scenario where such an > >> >> enumerated AVP would help? I could be missing something. > >> >> > >> >> Vijay > >> >> > >> >> > > >> >> > As a side note.. this discussion has been gone = > through at least > >> >> > once. At that time I thought using FQDN piggypack agent flavor > >> >> > information would be enough.. but having a separate AVP would > >> >> > actually be nicer imho. > >> >> > > >> >> > Cheers, > >> >> > Jouni > >> >> > _______________________________________________ > >> >> > DiME mailing list > >> >> > DiME@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/dime > >> >> > > >> >> _______________________________________________ > >> >> DiME mailing list > >> >> DiME@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/dime > >> >> > >> > > >> > > > > > = _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 25 01:14:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534523A6939; Wed, 25 Jun 2008 01:14:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A902C3A6939 for ; Wed, 25 Jun 2008 01:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISN1LutUJjPH for ; Wed, 25 Jun 2008 01:14:54 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9E88C3A68ED for ; Wed, 25 Jun 2008 01:14:53 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5P8EZn1003626 for ; Wed, 25 Jun 2008 11:14:53 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:12:58 +0300 Received: from vaebe110.NOE.Nokia.com ([10.160.244.79]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:12:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:12:40 +0300 Message-ID: In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0559AC67@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVlVgMOPo9GmV5RqWwhFRQjDdUyAAEB7CAABjQiiAAJHBhIA== References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com><4860466B.9020800@nict.go.jp><69FADB84C90B1248A7DE59422771FA0C0559ABB8@exchindia3.starentnetworks.com> <69FADB84C90B1248A7DE59422771FA0C0559AC67@exchindia3.starentnetworks.com> From: To: X-OriginalArrivalTime: 25 Jun 2008 08:12:44.0948 (UTC) FILETIME=[3F3FCD40:01C8D69B] X-Nokia-AV: Clean Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, > When a DWR is sent with wrong version from server then is it > must for client to send DWA back?? In that kind of case client should send DWA back with result-code DIAMETER_UNSUPPORTED_VERSION. Best Regards, Mikko >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Gowda, Avinash >Sent: 24 June, 2008 17:45 >To: Gowda, Avinash; Sebastien Decugis; dime@ietf.org >Subject: Re: [Dime] One question on DWR. > >Please anybody comment on this e-mail thread. We want to >understand this behavior very clearly. > >Thanks, >Avinash Gowda > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Gowda, Avinash >Sent: Tuesday, June 24, 2008 8:32 AM >To: Sebastien Decugis; dime@ietf.org >Subject: Re: [Dime] One question on DWR. > >Hi Sebastien, > >I got your explanation. It was just a testing of negative scenario. > >I have one more query. :) > >When a DWR is sent with wrong version from server then is it >must for client to send DWA back?? > >Thanks, >Avinash Gowda _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jun 25 02:03:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F383A6860; Wed, 25 Jun 2008 02:03:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01893A6860 for ; Wed, 25 Jun 2008 02:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjKQMwltHD68 for ; Wed, 25 Jun 2008 02:03:24 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id ACB3E3A6859 for ; Wed, 25 Jun 2008 02:03:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id F33889000E for ; Wed, 25 Jun 2008 05:03:22 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06800-06 for ; Wed, 25 Jun 2008 05:03:19 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 25 Jun 2008 05:03:19 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 05:03:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 14:33:15 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0559ACFB@exchindia3.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One question on DWR. Thread-Index: AcjVlVgMOPo9GmV5RqWwhFRQjDdUyAAEB7CAABjQiiAAJHBhIAABxLNw References: <69FADB84C90B1248A7DE59422771FA0C0559AB59@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559ABB0@exchindia3.starentnetworks.com><4860466B.9020800@nict.go.jp><69FADB84C90B1248A7DE59422771FA0C0559ABB8@exchindia3.starentnetworks.com><69FADB84C90B1248A7DE59422771FA0C0559AC67@exchindia3.starentnetworks.com> From: "Gowda, Avinash" To: , X-OriginalArrivalTime: 25 Jun 2008 09:03:18.0985 (UTC) FILETIME=[4FAD1B90:01C8D6A2] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] One question on DWR. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Mikko, One more question. After sending DWA back with result-code DIAMETER_UNSUPPORTED_VERSION do we need to close the connection?? Thanks, Avinash Gowda -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of mikko.aittola@nokia.com Sent: Wednesday, June 25, 2008 1:43 PM To: dime@ietf.org Subject: Re: [Dime] One question on DWR. Hi, > When a DWR is sent with wrong version from server then is it > must for client to send DWA back?? In that kind of case client should send DWA back with result-code DIAMETER_UNSUPPORTED_VERSION. Best Regards, Mikko >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Gowda, Avinash >Sent: 24 June, 2008 17:45 >To: Gowda, Avinash; Sebastien Decugis; dime@ietf.org >Subject: Re: [Dime] One question on DWR. > >Please anybody comment on this e-mail thread. We want to >understand this behavior very clearly. > >Thanks, >Avinash Gowda > >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Gowda, Avinash >Sent: Tuesday, June 24, 2008 8:32 AM >To: Sebastien Decugis; dime@ietf.org >Subject: Re: [Dime] One question on DWR. > >Hi Sebastien, > >I got your explanation. It was just a testing of negative scenario. > >I have one more query. :) > >When a DWR is sent with wrong version from server then is it >must for client to send DWA back?? > >Thanks, >Avinash Gowda _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jun 26 06:00:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F8728C12E; Thu, 26 Jun 2008 06:00:04 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 90B8C3A6A32; Thu, 26 Jun 2008 06:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080626130001.90B8C3A6A32@core3.amsl.com> Date: Thu, 26 Jun 2008 06:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-07.txt Pages : 32 Date : 2008-06-26 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-dime-qos-attributes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-26054902.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Jun 26 19:16:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 075FD3A6AB6; Thu, 26 Jun 2008 19:16:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D60F3A6AB7 for ; Thu, 26 Jun 2008 19:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHELJPF3rh-z for ; Thu, 26 Jun 2008 19:16:55 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id B815F3A6AB0 for ; Thu, 26 Jun 2008 19:16:55 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so257268rvf.49 for ; Thu, 26 Jun 2008 19:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=ZnR8De2CGMwtPpUId3ZN2SSjDuTfOS/XRd99dqyu5HU=; b=MoQzJrTCV0IX5C5m4XGYpvdCTdTo6DpcZA8pbFVOEfzxNwBDZ2RUXCkcbkdvBPksrP RT+J84stpL4xqqKAAh49x86QLjyy/z0h3t6vsGRf0jdgtfoC/8AAMBPQsCen1qGp36R1 n5Je/IR60HK+WvyE8wVqBQakvmijcJNOre5So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :x-google-sender-auth; b=T+asNVPJj16blrO8aS9rM3VQVSGdhx1goCLWA14pE5C+VbMsmZxIs+v6FeHjtxbUCG xrroWGS7qQq+7sg9wdhsy9Ud4OPXHm9l+kAQ0P6QtDBKwHcalZqVSv6F9e7n2dW3pdkR Jw/z3XW7qiIP6ZggUKe/Q9ayjuP5o0JO58xvY= Received: by 10.140.247.11 with SMTP id u11mr479278rvh.37.1214533018857; Thu, 26 Jun 2008 19:16:58 -0700 (PDT) Received: by 10.141.35.15 with HTTP; Thu, 26 Jun 2008 19:16:58 -0700 (PDT) Message-ID: <9cf5ced20806261916x16bcf1ady32f1a0650710cbe4@mail.gmail.com> Date: Thu, 26 Jun 2008 22:16:58 -0400 From: "David Frascone" To: ietf-secretariat@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6733_23436454.1214533018854" X-Google-Sender-Auth: 4f3b31625800cf34 Cc: dime@ietf.org Subject: [Dime] Proto Submittal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org ------=_Part_6733_23436454.1214533018854 Content-Type: multipart/alternative; boundary="----=_Part_6734_17265232.1214533018854" ------=_Part_6734_17265232.1214533018854 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a re-submittal of the proto writeup for draft-ietf-dime-mip6-integrated-09 I do not know what happened to the first submittal. Please cc dime@ietf.org with any responses! -Dave ------=_Part_6734_17265232.1214533018854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This is a re-submittal of the proto writeup for draft-ietf-dime-mip6-integrated-09  I do not know what happened to the first submittal.

Please cc dime@ietf.org with any responses!

-Dave


------=_Part_6734_17265232.1214533018854-- ------=_Part_6733_23436454.1214533018854 Content-Type: text/plain; name=draft-ietf-dime-mip6-integrated-09-PROTO.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fhy5kuew0 Content-Disposition: attachment; filename=draft-ietf-dime-mip6-integrated-09-PROTO.txt UFJPVE8gV1JJVEVVUCBmb3IgZHJhZnQtaWV0Zi1kaW1lLW1pcDYtaW50ZWdyYXRlZC0wOS50eHQK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K CgogICAoMS5hKSAgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVu dD8gIEhhcyB0aGUKICAgICAgICAgIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgcmV2aWV3 ZWQgdGhpcyB2ZXJzaW9uIG9mIHRoZQogICAgICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1 bGFyLCBkb2VzIGhlIG9yIHNoZSBiZWxpZXZlIHRoaXMKICAgICAgICAgIHZlcnNpb24gaXMgcmVh ZHkgZm9yIGZvcndhcmRpbmcgdG8gdGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uPwoKCiAgICAgIFRo ZSBEb2N1bWVudCBTaGVwaGVyZCBpcyBEYXZpZCBGcmFzY29uZSA8ZGF2ZUBmcmFzY29uZS5jb20+ LgogICAgICBUaGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9ucyBhbmQgSSBoYXZl IHJldmlld2VkIHRoZSAKICAgICAgZG9jdW1lbnQgcGVyc29uYWxseS4KCgogICAoMS5iKSAgSGFz IHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVy cwogICAgICAgICAgYW5kIGZyb20ga2V5IG5vbi1XRyBtZW1iZXJzPyAgRG9lcyB0aGUgRG9jdW1l bnQgU2hlcGhlcmQgaGF2ZQogICAgICAgICAgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBv ciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQKICAgICAgICAgIGhhdmUgYmVlbiBwZXJmb3Jt ZWQ/CgogICAgICBUaGlzIGRvY3VtZW50IGlzIHBhcnQgb2YgdGhlIHdvcmsgZG9uZSBvbiBNb2Jp bGUgSVB2NiBib290c3RyYXBwaW5nCiAgICAgIGluIHRoZSBNSVA2IHdvcmtpbmcgZ3JvdXAuIFdo aWxlIHRoZSBNSVA2IFdHIGRldmVsb3BlZCB0aGUgCiAgICAgIG92ZXJhbGwgYXJjaGl0ZWN0dXJl IGFuZCB0aGUgcHJvdG9jb2wgc3VwcG9ydCBmb3IgdGhlIGZyb250LWVuZCAKICAgICAgKG5hbWVs eSBNTiB0b3dhcmRzIE5BUyBhbmQgTU4gdG8gSEEpCiAgICAgIHRoaXMgZG9jdW1lbnQgaXMgb25l IG9mIHR3byBzcGVjaWZpY2F0aW9ucyBwcm92aWRpbmcgdGhlIAogICAgICBuZWNlc3NhcnkgYmFj ay1lbmQgaW5mcmFzdHJ1Y3R1cmUgc3VwcG9ydC4KICAgICAgCiAgICAgIEEgbGlzdCBvZiB0aGUg cmVsYXRlZCBNb2JpbGUgSVB2NiBib290c3RyYXBwaW5nIGRvY3VtZW50cyAKICAgICAgY2FuIGJl IGZvdW5kIGluIHRoZSBkcmFmdC4gCiAgICAgIAogICAgICBXaXRob3V0IHRoaXMgZG9jdW1lbnQg dGhlIE1JUHY2IGJvb3RzdHJhcHBpbmcgc29sdXRpb24gaXMgaW5jb21wbGV0ZS4KICAgICAgCiAg ICAgIEEgZmlyc3QgV0dMQyB3YXMgc3RhcnRlZCBvbiAyNi4gQXVndXN0IDIwMDcsIHNlZQogICAg ICBodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RpbWUvY3VycmVudC9tc2cw MTk0MC5odG1sIAoKICAgICAgVGhlIGRvY3VtZW50IGhhcyByZWNlaXZlZCByZXZpZXdzIGZyb20g RElNRSBhbmQgTUlQNiBtZW1iZXJzLiAKICAgICAgVHdvIGZ1cnRoZXIgZHJhZnQgdmVyc2lvbnMg aGF2ZSBiZWVuIHN1Ym1pdHRlZCB0byByZWZsZWN0IHRoZSByZXZpZXcgCiAgICAgIGNvbW1lbnRz LiBUaGUgY2hhbmdlcyBjYW4gYmUgc2VlbiBoZXJlOiAKICAgICAgCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZGlt ZS1taXA2LWludGVncmF0ZWQtMDYudHh0Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZGltZS1taXA2LWludGVncmF0 ZWQtMDcudHh0ICAKICAgICAgCiAgICAgICBEdWUgdG8gdGhlIG51bWJlciBvZiBjaGFuZ2VzIGEg c2Vjb25kIFdHTEMgd2FzIHN0YXJ0ZWQgMy4gSmFuLiAyMDA4LCBzZWUgCiAgICAgICBodHRwOi8v d3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RpbWUvY3VycmVudC9tc2cwMjI5MC5odG1s CgpUaGUgcmVjZWl2ZWQgY29tbWVudHMgd2VyZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZG9jdW1l bnQ6IApodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWh0dHA6Ly90b29scy5pZXRm Lm9yZy9pZC9kcmFmdC1pZXRmLWRpbWUtbWlwNi1pbnRlZ3JhdGVkLTA4LnR4dAoKVGhlIGZpbmFs IHZlcnNpb24gcmVmbGVjdHMgYSBjb250YWN0IGluZm8gY2hhbmdlIGFuZCBzaW1wbGlmaWNhdGlv bnMgcmVnYXJkaW5nIHRoZSBleGFtcGxlIHVzYWdlIChvbmx5IERpYW1ldGVyIEVBUCB1c2FnZSBp cyBzaG93bjsgRGlhbWV0ZXIgTkFTUkVRIHVzYWdlIGhhcyBiZWVuIHJlbW92ZWQpOiAKaHR0cDov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtaWV0Zi1kaW1lLW1pcDYtaW50ZWdyYXRlZC0wOS50eHQKCiAgICgxLmMpICBEb2VzIHRoZSBE b2N1bWVudCBTaGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50CiAgICAgICAg ICBuZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0 aXZlLAogICAgICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIHNv bWVvbmUgZmFtaWxpYXIgd2l0aAogICAgICAgICAgQUFBLCBpbnRlcm5hdGlvbmFsaXphdGlvbiwg b3IgWE1MPwogICAgICAgICAgCiAgICAgIFRoZXJlIGFyZSBubyBjb25jZXJucyB3aXRoIHRoZSBk b2N1bWVudC4gCgoKICAgKDEuZCkgIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55 IHNwZWNpZmljIGNvbmNlcm5zIG9yCiAgICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50 IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IKICAgICAgICAgIGFuZC9vciB0aGUg SUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/ICBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZQogICAgICAg ICAgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUgd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1 bWVudCwgb3IKICAgICAgICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBh IG5lZWQgZm9yIGl0LiAgSW4gYW55CiAgICAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNj dXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkCiAgICAgICAgICB0aGF0IGl0IHN0 aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlCiAgICAgICAg ICBjb25jZXJucyBoZXJlLiAgSGFzIGFuIElQUiBkaXNjbG9zdXJlIHJlbGF0ZWQgdG8gdGhpcyBk b2N1bWVudAogICAgICAgICAgYmVlbiBmaWxlZD8gIElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJl ZmVyZW5jZSB0byB0aGUKICAgICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cg ZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiBvbgogICAgICAgICAgdGhpcyBpc3N1ZS4KCiAgICAg IFRoZXJlIGFyZSBubyBjb25jZXJucy4gCiAgICAgIAogICAoMS5lKSAgSG93IHNvbGlkIGlzIHRo ZSBXRyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/ICBEb2VzIGl0CiAgICAgICAgICBy ZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0 aAogICAgICAgICAgb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9s ZSB1bmRlcnN0YW5kIGFuZAogICAgICAgICAgYWdyZWUgd2l0aCBpdD8KICAgICAgICAgIAogICAg ICBUaGVyZSBpcyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQuCiAgICAgIAoKCiAgICgx LmYpICBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0 ZWQgZXh0cmVtZQogICAgICAgICAgZGlzY29udGVudD8gIElmIHNvLCBwbGVhc2Ugc3VtbWFyaXpl IHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbgogICAgICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2Fn ZXMgdG8gdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuICAoSXQKICAgICAgICAgIHNob3Vs ZCBiZSBpbiBhIHNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzCiAg ICAgICAgICBlbnRlcmVkIGludG8gdGhlIElEIFRyYWNrZXIuKQogICAgICAgICAgCiAgICAgIE5v LiAKCiAgICgxLmcpICBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVyaWZp ZWQgdGhhdCB0aGUKICAgICAgICAgIGRvY3VtZW50IHNhdGlzZmllcyBhbGwgSUQgbml0cz8gIChT ZWUKICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvSUQtQ2hlY2tsaXN0Lmh0bWwgYW5kCiAg ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLy4pICBCb2lsZXJwbGF0 ZSBjaGVja3MgYXJlCiAgICAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJl IHRob3JvdWdoLiAgSGFzIHRoZSBkb2N1bWVudAogICAgICAgICAgbWV0IGFsbCBmb3JtYWwgcmV2 aWV3IGNyaXRlcmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRoZSBNSUIKICAgICAgICAgIERvY3Rv ciwgbWVkaWEgdHlwZSwgYW5kIFVSSSB0eXBlIHJldmlld3M/ICBJZiB0aGUgZG9jdW1lbnQKICAg ICAgICAgIGRvZXMgbm90IGFscmVhZHkgaW5kaWNhdGUgaXRzIGludGVuZGVkIHN0YXR1cyBhdCB0 aGUgdG9wIG9mCiAgICAgICAgICB0aGUgZmlyc3QgcGFnZSwgcGxlYXNlIGluZGljYXRlIHRoZSBp bnRlbmRlZCBzdGF0dXMgaGVyZS4KCiAgICAgIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWlu IG5pdHMuIAoKCiAgICgxLmgpICBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2Vz IGludG8gbm9ybWF0aXZlIGFuZAogICAgICAgICAgaW5mb3JtYXRpdmU/ICBBcmUgdGhlcmUgbm9y bWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQKICAgICAgICAgIGFyZSBub3QgcmVh ZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhcgogICAgICAg ICAgc3RhdGU/ICBJZiBzdWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRo ZQogICAgICAgICAgc3RyYXRlZ3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/ICBBcmUgdGhlcmUgbm9y bWF0aXZlIHJlZmVyZW5jZXMKICAgICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMs IGFzIGRlc2NyaWJlZCBpbiBbUkZDMzk2N10/ICBJZgogICAgICAgICAgc28sIGxpc3QgdGhlc2Ug ZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhCiAgICAgICAgICBEaXJlY3Rv ciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVyZSBmb3IgdGhlbSBbUkZDMzk2N10uCgoKICAgICBU aGUgZG9jdW1lbnQgaGFzIHJlZmVyZW5jZXMgc3BsaXQgaW50byBub3JtYXRpdmUgYW5kIAogICAg IGluZm9ybWF0aXZlIHJlZmVyZW5jZXMuIFRoZXJlIGFyZSBubyBkb3dud2FyZCByZWZlcmVuY2Vz LiAKCgogICAgIAogICAoMS5pKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0 aGF0IHRoZSBkb2N1bWVudCdzIElBTkEKICAgICAgICAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24g ZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkKICAgICAgICAgIG9mIHRoZSBk b2N1bWVudD8gIElmIHRoZSBkb2N1bWVudCBzcGVjaWZpZXMgcHJvdG9jb2wKICAgICAgICAgIGV4 dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEK ICAgICAgICAgIHJlZ2lzdHJpZXM/ICBBcmUgdGhlIElBTkEgcmVnaXN0cmllcyBjbGVhcmx5IGlk ZW50aWZpZWQ/ICBJZgogICAgICAgICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0 cnksIGRvZXMgaXQgZGVmaW5lIHRoZQogICAgICAgICAgcHJvcG9zZWQgaW5pdGlhbCBjb250ZW50 cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24KICAgICAgICAgIHByb2NlZHVyZSBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/ICBEb2VzIGl0IHN1Z2dlc3QgYQogICAgICAgICAgcmVh c29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyAgU2VlIFtSRkMyNDM0XS4gIElmIHRo ZQogICAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJvY2Vzcywg aGFzIHRoZSBEb2N1bWVudAogICAgICAgICAgU2hlcGhlcmQgY29uZmVycmVkIHdpdGggdGhlIFJl c3BvbnNpYmxlIEFyZWEgRGlyZWN0b3Igc28gdGhhdAogICAgICAgICAgdGhlIElFU0cgY2FuIGFw cG9pbnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIElFU0cgRXZhbHVhdGlvbj8KCiAgIEFuIElB TkEgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29uc2lzdGVudCB3aXRoIHRo ZSByZXN0IAogICBvZiB0aGUgZG9jdW1lbnQuIAoKICAgVGhlIGRvY3VtZW50IGRlZmluZXMgMyBu ZXcgQVZQcyBhbmQgb25lIHJlZ2lzdHJ5LCBjYWxsZWQgIk1vYmlsaXR5IAogICBDYXBhYmlsaXR5 IiB0aGF0IGlzIHVzZWQgZm9yIHN0b3JpbmcgZmxhZyB2YWx1ZXMuIAoKCiAgICgxLmopICBIYXMg dGhlIERvY3VtZW50IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlCiAgICAg ICAgICBkb2N1bWVudCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNo IGFzIFhNTAogICAgICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4s IHZhbGlkYXRlIGNvcnJlY3RseSBpbgogICAgICAgICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/Cgog ICBUaGUgQUJORiBmb3IgdGhlIERpYW1ldGVyIGNvbW1hbmRzIGhhcyBiZWVuIGNoZWNrZWQuIAog ICAKICAgCiAgICgxLmspICBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMg YSBEb2N1bWVudAogICAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiAgUGxlYXNlIHByb3Zp ZGUgc3VjaCBhIERvY3VtZW50CiAgICAgICAgICBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuICBSZWNl bnQgZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIHRoZQogICAgICAgICAgIkFjdGlvbiIgYW5ub3Vu Y2VtZW50cyBmb3IgYXBwcm92ZWQgZG9jdW1lbnRzLiAKCgoKRG9jdW1lbnQgQW5ub3VuY2VtZW50 IFdyaXRlLVVwIGZvciAiRGlhbWV0ZXIgTW9iaWxlIElQdjY6IApTdXBwb3J0IGZvciBOZXR3b3Jr IEFjY2VzcyBTZXJ2ZXIgdG8gRGlhbWV0ZXIiCihkcmFmdC1pZXRmLWRpbWUtbWlwNi1pbnRlZ3Jh dGVkLTA5KQoKICAgVGVjaG5pY2FsIFN1bW1hcnkKCiAgIEEgTW9iaWxlIElQdjYgbm9kZSByZXF1 aXJlcyBhIEhvbWUgQWdlbnQgYWRkcmVzcywgYSBob21lIGFkZHJlc3MsIGFuZAogICBhIHNlY3Vy aXR5IGFzc29jaWF0aW9uIHdpdGggaXRzIEhvbWUgQWdlbnQgYmVmb3JlIGl0IGNhbiBzdGFydAog ICB1dGlsaXppbmcgTW9iaWxlIElQdjYuICBSRkMgMzc3NSByZXF1aXJlcyB0aGF0IHNvbWUgb3Ig YWxsIG9mIHRoZXNlCiAgIHBhcmFtZXRlcnMgYXJlIHN0YXRpY2FsbHkgY29uZmlndXJlZC4gIE1v YmlsZSBJUHY2IGJvb3RzdHJhcHBpbmcgd29yawogICBhaW1zIHRvIG1ha2UgdGhpcyBpbmZvcm1h dGlvbiBkeW5hbWljYWxseSBhdmFpbGFibGUgdG8gdGhlIE1vYmlsZQogICBOb2RlLiAgQW4gaW1w b3J0YW50IGFzcGVjdCBvZiB0aGUgTW9iaWxlIElQdjYgYm9vdHN0cmFwcGluZyBzb2x1dGlvbgog ICBpcyB0byBzdXBwb3J0IGludGVyd29ya2luZyB3aXRoIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9u LAogICBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIGluZnJhc3RydWN0dXJlLiAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMKICAgdGhlIE1JUHY2IGJvb3RzdHJhcHBpbmcgdXNpbmcgdGhlIERp YW1ldGVyIE5ldHdvcmsgQWNjZXNzIFNlcnZlcgogICAoTkFTKSB0byBob21lIEF1dGhlbnRpY2F0 aW9uLCBBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50aW5nIHNlcnZlcgogICAoSEFBQSkgaW50ZXJm YWNlLgoKCgogICBXb3JraW5nIEdyb3VwIFN1bW1hcnkKCiAgICAgIFRoZXJlIGlzIGNvbnNlbnN1 cyBpbiB0aGUgV0cgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50LgoKICAgRG9jdW1lbnQgUXVhbGl0 eQoKICAgICAgVGhlIGRvY3VtZW50IGhhcyByZWNlaXZlZCBleHRlbnNpdmUgcmV2aWV3cyBmcm9t IERJTUUgYW5kIE1JUDYgCiAgICAgIHdvcmtpbmcgZ3JvdXAgbWVtYmVycy4gVGhpcyBkb2N1bWVu dCBpcyBhIGJ1aWxkaW5nIGJsb2NrIGluIHRoZSAKICAgICAgTW9iaWxlIElQdjYgYm9vdHN0cmFw cGluZyBhcmNoaXRlY3R1cmUuIAogICAgICAKICAgUGVyc29ubmVsCgogICAgIERhdmlkIEZyYXNj b25lIGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudC4gIAoK ------=_Part_6733_23436454.1214533018854 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://www.ietf.org/mailman/listinfo/dime ------=_Part_6733_23436454.1214533018854-- From dime-bounces@ietf.org Thu Jun 26 19:18:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 785EB3A6AB0; Thu, 26 Jun 2008 19:18:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F30B3A6AB0 for ; Thu, 26 Jun 2008 19:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpC2kKqg0rda for ; Thu, 26 Jun 2008 19:18:14 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 4A55C3A6AAF for ; Thu, 26 Jun 2008 19:18:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so257598rvf.49 for ; Thu, 26 Jun 2008 19:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:mime-version:content-type:x-google-sender-auth; bh=P8g5lTzFJUuFkVDJ8QHNXaDXMKnIjQiTS29sWthGOpc=; b=x7z575Hv9iDHfdZINPFlIpVetUlKhM2vQJntTvjWGQ6y7K1CiDWfoYaCp2dnnexMqd LuO7/TNHTh29bd5bX776xUXsoSEOYBsBP4sUs52mUGwU+5rf3/9fYpRgqj8n2qZEUWKV T1hXf50Spk9XdgcMfeULSedvryyqIl6UeyTec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :x-google-sender-auth; b=RCj1USsHd2+izal9HLets4sQIP49svuXlpg/ElI3vPAUURzdQJDyl/qUUwYVnwqTkT 5EMwvR9jEUHt5n3SmmtOZN1H2zvHoiXIpMxJItT4T/7SxEqL10C6J7lCRWrqZ2nUF04W VMqE5A4jSYSqHnNRDmdrBRNC1tb2lagV+rxTE= Received: by 10.141.49.6 with SMTP id b6mr468990rvk.89.1214533097926; Thu, 26 Jun 2008 19:18:17 -0700 (PDT) Received: by 10.141.35.15 with HTTP; Thu, 26 Jun 2008 19:18:17 -0700 (PDT) Message-ID: <9cf5ced20806261918g32fc469cof87e6dfae241d37a@mail.gmail.com> Date: Thu, 26 Jun 2008 22:18:17 -0400 From: "David Frascone" To: ietf-secretariat@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6745_18747682.1214533097938" X-Google-Sender-Auth: 8b2f1233d4e3f676 Cc: dime@ietf.org Subject: [Dime] Proto Submittal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org ------=_Part_6745_18747682.1214533097938 Content-Type: multipart/alternative; boundary="----=_Part_6746_5206734.1214533097938" ------=_Part_6746_5206734.1214533097938 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a re-submittal of the proto writeup for draft-ietf-dime-qos-parameters-06 I do not know what happened to the first submittal. Please cc dime@ietf.org with any responses! -Dave ------=_Part_6746_5206734.1214533097938 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This is a re-submittal of the proto writeup for draft-ietf-dime-qos-parameters-06  I do not know what happened to the first submittal.

Please cc dime@ietf.org with any responses!

-Dave



------=_Part_6746_5206734.1214533097938-- ------=_Part_6745_18747682.1214533097938 Content-Type: text/plain; name=draft-ietf-dime-qos-parameters-06-PROTO.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fhy5n3a90 Content-Disposition: attachment; filename=draft-ietf-dime-qos-parameters-06-PROTO.txt UFJPVE8gV1JJVEVVUCBmb3IgZHJhZnQtaWV0Zi1kaW1lLXFvcy1wYXJhbWV0ZXJzLTA2LnR4dAo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgoK ICAgKDEuYSkgIFdobyBpcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgZm9yIHRoaXMgZG9jdW1lbnQ/ ICBIYXMgdGhlCiAgICAgICAgICBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHJldmlld2Vk IHRoaXMgdmVyc2lvbiBvZiB0aGUKICAgICAgICAgIGRvY3VtZW50IGFuZCwgaW4gcGFydGljdWxh ciwgZG9lcyBoZSBvciBzaGUgYmVsaWV2ZSB0aGlzCiAgICAgICAgICB2ZXJzaW9uIGlzIHJlYWR5 IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8KCgogICAgICBEb2N1 bWVudCBTaGVwaGVyZCBpcyBEYXZpZCBGcmFzY29uZSA8ZGF2ZUBmcmFzY29uZS5jb20+LgogICAg ICBUaGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9ucyBhbmQgSSBoYXZlIHJldmll d2VkIHRoZSAKICAgICAgZG9jdW1lbnQgcGVyc29uYWxseS4KCgogICAoMS5iKSAgSGFzIHRoZSBk b2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycwogICAg ICAgICAgYW5kIGZyb20ga2V5IG5vbi1XRyBtZW1iZXJzPyAgRG9lcyB0aGUgRG9jdW1lbnQgU2hl cGhlcmQgaGF2ZQogICAgICAgICAgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVh ZHRoIG9mIHRoZSByZXZpZXdzIHRoYXQKICAgICAgICAgIGhhdmUgYmVlbiBwZXJmb3JtZWQ/Cgog ICAgICBUaGlzIGRvY3VtZW50IGlzIHBhcnQgb2YgdGhlIHdvcmsgb24gZXh0ZW5kaW5nIHRoZSAK ICAgICAgUW9TRmlsdGVyUnVsZSBBVlAgZnVuY3Rpb25hbGl0eSBvZiB0aGUgRGlhbWV0ZXIgQmFz ZSBwcm90b2NvbCAKICAgICAgYW5kIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBRb1MtRmlsdGVy LVJ1bGUgQVZQIGRlZmluZWQgaW4gCiAgICAgIFJGQyA0MDA1LgoKICAgICAgVGhlIGVuY29kaW5n IG9mIHRoZSBhdHRyaWJ1dGVzIGlzIHByb3ZpZGVkIGluIGEgd2F5IHRvIGJlIHVzZWQKICAgICAg Zm9yIGEgQUFBIHByb3RvY29sIGluZGVwZW5kZW50IFJlc291cmNlIE1hbmFnZW1lbnQgRnVuY3Rp b24uIAoKICAgICAgVGhlIFdHTEMgd2FzIHN0YXJ0ZWQgMiBPY3QgMjAwNzoKICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RpbWUvY3VycmVudC9tc2cwMjA2Mi5odG1s CgogICAgICBUaGUgV0dMQyB3YXMgc2VudCB0byBOU0lTLCBSQURFWFQgYW5kIFRTVldHIHdoZXJl IGluY29uc2lzdGVuY2llcyAKICAgICAgYmV0d2VlbiByZWdpc3RyaWVzIHdlcmUgZGlzY292ZXJl ZCB0aGF0IGxlYWQgdG8gdGhlIGRlbGF5IG9mIHRoZQogICAgICBkb2N1bWVudC4gVGhlIGNoYW5n ZXMgYXJlIHJlZmxlY3RlZCBpbiB0aGUgc3Vic2VxdWVudCB2ZXJzaW9ucyAKICAgICAgYW5kIHdl cmUgZGlzY3Vzc2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QgYXMgd2VsbCBhcyBkdXJpbmcgdGhlIAog ICAgICBESU1FIElFVEYgbWVldGluZ3MuIAoKaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUv ZHJhZnQtaWV0Zi1kaW1lLXFvcy1wYXJhbWV0ZXJzL2RyYWZ0LWlldGYtZGltZS1xb3MtcGFyYW1l dGVycy0wMi1mcm9tLTAxLmRpZmYuaHRtbAoKaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUv ZHJhZnQtaWV0Zi1kaW1lLXFvcy1wYXJhbWV0ZXJzL2RyYWZ0LWlldGYtZGltZS1xb3MtcGFyYW1l dGVycy0wMy1mcm9tLTAyLmRpZmYuaHRtbAoKaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUv ZHJhZnQtaWV0Zi1kaW1lLXFvcy1wYXJhbWV0ZXJzL2RyYWZ0LWlldGYtZGltZS1xb3MtcGFyYW1l dGVycy0wNC1mcm9tLTAzLmRpZmYuaHRtbAoKCiAgICgxLmMpICBEb2VzIHRoZSBEb2N1bWVudCBT aGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQgdGhlIGRvY3VtZW50CiAgICAgICAgICBuZWVkcyBt b3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLAogICAg ICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIHNvbWVvbmUgZmFt aWxpYXIgd2l0aAogICAgICAgICAgQUFBLCBpbnRlcm5hdGlvbmFsaXphdGlvbiwgb3IgWE1MPwog ICAgICAgICAgCiAgICAgIFRoZXJlIGFyZSBubyBjb25jZXJucyB3aXRoIHRoZSBkb2N1bWVudC4g CgoKICAgKDEuZCkgIERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmlj IGNvbmNlcm5zIG9yCiAgICAgICAgICBpc3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhl IFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IKICAgICAgICAgIGFuZC9vciB0aGUgSUVTRyBzaG91 bGQgYmUgYXdhcmUgb2Y/ICBGb3IgZXhhbXBsZSwgcGVyaGFwcyBoZQogICAgICAgICAgb3Igc2hl IGlzIHVuY29tZm9ydGFibGUgd2l0aCBjZXJ0YWluIHBhcnRzIG9mIHRoZSBkb2N1bWVudCwgb3IK ICAgICAgICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9y IGl0LiAgSW4gYW55CiAgICAgICAgICBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhv c2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkCiAgICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hl cyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlCiAgICAgICAgICBjb25jZXJu cyBoZXJlLiAgSGFzIGFuIElQUiBkaXNjbG9zdXJlIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudAog ICAgICAgICAgYmVlbiBmaWxlZD8gIElmIHNvLCBwbGVhc2UgaW5jbHVkZSBhIHJlZmVyZW5jZSB0 byB0aGUKICAgICAgICAgIGRpc2Nsb3N1cmUgYW5kIHN1bW1hcml6ZSB0aGUgV0cgZGlzY3Vzc2lv biBhbmQgY29uY2x1c2lvbiBvbgogICAgICAgICAgdGhpcyBpc3N1ZS4KCiAgICAgIFRoZXJlIGFy ZSBubyBjb25jZXJucy4gCiAgICAgIAogICAoMS5lKSAgSG93IHNvbGlkIGlzIHRoZSBXRyBjb25z ZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQ/ICBEb2VzIGl0CiAgICAgICAgICByZXByZXNlbnQg dGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aAogICAgICAg ICAgb3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0 YW5kIGFuZAogICAgICAgICAgYWdyZWUgd2l0aCBpdD8KICAgICAgICAgIAogICAgICBUaGVyZSBp cyBjb25zZW5zdXMgYmVoaW5kIHRoaXMgZG9jdW1lbnQuCiAgICAgIAoKCiAgICgxLmYpICBIYXMg YW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVt ZQogICAgICAgICAgZGlzY29udGVudD8gIElmIHNvLCBwbGVhc2Ugc3VtbWFyaXplIHRoZSBhcmVh cyBvZiBjb25mbGljdCBpbgogICAgICAgICAgc2VwYXJhdGUgZW1haWwgbWVzc2FnZXMgdG8gdGhl IFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IuICAoSXQKICAgICAgICAgIHNob3VsZCBiZSBpbiBh IHNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzCiAgICAgICAgICBl bnRlcmVkIGludG8gdGhlIElEIFRyYWNrZXIuKQogICAgICAgICAgCiAgICAgIE5vLiAKCiAgICgx LmcpICBIYXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIHBlcnNvbmFsbHkgdmVyaWZpZWQgdGhhdCB0 aGUKICAgICAgICAgIGRvY3VtZW50IHNhdGlzZmllcyBhbGwgSUQgbml0cz8gIChTZWUKICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvSUQtQ2hlY2tsaXN0Lmh0bWwgYW5kCiAgICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLy4pICBCb2lsZXJwbGF0ZSBjaGVja3Mg YXJlCiAgICAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdo LiAgSGFzIHRoZSBkb2N1bWVudAogICAgICAgICAgbWV0IGFsbCBmb3JtYWwgcmV2aWV3IGNyaXRl cmlhIGl0IG5lZWRzIHRvLCBzdWNoIGFzIHRoZSBNSUIKICAgICAgICAgIERvY3RvciwgbWVkaWEg dHlwZSwgYW5kIFVSSSB0eXBlIHJldmlld3M/ICBJZiB0aGUgZG9jdW1lbnQKICAgICAgICAgIGRv ZXMgbm90IGFscmVhZHkgaW5kaWNhdGUgaXRzIGludGVuZGVkIHN0YXR1cyBhdCB0aGUgdG9wIG9m CiAgICAgICAgICB0aGUgZmlyc3QgcGFnZSwgcGxlYXNlIGluZGljYXRlIHRoZSBpbnRlbmRlZCBz dGF0dXMgaGVyZS4KCiAgICAgIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIG5pdHMuIAoK CiAgICgxLmgpICBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0cyByZWZlcmVuY2VzIGludG8gbm9y bWF0aXZlIGFuZAogICAgICAgICAgaW5mb3JtYXRpdmU/ICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJl ZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQKICAgICAgICAgIGFyZSBub3QgcmVhZHkgZm9yIGFk dmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhcgogICAgICAgICAgc3RhdGU/ ICBJZiBzdWNoIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGV4aXN0LCB3aGF0IGlzIHRoZQogICAgICAg ICAgc3RyYXRlZ3kgZm9yIHRoZWlyIGNvbXBsZXRpb24/ICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJl ZmVyZW5jZXMKICAgICAgICAgIHRoYXQgYXJlIGRvd253YXJkIHJlZmVyZW5jZXMsIGFzIGRlc2Ny aWJlZCBpbiBbUkZDMzk2N10/ICBJZgogICAgICAgICAgc28sIGxpc3QgdGhlc2UgZG93bndhcmQg cmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhCiAgICAgICAgICBEaXJlY3RvciBpbiB0aGUg TGFzdCBDYWxsIHByb2NlZHVyZSBmb3IgdGhlbSBbUkZDMzk2N10uCgoKICAgICBUaGUgZG9jdW1l bnQgaGFzIHJlZmVyZW5jZXMgc3BsaXQgaW50byBub3JtYXRpdmUgYW5kIAogICAgIGluZm9ybWF0 aXZlIHJlZmVyZW5jZXMuIFRoZSBkb2N1bWVudCBjb250YWlucyByZWZlcmVuY2VzIHRvIAogICAg IHR3byBJVFUtVCBkb2N1bWVudHM6IAoKCiAgICAgW1kuMTU0MV0gICAiTmV0d29yayBQZXJmb3Jt YW5jZSBPYmplY3RpdmVzIGZvciBJUC1CYXNlZCBTZXJ2aWNlcyIsCiAgICAgICAgICAgICAgICAy MDA2LgogCiAgICAgW1kuMTU3MV0gICAiQWRtaXNzaW9uIENvbnRyb2wgUHJpb3JpdHkgTGV2ZWxz IGluIE5leHQgR2VuZXJhdGlvbgogICAgICAgICAgICAgICAgTmV0d29ya3MiLCBKdWx5IDIwMDYu ICAKCgogICAgIAogICAoMS5pKSAgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCB2ZXJpZmllZCB0 aGF0IHRoZSBkb2N1bWVudCdzIElBTkEKICAgICAgICAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24g ZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkKICAgICAgICAgIG9mIHRoZSBk b2N1bWVudD8gIElmIHRoZSBkb2N1bWVudCBzcGVjaWZpZXMgcHJvdG9jb2wKICAgICAgICAgIGV4 dGVuc2lvbnMsIGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkEK ICAgICAgICAgIHJlZ2lzdHJpZXM/ICBBcmUgdGhlIElBTkEgcmVnaXN0cmllcyBjbGVhcmx5IGlk ZW50aWZpZWQ/ICBJZgogICAgICAgICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBuZXcgcmVnaXN0 cnksIGRvZXMgaXQgZGVmaW5lIHRoZQogICAgICAgICAgcHJvcG9zZWQgaW5pdGlhbCBjb250ZW50 cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24KICAgICAgICAgIHByb2NlZHVyZSBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/ICBEb2VzIGl0IHN1Z2dlc3QgYQogICAgICAgICAgcmVh c29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5PyAgU2VlIFtSRkMyNDM0XS4gIElmIHRo ZQogICAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJvY2Vzcywg aGFzIHRoZSBEb2N1bWVudAogICAgICAgICAgU2hlcGhlcmQgY29uZmVycmVkIHdpdGggdGhlIFJl c3BvbnNpYmxlIEFyZWEgRGlyZWN0b3Igc28gdGhhdAogICAgICAgICAgdGhlIElFU0cgY2FuIGFw cG9pbnQgdGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIElFU0cgRXZhbHVhdGlvbj8KCiAgIEFuIElB TkEgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGV4aXN0cyBhbmQgaXMgY29uc2lzdGVudCB3aXRoIHRo ZSByZXN0IAogICBvZiB0aGUgZG9jdW1lbnQuIAoKCiAgICgxLmopICBIYXMgdGhlIERvY3VtZW50 IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlCiAgICAgICAgICBkb2N1bWVu dCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTAogICAg ICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4sIHZhbGlkYXRlIGNv cnJlY3RseSBpbgogICAgICAgICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/CgogICBUaGUgZG9jdW1l bnQgZG9lcyBub3QgY29udGFpbiBmb3JtYWwgbGFuZ3VhZ2VzLiAKICAgCiAgIAogICAoMS5rKSAg VGhlIElFU0cgYXBwcm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQKICAgICAg ICAgIEFubm91bmNlbWVudCBXcml0ZS1VcC4gIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVu dAogICAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiAgUmVjZW50IGV4YW1wbGVzIGNhbiBi ZSBmb3VuZCBpbiB0aGUKICAgICAgICAgICJBY3Rpb24iIGFubm91bmNlbWVudHMgZm9yIGFwcHJv dmVkIGRvY3VtZW50cy4gCgoKRG9jdW1lbnQgQW5ub3VuY2VtZW50IFdyaXRlLVVwIGZvciAiUXVh bGl0eSBvZiBTZXJ2aWNlIFBhcmFtZXRlcnMgZm9yIApVc2FnZSB3aXRoIHRoZSBBQUEgRnJhbWV3 b3JrIiAoZHJhZnQtaWV0Zi1kaW1lLXFvcy1wYXJhbWV0ZXJzLTA2LnR4dCkKCiAgIFRlY2huaWNh bCBTdW1tYXJ5CgogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBudW1iZXIgb2YgUXVhbGl0eSBv ZiBTZXJ2aWNlIChRb1MpIHBhcmFtZXRlcnMKICAgdGhhdCBjYW4gYmUgcmV1c2VkIGZvciBjb252 ZXlpbmcgUW9TIGluZm9ybWF0aW9uIHdpdGhpbiBSQURJVVMgYW5kCiAgIERpYW1ldGVyLgoKICAg VGhlIHBheWxvYWRzIHVzZWQgdG8gY2FycnkgdGhlc2UgUW9TIHBhcmFtZXRlcnMgYXJlIG9wYXF1 ZSBmb3IgdGhlCiAgIEFBQSBjbGllbnQgYW5kIHRoZSBBQUEgc2VydmVyIGl0c2VsZiBhbmQgaW50 ZXJwcmV0ZWQgYnkgdGhlCiAgIHJlc3BlY3RpdmUgUmVzb3VyY2UgTWFuYWdlbWVudCBGdW5jdGlv bi4KCgogICBXb3JraW5nIEdyb3VwIFN1bW1hcnkKCiAgICAgIFRoZXJlIGlzIGNvbnNlbnN1cyBp biB0aGUgV0cgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50LgoKICAgRG9jdW1lbnQgUXVhbGl0eQoK ICAgICAgVGhlIGRvY3VtZW50IGhhcyBiZWVuIHNlbnQgZm9yIHJldmlldyB0byBESU1FLCBOU0lT LCBUU1ZXRyBhbmQgCiAgICAgIFJBREVYVC4gVGhpcyBkb2N1bWVudCBpcyBwYXJ0IG9mIHRoZSBz b2x1dGlvbiBmb3IgZXh0ZW5kaW5nIHRoZSAKICAgICAgUW9TRmlsdGVyUnVsZSBBVlAgZnVuY3Rp b25hbGl0eSBvZiB0aGUgRGlhbWV0ZXIgQmFzZSBwcm90b2NvbCAKICAgICAgYW5kIHRoZSBmdW5j dGlvbmFsaXR5IG9mIHRoZSBRb1MtRmlsdGVyLVJ1bGUgQVZQIGRlZmluZWQgaW4gCiAgICAgIFJG QyA0MDA1LgoKICAgICAgCiAgIFBlcnNvbm5lbAoKICAgICBEYXZpZCBGcmFzY29uZSBpcyB0aGUg ZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoaXMgZG9jdW1lbnQuICAKCg== ------=_Part_6745_18747682.1214533097938 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://www.ietf.org/mailman/listinfo/dime ------=_Part_6745_18747682.1214533097938-- From dime-bounces@ietf.org Sun Jun 29 22:10:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D963A6930; Sun, 29 Jun 2008 22:10:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21A33A6930 for ; Sun, 29 Jun 2008 22:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.164 X-Spam-Level: ** X-Spam-Status: No, score=2.164 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJVHfKAKANET for ; Sun, 29 Jun 2008 22:09:59 -0700 (PDT) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id E06BA3A68DE for ; Sun, 29 Jun 2008 22:09:57 -0700 (PDT) Received: from hemant ([172.16.12.8]) by ricky.india.internal.net (8.12.10/8.12.10) with SMTP id m5U5BN0t007724 for ; Mon, 30 Jun 2008 10:41:29 +0530 Message-ID: <003201c8da70$ad7a39c0$080c10ac@india.internal.net> From: "Hemant" To: Date: Mon, 30 Jun 2008 10:48:00 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Cyberoam-Version: 9.5.3.22 X-Cyberoam-smtpxy-version: 0.0.3.0 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy Subject: [Dime] Query for TLS timer in diameter. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 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="===============2104379296==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2104379296== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C8DA9E.C4074D80" This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C8DA9E.C4074D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, RFC 4346 does not specifies what should be the maximum time a node = should wait for handshake in case their is no response from peer. My = query is : 1). What should be the behavior when TLS client / diameter initiator = peer does not receive server hello after sending client hello? 2). What should be the behavior when TLS server / diameter responder = does not receive client hello. Thanks in advance, Hemant Bhatnagar IntelliNet Technologies. Bangalore. ------=_NextPart_000_002F_01C8DA9E.C4074D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
RFC 4346 does not specifies what should = be the=20 maximum time a node should wait for handshake in case their is no = response=20 from peer. My query is :
 
1). What should be the = behavior when TLS=20 client / diameter initiator peer does not receive server hello = after=20 sending client hello?
 
2). What should=20 be the behavior when TLS server / diameter responder does not receive = client=20 hello.
 
 
Thanks in advance,
Hemant Bhatnagar
IntelliNet Technologies.
Bangalore.
------=_NextPart_000_002F_01C8DA9E.C4074D80-- --===============2104379296== 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://www.ietf.org/mailman/listinfo/dime --===============2104379296==--