From dromasca@avaya.com Fri Oct 2 03:31:01 2009 Return-Path: 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 23F0728B23E; Fri, 2 Oct 2009 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 khkkMGcGyhqb; Fri, 2 Oct 2009 03:31:00 -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 7316428C0D8; Fri, 2 Oct 2009 03:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="158655251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Subject: [Dime] FW: Need for WebEx at IETF 76 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: , X-List-Received-Date: Fri, 02 Oct 2009 10:31:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 From root@core3.amsl.com Tue Oct 6 03:30:02 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A3533A691F; Tue, 6 Oct 2009 03:30: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: <20091006103002.1A3533A691F@core3.amsl.com> Date: Tue, 6 Oct 2009 03:30:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nai-routing-04.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: , X-List-Received-Date: Tue, 06 Oct 2009 10:30:02 -0000 --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 User-Name and Realm Based Request Routing Clarifications Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-nai-routing-04.txt Pages : 12 Date : 2009-10-06 This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-04.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-nai-routing-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06031615.I-D@ietf.org> --NextPart-- From vfajardo@research.telcordia.com Tue Oct 6 07:27:14 2009 Return-Path: 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 958E828C188 for ; Tue, 6 Oct 2009 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, 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 IIuOFrlWPyuq for ; Tue, 6 Oct 2009 07:27:10 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 948F13A68F3 for ; Tue, 6 Oct 2009 07:27:09 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n96ESk2f011960; Tue, 6 Oct 2009 10:28:46 -0400 (EDT) From: "Victor Fajardo" To: , References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> In-Reply-To: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> Date: Tue, 6 Oct 2009 10:28:46 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <003101ca4691$50537750$f0fa65f0$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CA466F.C941D750" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWA Content-Language: en-us Subject: Re: [Dime] Diameter API draft. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 14:27:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01CA466F.C941D750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, It's been over a month and we have not had any feedback regarding the Diameter API doc. At this point, I think it's safe to say that no one is interested in continuing this work and so we will effectively remove this doc from the charter. Regards, Victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Monday, August 24, 2009 8:25 AM To: dime@ietf.org Subject: [Dime] Diameter API draft. Hi Folks, During the last IETF, we were trying to gauge if there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If you see value in this draft and wish to see the work continue, make sure you respond to this email as well as address the questions "why and who" would use this API. If you don't see any value in this work pls state so as well. We'll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the draft. Regards, victor ------=_NextPart_000_0032_01CA466F.C941D750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

It’s been over = a month and we have not had any feedback regarding the Diameter API doc. At this = point, I think it’s safe to say that no one is interested in continuing = this work and so we will effectively remove this doc from the = charter.

 

Regards,

Victor

 

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Victor Fajardo
Sent: Monday, August 24, 2009 8:25 AM
To: dime@ietf.org
Subject: [Dime] Diameter API draft.

 

Hi Folks,

 

During the last IETF, we were trying to gauge if = there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This = email is a follow up to solicit a final vote/hum for this draft. If you see value = in this draft and wish to see the work continue,  make sure you respond to = this email as well as address the questions “why and who” would = use this API. If you don’t see any value in this work pls state so as well. We’ll give this hum some time to circulate through peoples = mailboxes (a month or so) after which we can decide the fate of the = draft.

 

Regards,

victor

------=_NextPart_000_0032_01CA466F.C941D750-- From vfajardo@research.telcordia.com Tue Oct 6 08:44:35 2009 Return-Path: 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 17AE23A69FF for ; Tue, 6 Oct 2009 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, 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 2eRspajN1BwQ for ; Tue, 6 Oct 2009 08:44:34 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id EA2803A68FE for ; Tue, 6 Oct 2009 08:44:33 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n96Fk6vP010775; Tue, 6 Oct 2009 11:46:06 -0400 (EDT) From: "Victor Fajardo" To: "'Tina TSOU'" , "'Tom Taylor'" References: <20090730110001.9CCC628C18C@core3.amsl.com> In-Reply-To: <20090730110001.9CCC628C18C@core3.amsl.com> Date: Tue, 6 Oct 2009 11:46:06 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <004b01ca469c$1e3e1cb0$5aba5610$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRBTs/zrPiSjK7Tw+T5niZFBnZyw1lk6oA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:44:35 -0000 Hi Tom/Tina, There a few leftover discussions regarding this doc (7/30 - 7/31 thread). Do you plan on updating the docs based on these comments ? Do you have any other open issues ? Regards, Victor -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, July 30, 2009 7:00 AM To: i-d-announce@ietf.org Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt 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 : Realm-Based Redirection In Diameter Author(s) : T. Tsou, T. Taylor Filename : draft-ietf-dime-realm-based-redirect-01.txt Pages : 6 Date : 2009-07-30 RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies the means by which this can be achieved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-01. 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. From tom.taylor@rogers.com Tue Oct 6 08:52:57 2009 Return-Path: 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 B551028C1D3 for ; Tue, 6 Oct 2009 08:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, 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 tNBsiOHS5qng for ; Tue, 6 Oct 2009 08:52:57 -0700 (PDT) Received: from smtp117.rog.mail.re2.yahoo.com (smtp117.rog.mail.re2.yahoo.com [68.142.225.233]) by core3.amsl.com (Postfix) with SMTP id C2AF428C0D8 for ; Tue, 6 Oct 2009 08:52:56 -0700 (PDT) Received: (qmail 47798 invoked from network); 6 Oct 2009 15:54:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Au4nIVvesu/Sw0wU4imIILs3injGb9XD73vfkiD6uefpSd2RgiP5++hCvclm54A1cvw0QiEcbORIlkoZZ7Dp5i8I4WrLvbPnEla52cazKSncnLZscxs7b/WnuCmqkGKGaDz0IVzbX1l0haXWjYQ6wGbCjeeFfYkKUW16Fkw0/30= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp117.rog.mail.re2.yahoo.com with SMTP; 6 Oct 2009 15:54:32 -0000 X-YMail-OSG: bqWbmD4VM1lPOVZ2MRCuJG1lhUdYC7dk6ty0tE1j4ocw2a.Xahzy3b3LmgMnudQIyQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACB6837.5090101@rogers.com> Date: Tue, 06 Oct 2009 11:54:31 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: vfajardo@research.telcordia.com References: <20090730110001.9CCC628C18C@core3.amsl.com> <004b01ca469c$1e3e1cb0$5aba5610$@telcordia.com> In-Reply-To: <004b01ca469c$1e3e1cb0$5aba5610$@telcordia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Tue, 06 Oct 2009 15:52:57 -0000 Yes, I'll update to remove the unneeded content. After that I think the draft is in good shape. Victor Fajardo wrote: > Hi Tom/Tina, > > There a few leftover discussions regarding this doc (7/30 - 7/31 thread). Do > you plan on updating the docs based on these comments ? Do you have any > other open issues ? > > Regards, > Victor > > > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, July 30, 2009 7:00 AM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt > > 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 : Realm-Based Redirection In Diameter > Author(s) : T. Tsou, T. Taylor > Filename : draft-ietf-dime-realm-based-redirect-01.txt > Pages : 6 > Date : 2009-07-30 > > RFC 3588 allows a Diameter redirect agent to specify one or more individual > hosts to which a Diameter message may be redirected by an upstream Diameter > node. However, in some circumstances an operator may wish to redirect > messages to an alternate domain without specifying individual hosts. This > document specifies the means by which this can be achieved. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-01. > 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. > > From tom.taylor@rogers.com Tue Oct 6 10:59:16 2009 Return-Path: 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 6ADFA3A67D9 for ; Tue, 6 Oct 2009 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 sbJ7VFqGtF3L for ; Tue, 6 Oct 2009 10:59:14 -0700 (PDT) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by core3.amsl.com (Postfix) with SMTP id D1E083A6997 for ; Tue, 6 Oct 2009 10:59:03 -0700 (PDT) Received: (qmail 95410 invoked from network); 6 Oct 2009 18:00:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=tWuqy1DaQe75k5ran7ly53QTlFfyMHdW7mexhoYItfVf9B5EiWn9Bj5WvLBvkHXdcwHcei0T8ARn0kMnAv66x5Ro4GOry5J0h/BuKNRKGNAeRkXuUmRxOt6nZJl0U+BDLD2ElRtOd1J2Xp+UZdJutoqqelzHKLsAHz7ne6Y9e1g= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 6 Oct 2009 18:00:38 -0000 X-YMail-OSG: 76t7a.AVM1mEdpDlngXMm16BjdH.CTeX_Ej4mRaoyIQGDeF89FfMZ9V.poD19uLX8g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACB85C5.9080609@rogers.com> Date: Tue, 06 Oct 2009 14:00:37 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Jones References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>, <4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> In-Reply-To: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Tue, 06 Oct 2009 17:59:16 -0000 I'm proposing in response to your concern on advertisement to add the following section to the document. Does this meet the requirements?
Because realm-based redirection is not part of base Diameter behaviour, support for realm-based redirection by the client cannot be guaranteed without advertisement at the application level. Designers of new applications MAY wish to incorporate a requirement to support realm-based redirection through normative reference to this document. An erstwhile service provider who deploys realm-based redirection without support from advertisement imposes a risk upon clients that they are unable to complete requests for the service concerned because, thanks to prevailing local policies, they have not derived alternative routes to other domains that can support the service. The decision to impose such a risk and the administrative actions that providers may take to mitigate this risk are based on non-technical considerations and are therefore out of scope of this document.
Mark Jones wrote: > The use case I had in mind when I made the comment in the DIME session was a wholesaler for AAA that was previously offering service for a given realm but the AAA service is now being provided by a new wholesaler. > > So the old wholesaler would use the redirect realm AVPs with: > Redirect-Realm = > Redirect-Realm-Usage = ALL_REALM > > The other question I had on this draft was how one advertises support for the realm redirect functionality. I understand from Tom's presentation that nothing too bad happens on the client if it does not support these AVPs but the intended redirect did not happen either and the redirecting server is unaware of the error. The way new functionality (i.e. beyond base functionaltiy) is advertised in Diameter is through the use of application ids in CER/CEA exchanges. If new applications require redirect realm functionaltiy, I would expect the specifications for these new applications to state this dependency and include a normative reference to the redirect realm draft. I think the redirect realm draft should clarify this because redirect realm is not base functionality. > > Regards > Mark > > ________________________________________ > From: dime-bounces@ietf.org [dime-bounces@ietf.org] On Behalf Of Sebastien Decugis [sdecugis@nict.go.jp] > Sent: Thursday, July 30, 2009 3:24 PM > To: Tom Taylor > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt > > Ok, I did not get that, sorry :) Just ignore my comment then. > > Thanks, > Sebastien. > > Tom Taylor a écrit : >> No difference, but didn't we say in the meeting we preferred not to >> overload Redirect-Host-Usage? >> >> Sebastien Decugis wrote: >>> Hi, >>> >>> Just quickly going through the new draft revision, I did not find any >>> difference between Redirect-Host-Usage (RFC3588) and the new >>> Redirect-Realm-Usage being defined. I am just wondering if the content >>> is the same, if we cannot just re-use the Redirect-Host-Usage AVP? >>> Please let me know (and pardon me) if I did miss a subtle difference :) >>> >>> My 2 cents, >>> Sebastien. >>> >>> >>> Tom Taylor a écrit : >> ... >> > _______________________________________________ > 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 Mark.Jones@bridgewatersystems.com Tue Oct 6 12:54:50 2009 Return-Path: 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 144403A6838 for ; Tue, 6 Oct 2009 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 XrDoMM9hOKD4 for ; Tue, 6 Oct 2009 12:54:49 -0700 (PDT) Received: from anders.electric.net (anders.electric.net [72.35.23.15]) by core3.amsl.com (Postfix) with ESMTP id 17E4F3A67D8 for ; Tue, 6 Oct 2009 12:54:49 -0700 (PDT) Received: from 1MvG94-0005zp-Tc by anders.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MvG94-000609-UC; Tue, 06 Oct 2009 12:56:26 -0700 Received: by emcmailer; Tue, 06 Oct 2009 12:56:26 -0700 Received: from [72.35.6.119] (helo=webmail.bridgewatersystems.com) by anders.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MvG94-0005zp-Tc; Tue, 06 Oct 2009 12:56:26 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 6 Oct 2009 15:56:26 -0400 From: Mark Jones To: Tom Taylor Date: Tue, 6 Oct 2009 15:56:24 -0400 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt Thread-Index: AcpGru238Glb9YDdSCGPtBLHqcFqhgABx5sA Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>,<4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> In-Reply-To: <4ACB85C5.9080609@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Tue, 06 Oct 2009 19:54:50 -0000 Hi Tom, I was expecting a stronger statement on advertisement at the application le= vel, e.g. "Because realm-based redirection is not part of base Diameter behaviour, su= pport for realm-based redirection by the peers MUST be advertised at the ap= plication level." I don't see how the feature works reliably otherwise and punting the risk e= valuation to the service provider seems inappropriate for a feature likely = to used on inter-service-provider interfaces. Regards Mark > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 > Sent: October 6, 2009 2:01 PM > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] I-D=20 > Action:draft-ietf-dime-realm-based-redirect-01.txt >=20 > I'm proposing in response to your concern on advertisement to=20 > add the following=20 > section to the document. Does this meet the requirements? >=20 >
>=20 > Because realm-based redirection is not part of base=20 > Diameter behaviour,=20 > support for realm-based redirection by the client cannot be=20 > guaranteed without=20 > advertisement at the application level. Designers of new=20 > applications MAY wish=20 > to incorporate a requirement to support realm-based=20 > redirection through=20 > normative reference to this document. >=20 > An erstwhile service provider who deploys realm-based=20 > redirection without=20 > support from advertisement imposes a risk upon clients that=20 > they are unable to=20 > complete requests for the service concerned because, thanks=20 > to prevailing local=20 > policies, they have not derived alternative routes to other=20 > domains that can=20 > support the service. The decision to impose such a risk and=20 > the administrative=20 > actions that providers may take to mitigate this risk are=20 > based on non-technical=20 > considerations and are therefore out of scope of this document. >=20 >
>=20 >=20 > Mark Jones wrote: > > The use case I had in mind when I made the comment in the=20 > DIME session was a wholesaler for AAA that was previously=20 > offering service for a given realm but the AAA service is now=20 > being provided by a new wholesaler. > >=20 > > So the old wholesaler would use the redirect realm AVPs with: > > Redirect-Realm =3D > > Redirect-Realm-Usage =3D ALL_REALM > >=20 > > The other question I had on this draft was how one=20 > advertises support for the realm redirect functionality. I=20 > understand from Tom's presentation that nothing too bad=20 > happens on the client if it does not support these AVPs but=20 > the intended redirect did not happen either and the=20 > redirecting server is unaware of the error. The way new=20 > functionality (i.e. beyond base functionaltiy) is advertised=20 > in Diameter is through the use of application ids in CER/CEA=20 > exchanges. If new applications require redirect realm=20 > functionaltiy, I would expect the specifications for these=20 > new applications to state this dependency and include a=20 > normative reference to the redirect realm draft. I think the=20 > redirect realm draft should clarify this because redirect=20 > realm is not base functionality. > >=20 > > Regards > > Mark > >=20 > > ________________________________________ > > From: dime-bounces@ietf.org [dime-bounces@ietf.org] On=20 > Behalf Of Sebastien Decugis [sdecugis@nict.go.jp] > > Sent: Thursday, July 30, 2009 3:24 PM > > To: Tom Taylor > > Cc: dime@ietf.org > > Subject: Re: [Dime] I-D=20 > Action:draft-ietf-dime-realm-based-redirect-01.txt > >=20 > > Ok, I did not get that, sorry :) Just ignore my comment then. > >=20 > > Thanks, > > Sebastien. > >=20 > > Tom Taylor a =E9crit : > >> No difference, but didn't we say in the meeting we preferred not to > >> overload Redirect-Host-Usage? > >> > >> Sebastien Decugis wrote: > >>> Hi, > >>> > >>> Just quickly going through the new draft revision, I did=20 > not find any > >>> difference between Redirect-Host-Usage (RFC3588) and the new > >>> Redirect-Realm-Usage being defined. I am just wondering=20 > if the content > >>> is the same, if we cannot just re-use the Redirect-Host-Usage AVP? > >>> Please let me know (and pardon me) if I did miss a subtle=20 > difference :) > >>> > >>> My 2 cents, > >>> Sebastien. > >>> > >>> > >>> Tom Taylor a =E9crit : > >> ... > >> > > _______________________________________________ > > 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 > >=20 > = From tom.taylor@rogers.com Tue Oct 6 19:07:46 2009 Return-Path: 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 8F21F28C20E for ; Tue, 6 Oct 2009 19:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 xX4MSk4DYhE8 for ; Tue, 6 Oct 2009 19:07:45 -0700 (PDT) Received: from smtp120.rog.mail.re2.yahoo.com (smtp120.rog.mail.re2.yahoo.com [68.142.224.75]) by core3.amsl.com (Postfix) with SMTP id 974DB28C1EE for ; Tue, 6 Oct 2009 19:07:45 -0700 (PDT) Received: (qmail 15643 invoked from network); 7 Oct 2009 02:09:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XvJ7nseRMEI/Ai2Z37lm1T1ahetPJzuhWH0WKZFHfgUCFDfFK18hlVTMTDLTG2QK2niYr2T7gOSW2iLLdBKlD+xuokuXW1Rgb4tM9xU+z8rwrJg5ix/f+E1gT/BoqDy07R/mgD+/OK8kuJbXPxJucSqfG+0fK1fVONbmv/kR1po= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp120.rog.mail.re2.yahoo.com with SMTP; 7 Oct 2009 02:09:21 -0000 X-YMail-OSG: D0.QHs0VM1l1Hbe616wPs_IZUvwzAKYGBh8vCuYknznTOfT5dA.dpS7CQeqc30GkRg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACBF84F.6020506@rogers.com> Date: Tue, 06 Oct 2009 22:09:19 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Jones References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>, <4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> In-Reply-To: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Wed, 07 Oct 2009 02:07:46 -0000 What I'm worried about is whether this implies every application out there has to be redefined to make use of this feature. Mark Jones wrote: > Hi Tom, > > I was expecting a stronger statement on advertisement at the application level, e.g. > > "Because realm-based redirection is not part of base Diameter behaviour, support for realm-based redirection by the peers MUST be advertised at the application level." > > I don't see how the feature works reliably otherwise and punting the risk evaluation to the service provider seems inappropriate for a feature likely to used on inter-service-provider interfaces. > > Regards > Mark > > From fbrockne@cisco.com Wed Oct 7 04:35:07 2009 Return-Path: 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 2D2BE28C276 for ; Wed, 7 Oct 2009 04:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 1DpwkKFgg-Al for ; Wed, 7 Oct 2009 04:35:06 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3AEE828C21C for ; Wed, 7 Oct 2009 04:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=1134; q=dns/txt; s=sjiport05001; t=1254915405; x=1256125005; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Frank=20Brockners=20(fbrockne)"=20|Subject:=20evolving=20draft-ietf-dime-nat-control -00|Date:=20Wed,=207=20Oct=202009=2013:35:59=20+0200 |Message-ID:=20<0D212BD466921646B58854FB79092CEC683966@XM B-AMS-106.cisco.com>|To:=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable; bh=+OKURxoQKZ/p+Yg3MQXBi7gLLqWSSl7ey5UdIwZD0rY=; b=CHFX/pmITfNGFIoZ4ZuKmZcUrsBgL1Z8VrhfE/QXGn5xLB969LkPDQ30 s8qOP6TUrrLb5cCGMWPeFNZp/MQEa2LkB0Yf3xaZVrUD/hVAuIzHDme4n JSaApf+XYQApGgHXuyRPYI1N0kMeD6qeG9hpwmqJv6NBbwdLbTcaQOwwX 8=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=fbrockne@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALMazEqrR7MV/2dsb2JhbAC9GIhjAY83BoQq X-IronPort-AV: E=Sophos;i="4.44,519,1249257600"; d="scan'208";a="97881595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 07 Oct 2009 11:36:45 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n97BajPk014979 for ; Wed, 7 Oct 2009 04:36:45 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n97BaN0C016296 for ; Wed, 7 Oct 2009 11:36:45 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 13:35:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 13:35:59 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC683966@XMB-AMS-106.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: evolving draft-ietf-dime-nat-control-00 Thread-Index: AcpHQldVzYKUzB2yT6OlLEz/R9p6pA== From: "Frank Brockners (fbrockne)" To: X-OriginalArrivalTime: 07 Oct 2009 11:35:59.0812 (UTC) FILETIME=[57B12040:01CA4742] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1134; t=1254915405; x=1255779405; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fbrockne@cisco.com; z=From:=20=22Frank=20Brockners=20(fbrockne)=22=20 |Subject:=20evolving=20draft-ietf-dime-nat-control-00 |Sender:=20; bh=+OKURxoQKZ/p+Yg3MQXBi7gLLqWSSl7ey5UdIwZD0rY=; b=UDVHomhLBbP9ZAgNZjvgGc7sUYGv/DGpCggQTJJ4OekfcoAShoRNLbZ4PG mMlRJSmfSjnguiAz3ck1oSg0m0BNtNO52/Kkf92tA18Y1MGSMVKM8rleItSv Dm7xeDHQl9/AG647R8q19aLGPhQE0svfa6mpiYma0eb/T9jIK52sM=; Subject: [Dime] evolving draft-ietf-dime-nat-control-00 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: , X-List-Received-Date: Wed, 07 Oct 2009 11:35:07 -0000 Hi Folks, just wanted to follow up on the status & planned evolution of the Diameter NAT Control Application (i.e. draft-ietf-dime-nat-control-00). The study of existing NAT control protocols (draft-brockners-nat-control-protocols-review-00.txt) which was requested by multiple folks and which was presented at the last meeting revealed a couple of control capabilities for NAT, that the DNCA would benefit from as well. We could take those as the starting point for further evolving the document. Any additional suggestions and comments are of course highly appreciated. For the next revision of the document, the proposal would be to add in the two most obvious capabilities which DNCA currently lacks, i.e. a) support for Twice-NAT (Twice-NAT is defined in RFC2663) b) support for transport specific bindings a) would result in the addition of an AVP to NCR (the request to create a session) to indicate the direction of a binding; whereas b) could be covered by introducing an AVP into the respective commands indicating whether the binding is for UDP or TCP. Appreciate your thoughts. Thanks, Frank From Mark.Jones@bridgewatersystems.com Wed Oct 7 08:46:10 2009 Return-Path: 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 EDCB63A657C for ; Wed, 7 Oct 2009 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 5H2YkH8kLxjb for ; Wed, 7 Oct 2009 08:46:10 -0700 (PDT) Received: from bean.electric.net (bean.electric.net [72.35.23.29]) by core3.amsl.com (Postfix) with ESMTP id 006473A692F for ; Wed, 7 Oct 2009 08:46:04 -0700 (PDT) Received: from 1MvYjw-0004Sx-U3 by bean.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MvYjw-0004TV-Uv; Wed, 07 Oct 2009 08:47:44 -0700 Received: by emcmailer; Wed, 07 Oct 2009 08:47:44 -0700 Received: from [72.35.6.119] (helo=webmail.bridgewatersystems.com) by bean.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MvYjw-0004Sx-U3; Wed, 07 Oct 2009 08:47:44 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 7 Oct 2009 11:47:44 -0400 From: Mark Jones To: Tom Taylor Date: Wed, 7 Oct 2009 11:47:43 -0400 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt Thread-Index: AcpG8zO3rj2HYv/fQQOa2MA4elZQKwAcWINg Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822999@m679t05.fpmis.bridgewatersys.com> References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>,<4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> <4ACBF84F.6020506@rogers.com> In-Reply-To: <4ACBF84F.6020506@rogers.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 750505 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Wed, 07 Oct 2009 15:46:11 -0000 Hi Tom,=20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 > Sent: October 6, 2009 10:09 PM > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] I-D=20 > Action:draft-ietf-dime-realm-based-redirect-01.txt >=20 > What I'm worried about is whether this implies every=20 > application out there has=20 > to be redefined to make use of this feature. >=20 That is indeed the implication. Alternatively, you define a new application= id for the realm-based redirect functionality and it complements the exist= ing applications, i.e. if you need NASREQ with realm-based redirect, the CE= R/CEA advertises the NASREQ Application Id and the Realm-based Redirect App= lication ID. Regards Mark > Mark Jones wrote: > > Hi Tom, > >=20 > > I was expecting a stronger statement on advertisement at=20 > the application level, e.g. > >=20 > > "Because realm-based redirection is not part of base=20 > Diameter behaviour, support for realm-based redirection by=20 > the peers MUST be advertised at the application level." > >=20 > > I don't see how the feature works reliably otherwise and=20 > punting the risk evaluation to the service provider seems=20 > inappropriate for a feature likely to used on=20 > inter-service-provider interfaces. > >=20 > > Regards > > Mark > >=20 > >=20 > = From tom.taylor@rogers.com Wed Oct 7 12:47:58 2009 Return-Path: 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 5813B28C1F8 for ; Wed, 7 Oct 2009 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 sjJ3UDKXCnkE for ; Wed, 7 Oct 2009 12:47:57 -0700 (PDT) Received: from smtp129.rog.mail.re2.yahoo.com (smtp129.rog.mail.re2.yahoo.com [206.190.53.34]) by core3.amsl.com (Postfix) with SMTP id 6955828C1F6 for ; Wed, 7 Oct 2009 12:47:57 -0700 (PDT) Received: (qmail 71847 invoked from network); 7 Oct 2009 19:49:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GA/RdrLKZzrMb+RrmuDdH1Mg12ArzcMk16nLdDOTaN3oj+ZTE7wXYCEytXEUpDbodBSNkOJZ3BCPvubPLHXRu9+V5IGYEs/eiyhXDoDnDtRls5NupS2u6cL+90xyVNxurvTb02rNzLNXEBKaNZhIxRVBXog6+F/kcpIG0KKHrP8= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp129.rog.mail.re2.yahoo.com with SMTP; 7 Oct 2009 19:49:35 -0000 X-YMail-OSG: DESI23cVM1nv8llPKr9vZlbEEhU2wFrKpquQbc7Ok8p_HVRSispggcqi2nTEtW_JeA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACCF0CE.8080603@rogers.com> Date: Wed, 07 Oct 2009 15:49:34 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Jones References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>, <4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> <4ACBF84F.6020506@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822999@m679t05.fpmis.bridgewatersys.com> In-Reply-To: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822999@m679t05.fpmis.bridgewatersys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Wed, 07 Oct 2009 19:47:58 -0000 I'll take the second choice you offer. Mark Jones wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor@rogers.com] >> Sent: October 6, 2009 10:09 PM >> To: Mark Jones >> Cc: dime@ietf.org >> Subject: Re: [Dime] I-D >> Action:draft-ietf-dime-realm-based-redirect-01.txt >> >> What I'm worried about is whether this implies every >> application out there has >> to be redefined to make use of this feature. >> > > That is indeed the implication. Alternatively, you define a new application id for the realm-based redirect functionality and it complements the existing applications, i.e. if you need NASREQ with realm-based redirect, the CER/CEA advertises the NASREQ Application Id and the Realm-based Redirect Application ID. > > Regards > Mark > > >> Mark Jones wrote: >>> Hi Tom, >>> >>> I was expecting a stronger statement on advertisement at >> the application level, e.g. >>> "Because realm-based redirection is not part of base >> Diameter behaviour, support for realm-based redirection by >> the peers MUST be advertised at the application level." >>> I don't see how the feature works reliably otherwise and >> punting the risk evaluation to the service provider seems >> inappropriate for a feature likely to used on >> inter-service-provider interfaces. >>> Regards >>> Mark >>> >>> From root@core3.amsl.com Thu Oct 8 14:30:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8F5A13A672E; Thu, 8 Oct 2009 14:30: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: <20091008213001.8F5A13A672E@core3.amsl.com> Date: Thu, 8 Oct 2009 14:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-erp-02.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: , X-List-Received-Date: Thu, 08 Oct 2009 21:30:01 -0000 --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 Support for EAP Re-authentication Protocol (ERP) Author(s) : L. Dondeti, J. Bournelle, L. Morand, S. Decugis Filename : draft-ietf-dime-erp-02.txt Pages : 18 Date : 2009-10-8 EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between ER authenticator and ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-erp-02.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-erp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-8142335.I-D@ietf.org> --NextPart-- From gwz@net-zen.net Sun Oct 11 01:59:35 2009 Return-Path: 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 78F743A68CD for ; Sun, 11 Oct 2009 01:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[AWL=-1.722, BAYES_50=0.001, FRT_SOMA2=2.199] 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 8fyYJ3DuckEO for ; Sun, 11 Oct 2009 01:59:34 -0700 (PDT) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id 8B5963A67C0 for ; Sun, 11 Oct 2009 01:59:34 -0700 (PDT) Received: (qmail 4016 invoked from network); 11 Oct 2009 09:01:19 -0000 Received: from unknown (124.120.221.158) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 11 Oct 2009 09:01:18 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <002301ca2756$78339e80$689adb80$@net> <4A9743F4.60404@nict.go.jp> <008001ca2a5f$f4026da0$dc0748e0$@net> <4A9C7FC4.4030903@nict.go.jp> In-Reply-To: <4A9C7FC4.4030903@nict.go.jp> Date: Sun, 11 Oct 2009 16:00:50 +0700 Organization: Network Zen Message-ID: <014a01ca4a51$571daf10$05590d30$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acoqp7p6UmISesbWSfm4OQ/OjJBzbwfqD+jQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [DIME] Comments about AVP for crypto key transport draft 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: , X-List-Received-Date: Sun, 11 Oct 2009 08:59:35 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: >=20 > Hi Glen, >=20 > Glen Zorn a =E9crit : > > As I understand it, you're saying that by putting the key type at = the > top > > level of the AVP structure it will be easier for a node to decide if > it is > > interested in the contents of the AVP. Is that correct? > Yes, it is exactly what I am saying. >=20 > > If so, I'm saying > > that if a node receives any key in which it is not interested, that > in > > itself is a security problem. It should never happen & I can't see > the > > point of optimizing for something that should not happen in the = first > place. > > > Actually, any agent that relays a Diameter message (not only the > proxies) receive this kind of information, right ?=20 Physically, yes, it will receive the message. Logically, however, I = fail to see any reason why an agent (with the exception of the ERP server, if = you wish to call it an agent) should look inside any AVP containing a key, = since by definition the AVP is not any of its business. > Do you mean that key > material should be protected in an end-to-end maneer (from sender to > recipient), instead of having only the hop-by-hop protection of > Diameter?=20 No. > I think this is quite contradictory with Diameter trust model > (which on the other side I believe is not scalable) >=20 > For a concrete example, in ERP explicit bootstrapping, the home server > generates two keys (rDSRK and rMSK) that are directed to two different > nodes (ERP server and NAS). Do you imply that these keys should not be > sent in the same Diameter message? No. >=20 >=20 > >> You are right, it is my mistake. RFC4072 (Diameter EAP) only say > that > >> DEA MAY include this AVP, so it is no problem to have a new > container. > >> Anyway, on an implementation point of view, this would be very > >> confusing > >> (again, interoperability is getting worse)... :-( > >> > > > > I don't know why... > > > If the NAS does not support the new container and receives a DEA with > the MSK key in this container, it will fail to establish the session > with the peer. (basically, the new container will have its 'M' flag > set, > and the NAS will not recognize it). > Therefore, the server has to either: > - have a configuration parameter for each NAS, telling if the new > container can be used or not. > - start using the new container only after all NAS (in the world?) = have > been upgraded to support the new container. We are defining the Diameter ERP application & we can state that the 'M' = bit is set for the new container. >=20 > Both solutions seems not very convenient to me. >=20 > My comment of course assumes that some NAS already support RFC4072 as > it > is defined currently... I don't know if this is true or not. If nobody > is "doing" RFC4072 currently, it is not a problem to change the > recommanded way of passing the MSK to the NAS... >=20 > Best regards, > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 From dromasca@avaya.com Mon Oct 12 05:20:44 2009 Return-Path: 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 E4BC13A69BE for ; Mon, 12 Oct 2009 05:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_20=-0.74, 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 ZDLie3ZjrVEQ for ; Mon, 12 Oct 2009 05:20:40 -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 E93643A6358 for ; Mon, 12 Oct 2009 05:20:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,545,1249272000"; d="scan'208,217";a="160015993" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Oct 2009 08:20:38 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Oct 2009 08:20:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4B36.664B1A9C" Date: Mon, 12 Oct 2009 14:20:34 +0200 Message-ID: In-Reply-To: <003101ca4691$50537750$f0fa65f0$@telcordia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter API draft. thread-index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBA= References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> From: "Romascanu, Dan (Dan)" To: , Subject: Re: [Dime] Diameter API draft. 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: , X-List-Received-Date: Mon, 12 Oct 2009 12:20:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B36.664B1A9C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable What does the WG want to do with the I-D? Declare it 'Dead'? Publish it as Historic RFC with a note reflecting that this was OBE (Overcome By Events)? =20 Dan =20 ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Tuesday, October 06, 2009 4:29 PM To: vfajardo@research.telcordia.com; dime@ietf.org Subject: Re: [Dime] Diameter API draft. =09 =09 Hi, =20 It's been over a month and we have not had any feedback regarding the Diameter API doc. At this point, I think it's safe to say that no one is interested in continuing this work and so we will effectively remove this doc from the charter. =20 Regards, Victor =20 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Monday, August 24, 2009 8:25 AM To: dime@ietf.org Subject: [Dime] Diameter API draft. =20 Hi Folks, =20 During the last IETF, we were trying to gauge if there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If you see value in this draft and wish to see the work continue, make sure you respond to this email as well as address the questions "why and who" would use this API. If you don't see any value in this work pls state so as well. We'll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the draft. =20 Regards, victor ------_=_NextPart_001_01CA4B36.664B1A9C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
What=20 does the WG want to do with the I-D? Declare it 'Dead'? Publish it as = Historic=20 RFC with a note reflecting that this was OBE (Overcome By=20 Events)?
 
Dan
 

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Victor=20 Fajardo
Sent: Tuesday, October 06, 2009 4:29 = PM
To:=20 vfajardo@research.telcordia.com; dime@ietf.org
Subject: Re: = [Dime]=20 Diameter API draft.

Hi,

 

It’s been = over a month and we=20 have not had any feedback regarding the Diameter API doc. At this = point, I=20 think it’s safe to say that no one is interested in continuing = this work and=20 so we will effectively remove this doc from the = charter.

 

Regards,

Victor

 

 

From:=20 dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of=20 Victor Fajardo
Sent: Monday, August 24, 2009 8:25=20 AM
To: dime@ietf.org
Subject: [Dime] Diameter API=20 draft.

 

Hi Folks,

 

During the last IETF, we were trying to gauge if = there is=20 leftover interest in continuing work with the Diameter AP=20 (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This = email is a=20 follow up to solicit a final vote/hum for this draft. If you see value = in this=20 draft and wish to see the work continue,  make sure you respond = to this=20 email as well as address the questions “why and who” would = use this API. If=20 you don’t see any value in this work pls state so as well. = We’ll give this hum=20 some time to circulate through peoples mailboxes (a month or so) after = which=20 we can decide the fate of the draft.

 

Regards,

victor

------_=_NextPart_001_01CA4B36.664B1A9C-- From gwz@net-zen.net Mon Oct 12 06:37:20 2009 Return-Path: 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 9CD3528C1E9 for ; Mon, 12 Oct 2009 06:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[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 2ahjEzA2b6Pl for ; Mon, 12 Oct 2009 06:37:16 -0700 (PDT) Received: from p3plsmtpa01-01.prod.phx3.secureserver.net (p3plsmtpa01-01.prod.phx3.secureserver.net [72.167.82.81]) by core3.amsl.com (Postfix) with SMTP id 2BA3B28C1DC for ; Mon, 12 Oct 2009 06:37:16 -0700 (PDT) Received: (qmail 13838 invoked from network); 12 Oct 2009 13:37:15 -0000 Received: from unknown (124.120.216.151) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 12 Oct 2009 13:37:13 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" , , References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> In-Reply-To: Date: Mon, 12 Oct 2009 20:37:03 +0700 Organization: Network Zen Message-ID: <023101ca4b41$187552e0$495ff8a0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0232_01CA4B7B.C4D42AE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBAAAra1QA== Content-Language: en-us Subject: Re: [Dime] Diameter API draft. 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: , X-List-Received-Date: Mon, 12 Oct 2009 13:37:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0232_01CA4B7B.C4D42AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What does the WG want to do with the I-D? Declare it 'Dead'? Publish it as Historic RFC with a note reflecting that this was OBE (Overcome By Events)? Personally, I like the latter idea. Dan _____ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Tuesday, October 06, 2009 4:29 PM To: vfajardo@research.telcordia.com; dime@ietf.org Subject: Re: [Dime] Diameter API draft. Hi, It's been over a month and we have not had any feedback regarding the Diameter API doc. At this point, I think it's safe to say that no one is interested in continuing this work and so we will effectively remove this doc from the charter. Regards, Victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Monday, August 24, 2009 8:25 AM To: dime@ietf.org Subject: [Dime] Diameter API draft. Hi Folks, During the last IETF, we were trying to gauge if there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If you see value in this draft and wish to see the work continue, make sure you respond to this email as well as address the questions "why and who" would use this API. If you don't see any value in this work pls state so as well. We'll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the draft. Regards, victor ------=_NextPart_000_0232_01CA4B7B.C4D42AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

What does the WG want to do with the I-D? Declare it 'Dead'? Publish it as Historic RFC with a note reflecting that this was OBE (Overcome By Events)?

Personally, I like the latter idea.

Dan

 

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo
Sent: Tuesday, October 06, 2009 4:29 PM
To: vfajardo@research.telcordia.com; dime@ietf.org
Subject: Re: [Dime] Diameter API draft.

Hi,

 

It’s been over = a month and we have not had any feedback regarding the Diameter API doc. At this = point, I think it’s safe to say that no one is interested in continuing = this work and so we will effectively remove this doc from the = charter.

 

Regards,

Victor

 

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Victor Fajardo
Sent: Monday, August 24, 2009 8:25 AM
To: dime@ietf.org
Subject: [Dime] Diameter API draft.

 

Hi Folks,

 

During the last IETF, we were trying to gauge if = there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This = email is a follow up to solicit a final vote/hum for this draft. If you see value = in this draft and wish to see the work continue,  make sure you respond to = this email as well as address the questions “why and who” would = use this API. If you don’t see any value in this work pls state so as well. We’ll give this hum some time to circulate through peoples = mailboxes (a month or so) after which we can decide the fate of the = draft.

 

Regards,

victor

------=_NextPart_000_0232_01CA4B7B.C4D42AE0-- From Hannes.Tschofenig@gmx.net Mon Oct 12 10:37:33 2009 Return-Path: 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 C8ED328C236 for ; Mon, 12 Oct 2009 10:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 mXdD+KZgaTPK for ; Mon, 12 Oct 2009 10:37:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 851D428C0E0 for ; Mon, 12 Oct 2009 10:37:32 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2009 17:37:30 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp008) with SMTP; 12 Oct 2009 19:37:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/NmJM7gbzNQOjMi43M8I+hl+5kWpQfrx5QGIJEsC N7rUHXdDMTUhTb From: "Hannes Tschofenig" To: "'Glen Zorn'" , "'Romascanu, Dan \(Dan\)'" , , References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> <023101ca4b41$187552e0$495ff8a0$@net> Date: Mon, 12 Oct 2009 20:40:35 +0300 Message-ID: <008a01ca4b63$1c5c0a80$03ffa8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <023101ca4b41$187552e0$495ff8a0$@net> Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBAAAra1QAAIewsg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Subject: Re: [Dime] Diameter API draft. 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: , X-List-Received-Date: Mon, 12 Oct 2009 17:37:33 -0000 Hmmm. Publishing something as historic is not particularly helpful and only wasting the time of the RFC Editor. ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn Sent: 12 October, 2009 16:37 To: 'Romascanu, Dan (Dan)'; vfajardo@research.telcordia.com; dime@ietf.org Subject: Re: [Dime] Diameter API draft. What does the WG want to do with the I-D? Declare it 'Dead'? Publish it as Historic RFC with a note reflecting that this was OBE (Overcome By Events)? Personally, I like the latter idea. Dan ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Tuesday, October 06, 2009 4:29 PM To: vfajardo@research.telcordia.com; dime@ietf.org Subject: Re: [Dime] Diameter API draft. Hi, It's been over a month and we have not had any feedback regarding the Diameter API doc. At this point, I think it's safe to say that no one is interested in continuing this work and so we will effectively remove this doc from the charter. Regards, Victor From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Monday, August 24, 2009 8:25 AM To: dime@ietf.org Subject: [Dime] Diameter API draft. Hi Folks, During the last IETF, we were trying to gauge if there is leftover interest in continuing work with the Diameter AP (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. This email is a follow up to solicit a final vote/hum for this draft. If you see value in this draft and wish to see the work continue, make sure you respond to this email as well as address the questions "why and who" would use this API. If you don't see any value in this work pls state so as well. We'll give this hum some time to circulate through peoples mailboxes (a month or so) after which we can decide the fate of the draft. Regards, victor From wwwrun@core3.amsl.com Mon Oct 12 12:59:31 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6C7873A6963; Mon, 12 Oct 2009 12:59:31 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091012195931.6C7873A6963@core3.amsl.com> Date: Mon, 12 Oct 2009 12:59:31 -0700 (PDT) Cc: Internet Architecture Board , dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Updated IANA Considerations for Diameter Command Code Allocations' to Proposed Standard 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: , X-List-Received-Date: Mon, 12 Oct 2009 19:59:31 -0000 The IESG has approved the following document: - 'Updated IANA Considerations for Diameter Command Code Allocations ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-01.txt Technical Summary The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. Working Group Summary This document is the product of the DIME working group. The extensibility rules of Diameter have been investigated by a design team and the alignment of policy for extending Diameter applications and Diameter commands has been agreed. Document Quality This document focuses on the description of the allocation policy change in the IANA consideration section and has been discussed for some time. Personnel Victor Fajardo is the document shepherd for this document. Ron Bonica is the responsible AD. RFC Editor Note Section 3 content should be modified as follows: OLD This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that fewer security reviews are conducted and hence the quality of the resulting protocol document is weaker compared to the rather extensive reviews performed in the IETF. The members of the DIME working group are aware of the tradeoff between better specification quality and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. NEW This document modifies the IANA allocation of Diameter Command Codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command codes space is split into a standards commands space and a vendor-specific command codes space, the later being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF there is always the chance that security reviews are conducted in different manner and the criteria and style of the reviews are different than the reviews performed in the IETF. The members of the DIME working group are aware of the risks involved in using different security and quality review processes and the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce. From dromasca@avaya.com Tue Oct 13 07:19:01 2009 Return-Path: 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 2FC593A6359 for ; Tue, 13 Oct 2009 07:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.639, 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 q2XIa5Q2A6Te for ; Tue, 13 Oct 2009 07:19:00 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 23E193A682B for ; Tue, 13 Oct 2009 07:19:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,551,1249272000"; d="scan'208";a="176827387" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 13 Oct 2009 10:19:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 13 Oct 2009 10:19:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 16:18:39 +0200 Message-ID: In-Reply-To: <008a01ca4b63$1c5c0a80$03ffa8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter API draft. thread-index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBAAAra1QAAIewsgACs9szA= References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> <023101ca4b41$187552e0$495ff8a0$@net> <008a01ca4b63$1c5c0a80$03ffa8c0@nsnintra.net> From: "Romascanu, Dan (Dan)" To: "Hannes Tschofenig" , "Glen Zorn" , , Subject: Re: [Dime] Diameter API draft. 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: , X-List-Received-Date: Tue, 13 Oct 2009 14:19:01 -0000 Just to clarify - the comment 'Personally, I like the latter idea' in the thread belongs to Glen.=20 I have no preference and will support whatever course the WG reaches consensus about.=20 Dan =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Monday, October 12, 2009 7:41 PM > To: 'Glen Zorn'; Romascanu, Dan (Dan);=20 > vfajardo@research.telcordia.com; dime@ietf.org > Subject: RE: [Dime] Diameter API draft. >=20 > Hmmm.=20 > =20 > Publishing something as historic is not particularly helpful=20 > and only wasting the time of the RFC Editor.=20 > =20 >=20 >=20 > ________________________________ >=20 > From: dime-bounces@ietf.org=20 > [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn > Sent: 12 October, 2009 16:37 > To: 'Romascanu, Dan (Dan)';=20 > vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. > =09 > =09 >=20 > =20 >=20 > What does the WG want to do with the I-D? Declare it=20 > 'Dead'? Publish it as Historic RFC with a note reflecting=20 > that this was OBE (Overcome By Events)? >=20 > Personally, I like the latter idea. >=20 > Dan >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Tuesday, October 06, 2009 4:29 PM > To: vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. >=20 > Hi, >=20 > =20 >=20 > It's been over a month and we have not had any=20 > feedback regarding the Diameter API doc. At this point, I=20 > think it's safe to say that no one is interested in=20 > continuing this work and so we will effectively remove this=20 > doc from the charter. >=20 > =20 >=20 > Regards, >=20 > Victor >=20 > =20 >=20 > =20 >=20 > From: dime-bounces@ietf.org=20 > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Monday, August 24, 2009 8:25 AM > To: dime@ietf.org > Subject: [Dime] Diameter API draft. >=20 > =20 >=20 > Hi Folks, >=20 > =20 >=20 > During the last IETF, we were trying to gauge=20 > if there is leftover interest in continuing work with the=20 > Diameter AP=20 > (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. > This email is a follow up to solicit a final vote/hum for=20 > this draft. If you see value in this draft and wish to see=20 > the work continue, make sure you respond to this email as=20 > well as address the questions "why and who" would use this=20 > API. If you don't see any value in this work pls state so as=20 > well. We'll give this hum some time to circulate through=20 > peoples mailboxes (a month or so) after which we can decide=20 > the fate of the draft. >=20 > =20 >=20 > Regards, >=20 > victor >=20 >=20 >=20 From vfajardo@research.telcordia.com Tue Oct 13 07:24:31 2009 Return-Path: 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 D53AE28C11B for ; Tue, 13 Oct 2009 07:24: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=[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 18aIuGO1brFD for ; Tue, 13 Oct 2009 07:24:31 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id D97D528C10A for ; Tue, 13 Oct 2009 07:24:30 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n9DEON35011259; Tue, 13 Oct 2009 10:24:23 -0400 (EDT) From: "Victor Fajardo" To: "'Romascanu, Dan \(Dan\)'" , "'Hannes Tschofenig'" , "'Glen Zorn'" , References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> <023101ca4b41$187552e0$495ff8a0$@net> <008a01ca4b63$1c5c0a80$03ffa8c0@nsnintra.net> In-Reply-To: Date: Tue, 13 Oct 2009 10:24:24 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <004101ca4c10$dd085920$97190b60$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBAAAra1QAAIewsgACs9szAAADf+0A== Content-Language: en-us Subject: Re: [Dime] Diameter API draft. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:24:31 -0000 Hi Dan, My vote is to declare the draft as 'dead'. Regards, victor -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, October 13, 2009 10:19 AM To: Hannes Tschofenig; Glen Zorn; vfajardo@research.telcordia.com; dime@ietf.org Subject: RE: [Dime] Diameter API draft. Just to clarify - the comment 'Personally, I like the latter idea' in the thread belongs to Glen. I have no preference and will support whatever course the WG reaches consensus about. Dan > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, October 12, 2009 7:41 PM > To: 'Glen Zorn'; Romascanu, Dan (Dan); > vfajardo@research.telcordia.com; dime@ietf.org > Subject: RE: [Dime] Diameter API draft. > > Hmmm. > > Publishing something as historic is not particularly helpful > and only wasting the time of the RFC Editor. > > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn > Sent: 12 October, 2009 16:37 > To: 'Romascanu, Dan (Dan)'; > vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. > > > > > > What does the WG want to do with the I-D? Declare it > 'Dead'? Publish it as Historic RFC with a note reflecting > that this was OBE (Overcome By Events)? > > Personally, I like the latter idea. > > Dan > > > > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Tuesday, October 06, 2009 4:29 PM > To: vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. > > Hi, > > > > It's been over a month and we have not had any > feedback regarding the Diameter API doc. At this point, I > think it's safe to say that no one is interested in > continuing this work and so we will effectively remove this > doc from the charter. > > > > Regards, > > Victor > > > > > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Monday, August 24, 2009 8:25 AM > To: dime@ietf.org > Subject: [Dime] Diameter API draft. > > > > Hi Folks, > > > > During the last IETF, we were trying to gauge > if there is leftover interest in continuing work with the > Diameter AP > (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. > This email is a follow up to solicit a final vote/hum for > this draft. If you see value in this draft and wish to see > the work continue, make sure you respond to this email as > well as address the questions "why and who" would use this > API. If you don't see any value in this work pls state so as > well. We'll give this hum some time to circulate through > peoples mailboxes (a month or so) after which we can decide > the fate of the draft. > > > > Regards, > > victor > > > From sdecugis@nict.go.jp Wed Oct 14 22:44:50 2009 Return-Path: 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 79B9C3A6844 for ; Wed, 14 Oct 2009 22:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.844 X-Spam-Level: X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_SOMA2=2.199, HELO_EQ_JP=1.244] 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 bRA3p0qDLQBM for ; Wed, 14 Oct 2009 22:44:49 -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 ED5483A67DF for ; Wed, 14 Oct 2009 22:44:48 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n9F5in0i013027; Thu, 15 Oct 2009 14:44:49 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n9F5inrf014326; Thu, 15 Oct 2009 14:44:49 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n9F5ineN014323; Thu, 15 Oct 2009 14:44:49 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id B2D522C350; Thu, 15 Oct 2009 14:44:49 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail3.nict.go.jp (NICT Mail) with ESMTP id AD0B02C343; Thu, 15 Oct 2009 14:44:49 +0900 (JST) Message-ID: <4AD6B6C4.3080205@nict.go.jp> Date: Thu, 15 Oct 2009 14:44:36 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Glen Zorn References: <018101ca24ba$01834ea0$0489ebe0$@telcordia.com> <02f201ca255e$11533620$260ca40a@china.huawei.com> <4A94F0EF.3080102@nict.go.jp> <002301ca2756$78339e80$689adb80$@net> <4A9743F4.60404@nict.go.jp> <008001ca2a5f$f4026da0$dc0748e0$@net> <4A9C7FC4.4030903@nict.go.jp> <014a01ca4a51$571daf10$05590d30$@net> In-Reply-To: <014a01ca4a51$571daf10$05590d30$@net> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] RE: [DIME] Comments about AVP for crypto key transport draft 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: , X-List-Received-Date: Thu, 15 Oct 2009 05:44:50 -0000 Hi, Glen Zorn a écrit : > Logically, however, I fail to > see any reason why an agent (with the exception of the ERP server, if you > wish to call it an agent) should look inside any AVP containing a key, since > by definition the AVP is not any of its business. > Well, I think this is a good argument in favor of having a different AVP code for different keys... So that the agent (example: ERP server) will only look inside the AVPs it has business with, and not other potential keys (such as rMSK). As far as the "security issue" I think this only concerns the nodes with bad intentions -- if nobody was ill-intended, we would not need security nor keys in the first place -- so assuming that the agent will not look into the message because it is none of its business seems quite light security to me ^^. >> If the NAS does not support the new container and receives a DEA with >> the MSK key in this container, it will fail to establish the session >> with the peer. (basically, the new container will have its 'M' flag >> set, >> and the NAS will not recognize it). >> Therefore, the server has to either: >> - have a configuration parameter for each NAS, telling if the new >> container can be used or not. >> - start using the new container only after all NAS (in the world?) have >> been upgraded to support the new container. >> > > We are defining the Diameter ERP application & we can state that the 'M' bit > is set for the new container. > OK for transporting a (r)MSK in a Diameter ERP message, but I was talking about the existing messages (NASREQ and Diameter EAP). I think we may lead to an interoperability issue if we create a new container for the same thing (MSK) in the same message... Bests, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Wed Oct 14 23:34:34 2009 Return-Path: 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 334F53A6890 for ; Wed, 14 Oct 2009 23:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.952 X-Spam-Level: X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_40=-0.185, HELO_EQ_JP=1.244] 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 UqrzZCq0HGpo for ; Wed, 14 Oct 2009 23:34:33 -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 CBD683A6841 for ; Wed, 14 Oct 2009 23:34:32 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n9F6YY9D024220 for ; Thu, 15 Oct 2009 15:34:34 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n9F6YYhV005239 for ; Thu, 15 Oct 2009 15:34:34 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n9F6YYwo005236 for ; Thu, 15 Oct 2009 15:34:34 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 5BB742C4CE for ; Thu, 15 Oct 2009 15:34:34 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 560E52C4CD for ; Thu, 15 Oct 2009 15:34:34 +0900 (JST) Message-ID: <4AD6C26C.90902@nict.go.jp> Date: Thu, 15 Oct 2009 15:34:20 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Diameter ERP 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: , X-List-Received-Date: Thu, 15 Oct 2009 06:34:34 -0000 Hello DIME members, FYI, draft-ietf-dime-erp-02.txt has been published. It is a small update from previous version, and does not contain new ideas. As a reminder, some issues are still pending on this document and your comments would be appreciated. See section 10 of the document for more details on the following issues: - do we use Diameter ERP (alone) to support re-authentication of the peer after a handover, or do we mandate the use of a mobility application (such as MIP6) in that case -- this mobility application could use Diameter ERP as an optimization. - in case the home domain contains several EAP servers, how does ERP mechanism find the one that possess the EMSK for a given peer ? We are looking forward to your comments... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Thu Oct 15 19:10:58 2009 Return-Path: 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 AC51B3A6807 for ; Thu, 15 Oct 2009 19:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_20=-0.74] 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 XZvc9vSyq+vr for ; Thu, 15 Oct 2009 19:10:57 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 85D0A3A67EA for ; Thu, 15 Oct 2009 19:10:57 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL00MVF4QBOH@szxga01-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 10:10:59 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL006US4QB2U@szxga01-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 10:10:59 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRL0045E4QBOC@szxml06-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 10:10:59 +0800 (CST) Date: Fri, 16 Oct 2009 10:10:58 +0800 From: Qin Wu To: Sebastien Decugis , dime@ietf.org Message-id: <00c301ca4e05$e73ce090$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4AD6C26C.90902@nict.go.jp> Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Fri, 16 Oct 2009 02:10:58 -0000 Hi, Sebastien and all: ----- Original Message ----- From: "Sebastien Decugis" To: Sent: Thursday, October 15, 2009 2:34 PM Subject: [Dime] Diameter ERP > Hello DIME members, > > FYI, draft-ietf-dime-erp-02.txt has been published. It is a small update > from previous version, and does not contain new ideas. > > As a reminder, some issues are still pending on this document and your > comments would be appreciated. See section 10 of the document for more > details on the following issues: > > - do we use Diameter ERP (alone) to support re-authentication of the > peer after a handover, or do we mandate the use of a mobility > application (such as MIP6) in that case -- this mobility application > could use Diameter ERP as an optimization. [Qin]: In my understanding, Diameter ERP is not mobility protocol but can reuse the similar mechanism specified in the mobility application, e.g., Diameter user session mangement ,as described in the section 4.1 of RFC4004, the different sessions can be correlated with the Acct-Multi-Session-Id AVP like. Therefore the similar mechanism(i.e.,user Session correlation) can also be adopted, i.e., each time the peer moves to the new NAS, the session-Id created from the new NAS will be correlated with the user name or Acct-Multi-Session-Id corresponding to this given peer. > - in case the home domain contains several EAP servers, how does ERP > mechanism find the one that possess the EMSK for a given peer ? [Qin]: Isn't EMSKname used to distinguish different EAP servers in the same home domain? If EMSKname can not be used to do this, I think ERP/DER messages can be advertised to all the EAP servers in the home domain, the first EAP server who responds will be viewed as the EAP server that possess the EMSK for a given peer. Is it right? > We are looking forward to your comments... > > Best regards, > Sebastien. > > -- > 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 julien.bournelle@gmail.com Thu Oct 15 19:15:14 2009 Return-Path: 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 99C4228C1CF for ; Thu, 15 Oct 2009 19:15:14 -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 UHfqVWzzQKAi for ; Thu, 15 Oct 2009 19:15:13 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 584F928C1B9 for ; Thu, 15 Oct 2009 19:15:13 -0700 (PDT) Received: by ewy4 with SMTP id 4so1185361ewy.37 for ; Thu, 15 Oct 2009 19:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rULSQeV9QlXmw6lT/qBMOjZvK7MYqzX5Z6mR7aEZiOk=; b=VfxIxpWp7rO0ATxXz9cOT0J1sTKm0Shy0qR2WP3lbzuMNb+S5CMO8/YMr4caR/NU3D ixqwEXMrAaT0ox1cc8pWTp95aqyMJsTht13lizmfq0c29R70VCrC3G5BYtvav3qNjGNk nQwMjEtOIxVDyI7gGUDTDmcAn591mIdLmd6/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eVAGfs3nte6sA5LzdtNZ89c09wMlCYTdtXa2KzZHSJub0qdl56VkAQWsuXkknBM37M Xv89uCGbShSiJXxbx0XF7gHmNasned7W7OPH4/gFj2mnusoeQo5fDtzjm5FxYVmSKszd x0DarShKUm3of5nkYeTAPAxkOepsr+42B+i0Y= MIME-Version: 1.0 Received: by 10.216.88.8 with SMTP id z8mr428396wee.109.1255659313384; Thu, 15 Oct 2009 19:15:13 -0700 (PDT) In-Reply-To: <4AD6C26C.90902@nict.go.jp> References: <4AD6C26C.90902@nict.go.jp> Date: Fri, 16 Oct 2009 04:15:13 +0200 Message-ID: <5e2406980910151915j4e834864o7614dcfcd91286c0@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e6d96d20554c4a047603f7dd Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Fri, 16 Oct 2009 02:15:14 -0000 --0016e6d96d20554c4a047603f7dd Content-Type: text/plain; charset=ISO-8859-1 Hello, On Thu, Oct 15, 2009 at 8:34 AM, Sebastien Decugis wrote: > Hello DIME members, > > FYI, draft-ietf-dime-erp-02.txt has been published. It is a small update > from previous version, and does not contain new ideas. > > As a reminder, some issues are still pending on this document and your > comments would be appreciated. See section 10 of the document for more > details on the following issues: > > - do we use Diameter ERP (alone) to support re-authentication of the > peer after a handover, or do we mandate the use of a mobility > application (such as MIP6) in that case -- this mobility application > could use Diameter ERP as an optimization. > What do you mean by a Mobility Application ? Regards, Julien > - in case the home domain contains several EAP servers, how does ERP > mechanism find the one that possess the EMSK for a given peer ? > > We are looking forward to your comments... > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016e6d96d20554c4a047603f7dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Oct 15, 2009 at 8:34 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:
Hello DIME members,

FYI, draft-ietf-dime-erp-02.txt has been published. It is a small update from previous version, and does not contain new ideas.

As a reminder, some issues are still pending on this document and your
comments would be appreciated. See section 10 of the document for more
details on the following issues:

- do we use Diameter ERP (alone) to support re-authentication of the
peer after a handover, or do we mandate the use of a mobility
application (such as MIP6) in that case -- this mobility application
could use Diameter ERP as an optimization.

<= div>
What do you mean by a Mobility Application ?
<= br>
=A0Regards,

=A0Julien
=A0<= /div>


- in case the home domain contains several EAP servers, how does ERP
mechanism find the one that possess the EMSK for a given peer ?

We are looking forward to your comments...

Best regards,
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--0016e6d96d20554c4a047603f7dd-- From sdecugis@nict.go.jp Thu Oct 15 19:24:02 2009 Return-Path: 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 8F2323A6810 for ; Thu, 15 Oct 2009 19:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=1.153, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 cTzekrOa3bRn for ; Thu, 15 Oct 2009 19:24:01 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 097D93A67E6 for ; Thu, 15 Oct 2009 19:24:00 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n9G2O1Tp005435; Fri, 16 Oct 2009 11:24:01 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n9G2O11r021035; Fri, 16 Oct 2009 11:24:01 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n9G2O19W021032; Fri, 16 Oct 2009 11:24:01 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 764592C54D; Fri, 16 Oct 2009 11:24:01 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 70A8B2C54B; Fri, 16 Oct 2009 11:24:01 +0900 (JST) Message-ID: <4AD7D935.5020700@nict.go.jp> Date: Fri, 16 Oct 2009 11:23:49 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Julien Bournelle References: <4AD6C26C.90902@nict.go.jp> <5e2406980910151915j4e834864o7614dcfcd91286c0@mail.gmail.com> In-Reply-To: <5e2406980910151915j4e834864o7614dcfcd91286c0@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Fri, 16 Oct 2009 02:24:02 -0000 Hi Julien, > What do you mean by a Mobility Application ? You are right, sorry for the lack of explanation. I mean an application that was *designed* for supporting peers attaching to different NAS during the lifetime of a session, and therefore already provides mechanisms for accounting records correlation, monitoring of the location of the peer at any time (for reachability by the home server), and this kind of mechanisms. In case we opt for the alternative choice, i.e. managing the handovers with Diameter ERP alone, we will have to provide this kind of mechanisms. Hope this clarifies, Best regards, Sebastien. > > Regards, > > Julien > > > > - in case the home domain contains several EAP servers, how does ERP > mechanism find the one that possess the EMSK for a given peer ? > > We are looking forward to your comments... > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp ) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Thu Oct 15 20:10:21 2009 Return-Path: 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 A26233A6952 for ; Thu, 15 Oct 2009 20:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 Kanuh7lMb3Ng for ; Thu, 15 Oct 2009 20:10:20 -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 3A9423A67BE for ; Thu, 15 Oct 2009 20:10:19 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n9G3AHrS018810; Fri, 16 Oct 2009 12:10:17 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n9G3AHt9013685; Fri, 16 Oct 2009 12:10:17 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n9G3AHmC013682; Fri, 16 Oct 2009 12:10:17 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 85E952C4F5; Fri, 16 Oct 2009 12:10:17 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 803DC2C545; Fri, 16 Oct 2009 12:10:17 +0900 (JST) Message-ID: <4AD7E40D.7090202@nict.go.jp> Date: Fri, 16 Oct 2009 12:10:05 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <4AD6C26C.90902@nict.go.jp> <00c301ca4e05$e73ce090$260ca40a@china.huawei.com> In-Reply-To: <00c301ca4e05$e73ce090$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Fri, 16 Oct 2009 03:10:21 -0000 Hi Qin, all, Thank you for your comments. Please see my answers inline. >> - do we use Diameter ERP (alone) to support re-authentication of the >> peer after a handover, or do we mandate the use of a mobility >> application (such as MIP6) in that case -- this mobility application >> could use Diameter ERP as an optimization. >> > > [Qin]: In my understanding, Diameter ERP is not mobility protocol but can reuse the similar mechanism specified in the mobility application, e.g., Diameter user session mangement ,as described in the section 4.1 of RFC4004, the different sessions can be correlated with the Acct-Multi-Session-Id AVP like. > > Therefore the similar mechanism(i.e.,user Session correlation) can also be adopted, i.e., each time the peer moves to the new NAS, the session-Id created from the new NAS will be correlated with the user name or Acct-Multi-Session-Id corresponding to this given peer. > Ok, so you are suggesting that we should "copy" the mechanism from RFC4004 in Diameter ERP, is that right ? In that case are we assuming that the (mobile) peer is not using a mobility protocol, and just achieving re-authentication but apart from this it is equivalent to a plain EAP authentication? What happens if the peer is using a mobility protocol (which seems reasonable for a mobile peer) ? Is there no conflict or at least duplicates between the ERP and the MIP applications in that case? >> - in case the home domain contains several EAP servers, how does ERP >> mechanism find the one that possess the EMSK for a given peer ? >> > > [Qin]: Isn't EMSKname used to distinguish different EAP servers in the same home domain? > Not that I know of... The EMSKname is made of a plain hashed value (no indication of server) and the domain name. If we want to use the EMSKname for routing, I think we would need a central entity that collects all EMSK (at least EMSKnames) from all EAP servers in the realm, and routes the messages to the correct servers. > If EMSKname can not be used to do this, I think ERP/DER messages can be advertised to all the EAP > servers in the home domain, the first EAP server who responds will be viewed as the EAP server that > possess the EMSK for a given peer. Is it right? > There is no broadcast mechanism in Diameter (afaik), and going through all the servers in sequence seems not efficient to me. I believe a solution is to store the information about the server (that is known during the initial EAP exchange) and then use this information when ERP is started. But I am not sure in which location the information should be stored, NAS or ER server... Thank you for proposing a solution anyway :) I hope other people can also suggest different approaches, or at least comment on the already proposed ones. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From b.swamy@aricent.com Thu Oct 15 22:46:07 2009 Return-Path: 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 7F8E93A6783 for ; Thu, 15 Oct 2009 22:46:07 -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_56=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 aPlDOkNAth+J for ; Thu, 15 Oct 2009 22:46:06 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 8946F28C136 for ; Thu, 15 Oct 2009 22:46:06 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 7C2CD2364E for ; Fri, 16 Oct 2009 11:14:18 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 66AD223649 for ; Fri, 16 Oct 2009 11:14:18 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Fri, 16 Oct 2009 11:16:08 +0530 From: B Venkat S R Swamy To: "dime@ietf.org" Date: Fri, 16 Oct 2009 11:16:18 +0530 Thread-Topic: Decorated NAI handling at Diameter Agents Thread-Index: AcpNyi6ggltJ2cXVTxioCJOmn6FmwwAWPd+g Message-ID: <079B6109FD98AD488574FF3191B508BE017386EEAB@GUREXMB01.ASIAN.AD.ARICENT.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Dime] Decorated NAI handling at Diameter Agents 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: , X-List-Received-Date: Fri, 16 Oct 2009 05:46:07 -0000 Hi Need a small clarification whether the procedures defined in draft-ietf-dim= e-nai-routing-04.txt for handling the decorated NAI is applicable to Diamet= er Proxy only or it can be applied on Redirect/Relay nodes also. regards Venkat "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." From w52006@huawei.com Thu Oct 15 23:58:21 2009 Return-Path: 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 215E23A6A1B for ; Thu, 15 Oct 2009 23:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 H5ySuFN-qnKw for ; Thu, 15 Oct 2009 23:58:20 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 024EC3A684F for ; Thu, 15 Oct 2009 23:58:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL009ZHHXK1A@szxga03-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 14:56:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRL002HCHXKZX@szxga03-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 14:56:08 +0800 (CST) Received: from w52006e ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRL00C5JHXGCR@szxml06-in.huawei.com> for dime@ietf.org; Fri, 16 Oct 2009 14:56:08 +0800 (CST) Date: Fri, 16 Oct 2009 14:56:04 +0800 From: w52006 In-reply-to: <4AD7D935.5020700@nict.go.jp> To: 'Sebastien Decugis' , 'Julien Bournelle' Message-id: <027a01ca4e2d$bac2e4b0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpOB8KY4Njzn7BxTZaI6PJNaUcB0AAHwFig Cc: dime@ietf.org Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Fri, 16 Oct 2009 06:58:21 -0000 Hello all It seems the issue is involved in Diameter ERP application only. I don't think it needs to be expanded to other application or new application. As we know, in ERP framework, the re-authentication session terminated by the ER server is de-coupled from the authentication session terminated by the home server. Do you want to re-couple them implicitly with the Diameter ERP application and 'new mobility application'? In my mind, the issue can be resolved by the Diameter enities for the Diameter ERP application. That's, the on-path Diameter peer collocated with the ER server may be possible to do these works instead of the home server, e.g. accounting records correlation, monitoring of the location of the peer. For implementation, i.e., it could establish the association between the authentication session and the re-authentication session which are oriented from the home server and the up-to-date NAS respectively. B.R. Yungui > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Sebastien Decugis > Sent: Friday, October 16, 2009 10:24 AM > To: Julien Bournelle > Cc: dime@ietf.org > Subject: Re: [Dime] Diameter ERP > > Hi Julien, > > > What do you mean by a Mobility Application ? > You are right, sorry for the lack of explanation. I mean an > application > that was *designed* for supporting peers attaching to different NAS > during the lifetime of a session, and therefore already provides > mechanisms for accounting records correlation, monitoring of the > location of the peer at any time (for reachability by the > home server), > and this kind of mechanisms. In case we opt for the > alternative choice, > i.e. managing the handovers with Diameter ERP alone, we will have to > provide this kind of mechanisms. > > Hope this clarifies, > Best regards, > Sebastien. > > > > > Regards, > > > > Julien > > > > > > > > - in case the home domain contains several EAP servers, > how does ERP > > mechanism find the one that possess the EMSK for a given peer ? > > > > We are looking forward to your comments... > > > > Best regards, > > Sebastien. > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp ) > > > > _______________________________________________ > > 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 sunseawq@huawei.com Wed Oct 21 02:11:11 2009 Return-Path: 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 2BC573A68DA for ; Wed, 21 Oct 2009 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 fmgkX4BhbuLT for ; Wed, 21 Oct 2009 02:11:10 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D94613A6883 for ; Wed, 21 Oct 2009 02:11:09 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU007JXXIJYW@szxga01-in.huawei.com> for dime@ietf.org; Wed, 21 Oct 2009 17:11:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU0056KXIJEA@szxga01-in.huawei.com> for dime@ietf.org; Wed, 21 Oct 2009 17:11:07 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00HGJXIHR9@szxml04-in.huawei.com> for dime@ietf.org; Wed, 21 Oct 2009 17:11:06 +0800 (CST) Date: Wed, 21 Oct 2009 17:11:05 +0800 From: Qin Wu To: Sebastien Decugis Message-id: <026901ca522e$6b9bb420$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4AD6C26C.90902@nict.go.jp> <00c301ca4e05$e73ce090$260ca40a@china.huawei.com> <4AD7E40D.7090202@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Wed, 21 Oct 2009 09:11:11 -0000 Hi, Sebastien: ----- Original Message ----- From: "Sebastien Decugis" To: "Qin Wu" Cc: Sent: Friday, October 16, 2009 11:10 AM Subject: Re: [Dime] Diameter ERP > Hi Qin, all, > > Thank you for your comments. Please see my answers inline. > >>> - do we use Diameter ERP (alone) to support re-authentication of the >>> peer after a handover, or do we mandate the use of a mobility >>> application (such as MIP6) in that case -- this mobility application >>> could use Diameter ERP as an optimization. >>> >> >> [Qin]: In my understanding, Diameter ERP is not mobility protocol but can reuse the similar mechanism specified in the mobility application, e.g., Diameter user session mangement ,as described in the section 4.1 of RFC4004, the different sessions can be correlated with the Acct-Multi-Session-Id AVP like. >> >> Therefore the similar mechanism(i.e.,user Session correlation) can also be adopted, i.e., each time the peer moves to the new NAS, the session-Id created from the new NAS will be correlated with the user name or Acct-Multi-Session-Id corresponding to this given peer. >> > Ok, so you are suggesting that we should "copy" the mechanism from > RFC4004 in Diameter ERP, is that right ? In that case are we assuming > that the (mobile) peer is not using a mobility protocol, and just > achieving re-authentication but apart from this it is equivalent to a > plain EAP authentication? What happens if the peer is using a mobility > protocol (which seems reasonable for a mobile peer) ? Is there no > conflict or at least duplicates between the ERP and the MIP applications > in that case? [Qin]: In the RFC4004, the Diameter user session and the Layer 3 mobility session associated with MIP application are not the same thing, and ERP may borrow the similar mechanism as user session management described in the RFC 4004, therefore there is no conflict between ERP and the MIP application. >>> - in case the home domain contains several EAP servers, how does ERP >>> mechanism find the one that possess the EMSK for a given peer ? >>> >> >> [Qin]: Isn't EMSKname used to distinguish different EAP servers in the same home domain? >> > Not that I know of... The EMSKname is made of a plain hashed value (no > indication of server) and the domain name. If we want to use the > EMSKname for routing, I think we would need a central entity that > collects all EMSK (at least EMSKnames) from all EAP servers in the > realm, and routes the messages to the correct servers. [Qin]: It seems not efficient way for message routing. How about Redirection mechanism, i.e., one EAP server possessing no EMSK can redirect the message to the EAP server possessing EMSK. It seems more efficient than the way you suggest. >> If EMSKname can not be used to do this, I think ERP/DER messages can be advertised to all the EAP >> servers in the home domain, the first EAP server who responds will be viewed as the EAP server that >> possess the EMSK for a given peer. Is it right? >> > There is no broadcast mechanism in Diameter (afaik), and going through > all the servers in sequence seems not efficient to me. [Qin]: I agree. > I believe a solution is to store the information about the server (that > is known during the initial EAP exchange) and then use this information > when ERP is started. But I am not sure in which location the information > should be stored, NAS or ER server... [Qin]: What I prefer is the information can be downloaded at the NAS. And then the peer can obtain this information directly or indirectly from the NAS. > Thank you for proposing a solution anyway :) I hope other people can > also suggest different approaches, or at least comment on the already > proposed ones. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > From sdecugis@nict.go.jp Wed Oct 21 02:41:14 2009 Return-Path: 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 C3CC13A68C5 for ; Wed, 21 Oct 2009 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_JP=1.244] 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 u4jdpW1jYY3r for ; Wed, 21 Oct 2009 02:41:14 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id 432153A69E1 for ; Wed, 21 Oct 2009 02:41:12 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n9L9ewQu023131; Wed, 21 Oct 2009 18:40:58 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n9L9ewbL003505; Wed, 21 Oct 2009 18:40:58 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n9L9ewqn003502; Wed, 21 Oct 2009 18:40:58 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 2B7A02C4BA; Wed, 21 Oct 2009 18:40:58 +0900 (JST) Received: from [133.243.146.206] (5gou2f-dhcp46.nict.go.jp [133.243.146.206]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 25B732C488; Wed, 21 Oct 2009 18:40:58 +0900 (JST) Message-ID: <4ADED723.20707@nict.go.jp> Date: Wed, 21 Oct 2009 18:40:51 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <4AD6C26C.90902@nict.go.jp> <00c301ca4e05$e73ce090$260ca40a@china.huawei.com> <4AD7E40D.7090202@nict.go.jp> <026901ca522e$6b9bb420$260ca40a@china.huawei.com> In-Reply-To: <026901ca522e$6b9bb420$260ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] Diameter ERP 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: , X-List-Received-Date: Wed, 21 Oct 2009 09:41:14 -0000 Hi Qin, all, > [Qin]: In the RFC4004, the Diameter user session and the Layer 3 mobility session associated > with MIP application are not the same thing, and ERP may borrow the similar mechanism as > user session management described in the RFC 4004, therefore there is no conflict between ERP > and the MIP application. > As I told before, I am not familiar with Diameter mobility applications, so I don't know what we can/cannot do in Diameter ERP and which conflicts we are exposing. I will have to read in depth the RFC4004 before I can really answer on this topic. In the meantime, it would be interesting to hear from others who are familiar with Diameter MIP6 for example ^^. > [Qin]: It seems not efficient way for message routing. How about Redirection mechanism, i.e., > one EAP server possessing no EMSK can redirect the message to the EAP server possessing EMSK. > It seems more efficient than the way you suggest. > Agreed, but how does this server that does not have the EMSK learn which server has it, to give the correct redirect indication ? >> I believe a solution is to store the information about the server (that >> is known during the initial EAP exchange) and then use this information >> when ERP is started. But I am not sure in which location the information >> should be stored, NAS or ER server... >> > > [Qin]: What I prefer is the information can be downloaded at the NAS. And then > the peer can obtain this information directly or indirectly from the NAS. > The peer does not need this information, only the NAS does. I agree that keeping the information in the NAS is the easy and efficient solution, but it does not work if we plan to support handovers :-) Hence the issue... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From Mark.Jones@bridgewatersystems.com Wed Oct 21 13:16:22 2009 Return-Path: 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 7F09528C13F; Wed, 21 Oct 2009 13:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 uUm8HVNXD1cu; Wed, 21 Oct 2009 13:16:21 -0700 (PDT) Received: from bean.electric.net (bean.electric.net [72.35.23.29]) by core3.amsl.com (Postfix) with ESMTP id 245AF28C113; Wed, 21 Oct 2009 13:16:17 -0700 (PDT) Received: from 1N0hbd-0001zk-TU by bean.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1N0hbd-00025w-Vc; Wed, 21 Oct 2009 13:16:25 -0700 Received: by emcmailer; Wed, 21 Oct 2009 13:16:25 -0700 Received: from [72.35.6.119] (helo=webmail.bridgewatersystems.com) by bean.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1N0hbd-0001zk-TU; Wed, 21 Oct 2009 13:16:25 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 21 Oct 2009 16:16:25 -0400 From: Mark Jones To: "dime@ietf.org" , "iesg@ietf.org" Date: Wed, 21 Oct 2009 16:16:20 -0400 Thread-Topic: draft-ietf-dime-qos-attributes: DISCUSS/Comments addressed in rev 13 Thread-Index: AcpSi1qysGpnVRZiQHKsCMHC+hzvnw== Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822DEA@m679t05.fpmis.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 781633 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Subject: [Dime] draft-ietf-dime-qos-attributes: DISCUSS/Comments addressed in rev 13 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: , X-List-Received-Date: Wed, 21 Oct 2009 20:16:22 -0000 I'm working on the next rev of the DIME QoS Attributes draft and just notic= ed that I neglected to send the description of the changes made for the pre= vious revision (-13).=20 Assuming better late than never, here is the summary of the IESG DISCUSS an= d comments addressed in rev 13 published on July 13th: + Amanda Babar (IANA), Tue.June 16th - TCP-Flag-Type: Fixed in rev 13. - Questions answered and actions confirmed on Wed. June 17th + Lothar Reith, Sun. June 21st - Issue1: QoS-Resources description. Fixed in rev 13. - Issue 2: Not an issue. Replied Tue, June 30th. - Issue 3: Charging granularity. Fixed in rev 13. - Issue 4: Not an issue. Replied Tue, June 30th. - Issue 5: Improve QoS-Semantic desc. Replied Tue, June 30th. Fix needed. . Replied with text on Mon, Aug 10th. To be fixed in rev 14 - Issue 6: Rework DCCA example. Replied Tue, June 30th. Fix needed. . Replied Mon, Aug 10th. To be fixed in rev 14 - Issue 7: DCCA Typo. Replied Tue, June 30th.=20 . Obsolete with DCCA example reworking. - Issue 8: Rework DCCA example. Replied Tue, June 30th. Fix needed. . Replied Mon, Aug 10th. To be fixed in rev 14 + Gonzalo Camarille, Wed. June 24th - Expand AVP and ABNF acronyms in Abstract. . To be fixed in rev 14. - Remove reference to RFC4005 from Abstract . To be fixed in rev 14. + Ralph Droms, Mon Jun 29th - Typos fixed in rev 13. Replied on Tue, June 30th. + Lars Eggert, Wed Jul 1st - DISCUSS-DISCUSS: Why TCP Options? Avi replied on Aug 7th. - DISCUSS: Firewall functionality. Fixed in rev 13. - Comment: Ports context within transport protocol. Fixed in rev 13. =09 * Adrian Farrel, Wed Jul 1st - Comment: Figure 1 and 5 alignment issues. Fixed in rev 13. - Comment: Section 5 action wording. Fixed in rev 13. - Comment: Identify IANA registries. Fixed in rev 13. =09 * Magnus Westerlund, Thu July 2nd . Replied on Mon July 13th - Discuss: Normative ref to formal language (notation). Fixed in rev 13. - Discuss: 4.1.7.2 Missing ref to imported definitions. Fixed in rev 13. - Discuss: 5.1 Missing info necessary for actions. Not an issue. - Discuss: 10.1 Missing registries. Fixed in rev 13. - Discuss: 10.2/10.3 Clarify new registry. Fixed in rev 13. Stay tuned for rev 14. Coming soon. ;) Regards Mark From root@core3.amsl.com Thu Oct 22 12:00:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A7B23A69A3; Thu, 22 Oct 2009 12: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: <20091022190001.4A7B23A69A3@core3.amsl.com> Date: Thu, 22 Oct 2009 12:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-12.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: , X-List-Received-Date: Thu, 22 Oct 2009 19:00:01 -0000 --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 Quality of Service Application Author(s) : M. Hill, et al. Filename : draft-ietf-dime-diameter-qos-12.txt Pages : 57 Date : 2009-10-22 This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-12.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-diameter-qos-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22115605.I-D@ietf.org> --NextPart-- From Mark.Jones@bridgewatersystems.com Fri Oct 23 06:11:08 2009 Return-Path: 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 234EF3A6875; Fri, 23 Oct 2009 06:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 RA1XmUdjAUb3; Fri, 23 Oct 2009 06:11:06 -0700 (PDT) Received: from worden.electric.net (worden.electric.net [72.35.23.25]) by core3.amsl.com (Postfix) with ESMTP id BE1EB3A67E9; Fri, 23 Oct 2009 06:11:06 -0700 (PDT) Received: from 1N1JvI-0002bQ-Ui by worden.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1N1JvI-0002bq-Vm; Fri, 23 Oct 2009 06:11:16 -0700 Received: by emcmailer; Fri, 23 Oct 2009 06:11:16 -0700 Received: from [72.35.6.119] (helo=webmail.bridgewatersystems.com) by worden.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1N1JvI-0002bQ-Ui; Fri, 23 Oct 2009 06:11:16 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Fri, 23 Oct 2009 09:11:16 -0400 From: Mark Jones To: "dime@ietf.org" , "iesg@ietf.org" Date: Fri, 23 Oct 2009 09:11:11 -0400 Thread-Topic: draft-ietf-dime-qos-attributes: DISCUSS/Comments addressed in rev 14 Thread-Index: AcpT4ksC3EEdNPXHRnavn2uquUsrsQ== Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822E7B@m679t05.fpmis.bridgewatersys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 781633 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Subject: [Dime] draft-ietf-dime-qos-attributes: DISCUSS/Comments addressed in rev 14 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: , X-List-Received-Date: Fri, 23 Oct 2009 13:11:08 -0000 Here is the summary of the IESG DISCUSS and comments addressed in rev 14 pu= blished today. + Lothar Reith, Sun. June 21st - Issue 6: Rework DCCA example. Replied Tue, June 30th. Fix needed. . Proposed text Mon, Aug 10th. Fixed in rev 14 - Issue 7: DCCA Typo. Replied Tue, June 30th.=20 . Obsolete with DCCA example reworking. - Issue 8: Rework DCCA example. Replied Tue, June 30th. Fix needed. . Proposed text Mon, Aug 10th. Fixed in rev 14 + Gonzalo Camarille, Wed. June 24th - Expand AVP and ABNF acronyms in Abstract. Fixed in rev 14 - Remove reference to RFC4005 from Abstract. Fixed in rev 14 + Lars Eggert, Wed Jul 1st - DISCUSS: Firewall functionality. . Agreed to remove. Fixed in rev 14. + Adrian Farrel/Eric Gray - DISCUSS: Clarify filter usage at L2. - Capture results of exchanges between Eric Gray and Max Riegel. - Fixed in rev 14. Regards Mark From root@core3.amsl.com Fri Oct 23 06:15:04 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 971183A67E9; Fri, 23 Oct 2009 06:15:04 -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: <20091023131504.971183A67E9@core3.amsl.com> Date: Fri, 23 Oct 2009 06:15:04 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-14.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: , X-List-Received-Date: Fri, 23 Oct 2009 13:15:04 -0000 --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-14.txt Pages : 42 Date : 2009-10-23 This document defines a number of Diameter Quality of Service (QoS) related attribute-value pairs (AVP) that can be used in existing and future Diameter applications where permitted by the Augmented Backus- Naur Form (ABNF) specification of the command. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-14.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-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23060944.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Oct 26 08:47:18 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DE46F28C2CB; Mon, 26 Oct 2009 08:47:18 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091026154718.DE46F28C2CB@core3.amsl.com> Date: Mon, 26 Oct 2009 08:47:18 -0700 (PDT) Cc: Internet Architecture Board , dime mailing list , dime chair , RFC Editor Subject: [Dime] Protocol Action: 'Diameter User-Name and Realm Based Request Routing Clarifications' to Proposed Standard 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: , X-List-Received-Date: Mon, 26 Oct 2009 15:47:19 -0000 The IESG has approved the following document: - 'Diameter User-Name and Realm Based Request Routing Clarifications ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-04.txt Technical Summary This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. Working Group Summary The document fixes a small technical aspect and hence it sailed smoothly through the DIME group. Document Quality This document is the product of the DIME working group. The current implementation status of this specification is, however, unknown. Implementations are expected to arrive to arrive when larger Diameter deployments utilize the RFC 4282 based NAI format. Personnel Hannes Tschofenig is the document shepherd for this document. Dan Romascanu is the responsible AD. RFC Editor Note Please remove RFC3588bis from the Updates line in the header of the document. From dromasca@avaya.com Mon Oct 26 08:56:01 2009 Return-Path: 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 E8E5A3A685D for ; Mon, 26 Oct 2009 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 1ROikYsQfC0P for ; Mon, 26 Oct 2009 08:56:01 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 5522D3A683E for ; Mon, 26 Oct 2009 08:56:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,626,1249272000"; d="scan'208";a="178193050" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 26 Oct 2009 11:56:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Oct 2009 11:56:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 16:55:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Protocol Action: 'Diameter User-Name and Realm Based RequestRouting Clarifications' to Proposed Standard Thread-Index: AcpWVEyvVpYh3iaYQUC/OjuSZyvBrwAAGFCA From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: Protocol Action: 'Diameter User-Name and Realm Based RequestRouting Clarifications' to Proposed Standard 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: , X-List-Received-Date: Mon, 26 Oct 2009 15:56:02 -0000 Congratulations to the editors, chairs and the whole WG for achieving this milestone.=20 Regards, Dan -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, October 26, 2009 5:47 PM To: IETF-Announce Cc: Internet Architecture Board; dime mailing list; dime chair; RFC Editor Subject: [Dime] Protocol Action: 'Diameter User-Name and Realm Based RequestRouting Clarifications' to Proposed Standard The IESG has approved the following document: - 'Diameter User-Name and Realm Based Request Routing Clarifications ' as a Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group.=20 The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-04.txt Technical Summary This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. Working Group Summary The document fixes a small technical aspect and hence it sailed smoothly through the DIME group. Document Quality This document is the product of the DIME working group. The current implementation status of this specification is, however, unknown. Implementations are expected to arrive to arrive when larger Diameter deployments utilize the RFC 4282 based NAI format. Personnel Hannes Tschofenig is the document shepherd for this document. Dan Romascanu is the responsible AD. RFC Editor Note Please remove RFC3588bis from the Updates line in the header of the document. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Mon Oct 26 09:15:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A4CEC28C0F9; Mon, 26 Oct 2009 09:15: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: <20091026161501.A4CEC28C0F9@core3.amsl.com> Date: Mon, 26 Oct 2009 09:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-13.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: , X-List-Received-Date: Mon, 26 Oct 2009 16:15:01 -0000 --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 Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-13.txt Pages : 57 Date : 2009-10-26 This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-13.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-diameter-qos-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26090718.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 10:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D4B473A6AF4; Mon, 26 Oct 2009 10: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: <20091026174501.D4B473A6AF4@core3.amsl.com> Date: Mon, 26 Oct 2009 10:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-nat-control-01.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: , X-List-Received-Date: Mon, 26 Oct 2009 17:45:01 -0000 --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 NAT Control Application Author(s) : F. Brockners, V. Singh, S. Bhandari, V. Fajardo Filename : draft-ietf-dime-nat-control-01.txt Pages : 40 Date : 2009-10-26 This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-01.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-nat-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26104154.I-D@ietf.org> --NextPart-- From vfajardo@research.telcordia.com Tue Oct 27 03:57:43 2009 Return-Path: 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 E276028C113 for ; Tue, 27 Oct 2009 03:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 WwoU40tGTrBU for ; Tue, 27 Oct 2009 03:57:43 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id DE0573A687C for ; Tue, 27 Oct 2009 03:57:42 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n9RAvued028433 for ; Tue, 27 Oct 2009 06:57:56 -0400 (EDT) From: "Victor Fajardo" To: References: <013c01ca24b5$d71860a0$854921e0$@telcordia.com> <003101ca4691$50537750$f0fa65f0$@telcordia.com> <023101ca4b41$187552e0$495ff8a0$@net> <008a01ca4b63$1c5c0a80$03ffa8c0@nsnintra.net> <004101ca4c10$dd085920$97190b60$@telcordia.com> In-Reply-To: <004101ca4c10$dd085920$97190b60$@telcordia.com> Date: Tue, 27 Oct 2009 06:57:56 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <000701ca56f4$573fac00$05bf0400$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoktdVfkFjNt7r3SQyekWKplEaedwh2nUWAASl3hBAAAra1QAAIewsgACs9szAAADf+0AK4nzcg Content-Language: en-us Subject: Re: [Dime] Diameter API draft. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:57:44 -0000 Since there are no more comments, we can officially declare this document as 'Dead'. -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo Sent: Tuesday, October 13, 2009 10:24 AM To: 'Romascanu, Dan (Dan)'; 'Hannes Tschofenig'; 'Glen Zorn'; dime@ietf.org Subject: Re: [Dime] Diameter API draft. Hi Dan, My vote is to declare the draft as 'dead'. Regards, victor -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, October 13, 2009 10:19 AM To: Hannes Tschofenig; Glen Zorn; vfajardo@research.telcordia.com; dime@ietf.org Subject: RE: [Dime] Diameter API draft. Just to clarify - the comment 'Personally, I like the latter idea' in the thread belongs to Glen. I have no preference and will support whatever course the WG reaches consensus about. Dan > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, October 12, 2009 7:41 PM > To: 'Glen Zorn'; Romascanu, Dan (Dan); > vfajardo@research.telcordia.com; dime@ietf.org > Subject: RE: [Dime] Diameter API draft. > > Hmmm. > > Publishing something as historic is not particularly helpful > and only wasting the time of the RFC Editor. > > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Glen Zorn > Sent: 12 October, 2009 16:37 > To: 'Romascanu, Dan (Dan)'; > vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. > > > > > > What does the WG want to do with the I-D? Declare it > 'Dead'? Publish it as Historic RFC with a note reflecting > that this was OBE (Overcome By Events)? > > Personally, I like the latter idea. > > Dan > > > > > > ________________________________ > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Tuesday, October 06, 2009 4:29 PM > To: vfajardo@research.telcordia.com; dime@ietf.org > Subject: Re: [Dime] Diameter API draft. > > Hi, > > > > It's been over a month and we have not had any > feedback regarding the Diameter API doc. At this point, I > think it's safe to say that no one is interested in > continuing this work and so we will effectively remove this > doc from the charter. > > > > Regards, > > Victor > > > > > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org] On Behalf Of Victor Fajardo > Sent: Monday, August 24, 2009 8:25 AM > To: dime@ietf.org > Subject: [Dime] Diameter API draft. > > > > Hi Folks, > > > > During the last IETF, we were trying to gauge > if there is leftover interest in continuing work with the > Diameter AP > (http://tools.ietf.org/html/draft-ietf-dime-diameter-api-08)I. > This email is a follow up to solicit a final vote/hum for > this draft. If you see value in this draft and wish to see > the work continue, make sure you respond to this email as > well as address the questions "why and who" would use this > API. If you don't see any value in this work pls state so as > well. We'll give this hum some time to circulate through > peoples mailboxes (a month or so) after which we can decide > the fate of the draft. > > > > Regards, > > victor > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From vfajardo@research.telcordia.com Tue Oct 27 04:01:26 2009 Return-Path: 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 C400228C148 for ; Tue, 27 Oct 2009 04:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 QeiXy-Y4VPTh for ; Tue, 27 Oct 2009 04:01:25 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id B6FA328C143 for ; Tue, 27 Oct 2009 04:01:25 -0700 (PDT) Received: from fajardov1 (vpntnlB33.research.telcordia.com [128.96.59.33]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id n9RB1X6q029522; Tue, 27 Oct 2009 07:01:33 -0400 (EDT) From: "Victor Fajardo" To: "'Tom Taylor'" , "'Mark Jones'" References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>, <4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> <4ACBF84F.6020506@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822999@m679t05.fpmis.bridgewatersys.com> <4ACCF0CE.8080603@rogers.com> In-Reply-To: <4ACCF0CE.8080603@rogers.com> Date: Tue, 27 Oct 2009 07:01:33 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <001001ca56f4$d888bf90$899a3eb0$@telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpHh09L+Nm1YSJ/TH65c64W1+H2PAPbXLJw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: vfajardo@research.telcordia.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 11:01:26 -0000 Hi Tom, Any plans on submitting and update to the doc ? Regards, Victor -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Wednesday, October 07, 2009 3:50 PM To: Mark Jones Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt I'll take the second choice you offer. Mark Jones wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor@rogers.com] >> Sent: October 6, 2009 10:09 PM >> To: Mark Jones >> Cc: dime@ietf.org >> Subject: Re: [Dime] I-D >> Action:draft-ietf-dime-realm-based-redirect-01.txt >> >> What I'm worried about is whether this implies every >> application out there has >> to be redefined to make use of this feature. >> > > That is indeed the implication. Alternatively, you define a new application id for the realm-based redirect functionality and it complements the existing applications, i.e. if you need NASREQ with realm-based redirect, the CER/CEA advertises the NASREQ Application Id and the Realm-based Redirect Application ID. > > Regards > Mark > > >> Mark Jones wrote: >>> Hi Tom, >>> >>> I was expecting a stronger statement on advertisement at >> the application level, e.g. >>> "Because realm-based redirection is not part of base >> Diameter behaviour, support for realm-based redirection by >> the peers MUST be advertised at the application level." >>> I don't see how the feature works reliably otherwise and >> punting the risk evaluation to the service provider seems >> inappropriate for a feature likely to used on >> inter-service-provider interfaces. >>> Regards >>> Mark >>> >>> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From tom111.taylor@bell.net Tue Oct 27 08:02:20 2009 Return-Path: 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 6B1FC3A695D for ; Tue, 27 Oct 2009 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] 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 4KBQnnKVLnuH for ; Tue, 27 Oct 2009 08:02:19 -0700 (PDT) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 7FF2E3A6835 for ; Tue, 27 Oct 2009 08:02:19 -0700 (PDT) Received: from BLU0-SMTP9 ([65.55.111.73]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 08:02:34 -0700 X-Originating-IP: [70.54.11.20] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.54.11.20]) by BLU0-SMTP9.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 08:02:33 -0700 Date: Tue, 27 Oct 2009 11:02:30 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: vfajardo@research.telcordia.com References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com>, <4A719F10.6090701@nict.go.jp> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@m679t05.fpmis.bridgewatersys.com> <4ACB85C5.9080609@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822961@m679t05.fpmis.bridgewatersys.com> <4ACBF84F.6020506@rogers.com> <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4822999@m679t05.fpmis.bridgewatersys.com> <4ACCF0CE.8080603@rogers.com> <001001ca56f4$d888bf90$899a3eb0$@telcordia.com> In-Reply-To: <001001ca56f4$d888bf90$899a3eb0$@telcordia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2009 15:02:33.0548 (UTC) FILETIME=[833228C0:01CA5716] Cc: 'Mark Jones' , dime@ietf.org, 'Tom Taylor' Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.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: , X-List-Received-Date: Tue, 27 Oct 2009 15:02:20 -0000 I did so, but it will need manual follow-up because my new ISP thought the authentication messages were spam and intercepted them. Victor Fajardo wrote: > Hi Tom, > > Any plans on submitting and update to the doc ? > > Regards, > Victor > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tom > Taylor > Sent: Wednesday, October 07, 2009 3:50 PM > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt > > I'll take the second choice you offer. > > Mark Jones wrote: >> Hi Tom, >> >>> -----Original Message----- >>> From: Tom Taylor [mailto:tom.taylor@rogers.com] >>> Sent: October 6, 2009 10:09 PM >>> To: Mark Jones >>> Cc: dime@ietf.org >>> Subject: Re: [Dime] I-D >>> Action:draft-ietf-dime-realm-based-redirect-01.txt >>> >>> What I'm worried about is whether this implies every >>> application out there has >>> to be redefined to make use of this feature. >>> >> That is indeed the implication. Alternatively, you define a new > application id for the realm-based redirect functionality and it complements > the existing applications, i.e. if you need NASREQ with realm-based > redirect, the CER/CEA advertises the NASREQ Application Id and the > Realm-based Redirect Application ID. >> Regards >> Mark >> >> >>> Mark Jones wrote: >>>> Hi Tom, >>>> >>>> I was expecting a stronger statement on advertisement at >>> the application level, e.g. >>>> "Because realm-based redirection is not part of base >>> Diameter behaviour, support for realm-based redirection by >>> the peers MUST be advertised at the application level." >>>> I don't see how the feature works reliably otherwise and >>> punting the risk evaluation to the service provider seems >>> inappropriate for a feature likely to used on >>> inter-service-provider interfaces. >>>> Regards >>>> Mark >>>> >>>> > _______________________________________________ > 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 root@core3.amsl.com Tue Oct 27 10:00:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 924033A69D1; Tue, 27 Oct 2009 10: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: <20091027170001.924033A69D1@core3.amsl.com> Date: Tue, 27 Oct 2009 10:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-realm-based-redirect-02.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: , X-List-Received-Date: Tue, 27 Oct 2009 17:00:01 -0000 --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 : Realm-Based Redirection In Diameter Author(s) : T. Tsou (Ting ZOU), T. Taylor Filename : draft-ietf-dime-realm-based-redirect-02.txt Pages : 6 Date : 2009-10-27 RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies the means by which this can be achieved. It also defines a new application by means of which support for this capability can be advertised. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-02.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-realm-based-redirect-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-27094631.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Wed Oct 28 03:25:15 2009 Return-Path: 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 80B1D3A6889; Wed, 28 Oct 2009 03:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 vf3KtvHBoKGO; Wed, 28 Oct 2009 03:25:14 -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 2CBEA3A6875; Wed, 28 Oct 2009 03:25:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,639,1249272000"; d="scan'208";a="161579895" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Oct 2009 06:25:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Oct 2009 06:25:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 11:24:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Handover Keying (hokey) Thread-Index: AcpXSI4gdwuwlXVZRzCWaWO5/ULIAgAcD0kQ From: "Romascanu, Dan (Dan)" To: , , , , , Subject: [Dime] FW: WG Review: Recharter of Handover Keying (hokey) 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: , X-List-Received-Date: Wed, 28 Oct 2009 10:25:15 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, October 27, 2009 11:00 PM To: new-work@ietf.org Subject: WG Review: Recharter of Handover Keying (hokey)=20 A modified charter has been submitted for the Handover Keying (hokey) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, November 3, 2009. Handover Keying (hokey) ------------------------ Last Modified: 2009-10-19 Chair(s): Glen Zorn Tina Tsou (Ting ZOU) =20 Security Area Director(s): Tim Polk Pasi Eronen =20 Security Area Advisor: Tim Polk =20 Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Nov 2009 First draft on Local Domain Name Discovery for ERP Nov 2009 First draft on Early Authentication solutions Mar 2010 First draft on Hokey architecture Mar 2010 First draft on NAS-Authenticator Interaction Jul 2010 First draft on revision of RFC 5296 Mar 2011 Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 Submit the Early Authentication solutions draft to IESG Jul 2011 Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 Submit the Hokey architecture draft to IESG Nov 2011 Submit the revision of RFC 5296 to IESG Mar 2012 Re-charter or shut down WG From gwz@net-zen.net Thu Oct 29 03:08:24 2009 Return-Path: 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 A61E03A6819 for ; Thu, 29 Oct 2009 03:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.055 X-Spam-Level: X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_05=-1.11] 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 YS2W7LGswfsS for ; Thu, 29 Oct 2009 03:08:23 -0700 (PDT) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id ACA153A68A9 for ; Thu, 29 Oct 2009 03:08:23 -0700 (PDT) Received: (qmail 24225 invoked from network); 29 Oct 2009 10:08:33 -0000 Received: from unknown (124.120.224.88) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 29 Oct 2009 10:08:32 -0000 From: "Glen Zorn" To: Date: Thu, 29 Oct 2009 17:08:19 +0700 Organization: Network Zen Message-ID: <024501ca587f$bf8d4d80$3ea7e880$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpYf7znSwDgO6bjRlKTgL/vBZDTXw== Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 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: , X-List-Received-Date: Thu, 29 Oct 2009 10:08:24 -0000 Hi, Mark. I've been reconstructing the latest (unpublished) version of th8is draft & going through the archives to make sure that the new rev will cover all the comments. Anyway, at some point in the past you wrote "I have reviewed this draft and only have one comment: The dbpPeerVendorId should be Unsigned32 rather than enumerated INTEGER." I see that I agreed to this change, but I'm wondering what the rationale might be... From dromasca@avaya.com Thu Oct 29 03:24:40 2009 Return-Path: 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 C166E3A6A86 for ; Thu, 29 Oct 2009 03:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 yO6OLA2cMmNx for ; Thu, 29 Oct 2009 03:24:40 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E8C2E3A6997 for ; Thu, 29 Oct 2009 03:24:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,645,1249272000"; d="scan'208";a="188523626" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Oct 2009 06:24:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 29 Oct 2009 06:24:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 11:24:42 +0100 Message-ID: In-Reply-To: <024501ca587f$bf8d4d80$3ea7e880$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 Thread-Index: AcpYf7znSwDgO6bjRlKTgL/vBZDTXwAAcBJw References: <024501ca587f$bf8d4d80$3ea7e880$@net> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" , Cc: dime@ietf.org Subject: Re: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 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: , X-List-Received-Date: Thu, 29 Oct 2009 10:24:40 -0000 What is the latest version of this document? Shouldn't we look at draft-ietf-dime-diameter-base-protocol-mib-02.txt?=20 In any case, it does not make to much sense for a vendorID object which is always as I can understand a positive integer to be something else than an Unsigned32. RFC 4181 actually says that INTEGER MUST NOT be used in such cases. I think draft-ietf-dime-diameter-base-protocol-mib-02 fixed this.=20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Glen Zorn > Sent: Thursday, October 29, 2009 12:08 PM > To: mark.jones@bridgewatersystems.com > Cc: dime@ietf.org > Subject: Re: [Dime] Review of=20 > draft-ietf-dime-diameter-base-protocol-mib-00 >=20 > Hi, Mark. I've been reconstructing the latest (unpublished)=20 > version of th8is draft & going through the archives to make=20 > sure that the new rev will cover all the comments. Anyway,=20 > at some point in the past you wrote "I have reviewed this=20 > draft and only have one comment: The dbpPeerVendorId should be > Unsigned32 rather than enumerated INTEGER." I see that I=20 > agreed to this change, but I'm wondering what the rationale=20 > might be... >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From Mark.Jones@bridgewatersystems.com Thu Oct 29 07:07:41 2009 Return-Path: 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 F3B0F3A6A67 for ; Thu, 29 Oct 2009 07:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 8nhoQPE3lbPu for ; Thu, 29 Oct 2009 07:07:37 -0700 (PDT) Received: from cernan.electric.net (cernan.electric.net [72.35.23.19]) by core3.amsl.com (Postfix) with ESMTP id 13F423A6A8C for ; Thu, 29 Oct 2009 07:07:36 -0700 (PDT) Received: from 1N3VfL-0000pG-W5 by cernan.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1N3VfM-0000pZ-Us; Thu, 29 Oct 2009 07:07:52 -0700 Received: by emcmailer; Thu, 29 Oct 2009 07:07:52 -0700 Received: from [72.35.6.119] (helo=webmail.bridgewatersystems.com) by cernan.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1N3VfL-0000pG-W5; Thu, 29 Oct 2009 07:07:51 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 29 Oct 2009 10:07:51 -0400 From: Mark Jones To: Glen Zorn Date: Thu, 29 Oct 2009 10:07:46 -0400 Thread-Topic: Review of draft-ietf-dime-diameter-base-protocol-mib-00 Thread-Index: AcpYf7znSwDgO6bjRlKTgL/vBZDTXwAHS/ew Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD4823150@m679t05.fpmis.bridgewatersys.com> References: <024501ca587f$bf8d4d80$3ea7e880$@net> In-Reply-To: <024501ca587f$bf8d4d80$3ea7e880$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 72.35.6.119 X-Env-From: Mark.Jones@bridgewatersystems.com X-PolicySMART: 781633 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Cc: "dime@ietf.org" Subject: Re: [Dime] Review of draft-ietf-dime-diameter-base-protocol-mib-00 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: , X-List-Received-Date: Thu, 29 Oct 2009 14:07:41 -0000 Hi Glen, > -----Original Message----- > From: Glen Zorn [mailto:gwz@net-zen.net] > Sent: October 29, 2009 6:08 AM > To: Mark Jones > Cc: dime@ietf.org > Subject: RE: Review of draft-ietf-dime-diameter-base-protocol-mib-00 >=20 > Hi, Mark. I've been reconstructing the latest (unpublished) version of > th8is draft & going through the archives to make sure that the new rev > will > cover all the comments. Anyway, at some point in the past you wrote "I > have > reviewed this draft and only have one comment: The dbpPeerVendorId > should be > Unsigned32 rather than enumerated INTEGER." I see that I agreed to > this > change, but I'm wondering what the rationale might be... >=20 I assumed this was just an oversight as the other vendorId in the MIB are U= nsigned32.=20 I understand that the INTEGER type is recommended for representing named-nu= mber enumerations but it struck me as strange that the ID would define just= four enumeration values for IETF, Cisco, 3GPP and Vodafone. The vendor nam= e/id list is potentially very long and it didn't seem like the appropriate = use of the enumerated INTEGER type. I'm not a MIB designer so this comment = is largely based on how I've seen enums used in other MIBs. I now await the= counter examples from the MIB experts ;) Regards Mark From Hannes.Tschofenig@gmx.net Fri Oct 30 09:05:00 2009 Return-Path: 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 54F493A694C for ; Fri, 30 Oct 2009 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 9GsXfY28yr9p for ; Fri, 30 Oct 2009 09:04:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DEB093A68DA for ; Fri, 30 Oct 2009 09:04:58 -0700 (PDT) Received: (qmail invoked by alias); 30 Oct 2009 16:05:14 -0000 Received: from 30-5-246.wireless.csail.mit.edu (EHLO 4FIL42860) [128.30.5.246] by mail.gmx.net (mp006) with SMTP; 30 Oct 2009 17:05:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/YVusmYSnYbgbCNtrZbA3FQWJeVDA60zumCEzKi8 BFSqn7qhSmT4hk From: "Hannes Tschofenig" To: Date: Fri, 30 Oct 2009 18:08:29 +0200 Message-ID: <06f301ca597b$3a820750$98221f80@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpZezgY2FIt/hqFSfqXzvmGbQwiOg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Dime] Agenda Proposal 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: , X-List-Received-Date: Fri, 30 Oct 2009 16:05:00 -0000 Hi all, I have just crafted an agenda proposal and you can find it here: http://www.ietf.org/proceedings/09nov/agenda/dime.txt Please let me know what you think about it. I will refine it based on your feedback. Ciao Hannes PS: I plan to have Webex setup so that remote participants can actually listen and speak during the meeting.