From dromasca@avaya.com Wed Jul 1 00:43:38 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 D78BF3A6F19 for ; Wed, 1 Jul 2009 00:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Ums3HUW+RgjH for ; Wed, 1 Jul 2009 00:43:38 -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 EB7003A6F17 for ; Wed, 1 Jul 2009 00:43:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,322,1243828800"; d="scan'208";a="165938347" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Jul 2009 03:43:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jul 2009 03:43:50 -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, 1 Jul 2009 09:43:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-dime-qos-attributes thread-index: Acn6HVOi/o1M0pWcRoCk28ydpfOYEgAAg6jw From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: DISCUSS and COMMENT: draft-ietf-dime-qos-attributes 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, 01 Jul 2009 07:43:38 -0000 =20 Editors and Chairs,=20 Please deal with the comments raised by Adrian in his DISCUSS.=20 Thanks and Regards, Dan =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, July 01, 2009 10:26 AM To: iesg@ietf.org Cc: dime-chairs@tools.ietf.org; draft-ietf-dime-qos-attributes@tools.ietf.org Subject: DISCUSS and COMMENT: draft-ietf-dime-qos-attributes=20 Discuss: I hope this is a minor Discuss that can be addressed with a clarifying email. Section 4.1.8.14 through 4.1.8.23 apply to matching on Ethernet fields. It is unclear to me what this is doing in an IETF document. - What happens if the L2 protocol is not Ethernet? - Have you consulted the owning SDO for Ethernet? If Ethernet encapsulation really is in scope, perhaps this could be highlighted in the Abstract and Introduction. Comment: Figure 1 and figure 5 have minor alignment problems. Section 5 says: This section illustrates the actions associated with a rule. But it appears to me that the subsequent subsections *define* the actions. It would be really nice if the IANA section named the registries from which the allocations are to be made. From sdecugis@nict.go.jp Wed Jul 1 00:59:55 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 D84E03A6BE6 for ; Wed, 1 Jul 2009 00:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.251, 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 zS8rLeAa6pNQ for ; Wed, 1 Jul 2009 00:59:55 -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 96D163A6A4F for ; Wed, 1 Jul 2009 00:59:54 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n6180ATm016657; Wed, 1 Jul 2009 17:00:10 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n6180AnJ014611; Wed, 1 Jul 2009 17:00:10 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n6180AOi014608; Wed, 1 Jul 2009 17:00:10 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 9FF0C2A83; Wed, 1 Jul 2009 17:00:10 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 99CD82A79; Wed, 1 Jul 2009 17:00:10 +0900 (JST) Message-ID: <4A4B177F.3040100@nict.go.jp> Date: Wed, 01 Jul 2009 16:59:59 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> In-Reply-To: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 01 Jul 2009 07:59:55 -0000 Hi Julien, Sorry for late answer. > Before going further, can we agree on this ? I agree that we have an issue if several Diameter proxies provide ERP functions in the local domain. We will have to study this situation. I am not too sure if this is a question of ERP architecture, or if it is Diameter specific, anyway. It might be worth asking HOKEY group for advice on this case. Anyway, this issue is not the motivation for changing the application-id of ERP-encapsulated messages. I will open a different thread to present the issue that motivated this change, in my opinion. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Wed Jul 1 01:32: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 03FAA3A6CEB for ; Wed, 1 Jul 2009 01:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_BACKHAIR_57=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 lSe-oCetQIir for ; Wed, 1 Jul 2009 01:32:40 -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 687F33A6A09 for ; Wed, 1 Jul 2009 01:32:39 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n618WvFZ026554; Wed, 1 Jul 2009 17:32:57 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n618WvAE015312; Wed, 1 Jul 2009 17:32:57 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n618Wv03015309; Wed, 1 Jul 2009 17:32:57 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 63E754D94; Wed, 1 Jul 2009 17:32:57 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 5D6902AF1; Wed, 1 Jul 2009 17:32:57 +0900 (JST) Message-ID: <4A4B1F2E.1020602@nict.go.jp> Date: Wed, 01 Jul 2009 17:32:46 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] ERP & routing issue, take 2. 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, 01 Jul 2009 08:32:41 -0000 Hi all, Since there were some confusions on the motivation for (proposed) changing the Application-Id in ERP messages, I will try to clarify the issue, and show what the separate application-id improves. In the considered scenario, we have two domains (A and B). We have one NAS, one PROXY, and one SERVER in each domain. (NAS_A, NAS_B, ...). We have 2 users: USER_A and USER_B, who belong respectively to domains A and B. I make the following assumptions, when we don't consider ERP (so only full EAP authentication is possible): (a) When USER_A connects to NAS_A, a full EAP exchange occurs between NAS_A and SERVER_A. (b) When USER_B connects to NAS_A, full EAP exchange between NAS_A<->PROXY_A<->SERVER_B. Do we agree so far? Please let me know if these assumptions are false / too incomplete. >From this point, we consider addition of ERP to the picture. Let's consider the situation induced by draft-ietf-dime-erp-00 (i.e. ERP messages are embedded inside DER/DEA with EAP application). The well-known benefit case is for (b): PROXY_A supports ERP and receives rDSRK at the end of the full authentication. It means that after this first step, (b) exchange becomes: (br) When USER_B connects to NAS_A, a re-authentication exchange occurs between NAS_A and PROXY_A. The routing issue is that the DER message in situation (br) is *identical* to the DER message in situation (a) in terms of Diameter routing, but the two messages (a) and (br) must be routed to different AAA entities, respectively SERVER_A and PROXY_A. The characteristics of the messages are: - Application-Id: Diameter EAP application. - Destination-Realm: A. If we have a separate Application-Id for DER encapsulating ERP, it becomes easy to route the messages to the expected entity. This picture makes a lot of simplifications, but I think it is pertinent to highlight the issue. Do you have any comment? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From root@core3.amsl.com Wed Jul 1 01: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 72D6C3A6CF0; Wed, 1 Jul 2009 01: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: <20090701084501.72D6C3A6CF0@core3.amsl.com> Date: Wed, 1 Jul 2009 01:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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, 01 Jul 2009 08: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 Base Protocol MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-base-protocol-mib-01.txt Pages : 51 Date : 2009-07-01 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-protocol-mib-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-diameter-base-protocol-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-01014450.I-D@ietf.org> --NextPart-- From glenzorn@comcast.net Wed Jul 1 01:49: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 604CA28C3E2 for ; Wed, 1 Jul 2009 01:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 YzKHZK6zFaYQ for ; Wed, 1 Jul 2009 01:49:32 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id C307F28C12F for ; Wed, 1 Jul 2009 01:49:07 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA06.westchester.pa.mail.comcast.net with comcast id AYmA1c0060bG4ec56YpWKK; Wed, 01 Jul 2009 08:49:30 +0000 Received: from gwzPC ([124.122.99.50]) by OMTA03.westchester.pa.mail.comcast.net with comcast id AYou1c00215DnqL3PYp2yL; Wed, 01 Jul 2009 08:49:25 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Victor Fajardo'" References: <20090701084501.72D6C3A6CF0@core3.amsl.com> In-Reply-To: <20090701084501.72D6C3A6CF0@core3.amsl.com> Date: Wed, 1 Jul 2009 15:45:04 +0700 Message-ID: <002101c9fa28$4d565870$e8030950$@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: Acn6KEuNc8wfqCeQQmGgwY2WGFgMSgAAGDPA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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, 01 Jul 2009 08:49:33 -0000 I have addressed all the comments received during WGLC. Can we take the next step down the long & winding road to RFC publication? > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, July 01, 2009 3:45 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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 : Diameter Base Protocol MIB > Author(s) : G. Zorn, S. Comerica > Filename : draft-ietf-dime-diameter-base-protocol-mib- > 01.txt > Pages : 51 > Date : 2009-07-01 > > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter protocol is > designed to provide a framework for AAA applications. > > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base- > protocol-mib-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 root@core3.amsl.com Wed Jul 1 02:00:05 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 623B33A6BFA; Wed, 1 Jul 2009 02: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: <20090701090005.623B33A6BFA@core3.amsl.com> Date: Wed, 1 Jul 2009 02:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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, 01 Jul 2009 09:00:05 -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 Credit Control Application MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-cc-appl-mib-01.txt Pages : 20 Date : 2009-07-01 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control Application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl-mib-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-diameter-cc-appl-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-01014518.I-D@ietf.org> --NextPart-- From glenzorn@comcast.net Wed Jul 1 02:45:45 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 609053A67DA for ; Wed, 1 Jul 2009 02:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 4wU3gvDsdpit for ; Wed, 1 Jul 2009 02:45:44 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 6DF523A6359 for ; Wed, 1 Jul 2009 02:45:43 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id AZjC1c0031HzFnQ55Zm2be; Wed, 01 Jul 2009 09:46:02 +0000 Received: from gwzPC ([124.122.99.50]) by OMTA14.westchester.pa.mail.comcast.net with comcast id AZlS1c00115DnqL3aZlaNT; Wed, 01 Jul 2009 09:45:57 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Victor Fajardo'" References: <20090701090005.623B33A6BFA@core3.amsl.com> In-Reply-To: <20090701090005.623B33A6BFA@core3.amsl.com> Date: Wed, 1 Jul 2009 16:41:36 +0700 Message-ID: <004301c9fa30$3327cb70$99776250$@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: Acn6KmUw24vAxoN/QRubwazt8kSh2wABalDA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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, 01 Jul 2009 09:45:45 -0000 I have addressed all the comments received during WGLC. Can we take the next step down the long & winding road to RFC publication? > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, July 01, 2009 4:00 PM > To: i-d-announce@ietf.org > Cc: dime@ietf.org > Subject: I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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 : Diameter Credit Control Application MIB > Author(s) : G. Zorn, S. Comerica > Filename : draft-ietf-dime-diameter-cc-appl-mib-01.txt > Pages : 20 > Date : 2009-07-01 > > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter base protocol is > intended to provide a framework for AAA applications. > > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter Credit Control Application. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl- > mib-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 behcetsarikaya@yahoo.com Wed Jul 1 09:47: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 ACB3B3A6A55 for ; Wed, 1 Jul 2009 09:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 wXVuLYSXI3a2 for ; Wed, 1 Jul 2009 09:47:35 -0700 (PDT) Received: from n7.bullet.re3.yahoo.com (n7.bullet.re3.yahoo.com [68.142.237.92]) by core3.amsl.com (Postfix) with SMTP id B874E3A67B7 for ; Wed, 1 Jul 2009 09:47:34 -0700 (PDT) Received: from [68.142.237.89] by n7.bullet.re3.yahoo.com with NNFMP; 01 Jul 2009 16:44:05 -0000 Received: from [67.195.9.81] by t5.bullet.re3.yahoo.com with NNFMP; 01 Jul 2009 16:44:05 -0000 Received: from [67.195.9.111] by t1.bullet.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 16:44:05 -0000 Received: from [127.0.0.1] by omp115.mail.gq1.yahoo.com with NNFMP; 01 Jul 2009 16:44:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 480186.23790.bm@omp115.mail.gq1.yahoo.com Received: (qmail 65436 invoked by uid 60001); 1 Jul 2009 16:44:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246466645; bh=+JOaqwm1My5d4mEfp04uWp2i1R72z4HtnIbjvcUI2F0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=g3D47S7M5wLffB3GIhaokhNAjr8QGXGeZfUxIrBHRMi73P4VukvGWhNEygnWReXdmfQAHVnjnjL/+XQs8VZAVcvdRw9p4fJTKgzVNwV3HkbCSMEVBiMUkHjKS1Gi/B6KEIRQ6z9v8PcReUuKdLrTVt0V+WpAJS4kjHoRhmTyv8w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ax87LHKpPqBZC150j5jNbnG6gw6D6XTLexlw93QQc7rTB6GDiCiyxfcv4ahdvYP9sCOBwMWnI6vQJ9wr8qCS5gtQU0U7TLi2b2LvhR5VFfw6kElxYa9usYV5omHAnU+KG0bRNvQsRrL3wwIVzmHED/AxLbAIDrYPjvivtTibJt8=; Message-ID: <309849.59899.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: GNxP7PcVM1mDJeScOiLSl1wdnscsBzi7f0V86Md2ujqSbBE.oPx7r80T8m8FYj_Px5NbL4ddD2ONP1sJpy8TnDcfoPJ6Ivi0yoAfjuizUmfjRG2Rej90KZea9X6gqU2ItOh.j0OFOjUQNDLWN2G28ejWhfc1rJ53AObEgt87SpGvABoAu1pO_T1kAm76S3fr8csqyqlzf0AMkle59Dk_WqUc6dTLlEAdU4_Y47EjRxDT172DcZdZBVYFdVJuQrYl8X13q5eGnmU0HruZhdixIbA.sR6XPcrhO8r3hHAIL4uKLiXc9HicX4gs..cZADzmz6JvDa71R6_kUYWcnqqnOKmahA-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 01 Jul 2009 09:44:05 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <5e2406980906242032t60f8b05fwc3b3127790931ef7@mail.gmail.com> <4A42F67F.6020108@nict.go.jp> <701005.98419.qm@web111413.mail.gq1.yahoo.com> <4A481B88.6020703@nict.go.jp> <014801c9f926$996b7680$260ca40a@china.huawei.com> <4A4979D0.2010106@nict.go.jp> <030f01c9f94a$2c1ddae0$260ca40a@china.huawei.com> <989276.34190.qm@web111402.mail.gq1.yahoo.com> <010c01c9f9f0$b1028750$260ca40a@china.huawei.com> Date: Wed, 1 Jul 2009 09:44:05 -0700 (PDT) From: Behcet Sarikaya To: Qin Wu In-Reply-To: <010c01c9f9f0$b1028750$260ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dime@ietf.org Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:47:35 -0000 ----- Original Message ---- > From: Qin Wu > To: Behcet Sarikaya > Cc: dime@ietf.org > Sent: Tuesday, June 30, 2009 9:07:31 PM > Subject: Re: [Dime] Session-ID in draft-sdecugis-dime-diameter-erp-01 > > Hi, Behcet: > Full EAP authentication can be method specific and create EAP method specific > session-Id, however, as described in RFC5296, ERP is a method independent > protocol. >From EAP point of view, EAP exports several things like EMSK which is used by ERP. Session-ID is also exported and can be used by ERP. That's my point. Unless the ERP reuse the method specific Session-Id generated from > Full EAP authentication, it seems difficult for ERP to create EAP method > specific Session-Id. It is exported like EMSK, why should ERP regenerate the Session-ID? It is only used in EMSKName calculation. > On the other hand, if ERP can create Session-Id that is independent of EAP, > that's another case. AAA specific session-IDs also exist but different for each protocol like RADIUS or Diameter. To be used for accounting like Sebastien mentioned. IMHO EAP Session-ID is not the AAA session ID. Regards, Behcet From sunseawq@huawei.com Wed Jul 1 20:28: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 D53933A6A02 for ; Wed, 1 Jul 2009 20:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=0.013, 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 ufUh2xuthzo9 for ; Wed, 1 Jul 2009 20:28:14 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id CBF483A69E4 for ; Wed, 1 Jul 2009 20:28:13 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM400DJNXNDAG@szxga02-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 11:28:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM400GXVXND1R@szxga02-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 11:28:25 +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 <0KM400CPMXNCIG@szxml04-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 11:28:25 +0800 (CST) Date: Thu, 02 Jul 2009 11:28:24 +0800 From: Qin Wu To: Sebastien Decugis , Julien Bournelle Message-id: <016101c9fac5$28a58fd0$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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 03:28:15 -0000 Hi, Sebastien and Julien: It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain, Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve this kind of issues. Am I right? Regards! -Qin ----- Original Message ----- From: "Sebastien Decugis" To: "Julien Bournelle" Cc: Sent: Wednesday, July 01, 2009 3:59 PM Subject: Re: [Dime] ERP/Routing Issue ? > Hi Julien, > > Sorry for late answer. > >> Before going further, can we agree on this ? > I agree that we have an issue if several Diameter proxies provide ERP > functions in the local domain. We will have to study this situation. I > am not too sure if this is a question of ERP architecture, or if it is > Diameter specific, anyway. It might be worth asking HOKEY group for > advice on this case. > > Anyway, this issue is not the motivation for changing the application-id > of ERP-encapsulated messages. I will open a different thread to present > the issue that motivated this change, in my opinion. > > 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 sdecugis@nict.go.jp Wed Jul 1 21:01:19 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 3EB3F3A6971 for ; Wed, 1 Jul 2009 21:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.251, 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 Og3pBzibQX2j for ; Wed, 1 Jul 2009 21:01:18 -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 B96E93A67E1 for ; Wed, 1 Jul 2009 21:01:17 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n6241Mpo004191; Thu, 2 Jul 2009 13:01:22 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n6241MY0015125; Thu, 2 Jul 2009 13:01:22 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n6241M3g015122; Thu, 2 Jul 2009 13:01:22 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9E2BC16745; Thu, 2 Jul 2009 13:01:22 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 9445B1671D; Thu, 2 Jul 2009 13:01:22 +0900 (JST) Message-ID: <4A4C3107.7000206@nict.go.jp> Date: Thu, 02 Jul 2009 13:01:11 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Qin Wu References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> In-Reply-To: <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 04:01:19 -0000 Hi Qin, > It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain, > Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve > this kind of issues. Am I right? > It is a good point :) I think the implicit assumption is that routing from a given NAS to a given server is assumed to be stable (i.e. go through the same proxy) although nothing guarantees this in the current Diameter protocol. About the end server, there is no problem since Destination-Host is provided after the first message to ensure later messages are sent to the same server. There is no such facility for Proxy(ies), as far as I know. As for decorated NAI, I think it is an issue under consideration currently. Diameter base protocol does not support decorated NAI. You might want to check draft-ietf-dime-nai-routing-02 for more information. I can see an obvious solution to the problem : if we have several entities that act as a given application Proxy in a domain, these entities can be synchronized by some mean (for example using a common database) so that they can be used interchangeably. But I would be interested to know if other possibilities / deployments exist. Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From tom.taylor@rogers.com Wed Jul 1 21:26: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 B5E473A6B87 for ; Wed, 1 Jul 2009 21:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492, 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 bhJZC1YlMrKS for ; Wed, 1 Jul 2009 21:26:25 -0700 (PDT) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by core3.amsl.com (Postfix) with SMTP id 60A773A68C5 for ; Wed, 1 Jul 2009 21:25:52 -0700 (PDT) Received: (qmail 2841 invoked from network); 2 Jul 2009 04:26:11 -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=Br68DgmbX+3YMfgKCWS8OuxUwMc5TSwVMeRH2w3qGwlnaYki/hTFd8gzLdSmz4oU1kJUygdKzF+EMGBsq7YoxNf4iHrEyzUraXsQZK/1WzT8Jd3fLtbWmKH0bHzOJi9SdklUIk1UechMlV2mBzEmuMvXLoe2ReCoXKnG9XL1MEk= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 2 Jul 2009 04:26:11 -0000 X-YMail-OSG: caxMvc8VM1kcrKajP0CkNgRM8yu8O.sQxbPA4O8crfGAObnBDZlnJ2aNzMXsGDPWcA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4C36E1.2080301@rogers.com> Date: Thu, 02 Jul 2009 00:26:09 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Sebastien Decugis References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <4A4C3107.7000206@nict.go.jp> In-Reply-To: <4A4C3107.7000206@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 04:26:26 -0000 Well, as I said way back when, explicit routing would solve it. We will be bringing in a draft shortly. Sebastien Decugis wrote: > Hi Qin, > >> It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain, >> Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve >> this kind of issues. Am I right? >> > It is a good point :) I think the implicit assumption is that routing > from a given NAS to a given server is assumed to be stable (i.e. go > through the same proxy) although nothing guarantees this in the current > Diameter protocol. About the end server, there is no problem since > Destination-Host is provided after the first message to ensure later > messages are sent to the same server. There is no such facility for > Proxy(ies), as far as I know. > > As for decorated NAI, I think it is an issue under consideration > currently. Diameter base protocol does not support decorated NAI. You > might want to check draft-ietf-dime-nai-routing-02 for more information. > > I can see an obvious solution to the problem : if we have several > entities that act as a given application Proxy in a domain, these > entities can be synchronized by some mean (for example using a common > database) so that they can be used interchangeably. But I would be > interested to know if other possibilities / deployments exist. > > Best regards, > Sebastien. > From gwz@net-zen.net Wed Jul 1 22:49:27 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 B6ACB3A6B88 for ; Wed, 1 Jul 2009 22:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQX-1C6TEwwi for ; Wed, 1 Jul 2009 22:49:27 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 044B33A69B8 for ; Wed, 1 Jul 2009 22:49:26 -0700 (PDT) Received: (qmail 12297 invoked from network); 2 Jul 2009 05:49:48 -0000 Received: from unknown (124.120.229.96) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 02 Jul 2009 05:49:47 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" , "'Qin Wu'" References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <4A4C3107.7000206@nict.go.jp> In-Reply-To: <4A4C3107.7000206@nict.go.jp> Date: Thu, 2 Jul 2009 12:45:52 +0700 Organization: Network Zen Message-ID: <002a01c9fad8$5f963810$1ec2a830$@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: Acn6yc9LmIrDJiyoRXmZaU9sxPUYAAADh8/Q Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 05:49:27 -0000 ... > I can see an obvious solution to the problem : if we have several > entities that act as a given application Proxy in a domain, these > entities can be synchronized by some mean (for example using a common > database) so that they can be used interchangeably. But I would be > interested to know if other possibilities / deployments exist. This should be the main purpose of the Diameter ERP application, the other being explicit bootstrapping, neither of which require any interaction w/the HAAA. ... From w52006@huawei.com Wed Jul 1 23:25:54 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 20E823A69EA for ; Wed, 1 Jul 2009 23:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_BACKHAIR_57=1, 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 wrts1QLx26MI for ; Wed, 1 Jul 2009 23:25:52 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 793FE3A687C for ; Wed, 1 Jul 2009 23:25:52 -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 <0KM500ELM5V2SZ@szxga03-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 14:25:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM500MIR5V2RC@szxga03-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 14:25:50 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM5006I75V0XF@szxml04-in.huawei.com> for dime@ietf.org; Thu, 02 Jul 2009 14:25:48 +0800 (CST) Date: Thu, 02 Jul 2009 14:25:48 +0800 From: Yungui Wang In-reply-to: <4A4B1F2E.1020602@nict.go.jp> To: 'Sebastien Decugis' Message-id: <003e01c9fadd$f08c6920$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: Acn6JvFAwOge1FBIRVCAYW/Y6PBoewAtmCqg Cc: dime@ietf.org Subject: Re: [Dime] ERP & routing issue, take 2. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 06:25:54 -0000 Hello Please see inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Sebastien Decugis > Sent: Wednesday, July 01, 2009 4:33 PM > To: dime@ietf.org > Subject: [Dime] ERP & routing issue, take 2. > > Hi all, > > Since there were some confusions on the motivation for > (proposed) changing the Application-Id in ERP messages, I > will try to clarify the issue, and show what the separate > application-id improves. > > In the considered scenario, we have two domains (A and B). We > have one NAS, one PROXY, and one SERVER in each domain. > (NAS_A, NAS_B, ...). We have 2 users: USER_A and USER_B, who > belong respectively to domains A and B. > > I make the following assumptions, when we don't consider ERP > (so only full EAP authentication is possible): > > (a) When USER_A connects to NAS_A, a full EAP exchange occurs > between NAS_A and SERVER_A. > (b) When USER_B connects to NAS_A, full EAP exchange between > NAS_A<->PROXY_A<->SERVER_B. > > Do we agree so far? Please let me know if these assumptions > are false / too incomplete. > > From this point, we consider addition of ERP to the picture. > > Let's consider the situation induced by > draft-ietf-dime-erp-00 (i.e. ERP messages are embedded inside > DER/DEA with EAP application). > The well-known benefit case is for (b): PROXY_A supports ERP > and receives rDSRK at the end of the full authentication. It > means that after this first step, (b) exchange becomes: > (br) When USER_B connects to NAS_A, a re-authentication > exchange occurs between NAS_A and PROXY_A. > > The routing issue is that the DER message in situation (br) is > *identical* to the DER message in situation (a) in terms of > Diameter routing, but the two messages (a) and (br) must be > routed to different AAA entities, respectively SERVER_A and > PROXY_A. The characteristics of the messages are: > - Application-Id: Diameter EAP application. > - Destination-Realm: A. > In my mind, for (br), when re-auth request is received, the NAS_A should firstly locate the USER_B's Diameter Session which is created during full authentication and has recorded the Proxy_A (and/or SERVER_B) in the Peer Table. It can then determine the Proxy_A is next hop. Right? Thanks. Regards Yungui > If we have a separate Application-Id for DER encapsulating > ERP, it becomes easy to route the messages to the expected entity. > > This picture makes a lot of simplifications, but I think it > is pertinent to highlight the issue. > Do you have any comment? > > 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 sdecugis@nict.go.jp Wed Jul 1 23:48:38 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 E59513A69EA for ; Wed, 1 Jul 2009 23:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.241, 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 BiPJfAw394ZL for ; Wed, 1 Jul 2009 23:48:38 -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 991033A69C8 for ; Wed, 1 Jul 2009 23:48:37 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n626mlEg011299; Thu, 2 Jul 2009 15:48:47 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n626mlGL001710; Thu, 2 Jul 2009 15:48:47 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n626mlHb001707; Thu, 2 Jul 2009 15:48:47 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id BC9BF16826; Thu, 2 Jul 2009 15:48:47 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id B62621674A; Thu, 2 Jul 2009 15:48:47 +0900 (JST) Message-ID: <4A4C5841.3020201@nict.go.jp> Date: Thu, 02 Jul 2009 15:48:33 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: w52006@huawei.com References: <003e01c9fadd$f08c6920$110ca40a@china.huawei.com> In-Reply-To: <003e01c9fadd$f08c6920$110ca40a@china.huawei.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] ERP & routing issue, take 2. 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, 02 Jul 2009 06:48:39 -0000 Hello Yungui, > In my mind, for (br), when re-auth request is received, the NAS_A > should firstly locate the USER_B's Diameter Session which is > created during full authentication and has recorded the Proxy_A > (and/or SERVER_B) in the Peer Table. It can then determine the > Proxy_A is next hop. Right? Thanks. > Are you talking about Re-Auth-Request messages initiated by the server? In the scenario, I was rather considering the case where the user initiates the re-authentication, for example after a handover. In case of RAR, you are right, the Session-Id, User-Name, and Destination-Realm may already be known by the NAS, and correct information set in the message for routing to the Proxy. In case of handover, the new NAS does not know anything about the previous authentication of the user, and has no routing entry associated in its peer table. The identity presented by ERP is KeyName-NAI, which do not allow to retrieve for example the correct Destination-Realm for the peer. Does this make sense? Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From julien.bournelle@gmail.com Thu Jul 2 03:50:55 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 394B528C21F for ; Thu, 2 Jul 2009 03:50:55 -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 OoLKWjJNygq6 for ; Thu, 2 Jul 2009 03:50:54 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 3E6B528C228 for ; Thu, 2 Jul 2009 03:49:25 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so359523eye.65 for ; Thu, 02 Jul 2009 03:49:45 -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=iOZs7z1aIQtMZGjXRFjfeZTuSa/Ns1p/loGAGx3Jw/I=; b=iPVty582nyLVtRcQsFd77gSjN1l71N+PKPFZlJ+hz2ux6AzHHZlhHl89EQjiVwNJw8 F92YLehGdQadymWb6lqnKiIb+qIegVzDA3Lu3mn6ZNmIwSKApEJR5GNh+0hMESghmst6 c2q64DzIvpu9ySVGbkQGUYXtmw4voDT1xFV44= 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=lCZF0TcnsjHw8WQoJtLETQPvCkOcdQL7AUXPuveMIKMhuvdARa1kazyJiL/tnBHxU/ gq6S5HUaTgLJJBL48iuxbiJr5Wl2XhHY5cdYGQd93suoXKMIciS+FfKrqAxtaeWBcXZi ghZGmpCow4dYApj92LLBtZfDlnSrX+inEkNzg= MIME-Version: 1.0 Received: by 10.216.15.85 with SMTP id e63mr3122889wee.199.1246531785828; Thu, 02 Jul 2009 03:49:45 -0700 (PDT) In-Reply-To: <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> Date: Thu, 2 Jul 2009 12:49:45 +0200 Message-ID: <5e2406980907020349p646c4301pd378f94afb7bd152@mail.gmail.com> From: Julien Bournelle To: Qin Wu Content-Type: multipart/alternative; boundary=0016e64c1ab44ba989046db6cc22 Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 10:50:55 -0000 --0016e64c1ab44ba989046db6cc22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Thu, Jul 2, 2009 at 5:28 AM, Qin Wu wrote: > Hi, Sebastien and Julien: > It seems this issue is not specific to ERP. Suppose serveral Diameter > proxies are located in the visited domain, Yes this is not specific to ERP. But I thought it was the implicit reason to have a new Diameter App-ID for ERP. > > Full EAP authentication has to face the same problems. To my knowledge, > Decorated NAI can be used to resolve > this kind of issues. Am I right? how ? regards, Julien > > > Regards! > -Qin > ----- Original Message ----- > From: "Sebastien Decugis" > To: "Julien Bournelle" > Cc: > Sent: Wednesday, July 01, 2009 3:59 PM > Subject: Re: [Dime] ERP/Routing Issue ? > > > > Hi Julien, > > > > Sorry for late answer. > > > >> Before going further, can we agree on this ? > > I agree that we have an issue if several Diameter proxies provide ERP > > functions in the local domain. We will have to study this situation. I > > am not too sure if this is a question of ERP architecture, or if it is > > Diameter specific, anyway. It might be worth asking HOKEY group for > > advice on this case. > > > > Anyway, this issue is not the motivation for changing the application-id > > of ERP-encapsulated messages. I will open a different thread to present > > the issue that motivated this change, in my opinion. > > > > 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 > --0016e64c1ab44ba989046db6cc22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jul 2, 2009 at 5:28 AM, Qi= n Wu <sunseawq@= huawei.com> wrote:
Hi, Sebastien and Julien:
It seems this issue is not specific to ERP. Suppose serveral Diameter proxi= es are located in the visited domain,


Yes this is = not specific to ERP. But I thought it was the implicit reason to have a new= Diameter App-ID for ERP.
=A0

Full EAP authentication has to face the same problems. To my knowledge, Dec= orated NAI can be used to resolve
this kind of issues. Am I right?

=A0how ?

=A0re= gards,

=A0Julien
=A0


Regards!
-Qin
----- Original Message -----
From: "Sebastien Decugis" <sdecugis@nict.go.jp>
To: "Julien Bournelle" <julien.bournelle@gmail.com>
Cc: <dime@ietf.org>
Sent: Wednesday, July 01, 2009 3:59 PM
Subject: Re: [Dime] ERP/Routing Issue ?


> Hi Julien,
>
> Sorry for late answer.
>
>> =A0Before going further, can we agree on this ?
> I agree that we have an issue if several Diameter proxies provide ERP<= br> > functions in the local domain. We will have to study this situation. I=
> am not too sure if this is a question of ERP architecture, or if it is=
> Diameter specific, anyway. It might be worth asking HOKEY group for > advice on this case.
>
> Anyway, this issue is not the motivation for changing the application-= id
> of ERP-encapsulated messages. I will open a different thread to presen= t
> the issue that motivated this change, in my opinion.
>
> Best regards,
> Sebastien.
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)<= br> >
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

--0016e64c1ab44ba989046db6cc22-- From julien.bournelle@gmail.com Thu Jul 2 03:52:53 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 029D63A691A for ; Thu, 2 Jul 2009 03:52:53 -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 cydx0qzLOIwC for ; Thu, 2 Jul 2009 03:52:52 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 98D4E3A67A4 for ; Thu, 2 Jul 2009 03:52:51 -0700 (PDT) Received: by ewy11 with SMTP id 11so6127ewy.37 for ; Thu, 02 Jul 2009 03:53:11 -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=bvj8XGAkDOPkG+AEV/dH4ajMpT2kkEr4vpXJwoYAmBY=; b=uq39F1YPSwhBFeyPICmuE54cVPTDKU9dtlAR1gMyj+jblJj9y5Ha6DOnk++QJ8+h22 bQaP9Uzsuchfp7BhJFkp+s8Qu/v9+IbKLb35ONG8tIUp52cV2WClYXocuO7aL/993DOv CymqHmF6hx6drHKCfV+8DV9EisnxXCCD+wZbE= 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=iGNssGSLHtqepiNdJoW9uIWi0RB2ZzBjtygnYL+C+2G7HtmxvXV+nAlGyTPhOEXjeA uu+VNAcPV/cdE2mpfiYa5B6CBioW9gyTDF4iYCkPJneMKCayxvbiiQuZEYd+E3bduKjb ESL/CanPpG+7VadAjzgv64URVO/Ym/wAc4mMs= MIME-Version: 1.0 Received: by 10.216.51.82 with SMTP id a60mr3090644wec.108.1246531991649; Thu, 02 Jul 2009 03:53:11 -0700 (PDT) In-Reply-To: <4A4C3107.7000206@nict.go.jp> References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <4A4C3107.7000206@nict.go.jp> Date: Thu, 2 Jul 2009 12:53:11 +0200 Message-ID: <5e2406980907020353t1794a6b0ne7d0993d59ab8c1f@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e6db61ca90411c046db6d87c Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 02 Jul 2009 10:52:53 -0000 --0016e6db61ca90411c046db6d87c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Thu, Jul 2, 2009 at 6:01 AM, Sebastien Decugis wrote: > Hi Qin, > > > It seems this issue is not specific to ERP. Suppose serveral Diameter > proxies are located in the visited domain, > > Full EAP authentication has to face the same problems. To my knowledge, > Decorated NAI can be used to resolve > > this kind of issues. Am I right? > > > It is a good point :) I think the implicit assumption is that routing > from a given NAS to a given server is assumed to be stable (i.e. go > through the same proxy) although nothing guarantees this in the current > Diameter protocol. About the end server, there is no problem since > Destination-Host is provided after the first message to ensure later > messages are sent to the same server. There is no such facility for > Proxy(ies), as far as I know. I thought a given NAS will continue to send and receive Diameter message from the same AAA proxy for a current Diameter Session. Am I wrong ? For me, the issue was more when you have a HO to a new NAS. The new NAS can't know which AAA proxy/AAA server was used by the previous NAS for a current user. Regards, Julien > > > As for decorated NAI, I think it is an issue under consideration > currently. Diameter base protocol does not support decorated NAI. You > might want to check draft-ietf-dime-nai-routing-02 for more information. > > I can see an obvious solution to the problem : if we have several > entities that act as a given application Proxy in a domain, these > entities can be synchronized by some mean (for example using a common > database) so that they can be used interchangeably. But I would be > interested to know if other possibilities / deployments exist. > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016e6db61ca90411c046db6d87c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jul 2, 2009 at 6:01 AM, Se= bastien Decugis <sdecugis@nict.go.jp> wrote:
Hi Qin,

> It seems this issue is not specific to ERP. Suppose serveral Diameter = proxies are located in the visited domain,
> Full EAP authentication has to face the same problems. To my knowledge= , Decorated NAI can be used to resolve
> this kind of issues. Am I right?
>
It is a good point :) I think the implicit assumption is that routing=
from a given NAS to a given server is assumed to be stable (i.e. go
through the same proxy) although nothing guarantees this in the current
Diameter protocol. About the end server, there is no problem since
Destination-Host is provided after the first message to ensure later
messages are sent to the same server. There is no such facility for
Proxy(ies), as far as I know.


=A0I thought a given= NAS will continue to send and receive Diameter message
from the same AA= A proxy for a current Diameter Session. Am I wrong ?

=A0For me, the = issue was more when you have a HO to a new NAS. The new NAS
can't know which AAA proxy/AAA server was used by the previous NAS for<= br>a current user.

=A0Regards,

=A0Julien

=A0


As for decorated NAI, I think it is an issue under consideration
currently. Diameter base protocol does not support decorated NAI. You
might want to check draft-ietf-dime-nai-routing-02 for more information.
I can see an obvious solution to the problem : if we have several
entities that act as a given application Proxy in a domain, these
entities can be synchronized by some mean (for example using a common
database) so that they can be used interchangeably. But I would be
interested to know if other possibilities / deployments exist.=


Best regards,
Sebastien.

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


--0016e6db61ca90411c046db6d87c-- From dromasca@avaya.com Thu Jul 2 07:17: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 ADFD73A6D30 for ; Thu, 2 Jul 2009 07:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 QFN3poX-aySR for ; Thu, 2 Jul 2009 07:17: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 7AF473A697C for ; Thu, 2 Jul 2009 07:17:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,334,1243828800"; d="scan'208";a="150269249" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Jul 2009 10:17:03 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Jul 2009 10:17:02 -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, 2 Jul 2009 16:16:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: draft-ietf-dime-qos-attributes thread-index: Acn7H4Lid1XgN1okSvuTwJVV8WZ8DQAABdlA From: "Romascanu, Dan (Dan)" To: "Victor Fajardo" , "Mark Jones" , , "Avi Lior" Cc: dime@ietf.org Subject: [Dime] FW: DISCUSS: draft-ietf-dime-qos-attributes 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, 02 Jul 2009 14:17:14 -0000 One more DISCUSS to address.=20 Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: Thursday, July 02, 2009 5:15 PM To: iesg@ietf.org Cc: dime-chairs@tools.ietf.org; draft-ietf-dime-qos-attributes@tools.ietf.org Subject: DISCUSS: draft-ietf-dime-qos-attributes=20 Discuss: Please provide a normative reference to the formal lagnuage (notation) you are using in the document to describe the rules. Two IESG statements are relevant to this: http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt http://www.ietf.org/IESG/STATEMENTS/syntax-format-def.txt There are also missing references to imported definitions, like address in section 4.1.7.2 Section 5.1: I can't really understand how one can define actions without actually defining what one should do and how to provide the information necesaray for the action. Both Shaping and Marking clearly needs to define how the actions are going to be carried out and what the parameters are.=20 Section 10.1: The registry for where the registration is going to happen is not really specified: I assume that the registry intended is: "Authentication, Authorization, and Accounting (AAA) Parameters" : "AVP codes" but that is not clear. Please write out the registries names. Section 10.2 and 10.3: Also here the clarify of what the registration request is for is not clear. I assume that you are requesting to add a new registry for "AVP specific values" under the "Authentication, Authorization, and Accounting (AAA) Parameters" page.=20 Can you make this clear so it is easier to find the correct registries in the future. From sunseawq@huawei.com Thu Jul 2 21:12:29 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 AC3663A6809 for ; Thu, 2 Jul 2009 21:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 d4UbG0UNeQvA for ; Thu, 2 Jul 2009 21:12:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 22BB43A6825 for ; Thu, 2 Jul 2009 21:12:28 -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 <0KM600BIIUD4AN@szxga03-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 12:12:40 +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 <0KM600I49UD4LA@szxga03-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 12:12:40 +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 <0KM60000NUD36X@szxml06-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 12:12:40 +0800 (CST) Date: Fri, 03 Jul 2009 12:12:39 +0800 From: Qin Wu To: Julien Bournelle Message-id: <017101c9fb94$81484ae0$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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_3BSSTYFqG3ql8sr+4vxQ1w)" X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <5e2406980907020349p646c4301pd378f94afb7bd152@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 03 Jul 2009 04:12:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3BSSTYFqG3ql8sr+4vxQ1w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Julien: ----- Original Message ----- From: Julien Bournelle To: Qin Wu Cc: Sebastien Decugis ; dime@ietf.org Sent: Thursday, July 02, 2009 6:49 PM Subject: Re: [Dime] ERP/Routing Issue ? Hello, On Thu, Jul 2, 2009 at 5:28 AM, Qin Wu wrote: Hi, Sebastien and Julien: It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain, Yes this is not specific to ERP. But I thought it was the implicit reason to have a new Diameter App-ID for ERP. [Qin]: I think how routing works when several Diameter proxys and NASs locate in the same visited realm is one generic issue. Even there is no handover/roaming happening, the host still face to choose right proxy in the visited realm. Decorated NAI can be one of candiate mechanism to resolve this problems. However I am a ittle doubt when we have several Diameter Proxys in the visited domain, why the AAA packet should go through the given Diameter proxy? If destination of AAA packet is home AAA server ,it seems we don't care which Diameter proxy the AAA packet go through if the home AAA realm is reachable? we can choose one default Diameter proxy to route the AAA packet to the given home AAA server. Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve this kind of issues. Am I right? how ? [Qin]: The Host MAY use decorated NAI to influence the routing choice of the next AAA hop when the home AAA realm is only reachable via another mediating realm (e.g., a visited Diameter Proxy). For example, Host uses a normal NAI (i.e., user-name@homedomain name) as the AAA packets can be directly routed to the AAA server in the home realm. Whereas, Host needs to construct a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as the AAA packets cannot directly be routed to the home AAA. With the decorated NAI, the AAA packeted will be firstly routed to the proxy1 and then proxy1 modify the decorated NAI into user-name@homedomain name, and forward the AAA packet to the given home AAA server based on the modified NAI. regards, Julien Regards! -Qin ----- Original Message ----- From: "Sebastien Decugis" To: "Julien Bournelle" Cc: Sent: Wednesday, July 01, 2009 3:59 PM Subject: Re: [Dime] ERP/Routing Issue ? > Hi Julien, > > Sorry for late answer. > >> Before going further, can we agree on this ? > I agree that we have an issue if several Diameter proxies provide ERP > functions in the local domain. We will have to study this situation. I > am not too sure if this is a question of ERP architecture, or if it is > Diameter specific, anyway. It might be worth asking HOKEY group for > advice on this case. > > Anyway, this issue is not the motivation for changing the application-id > of ERP-encapsulated messages. I will open a different thread to present > the issue that motivated this change, in my opinion. > > 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 --Boundary_(ID_3BSSTYFqG3ql8sr+4vxQ1w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, Julien:
----- Original Message -----
To: Qin Wu
Sent: Thursday, July 02, 2009 6:49 PM
Subject: Re: [Dime] ERP/Routing Issue ?

Hello,

On Thu, Jul 2, 2009 at 5:28 AM, Qin Wu <sunseawq@huawei.com> wrote:
Hi, Sebastien and Julien:
It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain,


Yes this is not specific to ERP. But I thought it was the implicit reason to have a new Diameter App-ID for ERP.
 
[Qin]:
I think how routing works when several Diameter proxys and NASs locate in the same visited realm
  is one generic issue. Even there is no handover/roaming happening, the host still face to choose right
proxy in the visited realm. Decorated NAI can be one of candiate mechanism to resolve this problems. However I am a ittle doubt
when we have several Diameter Proxys in the visited domain, why the AAA packet should go through the given Diameter proxy?
If destination of AAA packet is home AAA server ,it seems we don't care which Diameter proxy the AAA packet go through if the home AAA realm is reachable? we can choose one default Diameter proxy to route the AAA packet to the given home AAA server.
 

Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve
this kind of issues. Am I right?

 how ?
[Qin]:
The Host MAY use decorated NAI to influence the routing choice of the next AAA hop when the home AAA realm is only reachable via another mediating realm (e.g., a visited Diameter Proxy).  For example, Host uses a normal NAI (i.e., user-name@homedomain name) as the AAA packets can be directly routed to the AAA server in the home realm. Whereas, Host needs to construct a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as the AAA packets cannot directly be routed to the home AAA.  With the decorated NAI, the AAA packeted will be firstly routed to the proxy1 and then proxy1 modify the decorated NAI into user-name@homedomain name, and forward the AAA packet to the given home AAA server based on the modified NAI.

 regards,

 Julien
 


Regards!
-Qin
----- Original Message -----
From: "Sebastien Decugis" <sdecugis@nict.go.jp>
To: "Julien Bournelle" <julien.bournelle@gmail.com>
Cc: <dime@ietf.org>
Sent: Wednesday, July 01, 2009 3:59 PM
Subject: Re: [Dime] ERP/Routing Issue ?


> Hi Julien,
>
> Sorry for late answer.
>
>>  Before going further, can we agree on this ?
> I agree that we have an issue if several Diameter proxies provide ERP
> functions in the local domain. We will have to study this situation. I
> am not too sure if this is a question of ERP architecture, or if it is
> Diameter specific, anyway. It might be worth asking HOKEY group for
> advice on this case.
>
> Anyway, this issue is not the motivation for changing the application-id
> of ERP-encapsulated messages. I will open a different thread to present
> the issue that motivated this change, in my opinion.
>
> 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

--Boundary_(ID_3BSSTYFqG3ql8sr+4vxQ1w)-- From julien.bournelle@gmail.com Fri Jul 3 01:37: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 11FBA3A6CB8 for ; Fri, 3 Jul 2009 01:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 CfFuuI7+z7C2 for ; Fri, 3 Jul 2009 01:37:29 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 4BBE03A6C0D for ; Fri, 3 Jul 2009 01:37:28 -0700 (PDT) Received: by ewy11 with SMTP id 11so866005ewy.37 for ; Fri, 03 Jul 2009 01:37:48 -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=NPUoExpYP0M/0Y7AN7rIeHZYqdVL/+0uX7CvLiUwWxI=; b=NuYbTQhx6+uncN/LMiojRVWh23NMXB0uTLIyIv1scCbMy77T8crVejjM997oFiQKnB YfYOUene33NI6I17ErRB6G+sC865B96X5/zTJtRVnKPUFGbQKy+2loIC1GOpif1vZ5Eh UJtwwd1Wmge8go0giEqDy9jbqj+pAXAhy6lMc= 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=A1wLVZkNxpuMmYzO/gq0kGWPjugAIMmjLPAcZ8VXhFBHUq9Trdzf7xuvcR3IEHWRgd n1bBJr2tEZW0qj7vwpPWYnmZiAD2AoZ8+NACUvjyvzoPyuPoDt4oipoW5oqxNhYVy2P0 ZM6eJXYlR/eXStiPHtMXad/rArdqwCSWE8Qfk= MIME-Version: 1.0 Received: by 10.216.3.65 with SMTP id 43mr288320weg.149.1246610267854; Fri, 03 Jul 2009 01:37:47 -0700 (PDT) In-Reply-To: <017101c9fb94$81484ae0$260ca40a@china.huawei.com> References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <5e2406980907020349p646c4301pd378f94afb7bd152@mail.gmail.com> <017101c9fb94$81484ae0$260ca40a@china.huawei.com> Date: Fri, 3 Jul 2009 10:37:47 +0200 Message-ID: <5e2406980907030137w5a21b7d9gc74f8137849380ac@mail.gmail.com> From: Julien Bournelle To: Qin Wu Content-Type: multipart/alternative; boundary=0016e65681b0305a2c046dc91286 Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 03 Jul 2009 08:37:31 -0000 --0016e65681b0305a2c046dc91286 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, see inline, On Fri, Jul 3, 2009 at 6:12 AM, Qin Wu wrote: > Hi, Julien: > > ----- Original Message ----- > *From:* Julien Bournelle > *To:* Qin Wu > *Cc:* Sebastien Decugis ; dime@ietf.org > *Sent:* Thursday, July 02, 2009 6:49 PM > *Subject:* Re: [Dime] ERP/Routing Issue ? > > Hello, > > On Thu, Jul 2, 2009 at 5:28 AM, Qin Wu wrote: > >> Hi, Sebastien and Julien: >> It seems this issue is not specific to ERP. Suppose serveral Diameter >> proxies are located in the visited domain, > > > > Yes this is not specific to ERP. But I thought it was the implicit reason > to have a new Diameter App-ID for ERP. > > [Qin]: > I think how routing works when several Diameter proxys and NASs locate in > the same visited realm > is one generic issue. Even there is no handover/roaming happening, the > host still face to choose right > proxy in the visited realm. Decorated NAI can be one of candiate mechanism > to resolve this problems. However I am a ittle doubt > when we have several Diameter Proxys in the visited domain, why the AAA > packet should go through the given Diameter proxy? > > In the case of ERP, the keying material for the local re-authentication is in a local AAA server. The new NAS must be able to contact it. > If destination of AAA packet is home AAA server ,it seems we don't care > which Diameter proxy the AAA packet go through if the home AAA realm is > reachable? we can choose one default Diameter proxy to route the AAA packet > to the given home AAA server. > > >> >> Full EAP authentication has to face the same problems. To my knowledge, >> Decorated NAI can be used to resolve >> this kind of issues. Am I right? > > > how ? > [Qin]: > The Host MAY use decorated NAI to influence the routing choice of the next > AAA hop when the home AAA realm is only reachable via another mediating > realm (e.g., a visited Diameter Proxy). For example, Host uses a normal NAI > (i.e., user-name@homedomain name) as the AAA packets can be directly > routed to the AAA server in the home realm. Whereas, Host needs to construct > a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as > the AAA packets cannot directly be routed to the home AAA. With the > decorated NAI, the AAA packeted will be firstly routed to the proxy1 and > then proxy1 modify the decorated NAI into user-name@homedomain name, > and forward the AAA packet to the given home AAA server based on the > modified NAI. > > ok. I see.Thus, the host must be aware of the "proxy1.domain.name". I guess i'll have to read the corresponding draft. However, this won't solve the issue mentionned below. Regards, Julien > > > regards, > > Julien > > >> >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Sebastien Decugis" >> To: "Julien Bournelle" >> Cc: >> Sent: Wednesday, July 01, 2009 3:59 PM >> Subject: Re: [Dime] ERP/Routing Issue ? >> >> >> > Hi Julien, >> > >> > Sorry for late answer. >> > >> >> Before going further, can we agree on this ? >> > I agree that we have an issue if several Diameter proxies provide ERP >> > functions in the local domain. We will have to study this situation. I >> > am not too sure if this is a question of ERP architecture, or if it is >> > Diameter specific, anyway. It might be worth asking HOKEY group for >> > advice on this case. >> > >> > Anyway, this issue is not the motivation for changing the application-id >> > of ERP-encapsulated messages. I will open a different thread to present >> > the issue that motivated this change, in my opinion. >> > >> > 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 >> > > --0016e65681b0305a2c046dc91286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello,

=C2=A0see inline,

On Fri, J= ul 3, 2009 at 6:12 AM, Qin Wu <sunseawq@huawei.com> wrote:
Hi, Julien:
----- Original Message -----
To: Qin Wu
Cc: Sebastien Decugis ; dime@ietf.org
Sent: Thursday, July 02, 2009 6:49 PM
Subject: Re: [Dime] ERP/Routing Issue ?

Hello,

On Thu, Jul 2, 2009 at 5:28 = AM, Qin Wu <sunseawq@huawei.com>=20 wrote:
Hi,=20 Sebastien and Julien:
It seems this issue is not specific to ERP. Su= ppose=20 serveral Diameter proxies are located in the visited domain,


Yes this is not specific to ERP. But I thought it was the=20 implicit reason to have a new Diameter App-ID for ERP.
=C2=A0
[Qin]:
I think how routing works when several Diameter proxys and=20 NASs=C2=A0locate in the same visited realm
=C2=A0 is one generic issue. Even there is no handover/roaming happe= ning,=20 the host still face to choose right
proxy in the visited realm.=C2=A0Decorated NAI can be one of candiat= e=20 mechanism to resolve this problems. However I am a ittle doubt
when we have several Diameter Proxys in the visited domain, why the = AAA=20 packet should go through the given Diameter proxy?

In the case of ERP, the keying material for t= he local re-authentication is in a local AAA server. The new NAS must be ab= le to contact it.

=C2=A0
<= div bgcolor=3D"#ffffff">
If destination of AAA packet is home AAA server ,it seems we don'= ;t care=20 which Diameter proxy the AAA packet go through if the home AAA realm is= =20 reachable? we can choose one default Diameter proxy to route the AAA pack= et to=20 the given home AAA server.
=C2=A0

Full EAP authentication has to fac= e the same=20 problems. To my knowledge, Decorated NAI can be used to resolve
this= kind=20 of issues. Am I right?

=C2=A0how ?
[Qin]:
The Host MAY use decorated NAI to influence the routing choice of th= e=20 next AAA hop when the home AAA realm is only reachable via another mediat= ing=20 realm (e.g., a visited Diameter Proxy).=C2=A0 For example, Host uses a no= rmal=20 NAI (i.e., user= -name@homedomain=20 name) as the AAA packets can be directly routed to the AAA server in the = home=20 realm. Whereas, Host needs to construct a decorated NAI (e.g., home domai= n=20 name!user-name @proxy1 domain name) as the AAA packets cannot directly be= =20 routed to the home AAA. =C2=A0With the decorated NAI, the AAA packeted wi= ll be=20 firstly routed to the proxy1 and then proxy1 modify the decorated NAI int= o user-name@homed= omain=C2=A0name,=20 and=C2=A0forward the AAA packet to the=C2=A0given home AAA server based o= n the=20 modified NAI.


=C2= =A0ok. I see.Thus, the host must be aware of the "proxy1.domain.name". I guess i'll have to re= ad the corresponding draft. However, this won't solve the issue mention= ned below.

=C2=A0Regards,

=C2=A0Julien
=C2=A0


=C2=A0regards,

=C2=A0Julien<= br>=C2=A0


Regards= !
-Qin
----- Original Message -----
From: "Sebastien Decugis"= ;=20 <sdecugis@n= ict.go.jp>
To:=20 "Julien Bournelle" <julien.bournelle@gmail.com>
Cc:=20 <dime@ietf.org>
Sent: Wednesday,=20 July 01, 2009 3:59 PM
Subject: Re: [Dime] ERP/Routing Issue=20 ?


> Hi Julien,
>
> Sorry for late=20 answer.
>
>> =C2=A0Before going further, can we agree on= this=20 ?
> I agree that we have an issue if several Diameter proxies pro= vide=20 ERP
> functions in the local domain. We will have to study this= =20 situation. I
> am not too sure if this is a question of ERP=20 architecture, or if it is
> Diameter specific, anyway. It might b= e=20 worth asking HOKEY group for
> advice on this case.
>
&g= t;=20 Anyway, this issue is not the motivation for changing the=20 application-id
> of ERP-encapsulated messages. I will open a diff= erent=20 thread to present
> the issue that motivated this change, in my= =20 opinion.
>
> Best regards,
> Sebastien.
>
&g= t;=20 --
> Sebastien Decugis
> Research fellow
> Network=20 Architecture Group
> NICT (nict.go.jp)
>
>=20 _______________________________________________
> DiME mailing=20 list
> DiME@ie= tf.org
> https://www.ietf.org/mailman/listinfo/dime


--0016e65681b0305a2c046dc91286-- From julien.bournelle@gmail.com Fri Jul 3 01:40: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 48C913A6C3E for ; Fri, 3 Jul 2009 01:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_57=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 bqYZae66ss+P for ; Fri, 3 Jul 2009 01:40:39 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id E4B5E3A6BB9 for ; Fri, 3 Jul 2009 01:40:38 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so509533eye.65 for ; Fri, 03 Jul 2009 01:40:58 -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=xsy9pZDlHkzbymC5wX1o0PmX5rkht2W3cxXCAzZedyM=; b=OhPKj1FVsJ16LWtHGUIROc4n8zoqw7Xxj3YTXNVbuX8C6gQbVR+aee30hAn2D7TOks 7YHYb6cd4+P6U9mpOxIO+78lDx5ZKRTZvEcfyEGIspfcPdKEA6LpGvjdIJ96Q2EU1UH3 /s1RPevBB5V8MxbaY8IYx03657T8X2sLQX26M= 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=gcd833rFA3kWay4ruU2pUqqmIqJdvzD7TNo8y9tEwkvHvj6AMjAhdIz1/8GoZW3sTZ jW4uXb3RVbZpEvOGS2viLbLdNtoE7fmvGf6PaasfE9rYdRmqpYB8Nz9s5AR9V07Yc2TY OArvC82Wz3Q0z85FbzXHMvw3wrCr970b5/Sms= MIME-Version: 1.0 Received: by 10.216.55.208 with SMTP id k58mr314974wec.9.1246610458616; Fri, 03 Jul 2009 01:40:58 -0700 (PDT) In-Reply-To: <4A4B1F2E.1020602@nict.go.jp> References: <4A4B1F2E.1020602@nict.go.jp> Date: Fri, 3 Jul 2009 10:40:58 +0200 Message-ID: <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=00504502e2a08f2557046dc91d4e Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 03 Jul 2009 08:40:40 -0000 --00504502e2a08f2557046dc91d4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, see inline, On Wed, Jul 1, 2009 at 10:32 AM, Sebastien Decugis wrote: > Hi all, > > Since there were some confusions on the motivation for (proposed) > changing the Application-Id in ERP messages, I will try to clarify the > issue, and show what the separate application-id improves. Good ! > > > In the considered scenario, we have two domains (A and B). We have one > NAS, one PROXY, and one SERVER in each domain. (NAS_A, NAS_B, ...). We > have 2 users: USER_A and USER_B, who belong respectively to domains A and > B. > > I make the following assumptions, when we don't consider ERP (so only > full EAP authentication is possible): > > (a) When USER_A connects to NAS_A, a full EAP exchange occurs between > NAS_A and SERVER_A. > (b) When USER_B connects to NAS_A, full EAP exchange between > NAS_A<->PROXY_A<->SERVER_B. > > Do we agree so far? Please let me know if these assumptions are false / > too incomplete. We agree. > > > From this point, we consider addition of ERP to the picture. > > Let's consider the situation induced by draft-ietf-dime-erp-00 (i.e. ERP > messages are embedded inside DER/DEA with EAP application). > The well-known benefit case is for (b): PROXY_A supports ERP and > receives rDSRK at the end of the full authentication. It means that > after this first step, (b) exchange becomes: > (br) When USER_B connects to NAS_A, a re-authentication exchange occurs > between NAS_A and PROXY_A. > > The routing issue is that the DER message in situation (br) is > *identical* to the DER message in situation (a) in terms of Diameter > routing, but the two messages (a) and (br) must be routed to different > AAA entities, respectively SERVER_A and PROXY_A. The characteristics of > the messages are: > - Application-Id: Diameter EAP application. > - Destination-Realm: A. > > If we have a separate Application-Id for DER encapsulating ERP, it > becomes easy to route the messages to the expected entity. > > This picture makes a lot of simplifications, but I think it is pertinent > to highlight the issue. Ok, now I see your point. It is more a "internal routing issue" i.e. how does the PROXY_A knows if the DER message is to be routed to SERVER_B or locally handled ? Am I right ? Regards, Julien > > Do you have any comment? > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --00504502e2a08f2557046dc91d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0see inline,

On Wed, Jul = 1, 2009 at 10:32 AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi all,

Since there were some confusions on the motivation for (proposed)
changing the Application-Id in ERP messages, I will try to clarify the
issue, and show what the separate application-id improves.
=A0Good !
=A0


In the considered scenario, we have two domains (A and B). We have one
NAS, one PROXY, and one SERVER in each domain. (NAS_A, NAS_B, ...). We
have 2 users: USER_A and USER_B, who belong respectively to domains A and B= .

I make the following assumptions, when we don't consider ERP (so only full EAP authentication is possible):

(a) When USER_A connects to NAS_A, a full EAP exchange occurs between
NAS_A and SERVER_A.
(b) When USER_B connects to NAS_A, full EAP exchange between
NAS_A<->PROXY_A<->SERVER_B.

Do we agree so far? Please let me know if these assumptions are false /
too incomplete.

=A0We agree.
=A0


>From this point, we consider addition of ERP to the picture.

Let's consider the situation induced by draft-ietf-dime-erp-00 (i.e. ER= P
messages are embedded inside DER/DEA with EAP application).
The well-known benefit case is for (b): PROXY_A supports ERP and
receives rDSRK at the end of the full authentication. It means that
after this first step, (b) exchange becomes:
(br) When USER_B connects to NAS_A, a re-authentication exchange occurs
between NAS_A and PROXY_A.

The routing issue is that the DER message in situation (br) is
*identical* to the DER message in situation (a) in terms of Diameter
routing, but the two messages (a) and (br) must be routed to different
AAA entities, respectively SERVER_A and PROXY_A. The characteristics of
the messages are:
- Application-Id: Diameter EAP application.
- Destination-Realm: A.

If we have a separate Application-Id for DER encapsulating ERP, it
becomes easy to route the messages to the expected entity.

This picture makes a lot of simplifications, but I think it is pertinent to highlight the issue.


=A0Ok, now I see your poin= t. It is more a "internal routing issue" i.e. how does the PROXY_= A knows
if the DER message is to be routed to SERVER_B or locally handle= d ? Am I right ?

=A0Regards,

=A0Julien
=A0

Do you have any comment?

Best regards,
Sebastien.

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


--00504502e2a08f2557046dc91d4e-- From sunseawq@huawei.com Fri Jul 3 02:53:04 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 923193A6ACD for ; Fri, 3 Jul 2009 02:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.417 X-Spam-Level: * X-Spam-Status: No, score=1.417 tagged_above=-999 required=5 tests=[AWL=-1.926, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, 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 YoF8kln4nlFc for ; Fri, 3 Jul 2009 02:53:03 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9F0A23A6A62 for ; Fri, 3 Jul 2009 02:53:02 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM70096BA1JTX@szxga04-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 17:51:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM700F56A1JWR@szxga04-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 17:51:19 +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 <0KM700MUZA1HB5@szxml04-in.huawei.com> for dime@ietf.org; Fri, 03 Jul 2009 17:51:19 +0800 (CST) Date: Fri, 03 Jul 2009 17:51:17 +0800 From: Qin Wu To: Julien Bournelle Message-id: <001901c9fbc3$cfa4d350$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.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_XGTYSffAIiTR7wV9F2nZgg)" X-Priority: 3 X-MSMail-priority: Normal References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <5e2406980907020349p646c4301pd378f94afb7bd152@mail.gmail.com> <017101c9fb94$81484ae0$260ca40a@china.huawei.com> <5e2406980907030137w5a21b7d9gc74f8137849380ac@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 03 Jul 2009 09:53:04 -0000 This is a multi-part message in MIME format. --Boundary_(ID_XGTYSffAIiTR7wV9F2nZgg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 SGksIEp1bGllbjoNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogSnVs aWVuIEJvdXJuZWxsZSANCiAgVG86IFFpbiBXdSANCiAgQ2M6IFNlYmFzdGllbiBEZWN1Z2lzIDsg ZGltZUBpZXRmLm9yZyANCiAgU2VudDogRnJpZGF5LCBKdWx5IDAzLCAyMDA5IDQ6MzcgUE0NCiAg U3ViamVjdDogUmU6IFtEaW1lXSBFUlAvUm91dGluZyBJc3N1ZSA/DQoNCg0KICBIZWxsbywNCg0K ICDCIHNlZSBpbmxpbmUsDQoNCg0KICBPbiBGcmksIEp1bCAzLCAyMDA5IGF0IDY6MTIgQU0sIFFp biBXdSA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwgSnVsaWVuOg0KICAg ICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICAgIEZyb206IEp1bGllbiBCb3Vy bmVsbGUgDQogICAgICBUbzogUWluIFd1IA0KICAgICAgQ2M6IFNlYmFzdGllbiBEZWN1Z2lzIDsg ZGltZUBpZXRmLm9yZyANCiAgICAgIFNlbnQ6IFRodXJzZGF5LCBKdWx5IDAyLCAyMDA5IDY6NDkg UE0NCiAgICAgIFN1YmplY3Q6IFJlOiBbRGltZV0gRVJQL1JvdXRpbmcgSXNzdWUgPw0KDQoNCiAg ICAgIEhlbGxvLA0KDQoNCiAgICAgIE9uIFRodSwgSnVsIDIsIDIwMDkgYXQgNToyOCBBTSwgUWlu IFd1IDxzdW5zZWF3cUBodWF3ZWkuY29tPiB3cm90ZToNCg0KICAgICAgICBIaSwgU2ViYXN0aWVu IGFuZCBKdWxpZW46DQogICAgICAgIEl0IHNlZW1zIHRoaXMgaXNzdWUgaXMgbm90IHNwZWNpZmlj IHRvIEVSUC4gU3VwcG9zZSBzZXJ2ZXJhbCBEaWFtZXRlciBwcm94aWVzIGFyZSBsb2NhdGVkIGlu IHRoZSB2aXNpdGVkIGRvbWFpbiwNCg0KDQogICAgICBZZXMgdGhpcyBpcyBub3Qgc3BlY2lmaWMg dG8gRVJQLiBCdXQgSSB0aG91Z2h0IGl0IHdhcyB0aGUgaW1wbGljaXQgcmVhc29uIHRvIGhhdmUg YSBuZXcgRGlhbWV0ZXIgQXBwLUlEIGZvciBFUlAuIA0KICAgICAgwiANCiAgICAgIFtRaW5dOiAN CiAgICAgIEkgdGhpbmsgaG93IHJvdXRpbmcgd29ya3Mgd2hlbiBzZXZlcmFsIERpYW1ldGVyIHBy b3h5cyBhbmQgTkFTc8IgbG9jYXRlIGluIHRoZSBzYW1lIHZpc2l0ZWQgcmVhbG0gDQogICAgICDC ICBpcyBvbmUgZ2VuZXJpYyBpc3N1ZS4gRXZlbiB0aGVyZSBpcyBubyBoYW5kb3Zlci9yb2FtaW5n IGhhcHBlbmluZywgdGhlIGhvc3Qgc3RpbGwgZmFjZSB0byBjaG9vc2UgcmlnaHQgDQogICAgICBw cm94eSBpbiB0aGUgdmlzaXRlZCByZWFsbS7CIERlY29yYXRlZCBOQUkgY2FuIGJlIG9uZSBvZiBj YW5kaWF0ZSBtZWNoYW5pc20gdG8gcmVzb2x2ZSB0aGlzIHByb2JsZW1zLiBIb3dldmVyIEkgYW0g YSBpdHRsZSBkb3VidA0KICAgICAgd2hlbiB3ZSBoYXZlIHNldmVyYWwgRGlhbWV0ZXIgUHJveHlz IGluIHRoZSB2aXNpdGVkIGRvbWFpbiwgd2h5IHRoZSBBQUEgcGFja2V0IHNob3VsZCBnbyB0aHJv dWdoIHRoZSBnaXZlbiBEaWFtZXRlciBwcm94eT8NCg0KICBJbiB0aGUgY2FzZSBvZiBFUlAsIHRo ZSBrZXlpbmcgbWF0ZXJpYWwgZm9yIHRoZSBsb2NhbCByZS1hdXRoZW50aWNhdGlvbiBpcyBpbiBh IGxvY2FsIEFBQSBzZXJ2ZXIuIFRoZSBuZXcgTkFTIG11c3QgYmUgYWJsZSB0byBjb250YWN0IGl0 Lg0KDQogIFtRaW5dOkluIHRoZSBjYXNlIG9mIEVSUCxJZiB0aGUgSG9zdCBvciBQZWVyIGtub3cg dGhlIGxvY2FsIEFBQSBzZXJ2ZXIgdmlhIGxvd2VyIGxheWVyIG1lY2hhbmlzbXMgb3IgRVJQLCB0 aGUgcGVlciBvciBIb3N0IA0KICBjYW4gY29udGFjdCB3aXRoIHRoZSBjb3JyZWN0IGxvY2FsIEFB QSBzZXJ2ZXIsIEkgdGhpbmsuIEluIHRoaXMgd2F5LE5BUyBkb2VzIG5vdCBuZWVkIHRvIGNvbnRh Y3Qgd2l0aCB0aGUgIGxvY2FsIEFBQSBzZXJ2ZXIgZGlyZWN0bHkuDQogIE9uIHRoZSBvdGhlciBo YW5kLCAgSWYgdGhlIFBlZXIgb3IgSG9zdCBjYW4gbm90IGtub3cgdGhlIGxvY2FsIEFBQSBzZXJ2 ZXIsIHRoZSBOQVMgc2hvdWxkIGJlIGFibGUgdG8gY29udGFjdCB0aGUgcmlnaHQgbG9jYWwgQUFB IHNlcnZlciBpbnN0ZWFkLCBJbiB0aGlzIGNhc2UsIHdlIG1heSBjaG9vc2UgdG8gZGVmaW5lIG5l dyBhcHBsaWNhdGlvbiBJZCB0byBkaXN0aW5ndWlzaCByb3V0aW5nIHRvIHRoZSBsb2NhbCBFUiBz ZXJ2ZXIgZnJvbSByb3V0aW5nIHRvIHRoZSBub3JtYWwgQUFBIHByb3h5Lg0KDQogIMIgDQogICAg ICBJZiBkZXN0aW5hdGlvbiBvZiBBQUEgcGFja2V0IGlzIGhvbWUgQUFBIHNlcnZlciAsaXQgc2Vl bXMgd2UgZG9uJ3QgY2FyZSB3aGljaCBEaWFtZXRlciBwcm94eSB0aGUgQUFBIHBhY2tldCBnbyB0 aHJvdWdoIGlmIHRoZSBob21lIEFBQSByZWFsbSBpcyByZWFjaGFibGU/IHdlIGNhbiBjaG9vc2Ug b25lIGRlZmF1bHQgRGlhbWV0ZXIgcHJveHkgdG8gcm91dGUgdGhlIEFBQSBwYWNrZXQgdG8gdGhl IGdpdmVuIGhvbWUgQUFBIHNlcnZlci4NCiAgICAgIMIgDQoNCiAgICAgICAgRnVsbCBFQVAgYXV0 aGVudGljYXRpb24gaGFzIHRvIGZhY2UgdGhlIHNhbWUgcHJvYmxlbXMuIFRvIG15IGtub3dsZWRn ZSwgRGVjb3JhdGVkIE5BSSBjYW4gYmUgdXNlZCB0byByZXNvbHZlDQogICAgICAgIHRoaXMga2lu ZCBvZiBpc3N1ZXMuIEFtIEkgcmlnaHQ/DQoNCiAgICAgIMIgaG93ID8NCiAgICAgIFtRaW5dOg0K ICAgICAgVGhlIEhvc3QgTUFZIHVzZSBkZWNvcmF0ZWQgTkFJIHRvIGluZmx1ZW5jZSB0aGUgcm91 dGluZyBjaG9pY2Ugb2YgdGhlIG5leHQgQUFBIGhvcCB3aGVuIHRoZSBob21lIEFBQSByZWFsbSBp cyBvbmx5IHJlYWNoYWJsZSB2aWEgYW5vdGhlciBtZWRpYXRpbmcgcmVhbG0gKGUuZy4sIGEgdmlz aXRlZCBEaWFtZXRlciBQcm94eSkuwiAgRm9yIGV4YW1wbGUsIEhvc3QgdXNlcyBhIG5vcm1hbCBO QUkgKGkuZS4sIHVzZXItbmFtZUBob21lZG9tYWluIG5hbWUpIGFzIHRoZSBBQUEgcGFja2V0cyBj YW4gYmUgZGlyZWN0bHkgcm91dGVkIHRvIHRoZSBBQUEgc2VydmVyIGluIHRoZSBob21lIHJlYWxt LiBXaGVyZWFzLCBIb3N0IG5lZWRzIHRvIGNvbnN0cnVjdCBhIGRlY29yYXRlZCBOQUkgKGUuZy4s IGhvbWUgZG9tYWluIG5hbWUhdXNlci1uYW1lIEBwcm94eTEgZG9tYWluIG5hbWUpIGFzIHRoZSBB QUEgcGFja2V0cyBjYW5ub3QgZGlyZWN0bHkgYmUgcm91dGVkIHRvIHRoZSBob21lIEFBQS4gwiBX aXRoIHRoZSBkZWNvcmF0ZWQgTkFJLCB0aGUgQUFBIHBhY2tldGVkIHdpbGwgYmUgZmlyc3RseSBy b3V0ZWQgdG8gdGhlIHByb3h5MSBhbmQgdGhlbiBwcm94eTEgbW9kaWZ5IHRoZSBkZWNvcmF0ZWQg TkFJIGludG8gdXNlci1uYW1lQGhvbWVkb21haW7CIG5hbWUsIGFuZMIgZm9yd2FyZCB0aGUgQUFB IHBhY2tldCB0byB0aGXCIGdpdmVuIGhvbWUgQUFBIHNlcnZlciBiYXNlZCBvbiB0aGUgbW9kaWZp ZWQgTkFJLg0KDQoNCiAgwiBvay4gSSBzZWUuVGh1cywgdGhlIGhvc3QgbXVzdCBiZSBhd2FyZSBv ZiB0aGUgInByb3h5MS5kb21haW4ubmFtZSIuIEkgZ3Vlc3MgaSdsbCBoYXZlIHRvIHJlYWQgdGhl IGNvcnJlc3BvbmRpbmcgZHJhZnQuIEhvd2V2ZXIsIHRoaXMgd29uJ3Qgc29sdmUgdGhlIGlzc3Vl IG1lbnRpb25uZWQgYmVsb3cuDQogIFtRaW5dOiBSaWdodCwgdGhlIHByZXN1bXB0aW9uIGlzIHRo ZSBob3N0IGtub3cgdGhlIGxvY2FsIGRvbWFpbiBuYW1lLCBob3dldmVyIGlmIHRoZSBob3N0IGRv ZXMgbm90IGtub3cgdGhlIGxvY2FsIGRvbWFpbiBuYW1lLCBvdGhlciBwb3NzaWJpbGl0eSBvciBz b2x1dGlvbiBpcyBuZWVkZWQuDQoNCiAgwiBSZWdhcmRzLA0KDQogIMIgSnVsaWVuDQogIMIgDQoN Cg0KICAgICAgwiByZWdhcmRzLA0KDQogICAgICDCIEp1bGllbg0KICAgICAgwiANCg0KDQogICAg ICAgIFJlZ2FyZHMhDQogICAgICAgIC1RaW4NCg0KICAgICAgICAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQogICAgICAgIEZyb206ICJTZWJhc3RpZW4gRGVjdWdpcyIgPHNkZWN1Z2lzQG5p Y3QuZ28uanA+DQogICAgICAgIFRvOiAiSnVsaWVuIEJvdXJuZWxsZSIgPGp1bGllbi5ib3VybmVs bGVAZ21haWwuY29tPg0KICAgICAgICBDYzogPGRpbWVAaWV0Zi5vcmc+DQogICAgICAgIFNlbnQ6 IFdlZG5lc2RheSwgSnVseSAwMSwgMjAwOSAzOjU5IFBNDQogICAgICAgIFN1YmplY3Q6IFJlOiBb RGltZV0gRVJQL1JvdXRpbmcgSXNzdWUgPw0KDQoNCiAgICAgICAgPiBIaSBKdWxpZW4sDQogICAg ICAgID4NCiAgICAgICAgPiBTb3JyeSBmb3IgbGF0ZSBhbnN3ZXIuDQogICAgICAgID4NCiAgICAg ICAgPj4gwiBCZWZvcmUgZ29pbmcgZnVydGhlciwgY2FuIHdlIGFncmVlIG9uIHRoaXMgPw0KICAg ICAgICA+IEkgYWdyZWUgdGhhdCB3ZSBoYXZlIGFuIGlzc3VlIGlmIHNldmVyYWwgRGlhbWV0ZXIg cHJveGllcyBwcm92aWRlIEVSUA0KICAgICAgICA+IGZ1bmN0aW9ucyBpbiB0aGUgbG9jYWwgZG9t YWluLiBXZSB3aWxsIGhhdmUgdG8gc3R1ZHkgdGhpcyBzaXR1YXRpb24uIEkNCiAgICAgICAgPiBh bSBub3QgdG9vIHN1cmUgaWYgdGhpcyBpcyBhIHF1ZXN0aW9uIG9mIEVSUCBhcmNoaXRlY3R1cmUs IG9yIGlmIGl0IGlzDQogICAgICAgID4gRGlhbWV0ZXIgc3BlY2lmaWMsIGFueXdheS4gSXQgbWln aHQgYmUgd29ydGggYXNraW5nIEhPS0VZIGdyb3VwIGZvcg0KICAgICAgICA+IGFkdmljZSBvbiB0 aGlzIGNhc2UuDQogICAgICAgID4NCiAgICAgICAgPiBBbnl3YXksIHRoaXMgaXNzdWUgaXMgbm90 IHRoZSBtb3RpdmF0aW9uIGZvciBjaGFuZ2luZyB0aGUgYXBwbGljYXRpb24taWQNCiAgICAgICAg PiBvZiBFUlAtZW5jYXBzdWxhdGVkIG1lc3NhZ2VzLiBJIHdpbGwgb3BlbiBhIGRpZmZlcmVudCB0 aHJlYWQgdG8gcHJlc2VudA0KICAgICAgICA+IHRoZSBpc3N1ZSB0aGF0IG1vdGl2YXRlZCB0aGlz IGNoYW5nZSwgaW4gbXkgb3Bpbmlvbi4NCiAgICAgICAgPg0KICAgICAgICA+IEJlc3QgcmVnYXJk cywNCiAgICAgICAgPiBTZWJhc3RpZW4uDQogICAgICAgID4NCiAgICAgICAgPiAtLQ0KICAgICAg ICA+IFNlYmFzdGllbiBEZWN1Z2lzDQogICAgICAgID4gUmVzZWFyY2ggZmVsbG93DQogICAgICAg ID4gTmV0d29yayBBcmNoaXRlY3R1cmUgR3JvdXANCiAgICAgICAgPiBOSUNUIChuaWN0LmdvLmpw KQ0KICAgICAgICA+DQoNCiAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgICAgICA+IERpTUUgbWFpbGluZyBsaXN0DQogICAgICAgID4g RGlNRUBpZXRmLm9yZw0KICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KDQoNCg0KDQo= --Boundary_(ID_XGTYSffAIiTR7wV9F2nZgg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4zNTYyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSwgSnVsaWVuOjwvRElWPg0KPEJMT0NL UVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFS R0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklH SFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5E OiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2si PjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9anVsaWVuLmJvdXJuZWxsZUBnbWFpbC5jb20gDQog IGhyZWY9Im1haWx0bzpqdWxpZW4uYm91cm5lbGxlQGdtYWlsLmNvbSI+SnVsaWVuIEJvdXJuZWxs ZTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5Ubzo8L0I+IDxBIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0bzpz dW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05U OiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1zZGVjdWdpc0BuaWN0 LmdvLmpwIA0KICBocmVmPSJtYWlsdG86c2RlY3VnaXNAbmljdC5nby5qcCI+U2ViYXN0aWVuIERl Y3VnaXM8L0E+IDsgPEEgDQogIHRpdGxlPWRpbWVAaWV0Zi5vcmcgaHJlZj0ibWFpbHRvOmRpbWVA aWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVseSAwMywgMjAwOSA0 OjM3IFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5TdWJqZWN0OjwvQj4gUmU6IFtEaW1lXSBFUlAvUm91dGluZyBJc3N1ZSA/PC9ESVY+DQogIDxE SVY+PEJSPjwvRElWPkhlbGxvLDxCUj48QlI+wiZuYnNwO3NlZSBpbmxpbmUsPEJSPjxCUj4NCiAg PERJViBjbGFzcz1nbWFpbF9xdW90ZT5PbiBGcmksIEp1bCAzLCAyMDA5IGF0IDY6MTIgQU0sIFFp biBXdSA8U1BBTiANCiAgZGlyPWx0cj4mbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpzdW5zZWF3cUBo dWF3ZWkuY29tIj5zdW5zZWF3cUBodWF3ZWkuY29tPC9BPiZndDs8L1NQQU4+IA0Kd3JvdGU6PEJS Pg0KICA8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgc3R5bGU9IlBBRERJTkctTEVG VDogMWV4OyBNQVJHSU46IDBwdCAwcHQgMHB0IDAuOGV4OyBCT1JERVItTEVGVDogcmdiKDIwNCwy MDQsMjA0KSAxcHggc29saWQiPg0KICAgIDxESVYgYmdjb2xvcj0iI2ZmZmZmZiI+DQogICAgPERJ Vj5IaSwgSnVsaWVuOjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0eWxlPSJQQURESU5H LVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVIt TEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAgIDxE SVYgY2xhc3M9aW0+DQogICAgICA8RElWPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9E SVY+DQogICAgICA8RElWIA0KICAgICAgc3R5bGU9IkJBQ0tHUk9VTkQ6IHJnYigyMjgsMjI4LDIy OCk7IG1vei1iYWNrZ3JvdW5kLWNsaXA6IC1tb3otaW5pdGlhbDsgbW96LWJhY2tncm91bmQtb3Jp Z2luOiAtbW96LWluaXRpYWw7IG1vei1iYWNrZ3JvdW5kLWlubGluZS1wb2xpY3k6IC1tb3otaW5p dGlhbCI+PEI+RnJvbTo8L0I+IA0KICAgICAgPEEgdGl0bGU9anVsaWVuLmJvdXJuZWxsZUBnbWFp bC5jb20gDQogICAgICBocmVmPSJtYWlsdG86anVsaWVuLmJvdXJuZWxsZUBnbWFpbC5jb20iIHRh cmdldD1fYmxhbms+SnVsaWVuIA0KICAgICAgQm91cm5lbGxlPC9BPiA8L0RJVj4NCiAgICAgIDxE SVY+PEI+VG86PC9CPiA8QSB0aXRsZT1zdW5zZWF3cUBodWF3ZWkuY29tIA0KICAgICAgaHJlZj0i bWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb20iIHRhcmdldD1fYmxhbms+UWluIFd1PC9BPiA8L0RJ Vj4NCiAgICAgIDxESVY+PEI+Q2M6PC9CPiA8QSB0aXRsZT1zZGVjdWdpc0BuaWN0LmdvLmpwIA0K ICAgICAgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28uanAiIHRhcmdldD1fYmxhbms+U2Vi YXN0aWVuIERlY3VnaXM8L0E+IDsgPEEgDQogICAgICB0aXRsZT1kaW1lQGlldGYub3JnIGhyZWY9 Im1haWx0bzpkaW1lQGlldGYub3JnIiANCiAgICAgIHRhcmdldD1fYmxhbms+ZGltZUBpZXRmLm9y ZzwvQT4gPC9ESVY+DQogICAgICA8RElWPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgSnVseSAwMiwg MjAwOSA2OjQ5IFBNPC9ESVY+DQogICAgICA8RElWPjxCPlN1YmplY3Q6PC9CPiBSZTogW0RpbWVd IEVSUC9Sb3V0aW5nIElzc3VlID88L0RJVj4NCiAgICAgIDxESVY+PEJSPjwvRElWPjwvRElWPkhl bGxvLDxCUj48QlI+DQogICAgICA8RElWIGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgICAgPERJViBj bGFzcz1pbT5PbiBUaHUsIEp1bCAyLCAyMDA5IGF0IDU6MjggQU0sIFFpbiBXdSA8U1BBTiBkaXI9 bHRyPiZsdDs8QSANCiAgICAgIGhyZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIiANCiAg ICAgIHRhcmdldD1fYmxhbms+c3Vuc2Vhd3FAaHVhd2VpLmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90 ZTo8QlI+DQogICAgICA8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgICAgIHN0eWxl PSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHQgMHB0IDBwdCAwLjhleDsgQk9SREVSLUxF RlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkIj5IaSwgDQogICAgICAgIFNlYmFzdGllbiBh bmQgSnVsaWVuOjxCUj5JdCBzZWVtcyB0aGlzIGlzc3VlIGlzIG5vdCBzcGVjaWZpYyB0byBFUlAu IA0KICAgICAgICBTdXBwb3NlIHNlcnZlcmFsIERpYW1ldGVyIHByb3hpZXMgYXJlIGxvY2F0ZWQg aW4gdGhlIHZpc2l0ZWQgDQogICAgICBkb21haW4sPC9CTE9DS1FVT1RFPg0KICAgICAgPERJVj48 QlI+PEJSPlllcyB0aGlzIGlzIG5vdCBzcGVjaWZpYyB0byBFUlAuIEJ1dCBJIHRob3VnaHQgaXQg d2FzIHRoZSANCiAgICAgIGltcGxpY2l0IHJlYXNvbiB0byBoYXZlIGEgbmV3IERpYW1ldGVyIEFw cC1JRCBmb3IgRVJQLiANCiAgICAgIDxCUj7CJm5ic3A7PC9ESVY+PC9ESVY+DQogICAgICA8RElW PltRaW5dOiA8L0RJVj4NCiAgICAgIDxESVY+SSB0aGluayBob3cgcm91dGluZyB3b3JrcyB3aGVu IHNldmVyYWwgRGlhbWV0ZXIgcHJveHlzIGFuZCANCiAgICAgIE5BU3PCJm5ic3A7bG9jYXRlIGlu IHRoZSBzYW1lIHZpc2l0ZWQgcmVhbG0gPC9ESVY+DQogICAgICA8RElWPsImbmJzcDsgaXMgb25l IGdlbmVyaWMgaXNzdWUuIEV2ZW4gdGhlcmUgaXMgbm8gaGFuZG92ZXIvcm9hbWluZyANCiAgICAg IGhhcHBlbmluZywgdGhlIGhvc3Qgc3RpbGwgZmFjZSB0byBjaG9vc2UgcmlnaHQgPC9ESVY+DQog ICAgICA8RElWPnByb3h5IGluIHRoZSB2aXNpdGVkIHJlYWxtLsImbmJzcDtEZWNvcmF0ZWQgTkFJ IGNhbiBiZSBvbmUgb2YgDQogICAgICBjYW5kaWF0ZSBtZWNoYW5pc20gdG8gcmVzb2x2ZSB0aGlz IHByb2JsZW1zLiBIb3dldmVyIEkgYW0gYSBpdHRsZSANCiAgICAgIGRvdWJ0PC9ESVY+DQogICAg ICA8RElWPndoZW4gd2UgaGF2ZSBzZXZlcmFsIERpYW1ldGVyIFByb3h5cyBpbiB0aGUgdmlzaXRl ZCBkb21haW4sIHdoeSB0aGUgDQogICAgICBBQUEgcGFja2V0IHNob3VsZCBnbyB0aHJvdWdoIHRo ZSBnaXZlbiBEaWFtZXRlciANCiAgICBwcm94eT88L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PC9E SVY+PC9CTE9DS1FVT1RFPg0KICA8RElWPjxCUj5JbiB0aGUgY2FzZSBvZiBFUlAsIHRoZSBrZXlp bmcgbWF0ZXJpYWwgZm9yIHRoZSBsb2NhbCANCiAgcmUtYXV0aGVudGljYXRpb24gaXMgaW4gYSBs b2NhbCBBQUEgc2VydmVyLiBUaGUgbmV3IE5BUyBtdXN0IGJlIGFibGUgdG8gDQogIGNvbnRhY3Qg aXQuPEJSPjxGT05UIHNpemU9ND48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT00PltR aW5dOkluIHRoZSBjYXNlIG9mIEVSUCxJZiB0aGUgSG9zdCBvciBQZWVyIGtub3cgdGhlIGxvY2Fs IA0KICBBQUEgc2VydmVyIHZpYSBsb3dlciBsYXllciBtZWNoYW5pc21zIG9yIEVSUCwgdGhlIHBl ZXIgb3IgSG9zdCA8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT00PmNhbiBjb250YWN0 IHdpdGggdGhlIGNvcnJlY3QgbG9jYWwgQUFBIHNlcnZlciwgSSB0aGluay4gSW4gDQogIHRoaXMg d2F5LE5BUyBkb2VzIG5vdCBuZWVkIHRvJm5ic3A7Y29udGFjdCB3aXRoIHRoZSAmbmJzcDtsb2Nh bCBBQUEgc2VydmVyIA0KICBkaXJlY3RseS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgc2l6 ZT00Pk9uIHRoZSBvdGhlciBoYW5kLCZuYnNwOyBJZiB0aGUgUGVlciBvciBIb3N0IGNhbiBub3Qg a25vdyANCiAgdGhlIGxvY2FsIEFBQSBzZXJ2ZXIsIHRoZSBOQVMgc2hvdWxkIGJlIGFibGUgdG8g Y29udGFjdCB0aGUgcmlnaHQgbG9jYWwgQUFBIA0KICBzZXJ2ZXIgaW5zdGVhZCwgSW4gdGhpcyBj YXNlLCB3ZSZuYnNwO21heSBjaG9vc2UgdG8gZGVmaW5lJm5ic3A7bmV3IA0KICBhcHBsaWNhdGlv biBJZCZuYnNwO3RvIGRpc3Rpbmd1aXNoJm5ic3A7cm91dGluZyB0byB0aGUgbG9jYWwmbmJzcDtF UiANCiAgc2VydmVyJm5ic3A7ZnJvbSByb3V0aW5nIHRvIHRoZSZuYnNwO25vcm1hbCBBQUEgcHJv eHkuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+PC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPjxCUj7C Jm5ic3A7PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0KICBzdHlsZT0i UEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7IEJPUkRFUi1MRUZU OiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZCI+DQogICAgPERJViBiZ2NvbG9yPSIjZmZmZmZm Ij4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURE SU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWIGNsYXNzPWdtYWlsX3F1 b3RlPg0KICAgICAgPERJVj48L0RJVj4NCiAgICAgIDxESVY+SWYgZGVzdGluYXRpb24gb2YgQUFB IHBhY2tldCBpcyBob21lIEFBQSBzZXJ2ZXIgLGl0IHNlZW1zIHdlIGRvbid0IA0KICAgICAgY2Fy ZSB3aGljaCBEaWFtZXRlciBwcm94eSB0aGUgQUFBIHBhY2tldCBnbyB0aHJvdWdoIGlmIHRoZSBo b21lIEFBQSByZWFsbSANCiAgICAgIGlzIHJlYWNoYWJsZT8gd2UgY2FuIGNob29zZSBvbmUgZGVm YXVsdCBEaWFtZXRlciBwcm94eSB0byByb3V0ZSB0aGUgQUFBIA0KICAgICAgcGFja2V0IHRvIHRo ZSBnaXZlbiBob21lIEFBQSBzZXJ2ZXIuPC9ESVY+DQogICAgICA8RElWIGNsYXNzPWltPg0KICAg ICAgPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPsImbmJzcDs8L0RJVj4NCiAg ICAgIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0KICAgICAgc3R5bGU9IlBBRERJTkct TEVGVDogMWV4OyBNQVJHSU46IDBwdCAwcHQgMHB0IDAuOGV4OyBCT1JERVItTEVGVDogcmdiKDIw NCwyMDQsMjA0KSAxcHggc29saWQiPjxGT05UIA0KICAgICAgICBmYWNlPeWui+S9kyBzaXplPTI+ PC9GT05UPjxCUj5GdWxsIEVBUCBhdXRoZW50aWNhdGlvbiBoYXMgdG8gZmFjZSB0aGUgDQogICAg ICAgIHNhbWUgcHJvYmxlbXMuIFRvIG15IGtub3dsZWRnZSwgRGVjb3JhdGVkIE5BSSBjYW4gYmUg dXNlZCB0byANCiAgICAgICAgcmVzb2x2ZTxCUj50aGlzIGtpbmQgb2YgaXNzdWVzLiBBbSBJIHJp Z2h0PzwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+PEJSPsImbmJzcDtob3cgPzwvRElWPjwvRElW Pg0KICAgICAgPERJVj5bUWluXTo8L0RJVj4NCiAgICAgIDxESVY+VGhlIEhvc3QgTUFZIHVzZSBk ZWNvcmF0ZWQgTkFJIHRvIGluZmx1ZW5jZSB0aGUgcm91dGluZyBjaG9pY2Ugb2YgdGhlIA0KICAg ICAgbmV4dCBBQUEgaG9wIHdoZW4gdGhlIGhvbWUgQUFBIHJlYWxtIGlzIG9ubHkgcmVhY2hhYmxl IHZpYSBhbm90aGVyIA0KICAgICAgbWVkaWF0aW5nIHJlYWxtIChlLmcuLCBhIHZpc2l0ZWQgRGlh bWV0ZXIgUHJveHkpLsImbmJzcDsgRm9yIGV4YW1wbGUsIEhvc3QgDQogICAgICB1c2VzIGEgbm9y bWFsIE5BSSAoaS5lLiwgPEEgaHJlZj0ibWFpbHRvOnVzZXItbmFtZUBob21lZG9tYWluIiANCiAg ICAgIHRhcmdldD1fYmxhbms+dXNlci1uYW1lQGhvbWVkb21haW48L0E+IG5hbWUpIGFzIHRoZSBB QUEgcGFja2V0cyBjYW4gYmUgDQogICAgICBkaXJlY3RseSByb3V0ZWQgdG8gdGhlIEFBQSBzZXJ2 ZXIgaW4gdGhlIGhvbWUgcmVhbG0uIFdoZXJlYXMsIEhvc3QgbmVlZHMgDQogICAgICB0byBjb25z dHJ1Y3QgYSBkZWNvcmF0ZWQgTkFJIChlLmcuLCBob21lIGRvbWFpbiBuYW1lIXVzZXItbmFtZSBA cHJveHkxIA0KICAgICAgZG9tYWluIG5hbWUpIGFzIHRoZSBBQUEgcGFja2V0cyBjYW5ub3QgZGly ZWN0bHkgYmUgcm91dGVkIHRvIHRoZSBob21lIEFBQS4gDQogICAgICDCJm5ic3A7V2l0aCB0aGUg ZGVjb3JhdGVkIE5BSSwgdGhlIEFBQSBwYWNrZXRlZCB3aWxsIGJlIGZpcnN0bHkgcm91dGVkIHRv IA0KICAgICAgdGhlIHByb3h5MSBhbmQgdGhlbiBwcm94eTEgbW9kaWZ5IHRoZSBkZWNvcmF0ZWQg TkFJIGludG8gPEEgDQogICAgICBocmVmPSJtYWlsdG86dXNlci1uYW1lQGhvbWVkb21haW4iIA0K ICAgICAgdGFyZ2V0PV9ibGFuaz51c2VyLW5hbWVAaG9tZWRvbWFpbjwvQT7CJm5ic3A7bmFtZSwg YW5kwiZuYnNwO2ZvcndhcmQgdGhlIA0KICAgICAgQUFBIHBhY2tldCB0byB0aGXCJm5ic3A7Z2l2 ZW4gaG9tZSBBQUEgc2VydmVyIGJhc2VkIG9uIHRoZSBtb2RpZmllZCANCiAgICAgIE5BSS48L0RJ Vj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9CTE9DS1FVT1RFPg0KICA8RElWPjxCUj48QlI+ wiZuYnNwO29rLiBJIHNlZS5UaHVzLCB0aGUgaG9zdCBtdXN0IGJlIGF3YXJlIG9mIHRoZSAiPEEg DQogIGhyZWY9Imh0dHA6Ly9wcm94eTEuZG9tYWluLm5hbWUiPnByb3h5MS5kb21haW4ubmFtZTwv QT4iLiBJIGd1ZXNzIGknbGwgaGF2ZSB0byANCiAgcmVhZCB0aGUgY29ycmVzcG9uZGluZyBkcmFm dC4gSG93ZXZlciwgdGhpcyB3b24ndCBzb2x2ZSB0aGUgaXNzdWUgbWVudGlvbm5lZCANCiAgYmVs b3cuPC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT00PltRaW5dOiBSaWdodCwgdGhlIHByZXN1bXB0 aW9uIGlzIHRoZSBob3N0IGtub3cgdGhlIGxvY2FsIA0KICBkb21haW4gbmFtZSwgaG93ZXZlciBp ZiB0aGUgaG9zdCBkb2VzIG5vdCBrbm93IHRoZSBsb2NhbCBkb21haW4gbmFtZSwgb3RoZXIgDQog IHBvc3NpYmlsaXR5IG9yIHNvbHV0aW9uIGlzIG5lZWRlZC48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEJSPsImbmJzcDtSZWdhcmRzLDxCUj48QlI+wiZuYnNwO0p1bGllbjxCUj7CJm5ic3A7PC9ESVY+ DQogIDxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0KICBzdHlsZT0iUEFERElORy1MRUZU OiAxZXg7IE1BUkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7IEJPUkRFUi1MRUZUOiByZ2IoMjA0LDIw NCwyMDQpIDFweCBzb2xpZCI+DQogICAgPERJViBiZ2NvbG9yPSIjZmZmZmZmIj4NCiAgICA8QkxP Q0tRVU9URSANCiAgICBzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkgMnB4IHNvbGlkOyBN QVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWIGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgICAg PERJVj48QlI+PEJSPsImbmJzcDtyZWdhcmRzLDxCUj48QlI+wiZuYnNwO0p1bGllbjxCUj7CJm5i c3A7PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPERJVj48L0RJVj4NCiAgICAgIDxESVYgY2xh c3M9aDU+DQogICAgICA8QkxPQ0tRVU9URSBjbGFzcz1nbWFpbF9xdW90ZSANCiAgICAgIHN0eWxl PSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHQgMHB0IDBwdCAwLjhleDsgQk9SREVSLUxF RlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkIj48QlI+PEJSPlJlZ2FyZHMhPEJSPi1RaW48 QlI+DQogICAgICAgIDxESVY+DQogICAgICAgIDxESVY+PC9ESVY+DQogICAgICAgIDxESVY+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj5Gcm9tOiAiU2ViYXN0aWVuIERlY3VnaXMiICZs dDs8QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28uanAiIA0KICAgICAg ICB0YXJnZXQ9X2JsYW5rPnNkZWN1Z2lzQG5pY3QuZ28uanA8L0E+Jmd0OzxCUj5UbzogIkp1bGll biBCb3VybmVsbGUiIA0KICAgICAgICAmbHQ7PEEgaHJlZj0ibWFpbHRvOmp1bGllbi5ib3VybmVs bGVAZ21haWwuY29tIiANCiAgICAgICAgdGFyZ2V0PV9ibGFuaz5qdWxpZW4uYm91cm5lbGxlQGdt YWlsLmNvbTwvQT4mZ3Q7PEJSPkNjOiAmbHQ7PEEgDQogICAgICAgIGhyZWY9Im1haWx0bzpkaW1l QGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPmRpbWVAaWV0Zi5vcmc8L0E+Jmd0OzxCUj5TZW50OiAN CiAgICAgICAgV2VkbmVzZGF5LCBKdWx5IDAxLCAyMDA5IDM6NTkgUE08QlI+U3ViamVjdDogUmU6 IFtEaW1lXSBFUlAvUm91dGluZyANCiAgICAgICAgSXNzdWUgPzxCUj48QlI+PEJSPiZndDsgSGkg SnVsaWVuLDxCUj4mZ3Q7PEJSPiZndDsgU29ycnkgZm9yIGxhdGUgDQogICAgICAgIGFuc3dlci48 QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyDCJm5ic3A7QmVmb3JlIGdvaW5nIGZ1cnRoZXIsIGNhbiB3ZSBh Z3JlZSBvbiANCiAgICAgICAgdGhpcyA/PEJSPiZndDsgSSBhZ3JlZSB0aGF0IHdlIGhhdmUgYW4g aXNzdWUgaWYgc2V2ZXJhbCBEaWFtZXRlciBwcm94aWVzIA0KICAgICAgICBwcm92aWRlIEVSUDxC Uj4mZ3Q7IGZ1bmN0aW9ucyBpbiB0aGUgbG9jYWwgZG9tYWluLiBXZSB3aWxsIGhhdmUgdG8gc3R1 ZHkgDQogICAgICAgIHRoaXMgc2l0dWF0aW9uLiBJPEJSPiZndDsgYW0gbm90IHRvbyBzdXJlIGlm IHRoaXMgaXMgYSBxdWVzdGlvbiBvZiBFUlAgDQogICAgICAgIGFyY2hpdGVjdHVyZSwgb3IgaWYg aXQgaXM8QlI+Jmd0OyBEaWFtZXRlciBzcGVjaWZpYywgYW55d2F5LiBJdCBtaWdodCBiZSANCiAg ICAgICAgd29ydGggYXNraW5nIEhPS0VZIGdyb3VwIGZvcjxCUj4mZ3Q7IGFkdmljZSBvbiB0aGlz IA0KICAgICAgICBjYXNlLjxCUj4mZ3Q7PEJSPiZndDsgQW55d2F5LCB0aGlzIGlzc3VlIGlzIG5v dCB0aGUgbW90aXZhdGlvbiBmb3IgDQogICAgICAgIGNoYW5naW5nIHRoZSBhcHBsaWNhdGlvbi1p ZDxCUj4mZ3Q7IG9mIEVSUC1lbmNhcHN1bGF0ZWQgbWVzc2FnZXMuIEkgd2lsbCANCiAgICAgICAg b3BlbiBhIGRpZmZlcmVudCB0aHJlYWQgdG8gcHJlc2VudDxCUj4mZ3Q7IHRoZSBpc3N1ZSB0aGF0 IG1vdGl2YXRlZCB0aGlzIA0KICAgICAgICBjaGFuZ2UsIGluIG15IG9waW5pb24uPEJSPiZndDs8 QlI+Jmd0OyBCZXN0IHJlZ2FyZHMsPEJSPiZndDsgDQogICAgICAgIFNlYmFzdGllbi48QlI+Jmd0 OzxCUj4mZ3Q7IC0tPEJSPiZndDsgU2ViYXN0aWVuIERlY3VnaXM8QlI+Jmd0OyBSZXNlYXJjaCAN CiAgICAgICAgZmVsbG93PEJSPiZndDsgTmV0d29yayBBcmNoaXRlY3R1cmUgR3JvdXA8QlI+Jmd0 OyBOSUNUICg8QSANCiAgICAgICAgaHJlZj0iaHR0cDovL25pY3QuZ28uanAiIA0KICAgICAgICB0 YXJnZXQ9X2JsYW5rPm5pY3QuZ28uanA8L0E+KTxCUj4mZ3Q7PEJSPjwvRElWPjwvRElWPiZndDsg DQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PEJSPiZndDsgRGlNRSBtYWlsaW5nIA0KICAgICAgICBsaXN0PEJSPiZndDsgPEEgaHJlZj0ibWFp bHRvOkRpTUVAaWV0Zi5vcmciIA0KICAgICAgICB0YXJnZXQ9X2JsYW5rPkRpTUVAaWV0Zi5vcmc8 L0E+PEJSPiZndDsgPEEgDQogICAgICAgIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGltZSIgDQogICAgICAgIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9BPjxCUj48L0JMT0NLUVVPVEU+PC9ESVY+PC9E SVY+PC9ESVY+PEJSPjwvQkxPQ0tRVU9URT48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwv QkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_XGTYSffAIiTR7wV9F2nZgg)-- From glenzorn@comcast.net Sun Jul 5 03:51:45 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 36E033A6894 for ; Sun, 5 Jul 2009 03:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 4RhI4Tyyde+P for ; Sun, 5 Jul 2009 03:51:44 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 649893A67D2 for ; Sun, 5 Jul 2009 03:51:43 -0700 (PDT) Received: from OMTA19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id CAqM1c0061eYJf8ADAs9TV; Sun, 05 Jul 2009 10:52:09 +0000 Received: from gwzPC ([124.120.224.122]) by OMTA19.emeryville.ca.mail.comcast.net with comcast id CArw1c0012f47aL01As1zJ; Sun, 05 Jul 2009 10:52:07 +0000 From: "Glen Zorn" To: Date: Sun, 5 Jul 2009 17:47:54 +0700 Message-ID: <008e01c9fd5e$14bcf210$3e36d630$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008F_01C9FD98.C11BCA10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn9Xbi9tQSe4gxwQqe+za8DCpAfngAAEkrw Content-Language: en-us Subject: [Dime] FW: I-D Action:draft-zorn-dime-radia-gate-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 10:51:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C9FD98.C11BCA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, July 05, 2009 5:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-zorn-dime-radia-gate-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The RADIUS-Diameter Gateway (RADIA) Application Author(s) : G. Zorn, L. Morand Filename : draft-zorn-dime-radia-gate-00.txt Pages : 6 Date : 2009-07-05 This document describes the Diameter RADIUS-Diameter Gateway (RADIA) Application, which is designed to facillitate the interoperability of Authentication, Authorization and Accounting (AAA) systems based upon RADIUS and Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zorn-dime-radia-gate-00.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_000_008F_01C9FD98.C11BCA10 Content-Type: Message/External-body; name="draft-zorn-dime-radia-gate-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-zorn-dime-radia-gate-00.txt" Content-Type: text/plain Content-ID: <2009-07-05034359.I-D@ietf.org> ------=_NextPart_000_008F_01C9FD98.C11BCA10 Content-Type: text/plain; name="ATT00139.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00139.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_008F_01C9FD98.C11BCA10-- From gwz@net-zen.net Sun Jul 5 06:50:32 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 88F4E3A6907 for ; Sun, 5 Jul 2009 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, 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 4azJ8bvnKSBO for ; Sun, 5 Jul 2009 06:50:31 -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 023943A6BC9 for ; Sun, 5 Jul 2009 06:49:36 -0700 (PDT) Received: (qmail 3405 invoked from network); 5 Jul 2009 13:50:01 -0000 Received: from unknown (124.120.224.122) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 05 Jul 2009 13:50:00 -0000 From: "Glen Zorn" To: References: <016501c9e5c8$9e730dd0$db592970$@net> <4A2912FE.70407@tari.toshiba.com> <001001c9e5e3$85c3d330$914b7990$@net> In-Reply-To: <001001c9e5e3$85c3d330$914b7990$@net> Date: Sun, 5 Jul 2009 20:45:56 +0700 Organization: Network Zen Message-ID: <00d601c9fd76$ef209cf0$cd61d6d0$@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: Acnl20Xky87yupV8TpmAS+rELiozegAB/6LgBeSGHMA= Content-Language: en-us Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-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: Sun, 05 Jul 2009 13:50:32 -0000 > >It would be really nice if we could just point to a > > stable > > > reference (maybe a BCP?) that would be up-to-date (almost) all the > > time and > > > just consists of a slightly modified version of this section + > > references. > > > > > Any thoughts on this idea? Just in case there _is_ any interest, I have written a draft: http://www.ietf.org/internet-drafts/draft-zorn-dime-doc-set-00.txt. From glenzorn@comcast.net Mon Jul 6 06:44:45 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 5073028C266 for ; Mon, 6 Jul 2009 06:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 P5IG1IGONJys for ; Mon, 6 Jul 2009 06:44:44 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 39E6A3A6A15 for ; Mon, 6 Jul 2009 06:44:44 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Cdb01c0011GhbT85BdiAPe; Mon, 06 Jul 2009 13:42:10 +0000 Received: from gwzPC ([124.121.212.240]) by OMTA07.westchester.pa.mail.comcast.net with comcast id Cdhy1c0015Blp2s3Tdi3C6; Mon, 06 Jul 2009 13:42:08 +0000 From: "Glen Zorn" To: Date: Mon, 6 Jul 2009 20:37:48 +0700 Message-ID: <02d801c9fe3e$faa14430$efe3cc90$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02D9_01C9FE79.A7001C30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn+Pk9hTzpp2YCsTIWPpPRgx79nVgAAJogg Content-Language: en-us Subject: [Dime] FW: I-D Action:draft-huang-dime-pcn-collection-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:44:45 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02D9_01C9FE79.A7001C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, July 06, 2009 8:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-huang-dime-pcn-collection-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Diameter Precongestion Notification (PCN) Data Collection Application Author(s) : F. Huang, G. Zorn Filename : draft-huang-dime-pcn-collection-00.txt Pages : 15 Date : 2009-07-06 Pre-Congestion notification (PCN) is a technique for maintaining QoS for inelastic flows in a DIFFServ domain. The PCN architecture requires that egress nodes send reports of congestion-related events (flow admission state change, excess flow) reliably to a policy decision point. The ITU-T is working on a variant of this architecture which places the policy decision point in a central node rather than ingress or egress nodes of the network. In this case the policy decision point must request and obtain certain data from an ingress node when it receives an excess flow report affecting that ingress node. This memo defines a Diameter application to support egress node reporting and data collection from the ingress node. The nature of the data flows requires the policy decision point to act both as server and as client. Hence this memo draws upon the precedent established by the Rw application (RFC 5431 and ITU-T Recommendation Q.3303.3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huang-dime-pcn-collection-00.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_000_02D9_01C9FE79.A7001C30 Content-Type: Message/External-body; name="draft-huang-dime-pcn-collection-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-huang-dime-pcn-collection-00.txt" Content-Type: text/plain Content-ID: <2009-07-06062854.I-D@ietf.org> ------=_NextPart_000_02D9_01C9FE79.A7001C30 Content-Type: text/plain; name="ATT00720.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00720.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_02D9_01C9FE79.A7001C30-- From Sujayyendhiren.Srinivas@lntinfotech.com Mon Jul 6 15:44:23 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 DD5B13A6819 for ; Mon, 6 Jul 2009 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] 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 bvKTkyhx9M1q for ; Mon, 6 Jul 2009 15:44:15 -0700 (PDT) Received: from mail142.messagelabs.com (mail142.messagelabs.com [216.82.249.99]) by core3.amsl.com (Postfix) with SMTP id 3F4253A6B83 for ; Mon, 6 Jul 2009 15:44:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Sujayyendhiren.Srinivas@lntinfotech.com X-Msg-Ref: server-5.tower-142.messagelabs.com!1246920248!44862804!1 X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 17117 invoked from network); 6 Jul 2009 22:44:08 -0000 Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-5.tower-142.messagelabs.com with SMTP; 6 Jul 2009 22:44:08 -0000 Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009070704155231-4876 ; Tue, 7 Jul 2009 04:15:52 +0530 From: Sujayyendhiren Srinivas To: dime@ietf.org Message-ID: Date: Tue, 7 Jul 2009 04:01:17 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 07/07/2009 04:14:05 AM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 07/07/2009 04:15:52 AM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 07/07/2009 04:15:54 AM, Serialize complete at 07/07/2009 04:15:54 AM Content-type: text/plain; charset=US-ASCII Subject: [Dime] Sujayyendhiren Srinivas is out of the office. 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, 06 Jul 2009 22:44:23 -0000 I will be out of the office starting Tue 07/07/2009 and will not return until Wed 07/08/2009. I am on leave/vacation on 07July2009 and 08July2009. I will respond to your message when I return. Regards Sujay ______________________________________________________________________ From sdecugis@nict.go.jp Mon Jul 6 18:18: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 AA6283A6DF9 for ; Mon, 6 Jul 2009 18:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=0.232, 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 DugK0S2olA6F for ; Mon, 6 Jul 2009 18:18:00 -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 415C53A6DF4 for ; Mon, 6 Jul 2009 18:17:59 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n671IFAZ011673; Tue, 7 Jul 2009 10:18:15 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n671IFKt018540; Tue, 7 Jul 2009 10:18:15 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n671IFfA018535; Tue, 7 Jul 2009 10:18:15 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 3538416B5C; Tue, 7 Jul 2009 10:18:15 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 2EFAD16B6B; Tue, 7 Jul 2009 10:18:15 +0900 (JST) Message-ID: <4A52A24B.2070803@nict.go.jp> Date: Tue, 07 Jul 2009 10:18:03 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <5e2406980906300015h1304df33oe24e1a2118507af9@mail.gmail.com> <4A4B177F.3040100@nict.go.jp> <016101c9fac5$28a58fd0$260ca40a@china.huawei.com> <4A4C3107.7000206@nict.go.jp> <5e2406980907020353t1794a6b0ne7d0993d59ab8c1f@mail.gmail.com> In-Reply-To: <5e2406980907020353t1794a6b0ne7d0993d59ab8c1f@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] ERP/Routing Issue ? 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, 07 Jul 2009 01:18:01 -0000 Hi Julien, all, > > I thought a given NAS will continue to send and receive Diameter message > from the same AAA proxy for a current Diameter Session. Am I wrong ? I don't think there is such guarantee in Diameter (but there is usually no reason for the routing table to change during a session). On the contrary, with failover / failback mechanism, it is clearly stated that the route may change during a session. Even after a redirect indication with Redirect-Host-Usage AVP set to ALL_SESSION, a message of the session might still be sent to another node as far as I understand, although this is not very clear in the Diameter Base Protocol. > For me, the issue was more when you have a HO to a new NAS. The new NAS > can't know which AAA proxy/AAA server was used by the previous NAS for > a current user. I agree this is an issue. B.R., Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Mon Jul 6 18:30:23 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 CB2723A6DD1 for ; Mon, 6 Jul 2009 18:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=0.223, 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 lsVDxW8gKRGT for ; Mon, 6 Jul 2009 18:30:23 -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 6545A3A6800 for ; Mon, 6 Jul 2009 18:30:22 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n671Uig4013551; Tue, 7 Jul 2009 10:30:44 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n671UixE022503; Tue, 7 Jul 2009 10:30:44 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n671UiGM022500; Tue, 7 Jul 2009 10:30:44 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 04B7B16B5C; Tue, 7 Jul 2009 10:30:44 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id F391016B58; Tue, 7 Jul 2009 10:30:43 +0900 (JST) Message-ID: <4A52A538.4040703@nict.go.jp> Date: Tue, 07 Jul 2009 10:30:32 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> In-Reply-To: <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 07 Jul 2009 01:30:23 -0000 Hi Julien, Julien Bournelle a écrit : > Ok, now I see your point. It is more a "internal routing issue" i.e. > how does the PROXY_A knows > if the DER message is to be routed to SERVER_B or locally handled ? Am > I right ? Well, if you consider that the NAS *always* send all the messages to the proxy_A, then yes it's an internal issue in that proxy. But if the NAS has to select to send the message to either the local EAP server, or a local proxy (usually for users belonging to foreign domains), then the issue is in the NAS, not the proxy. Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From xiajinwei@huawei.com Mon Jul 6 23:20:56 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 341143A6D31 for ; Mon, 6 Jul 2009 23:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, 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 MYOeYLQBxSzV for ; Mon, 6 Jul 2009 23:20:55 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5142A3A6CEC for ; Mon, 6 Jul 2009 23:20:55 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KME00BDEEGBD4@szxga04-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 14:09:47 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KME004FPEGBFT@szxga04-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 14:09:47 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KME00HR4EGAJ7@szxml06-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 14:09:47 +0800 (CST) Date: Tue, 07 Jul 2009 14:09:46 +0800 From: Jinwei Xia In-reply-to: <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> To: 'jouni korhonen' , dime@ietf.org Message-id: <003c01c9fec9$87837230$430ca40a@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: AcnpscYr5oQu80qwRqW4w2zulMTvdQVBgxZg Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01 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, 07 Jul 2009 06:20:56 -0000 Hi Jouni, Do you think it is better to mark this ID as updates of 5447? With the stability of MCoA and DSMIP, both feature will be added in MIP Diameter Application. However if you take PMIP feature into account, I support this ID is independent from RFC5447 and Dime-PMIPv6. In such case, IMHO "Bulk_Termination" and "Bulk_Re_Registration" should be involved in as PMIP feature. BR Jinwei > > Hi all, > > I have updated the additional feature bits draft. I did > remove some stuff so that the draft now only reserves > MIP6-Feature-Vector flag bits and nothing more. I'll forward > the draft soon to RFC editor so if anyone has comments, > please be quick :) > > Cheers, > Jouni > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: June 10, 2009 12:26:53 PM GMT+03:00 > > To: jouni.nospam@gmail.com > > Subject: New Version Notification for draft-korhonen-dime-mip6- > > feature-bits-01 > > > > > > A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt > > has been successfuly submitted by Jouni Korhonen and posted to the > > IETF repository. > > > > Filename: draft-korhonen-dime-mip6-feature-bits > > Revision: 01 > > Title: Diameter MIP6 Feature Vector > Additional Bit Allocations > > Creation_date: 2009-06-10 > > WG ID: Independent Submission > > Number_of_pages: 5 > > > > Abstract: > > During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 > > Home Agent and the Authentication, Authorization, and Accounting > > server may exchange a set of authorized mobility > capabilities. This > > document defines new mobility capability flags that are used to > > authorize per Mobile Node route optimization, Multiple > Care-of Address > > and user plane traffic encryption support. Furthermore, > this document > > also defines a capability flag of indicating whether the > Home Agent is > > authorized to act as a stand alone Virtual Private Network gateway. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Jul 7 04:27:19 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 1DC3928C45F for ; Tue, 7 Jul 2009 04:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, 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 J5cg0UjNHtdj for ; Tue, 7 Jul 2009 04:27:18 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 8606628C447 for ; Tue, 7 Jul 2009 04:27:17 -0700 (PDT) Received: by ewy26 with SMTP id 26so497054ewy.37 for ; Tue, 07 Jul 2009 04:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=wuDkGbMw0SxMK6o6Jt/s6I5/2EqahC1/r4YaPWmEDAU=; b=gwtiVFAwl5dJ57TsecTMrIWUnX48GCZzyEyC5x89B4T/KjZL+YsCrhoWqtEfasKBtz t9cz+uDFpS8pt34q9dAYx8GEci7BTsZA+oxUPxwEvKBvAYLaNKhf5avExZpPEBOlmpLQ Q9TgnIZYiBEHM0KlfWft3dIgiqBjZ+GsBpjHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=HWCD6YyKz4u8wdr+4IPu7XUTU7ZVPPopHTDt4OA7MwfLkJPVodNAdGivS+VnUUtf5U +UbhpV53cPCeIjY1gRNyXwG3L1imQ2wVcHX0wzRVBb4IQGsrCLTWlZCU9iN3eWBHi5S+ Z01v9Bv9Uffu3v1ldo/u08jrrY9ET798S0tec= Received: by 10.210.82.2 with SMTP id f2mr3885177ebb.2.1246966020564; Tue, 07 Jul 2009 04:27:00 -0700 (PDT) Received: from ?10.254.0.54? ([192.100.123.77]) by mx.google.com with ESMTPS id 5sm3594516eyh.10.2009.07.07.04.26.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 04:27:00 -0700 (PDT) Message-Id: From: jouni korhonen To: Jinwei Xia In-Reply-To: <003c01c9fec9$87837230$430ca40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 7 Jul 2009 14:26:57 +0300 References: <003c01c9fec9$87837230$430ca40a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01 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, 07 Jul 2009 11:27:19 -0000 Hi Jinwei, On Jul 7, 2009, at 9:09 AM, Jinwei Xia wrote: > Hi Jouni, > > Do you think it is better to mark this ID as updates of 5447? With > the stability of MCoA and DSMIP, both feature will be added in MIP > Diameter > Application. I don't think the draft would update RFC5447. It just uses the IANA procedures defined there. If something would be updated that is the dime-mip6-split draft. However, that is the draft we purposely removed these flags and spun off the feature-bits draft. > > However if you take PMIP feature into account, I support this ID is > independent from RFC5447 and Dime-PMIPv6. In such case, IMHO dime-pmip6 draft already defines its own feature bits. > > "Bulk_Termination" and "Bulk_Re_Registration" should be involved in > as PMIP > feature. Do you suggest adding feature bits for bulk operations (the recent work in netext)? Cheers, Jouni > > > > BR > > Jinwei > >> >> Hi all, >> >> I have updated the additional feature bits draft. I did >> remove some stuff so that the draft now only reserves >> MIP6-Feature-Vector flag bits and nothing more. I'll forward >> the draft soon to RFC editor so if anyone has comments, >> please be quick :) >> >> Cheers, >> Jouni >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>> To: jouni.nospam@gmail.com >>> Subject: New Version Notification for draft-korhonen-dime-mip6- >>> feature-bits-01 >>> >>> >>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt >>> has been successfuly submitted by Jouni Korhonen and posted to the >>> IETF repository. >>> >>> Filename: draft-korhonen-dime-mip6-feature-bits >>> Revision: 01 >>> Title: Diameter MIP6 Feature Vector >> Additional Bit Allocations >>> Creation_date: 2009-06-10 >>> WG ID: Independent Submission >>> Number_of_pages: 5 >>> >>> Abstract: >>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >>> Home Agent and the Authentication, Authorization, and Accounting >>> server may exchange a set of authorized mobility >> capabilities. This >>> document defines new mobility capability flags that are used to >>> authorize per Mobile Node route optimization, Multiple >> Care-of Address >>> and user plane traffic encryption support. Furthermore, >> this document >>> also defines a capability flag of indicating whether the >> Home Agent is >>> authorized to act as a stand alone Virtual Private Network gateway. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From xiajinwei@huawei.com Tue Jul 7 05:39:39 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 0BB2C3A6A2E for ; Tue, 7 Jul 2009 05:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 1WiS+oc233wk for ; Tue, 7 Jul 2009 05:39:38 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F07313A67CC for ; Tue, 7 Jul 2009 05:39:37 -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 <0KME005VTWFCIG@szxga01-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 20:38:00 +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 <0KME005HMWFC3Q@szxga01-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 20:38:00 +0800 (CST) Received: from x65217 ([10.164.12.67]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KME0087PWFBR7@szxml06-in.huawei.com> for dime@ietf.org; Tue, 07 Jul 2009 20:38:00 +0800 (CST) Date: Tue, 07 Jul 2009 20:37:59 +0800 From: Jinwei Xia In-reply-to: To: 'jouni korhonen' Message-id: <000901c9feff$c3425670$430ca40a@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: Acn+9rk9Tewsk7e8QXyCDe/QOA5X1gABeGSw Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01 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, 07 Jul 2009 12:39:39 -0000 Hi Jouni, Thank your feedback, please see inline. > > > > Do you think it is better to mark this ID as updates of > 5447? With > > the stability of MCoA and DSMIP, both feature will be added in MIP > > Diameter Application. > > I don't think the draft would update RFC5447. It just uses > the IANA procedures defined there. If something would be > updated that is the dime-mip6-split draft. However, that is > the draft we purposely removed these flags and spun off the > feature-bits draft. > Sure. It makes sense to spin off one feature-bits ID to maintain Dime-MIP base protocol stability . > > > > > However if you take PMIP feature into account, I > support this ID is > > independent from RFC5447 and Dime-PMIPv6. In such case, IMHO > > dime-pmip6 draft already defines its own feature bits. OK > > > > > > "Bulk_Termination" and "Bulk_Re_Registration" should be > involved in as > > PMIP feature. > > > Do you suggest adding feature bits for bulk operations (the > recent work in netext)? Yeah, since Dime-PMIP ID has entered IESG Processing stage, the remain feature bits (e.g. Bulk operations which do not standardized yet) sponsored in netext WG maybe should be added in a specific feature bits ID, make sense? BR Jinwei > > Cheers, > Jouni > > > > > > > > > > BR > > > > Jinwei > > > >> > >> Hi all, > >> > >> I have updated the additional feature bits draft. I did > remove some > >> stuff so that the draft now only reserves MIP6-Feature-Vector flag > >> bits and nothing more. I'll forward the draft soon to RFC > editor so > >> if anyone has comments, please be quick :) > >> > >> Cheers, > >> Jouni > >> > >> Begin forwarded message: > >> > >>> From: IETF I-D Submission Tool > >>> Date: June 10, 2009 12:26:53 PM GMT+03:00 > >>> To: jouni.nospam@gmail.com > >>> Subject: New Version Notification for draft-korhonen-dime-mip6- > >>> feature-bits-01 > >>> > >>> > >>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt > >>> has been successfuly submitted by Jouni Korhonen and > posted to the > >>> IETF repository. > >>> > >>> Filename: draft-korhonen-dime-mip6-feature-bits > >>> Revision: 01 > >>> Title: Diameter MIP6 Feature Vector > >> Additional Bit Allocations > >>> Creation_date: 2009-06-10 > >>> WG ID: Independent Submission > >>> Number_of_pages: 5 > >>> > >>> Abstract: > >>> During the Mobile IPv6 Split Scenario bootstrapping the > Mobile IPv6 > >>> Home Agent and the Authentication, Authorization, and Accounting > >>> server may exchange a set of authorized mobility > >> capabilities. This > >>> document defines new mobility capability flags that are used to > >>> authorize per Mobile Node route optimization, Multiple > >> Care-of Address > >>> and user plane traffic encryption support. Furthermore, > >> this document > >>> also defines a capability flag of indicating whether the > >> Home Agent is > >>> authorized to act as a stand alone Virtual Private > Network gateway. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > > From behcetsarikaya@yahoo.com Tue Jul 7 07:44: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 39AB93A6935 for ; Tue, 7 Jul 2009 07:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 FIvyXoDNGtRX for ; Tue, 7 Jul 2009 07:44:56 -0700 (PDT) Received: from n58.bullet.mail.sp1.yahoo.com (n58.bullet.mail.sp1.yahoo.com [98.136.44.46]) by core3.amsl.com (Postfix) with SMTP id 5AC293A6C82 for ; Tue, 7 Jul 2009 07:44:56 -0700 (PDT) Received: from [216.252.122.218] by n58.bullet.mail.sp1.yahoo.com with NNFMP; 07 Jul 2009 14:39:36 -0000 Received: from [67.195.9.83] by t3.bullet.sp1.yahoo.com with NNFMP; 07 Jul 2009 14:39:36 -0000 Received: from [67.195.9.109] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jul 2009 14:39:36 -0000 Received: from [127.0.0.1] by omp113.mail.gq1.yahoo.com with NNFMP; 07 Jul 2009 14:39:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 716926.7540.bm@omp113.mail.gq1.yahoo.com Received: (qmail 44221 invoked by uid 60001); 7 Jul 2009 14:39:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1246977576; bh=LP01aHGVqMQjfOKNTXExYwDv29ANnsCTM11CE9YDPUw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1/izRZ+6qZU6NsNQ8oqofwzMCdwfRNznEGdfyLzuraEnbYh3NtYwcC5CG9RI87Wcsb0yjNAvy2QlwicON1wpLbGmTgfrbjVDIfbawspHO1ZqtyYAjXx9Aua7gcfCThO2eA/xNKNBwxgVdDtlr2FH5LyF3MyHL8RVOcMp6lYXaI0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kVTIYs8W5+SRc3Fa5L00xW8TEEGyeejOQE4itlazjx7F9vRyZ4YM2VmnDPG3wWtaDqPRz1euUHwQlFxbaEnzPw7RiqxgRPNMTUfENwArfTu1XRzSy2hV1y5g4kYosKb7w/Crfp0mvhs/Y2H8HvpmaA+Y+9buMNvnjkEnranmqvI=; Message-ID: <605467.44209.qm@web111405.mail.gq1.yahoo.com> X-YMail-OSG: AjBNZdgVM1kZ2kDoFMg9yayLPOn1u9_8G7pJSY_6LCOOk5i.2gVwJpCOk4nw5Y4U5R1Xsi2vpC4lm_e_.lAdG6.677jWTMYgwmOTQ25baKqf5Xvyxx8jaTMM4VJ_iv.JjsmxvLED_OgpTopr9j6BWeXGrggU7KVBBkR_IaQGobpxBHoNg.rvJ_mnvOr6KZSmjjylJgAX9vxCmVI6sjvoOtrTEsk4ZeeLK.E8eJM_0X5LNPa.2uPqzxDs.3ZKThYIwv001pAtSfS3pg0OdTt7yuBAbj47ROD6rPnbNApDgc72VBkNbKTQqRRFFkEU6oJFaslpB3mJD02KqVTN.6t3Z34- Received: from [206.16.17.212] by web111405.mail.gq1.yahoo.com via HTTP; Tue, 07 Jul 2009 07:39:36 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> Date: Tue, 7 Jul 2009 07:39:36 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , dime@ietf.org In-Reply-To: <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:44:57 -0000 Hi Jouni,=0A=A0 Can you please add=0AIP4_IN_IP6_TUNNELING_SUPPORTED flag (w= hich could be defined as:=0AIP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000= 100)=0A)=0A=A0=0AThe need for this came out in a contribution we made to Wi= MAX NWG's IPv4/v6 Transition subteam on the scenarios for DSMIP.=0A=A0=0ARe= gards,=0A=A0=0ABehcet=0A=0A=0A=0A----- Original Message ----=0A> From: joun= i korhonen =0A> To: dime@ietf.org=0A> Sent: Wednesd= ay, June 10, 2009 4:55:36 AM=0A> Subject: [Dime] Fwd: New Version Notificat= ion for draft-korhonen-dime-mip6-feature-bits-01=0A> =0A> Hi all,=0A> =0A> = I have updated the additional feature bits draft. I did remove some stuff s= o =0A> that the draft now only reserves MIP6-Feature-Vector flag bits and n= othing more. =0A> I'll forward the draft soon to RFC editor so if anyone ha= s comments, please be =0A> quick :)=0A> =0A> Cheers,=0A> =A0=A0=A0 Jouni=0A= > =0A> Begin forwarded message:=0A> =0A> > From: IETF I-D Submission Tool = =0A> > Date: June 10, 2009 12:26:53 PM GMT+03:00=0A> > To: jouni.nospam@gma= il.com=0A> > Subject: New Version Notification for=A0 =0A> draft-korhonen-d= ime-mip6-feature-bits-01=0A> > =0A> > =0A> > A new version of I-D, draft-ko= rhonen-dime-mip6-feature-bits-01.txt has been =0A> successfuly submitted by= Jouni Korhonen and posted to the IETF repository.=0A> > =0A> > Filename:= =A0=A0=A0 draft-korhonen-dime-mip6-feature-bits=0A> > Revision:=A0=A0=A0 01= =0A> > Title:=A0=A0=A0 =A0=A0=A0 Diameter MIP6 Feature Vector Additional Bi= t Allocations=0A> > Creation_date:=A0=A0=A0 2009-06-10=0A> > WG ID:=A0=A0= =A0 =A0=A0=A0 Independent Submission=0A> > Number_of_pages: 5=0A> > =0A> > = Abstract:=0A> > During the Mobile IPv6 Split Scenario bootstrapping the Mob= ile IPv6=0A> > Home Agent and the Authentication, Authorization, and Accoun= ting=0A> > server may exchange a set of authorized mobility capabilities.= =A0 This=0A> > document defines new mobility capability flags that are used= to=0A> > authorize per Mobile Node route optimization, Multiple Care-of=0A= > > Address and user plane traffic encryption support.=A0 Furthermore, this= =0A> > document also defines a capability flag of indicating whether the=0A= > > Home Agent is authorized to act as a stand alone Virtual Private=0A> > = Network gateway.=0A> > =0A> > =0A> > =0A> > The IETF Secretariat.=0A> > =0A= > > =0A> =0A> _______________________________________________=0A> DiME mail= ing list=0A> DiME@ietf.org=0A> https://www.ietf.org/mailman/listinfo/dime= =0A=0A=0A=0A From root@core3.amsl.com Tue Jul 7 14:30:03 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 650523A694A; Tue, 7 Jul 2009 14:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090707213003.650523A694A@core3.amsl.com> Date: Tue, 7 Jul 2009 14:30:01 -0700 (PDT) Cc: dime@ietf.org, vfajardo@tari.toshiba.com Subject: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime) 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, 07 Jul 2009 21:30:03 -0000 The Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Diameter Maintenance and Extensions (dime) =========================================== Last Modified: 2009-06-10 Current Status: Working Group Chair(s): Hannes Tschofenig Victor Fajardo Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From jouni.nospam@gmail.com Tue Jul 7 23:05:12 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 2CB1A28C176 for ; Tue, 7 Jul 2009 23:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 EHquq-jxP2XM for ; Tue, 7 Jul 2009 23:05:11 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D11ED3A6821 for ; Tue, 7 Jul 2009 23:05:10 -0700 (PDT) Received: by fxm18 with SMTP id 18so5419118fxm.37 for ; Tue, 07 Jul 2009 23:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=UYlRjHxZP5Vh9q2/6+/75fi+/BZzHwRVwYyhLXN0v6I=; b=T/D5ra4BfqJpQzSbK3p9mzI9P9yZ6lExsuWu5ltwElSEi47ia/ncYHsOsY6oqnLz8I 9rmwUMT/Qy7rQ2Cf9HzSOqA54o287WdIXd4fHDfvPoE/iTlQ47KRiZ9thPMPE+g+QTZs Z/uD5SDUryXalhqFDa8kkfGyVhc75Xho8gMYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Lshjbh6yVyiR87m+1NVb2HLD2H0S0braI7Hp8X5AvI+M6YgWnFj4cQhOnSVQhexf53 nSC85giIt2Yq+M2JQvyaGOTow+H5B6BlASkTpeHUo4k3A0vvZDUEumxWnWQR3/i3nK9z FFeiymVEou7h8wWD05P993YXW4wUxztPX9iY0= Received: by 10.204.53.143 with SMTP id m15mr6527491bkg.119.1247033130268; Tue, 07 Jul 2009 23:05:30 -0700 (PDT) Received: from ?10.254.0.54? ([192.100.123.77]) by mx.google.com with ESMTPS id h2sm15228350fkh.16.2009.07.07.23.05.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 23:05:29 -0700 (PDT) Message-Id: <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> From: jouni korhonen To: Behcet Sarikaya In-Reply-To: <605467.44209.qm@web111405.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 09:05:25 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 08 Jul 2009 06:05:12 -0000 Could you point me at the relevant Wimax documents regarding the flags below? Cheers, Jouni On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: > > Hi Jouni, > Can you please add > IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: > IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) > ) > > The need for this came out in a contribution we made to WiMAX NWG's > IPv4/v6 Transition subteam on the scenarios for DSMIP. > > Regards, > > Behcet > > > > ----- Original Message ---- >> From: jouni korhonen >> To: dime@ietf.org >> Sent: Wednesday, June 10, 2009 4:55:36 AM >> Subject: [Dime] Fwd: New Version Notification for draft-korhonen- >> dime-mip6-feature-bits-01 >> >> Hi all, >> >> I have updated the additional feature bits draft. I did remove some >> stuff so >> that the draft now only reserves MIP6-Feature-Vector flag bits and >> nothing more. >> I'll forward the draft soon to RFC editor so if anyone has >> comments, please be >> quick :) >> >> Cheers, >> Jouni >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>> To: jouni.nospam@gmail.com >>> Subject: New Version Notification for >> draft-korhonen-dime-mip6-feature-bits-01 >>> >>> >>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt >>> has been >> successfuly submitted by Jouni Korhonen and posted to the IETF >> repository. >>> >>> Filename: draft-korhonen-dime-mip6-feature-bits >>> Revision: 01 >>> Title: Diameter MIP6 Feature Vector Additional Bit >>> Allocations >>> Creation_date: 2009-06-10 >>> WG ID: Independent Submission >>> Number_of_pages: 5 >>> >>> Abstract: >>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >>> Home Agent and the Authentication, Authorization, and Accounting >>> server may exchange a set of authorized mobility capabilities. This >>> document defines new mobility capability flags that are used to >>> authorize per Mobile Node route optimization, Multiple Care-of >>> Address and user plane traffic encryption support. Furthermore, >>> this >>> document also defines a capability flag of indicating whether the >>> Home Agent is authorized to act as a stand alone Virtual Private >>> Network gateway. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > > > From julien.bournelle@gmail.com Wed Jul 8 00:52:45 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 AF2273A6E5A for ; Wed, 8 Jul 2009 00:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, 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 GZQPnDupDrV7 for ; Wed, 8 Jul 2009 00:52:44 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 2584B3A6E4C for ; Wed, 8 Jul 2009 00:52:43 -0700 (PDT) Received: by bwz25 with SMTP id 25so2606498bwz.37 for ; Wed, 08 Jul 2009 00:53:06 -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=y+RXSFNdukL+BUIwV5Vzqv/6S4xnp3y3H8AEs7G+xis=; b=K1mgwgunBCW4XbbbCkGNbf3ebUMAWM2tHB5LoRYGU5zb6Sg4KrRGaJXnUJgaZyPVpV 0uI6Jj+nJmUnND3h4HtWOvxgdsgeE1+LOjWpIfl+k7V7guETmwVRqrsx1XXh5oKguU/5 BBNrnYsPEyEfhF5P/y3+PzgxuWfNm7snngAZE= 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=Dp24GYPe8koKFS+sD6Yaa5rHFcPUmL7riSSwdBJ2sxRXTlbdtA4UrIMUH8qyQ4YhKz Mzfh2S0xTwcES0XtVE6dn+VC3EkosPCy/UvZRxyn6Hwe/RK+N4XIX/IgKogR3OxubiJj PqB6C4yThMAtZE1W8D0itzO1pjPjL8t1FoYMs= MIME-Version: 1.0 Received: by 10.204.117.141 with SMTP id r13mr6706125bkq.207.1247039586493; Wed, 08 Jul 2009 00:53:06 -0700 (PDT) In-Reply-To: <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> Date: Wed, 8 Jul 2009 09:53:06 +0200 Message-ID: <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> From: Julien Bournelle To: jouni korhonen Content-Type: multipart/alternative; boundary=001636c599f692ef5f046e2d0788 Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 08 Jul 2009 07:52:45 -0000 --001636c599f692ef5f046e2d0788 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, one question maybe is if it is the IETF or IANA which will be used to register specifc SDO flags ? Maybe we could have a specific range for such allocation ? Any comments ? Julien On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen wrote: > > Could you point me at the relevant Wimax documents regarding the flags > below? > > Cheers, > Jouni > > > On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: > > >> Hi Jouni, >> Can you please add >> IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: >> IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) >> ) >> >> The need for this came out in a contribution we made to WiMAX NWG's >> IPv4/v6 Transition subteam on the scenarios for DSMIP. >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >> >>> From: jouni korhonen >>> To: dime@ietf.org >>> Sent: Wednesday, June 10, 2009 4:55:36 AM >>> Subject: [Dime] Fwd: New Version Notification for >>> draft-korhonen-dime-mip6-feature-bits-01 >>> >>> Hi all, >>> >>> I have updated the additional feature bits draft. I did remove some stuff >>> so >>> that the draft now only reserves MIP6-Feature-Vector flag bits and >>> nothing more. >>> I'll forward the draft soon to RFC editor so if anyone has comments, >>> please be >>> quick :) >>> >>> Cheers, >>> Jouni >>> >>> Begin forwarded message: >>> >>> From: IETF I-D Submission Tool >>>> Date: June 10, 2009 12:26:53 PM GMT+03:00 >>>> To: jouni.nospam@gmail.com >>>> Subject: New Version Notification for >>>> >>> draft-korhonen-dime-mip6-feature-bits-01 >>> >>>> >>>> >>>> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has >>>> been >>>> >>> successfuly submitted by Jouni Korhonen and posted to the IETF >>> repository. >>> >>>> >>>> Filename: draft-korhonen-dime-mip6-feature-bits >>>> Revision: 01 >>>> Title: Diameter MIP6 Feature Vector Additional Bit Allocations >>>> Creation_date: 2009-06-10 >>>> WG ID: Independent Submission >>>> Number_of_pages: 5 >>>> >>>> Abstract: >>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >>>> Home Agent and the Authentication, Authorization, and Accounting >>>> server may exchange a set of authorized mobility capabilities. This >>>> document defines new mobility capability flags that are used to >>>> authorize per Mobile Node route optimization, Multiple Care-of >>>> Address and user plane traffic encryption support. Furthermore, this >>>> document also defines a capability flag of indicating whether the >>>> Home Agent is authorized to act as a stand alone Virtual Private >>>> Network gateway. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>> _______________________________________________ >>> 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 > --001636c599f692ef5f046e2d0788 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0one question maybe is if it is the IETF or IANA which will= be used to register specifc SDO flags ?

=A0Maybe we could have a sp= ecific range for such allocation ?

=A0Any comments ?

=A0Julie= n

On Wed, Jul 8, 2009 at 8:05 AM, jouni korhon= en <jouni.no= spam@gmail.com> wrote:

Could you point me at the relevant Wimax documents regarding the flags belo= w?

Cheers,
=A0 =A0 =A0 =A0Jouni


On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote:


Hi Jouni,
=A0Can you please add
IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as:
IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100)
)

The need for this came out in a contribution we made to WiMAX NWG's IPv= 4/v6 Transition subteam on the scenarios for DSMIP.

Regards,

Behcet



----- Original Message ----
From: jouni korhonen <jouni.nospam@gmail.com>
To: dime@ietf.org Sent: Wednesday, June 10, 2009 4:55:36 AM
Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-= feature-bits-01

Hi all,

I have updated the additional feature bits draft. I did remove some stuff s= o
that the draft now only reserves MIP6-Feature-Vector flag bits and nothing = more.
I'll forward the draft soon to RFC editor so if anyone has comments, pl= ease be
quick :)

Cheers,
=A0 =A0Jouni

Begin forwarded message:

From: IETF I-D Submission Tool
Date: June 10, 2009 12:26:53 PM GMT+03:00
To: jouni.nospa= m@gmail.com
Subject: New Version Notification for
draft-korhonen-dime-mip6-feature-bits-01


A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has been=
successfuly submitted by Jouni Korhonen and posted to the IETF repository.<= br>

Filename: =A0 =A0draft-korhonen-dime-mip6-feature-bits
Revision: =A0 =A001
Title: =A0 =A0 =A0 =A0Diameter MIP6 Feature Vector Additional Bit Allocatio= ns
Creation_date: =A0 =A02009-06-10
WG ID: =A0 =A0 =A0 =A0Independent Submission
Number_of_pages: 5

Abstract:
During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
Home Agent and the Authentication, Authorization, and Accounting
server may exchange a set of authorized mobility capabilities. =A0This
document defines new mobility capability flags that are used to
authorize per Mobile Node route optimization, Multiple Care-of
Address and user plane traffic encryption support. =A0Furthermore, this
document also defines a capability flag of indicating whether the
Home Agent is authorized to act as a stand alone Virtual Private
Network gateway.



The IETF Secretariat.



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






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

--001636c599f692ef5f046e2d0788-- From jouni.nospam@gmail.com Wed Jul 8 01:25: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 A41063A6948 for ; Wed, 8 Jul 2009 01:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 Cs3udQYPJ-MZ for ; Wed, 8 Jul 2009 01:25:20 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 21E453A684D for ; Wed, 8 Jul 2009 01:25:19 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1171445eye.65 for ; Wed, 08 Jul 2009 01:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=P+ca7GXevjtB54v4nWuE1i6wgVUQA1F5EgPlnVOojAU=; b=xM+EnP5wuvI8r4odA6Tfie4L5lGBxigBTUec8qiiYWGF0x6UpAvfPbRcPz8jc31NC8 CENAXXY9oiiedi4Aql+6rj/6LtI2MeUq4g43tXXbJ9tBdqBEb4ZP1vS9KD/lpRVU1o1C GdgI8c60Nu3oTPHIeoE0i7m1PR4xlH0tpWgHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=kQ3kH6sIDaKnpkSY/7wBJrh5RvNvHUD8ZtKs2EjCoXrEQ/nt5rBCJqvFjpkWQVaTOZ iIiLVnNimTuLsxmkdFfd9KTFWGyJbAaYUdc5EBLvD5LqcK1rgQ+UvNGlqeQ5WPUOxWGm Dkf6v4aO9ScdQRPXrUV+WOTKI0GDBeh8x7Syc= Received: by 10.210.92.8 with SMTP id p8mr8375404ebb.7.1247041502464; Wed, 08 Jul 2009 01:25:02 -0700 (PDT) Received: from ?10.254.0.54? ([192.100.123.77]) by mx.google.com with ESMTPS id 5sm1415336eyf.34.2009.07.08.01.25.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 01:25:01 -0700 (PDT) Message-Id: <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> From: jouni korhonen To: Julien Bournelle In-Reply-To: <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 11:24:58 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 08 Jul 2009 08:25:22 -0000 Hi Julien, Well, the IANA allocation rules were crafted so that other SDOs could easily allocate their own flags once they document flag usage (the document can be any publicly available proper spec/document, not just RFC). Having said that, allocating flags "ahead" without relevant documentation which properly describe the use and need is not really what we want. And having said that, I basically self-conclude most flags the current I-D proposes are not needed ;) Cheers, Jouni On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote: > Hello, > > one question maybe is if it is the IETF or IANA which will be used > to register specifc SDO flags ? > > Maybe we could have a specific range for such allocation ? > > Any comments ? > > Julien > > On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen > wrote: > > Could you point me at the relevant Wimax documents regarding the > flags below? > > Cheers, > Jouni > > > On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: > > > Hi Jouni, > Can you please add > IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: > IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) > ) > > The need for this came out in a contribution we made to WiMAX NWG's > IPv4/v6 Transition subteam on the scenarios for DSMIP. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: jouni korhonen > To: dime@ietf.org > Sent: Wednesday, June 10, 2009 4:55:36 AM > Subject: [Dime] Fwd: New Version Notification for draft-korhonen- > dime-mip6-feature-bits-01 > > Hi all, > > I have updated the additional feature bits draft. I did remove some > stuff so > that the draft now only reserves MIP6-Feature-Vector flag bits and > nothing more. > I'll forward the draft soon to RFC editor so if anyone has comments, > please be > quick :) > > Cheers, > Jouni > > Begin forwarded message: > > From: IETF I-D Submission Tool > Date: June 10, 2009 12:26:53 PM GMT+03:00 > To: jouni.nospam@gmail.com > Subject: New Version Notification for > draft-korhonen-dime-mip6-feature-bits-01 > > > A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt > has been > successfuly submitted by Jouni Korhonen and posted to the IETF > repository. > > Filename: draft-korhonen-dime-mip6-feature-bits > Revision: 01 > Title: Diameter MIP6 Feature Vector Additional Bit Allocations > Creation_date: 2009-06-10 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 > Home Agent and the Authentication, Authorization, and Accounting > server may exchange a set of authorized mobility capabilities. This > document defines new mobility capability flags that are used to > authorize per Mobile Node route optimization, Multiple Care-of > Address and user plane traffic encryption support. Furthermore, this > document also defines a capability flag of indicating whether the > Home Agent is authorized to act as a stand alone Virtual Private > Network gateway. > > > > The IETF Secretariat. > > > > _______________________________________________ > 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 julien.bournelle@gmail.com Wed Jul 8 05:04: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 7793B3A6894 for ; Wed, 8 Jul 2009 05:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, 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 cx3HM7O-ikb7 for ; Wed, 8 Jul 2009 05:04:13 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 3DD633A6AA6 for ; Wed, 8 Jul 2009 05:03:51 -0700 (PDT) Received: by bwz25 with SMTP id 25so2750085bwz.37 for ; Wed, 08 Jul 2009 05:03:16 -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=E/U5lteE2X8KyGbi7vzm4q3RyDhKnFFcBGf/mYV+WKQ=; b=HuX4Ymx2UzOlpaPQmchB4U4J9fhp711dbkrY8OV0g5x58H0Lcm5EP1FbiwRzp2BmaW 3r9VGK4f9I4g0mfJYD3IT16cdqrSY7nQLnkTE/Rwms622H4FDEzSSDxNk1h+lk9uSOwm 17W92llSfWFtrS/84pct6SFnSR53NRFoluQBE= 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=MhiWF426YapXTGlQU3APg7WQwwmldqS73/jhzxmaT3lPzj6z5yzEqUioKUPrpPPDX+ bkl441SLyPSGIl0NM4cZv6uw1+uAAD4j9mePRljcn6228sbu06mo/n1JQmhCDko/4V7H hNqtLdL/Ybs2GNMoqFbcLlCNXDb2wyvM6NQRg= MIME-Version: 1.0 Received: by 10.204.66.2 with SMTP id l2mr6900568bki.177.1247054596844; Wed, 08 Jul 2009 05:03:16 -0700 (PDT) In-Reply-To: <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> Date: Wed, 8 Jul 2009 14:03:16 +0200 Message-ID: <5e2406980907080503w1eb1ad03o89a4601375c74ecb@mail.gmail.com> From: Julien Bournelle To: jouni korhonen Content-Type: multipart/alternative; boundary=001636c5bded42af1b046e3086af Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 08 Jul 2009 12:04:14 -0000 --001636c5bded42af1b046e3086af Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi jouni, On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen wrote: > Hi Julien, > > Well, the IANA allocation rules were crafted so that other SDOs could > easily allocate their own flags once they document flag usage (the document > can be any publicly available proper spec/document, not just RFC). Having > said that, allocating flags "ahead" without relevant documentation which > properly describe the use and need is not really what we want. And having > said that, I basically self-conclude most flags the current I-D proposes are > not needed ;) not sure to catch your conclusion ! :) > > > Cheers, > Jouni > > > > On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote: > > Hello, >> >> one question maybe is if it is the IETF or IANA which will be used to >> register specifc SDO flags ? >> >> Maybe we could have a specific range for such allocation ? >> >> Any comments ? >> >> Julien >> >> On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen >> wrote: >> >> Could you point me at the relevant Wimax documents regarding the flags >> below? >> >> Cheers, >> Jouni >> >> >> On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: >> >> >> Hi Jouni, >> Can you please add >> IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: >> IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) >> ) >> >> The need for this came out in a contribution we made to WiMAX NWG's >> IPv4/v6 Transition subteam on the scenarios for DSMIP. >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >> From: jouni korhonen >> To: dime@ietf.org >> Sent: Wednesday, June 10, 2009 4:55:36 AM >> Subject: [Dime] Fwd: New Version Notification for >> draft-korhonen-dime-mip6-feature-bits-01 >> >> Hi all, >> >> I have updated the additional feature bits draft. I did remove some stuff >> so >> that the draft now only reserves MIP6-Feature-Vector flag bits and nothing >> more. >> I'll forward the draft soon to RFC editor so if anyone has comments, >> please be >> quick :) >> >> Cheers, >> Jouni >> >> Begin forwarded message: >> >> From: IETF I-D Submission Tool >> Date: June 10, 2009 12:26:53 PM GMT+03:00 >> To: jouni.nospam@gmail.com >> Subject: New Version Notification for >> draft-korhonen-dime-mip6-feature-bits-01 >> >> >> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has >> been >> successfuly submitted by Jouni Korhonen and posted to the IETF repository. >> >> Filename: draft-korhonen-dime-mip6-feature-bits >> Revision: 01 >> Title: Diameter MIP6 Feature Vector Additional Bit Allocations >> Creation_date: 2009-06-10 >> WG ID: Independent Submission >> Number_of_pages: 5 >> >> Abstract: >> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >> Home Agent and the Authentication, Authorization, and Accounting >> server may exchange a set of authorized mobility capabilities. This >> document defines new mobility capability flags that are used to >> authorize per Mobile Node route optimization, Multiple Care-of >> Address and user plane traffic encryption support. Furthermore, this >> document also defines a capability flag of indicating whether the >> Home Agent is authorized to act as a stand alone Virtual Private >> Network gateway. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> 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 >> >> > --001636c5bded42af1b046e3086af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi jouni,

On Wed, Jul 8, 2009 at 10:24 AM= , jouni korhonen <jouni.nospam@gmail.com> wrote:
Hi Julien,

Well, the IANA allocation rules were crafted so that other SDOs could easil= y allocate their own flags once they document flag usage (the document can = be any publicly available proper spec/document, not just RFC). Having said = that, allocating flags "ahead" without relevant documentation whi= ch properly describe the use and need is not really what we want. And havin= g said that, I basically self-conclude most flags the current I-D proposes = are not needed ;)


=A0not sure to catch your conclusion ! :)
=A0


Cheers,
=A0 =A0 =A0 =A0Jouni



On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote:

Hello,

=A0one question maybe is if it is the IETF or IANA which will be used to re= gister specifc SDO flags ?

=A0Maybe we could have a specific range for such allocation ?

=A0Any comments ?

=A0Julien

On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
Could you point me at the relevant Wimax documents regarding the flags belo= w?

Cheers,
=A0 =A0 =A0 Jouni


On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote:


Hi Jouni,
=A0Can you please add
IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as:
IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100)
)

The need for this came out in a contribution we made to WiMAX NWG's IPv= 4/v6 Transition subteam on the scenarios for DSMIP.

Regards,

Behcet



----- Original Message ----
From: jouni korhonen <jouni.nospam@gmail.com>
To: dime@ietf.org Sent: Wednesday, June 10, 2009 4:55:36 AM
Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-= feature-bits-01

Hi all,

I have updated the additional feature bits draft. I did remove some stuff s= o
that the draft now only reserves MIP6-Feature-Vector flag bits and nothing = more.
I'll forward the draft soon to RFC editor so if anyone has comments, pl= ease be
quick :)

Cheers,
=A0 Jouni

Begin forwarded message:

From: IETF I-D Submission Tool
Date: June 10, 2009 12:26:53 PM GMT+03:00
To: jouni.nospa= m@gmail.com
Subject: New Version Notification for
draft-korhonen-dime-mip6-feature-bits-01


A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has been=
successfuly submitted by Jouni Korhonen and posted to the IETF repository.<= br>
Filename: =A0 =A0draft-korhonen-dime-mip6-feature-bits
Revision: =A0 =A001
Title: =A0 =A0 =A0 =A0Diameter MIP6 Feature Vector Additional Bit Allocatio= ns
Creation_date: =A0 =A02009-06-10
WG ID: =A0 =A0 =A0 =A0Independent Submission
Number_of_pages: 5

Abstract:
During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
Home Agent and the Authentication, Authorization, and Accounting
server may exchange a set of authorized mobility capabilities. =A0This
document defines new mobility capability flags that are used to
authorize per Mobile Node route optimization, Multiple Care-of
Address and user plane traffic encryption support. =A0Furthermore, this
document also defines a capability flag of indicating whether the
Home Agent is authorized to act as a stand alone Virtual Private
Network gateway.



The IETF Secretariat.



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






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



--001636c5bded42af1b046e3086af-- From behcetsarikaya@yahoo.com Wed Jul 8 07:58:03 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 7E4F93A6A78 for ; Wed, 8 Jul 2009 07:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 NVwc4MOEvrpE for ; Wed, 8 Jul 2009 07:58:02 -0700 (PDT) Received: from n71.bullet.mail.sp1.yahoo.com (n71.bullet.mail.sp1.yahoo.com [98.136.44.36]) by core3.amsl.com (Postfix) with SMTP id 9B0153A697C for ; Wed, 8 Jul 2009 07:58:02 -0700 (PDT) Received: from [216.252.122.216] by n71.bullet.mail.sp1.yahoo.com with NNFMP; 08 Jul 2009 14:58:20 -0000 Received: from [67.195.9.83] by t1.bullet.sp1.yahoo.com with NNFMP; 08 Jul 2009 14:58:19 -0000 Received: from [67.195.9.102] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jul 2009 14:58:19 -0000 Received: from [127.0.0.1] by omp106.mail.gq1.yahoo.com with NNFMP; 08 Jul 2009 14:58:19 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 773095.72880.bm@omp106.mail.gq1.yahoo.com Received: (qmail 61312 invoked by uid 60001); 8 Jul 2009 14:58:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247065099; bh=o8z2oTB8Nrf0mE37NSRww1B/ica1i+BOudLOi8Og1Ms=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=z2s03hX4fYAIElIHoyYYcqrGgLGBslmelO1YMM6iywjt792fxObk5Po6sudZMZn4IolqOgL7kVhd5AWZt4PDQtAccqn7OfPaAbNvy8mWDgUIbFNYGeWloA2CJFP5cPt6IZrYJEfgSzETzXQpRl6zdfSKuukYY6gQch5EAQMNrAQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ceV1D48diFds9fPRqhTLdHg1kXp0WoysK6uFok/wf+kecLfrQg8xxCR5O6Ywn1ZLtA124Leh4WpMSHFdiJTD8PGwiHybuft70Br4/IO4EeF1JTzgvvMh3TUz47K0nWFT8CLEG2W4JJQ+6RhXnQN1DbfakdHGFcWTuqeKPVNNSUU=; Message-ID: <663599.60533.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: wFdsRKEVM1n88EB5x3F1Def98U5FjkbWgG2S2pkauGzFyjGcAm.r4IAkYpxnLUW0cpziK1eEXIiUwnRNibIEBucocihehAcsf3E9nP2b7JNli3WOKsnhB2p98umFHCMsPxB3QNYRcuvAH3suQpBNb__luH4lsfwc.Z0cGJS5C_LRRHc26huRsx6.pu5PPxQp5l8uTUy0NRFUoMArRwXJfE_oPsJg8gISZ3rugDUqHASoXA8czkxckeyagVvottwim1xMjhxy6nkRQm3FSXL2AOpR9PS3iFPLS3GQUaQWBW.3edIbtb081XIIPJJ9VglLcB39JhDy5r9vZrBCYUM.aCQ- Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Wed, 08 Jul 2009 07:58:19 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> Date: Wed, 8 Jul 2009 07:58:19 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen , Julien Bournelle In-Reply-To: <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:58:03 -0000 =0A=0A=0A=0A----- Original Message ----=0A> From: jouni korhonen =0A> To: Julien Bournelle =0A> Cc= : Behcet Sarikaya ; dime@ietf.org=0A> Sent: Wednesday, J= uly 8, 2009 3:24:58 AM=0A> Subject: Re: [Dime] Fwd: New Version Notificatio= n for draft-korhonen-dime-mip6-feature-bits-01=0A> =0A> Hi Julien,=0A> =0A>= Well, the IANA allocation rules were crafted so that other SDOs could easi= ly =0A> allocate their own flags once they document flag usage (the documen= t can be any =0A> publicly available proper spec/document, not just RFC). H= aving said that, =0A> allocating flags "ahead" without relevant documentati= on which properly describe =0A> the use and need is not really what we want= .. And having said that, I basically =0A> self-conclude most flags the curre= nt I-D proposes are not needed ;)=0A=0A=0AThis is a good point.=0AIn the do= cument I mentioned one of them:=0A=A0IP4_HOA_SUPPORTED (0x0000020000000000)= =0A=A0=0Ais being used though.=0A=A0=0ARegards,=0A=A0=0ABehcet=0A=0A> =0A> = Cheers,=0A> =A0=A0=A0 Jouni=0A> =0A> =0A> On Jul 8, 2009, at 10:53 AM, Juli= en Bournelle wrote:=0A> =0A> > Hello,=0A> > =0A> >=A0 one question maybe is= if it is the IETF or IANA which will be used to =0A> register specifc SDO = flags ?=0A> > =0A> >=A0 Maybe we could have a specific range for such alloc= ation ?=0A> > =0A> >=A0 Any comments ?=0A> > =0A> >=A0 Julien=0A> > =0A> > = On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen wrote:=0A> > =0A> > Could yo= u point me at the relevant Wimax documents regarding the flags below?=0A> >= =0A> > Cheers,=0A> >=A0 =A0 =A0 =A0 Jouni=0A> > =0A> > =0A> > On Jul 7, 20= 09, at 5:39 PM, Behcet Sarikaya wrote:=0A> > =0A> > =0A> > Hi Jouni,=0A> >= =A0 Can you please add=0A> > IP4_IN_IP6_TUNNELING_SUPPORTED flag (which cou= ld be defined as:=0A> > IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100)= =0A> > )=0A> > =0A> > The need for this came out in a contribution we made = to WiMAX NWG's IPv4/v6 =0A> Transition subteam on the scenarios for DSMIP.= =0A> > =0A> > Regards,=0A> > =0A> > Behcet=0A> > =0A> > =0A> > =0A> > -----= Original Message ----=0A> > From: jouni korhonen =0A> > To: dime@ietf.org= =0A> > Sent: Wednesday, June 10, 2009 4:55:36 AM=0A> > Subject: [Dime] Fwd:= New Version Notification for =0A> draft-korhonen-dime-mip6-feature-bits-01= =0A> > =0A> > Hi all,=0A> > =0A> > I have updated the additional feature bi= ts draft. I did remove some stuff so=0A> > that the draft now only reserves= MIP6-Feature-Vector flag bits and nothing =0A> more.=0A> > I'll forward th= e draft soon to RFC editor so if anyone has comments, please be=0A> > quick= :)=0A> > =0A> > Cheers,=0A> >=A0 =A0 Jouni=0A> > =0A> > Begin forwarded me= ssage:=0A> > =0A> > From: IETF I-D Submission Tool=0A> > Date: June 10, 200= 9 12:26:53 PM GMT+03:00=0A> > To: jouni.nospam@gmail.com=0A> > Subject: New= Version Notification for=0A> > draft-korhonen-dime-mip6-feature-bits-01=0A= > > =0A> > =0A> > A new version of I-D, draft-korhonen-dime-mip6-feature-bi= ts-01.txt has been=0A> > successfuly submitted by Jouni Korhonen and posted= to the IETF repository.=0A> > =0A> > Filename:=A0 =A0 draft-korhonen-dime-= mip6-feature-bits=0A> > Revision:=A0 =A0 01=0A> > Title:=A0 =A0 =A0 =A0 Dia= meter MIP6 Feature Vector Additional Bit Allocations=0A> > Creation_date:= =A0 =A0 2009-06-10=0A> > WG ID:=A0 =A0 =A0 =A0 Independent Submission=0A> >= Number_of_pages: 5=0A> > =0A> > Abstract:=0A> > During the Mobile IPv6 Spl= it Scenario bootstrapping the Mobile IPv6=0A> > Home Agent and the Authenti= cation, Authorization, and Accounting=0A> > server may exchange a set of au= thorized mobility capabilities.=A0 This=0A> > document defines new mobility= capability flags that are used to=0A> > authorize per Mobile Node route op= timization, Multiple Care-of=0A> > Address and user plane traffic encryptio= n support.=A0 Furthermore, this=0A> > document also defines a capability fl= ag of indicating whether the=0A> > Home Agent is authorized to act as a sta= nd alone Virtual Private=0A> > Network gateway.=0A> > =0A> > =0A> > =0A> > = The IETF Secretariat.=0A> > =0A> > =0A> > =0A> > __________________________= _____________________=0A> > DiME mailing list=0A> > DiME@ietf.org=0A> > htt= ps://www.ietf.org/mailman/listinfo/dime=0A> > =0A> > =0A> > =0A> > =0A> > = =0A> > =0A> > _______________________________________________=0A> > DiME ma= iling list=0A> > DiME@ietf.org=0A> > https://www.ietf.org/mailman/listinfo/= dime=0A> > =0A=0A=0A=0A From jouni.nospam@gmail.com Wed Jul 8 12:03: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 2C6F53A6B7A for ; Wed, 8 Jul 2009 12:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivBCjJVFee6D for ; Wed, 8 Jul 2009 12:03:19 -0700 (PDT) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by core3.amsl.com (Postfix) with ESMTP id EAF3D3A6B34 for ; Wed, 8 Jul 2009 12:03:18 -0700 (PDT) Received: from a88-112-142-60.elisa-laajakaista.fi (a88-112-142-60.elisa-laajakaista.fi [88.112.142.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id C5D6E1518FD; Wed, 8 Jul 2009 22:03:40 +0300 (EEST) Message-Id: From: jouni To: Julien Bournelle In-Reply-To: <5e2406980907080503w1eb1ad03o89a4601375c74ecb@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 22:03:39 +0300 References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> <5e2406980907080503w1eb1ad03o89a4601375c74ecb@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 08 Jul 2009 19:03:20 -0000 Hi Julien, On Jul 8, 2009, at 3:03 PM, Julien Bournelle wrote: > Hi jouni, > > On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen > wrote: > Hi Julien, > > Well, the IANA allocation rules were crafted so that other SDOs > could easily allocate their own flags once they document flag usage > (the document can be any publicly available proper spec/document, > not just RFC). Having said that, allocating flags "ahead" without > relevant documentation which properly describe the use and need is > not really what we want. And having said that, I basically self- > conclude most flags the current I-D proposes are not needed ;) > > > not sure to catch your conclusion ! :) ;) Meaning.. SDOs could (should) go and allocate feature vector flag bits on their own directly from IANA, once they have appropriate documentation.. without getting involved in IETF WG level process. Regarding the proper documentation, I realize that draft-korhonen-dime- mip6-feature-bits does not really do a good job at explaining "use & need" for some flags it aims to allocate. JOuni > > > > Cheers, > Jouni > > > > On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote: > > Hello, > > one question maybe is if it is the IETF or IANA which will be used > to register specifc SDO flags ? > > Maybe we could have a specific range for such allocation ? > > Any comments ? > > Julien > > On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen > wrote: > > Could you point me at the relevant Wimax documents regarding the > flags below? > > Cheers, > Jouni > > > On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: > > > Hi Jouni, > Can you please add > IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: > IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) > ) > > The need for this came out in a contribution we made to WiMAX NWG's > IPv4/v6 Transition subteam on the scenarios for DSMIP. > > Regards, > > Behcet > > > > ----- Original Message ---- > From: jouni korhonen > To: dime@ietf.org > Sent: Wednesday, June 10, 2009 4:55:36 AM > Subject: [Dime] Fwd: New Version Notification for draft-korhonen- > dime-mip6-feature-bits-01 > > Hi all, > > I have updated the additional feature bits draft. I did remove some > stuff so > that the draft now only reserves MIP6-Feature-Vector flag bits and > nothing more. > I'll forward the draft soon to RFC editor so if anyone has comments, > please be > quick :) > > Cheers, > Jouni > > Begin forwarded message: > > From: IETF I-D Submission Tool > Date: June 10, 2009 12:26:53 PM GMT+03:00 > To: jouni.nospam@gmail.com > Subject: New Version Notification for > draft-korhonen-dime-mip6-feature-bits-01 > > > A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt > has been > successfuly submitted by Jouni Korhonen and posted to the IETF > repository. > > Filename: draft-korhonen-dime-mip6-feature-bits > Revision: 01 > Title: Diameter MIP6 Feature Vector Additional Bit Allocations > Creation_date: 2009-06-10 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 > Home Agent and the Authentication, Authorization, and Accounting > server may exchange a set of authorized mobility capabilities. This > document defines new mobility capability flags that are used to > authorize per Mobile Node route optimization, Multiple Care-of > Address and user plane traffic encryption support. Furthermore, this > document also defines a capability flag of indicating whether the > Home Agent is authorized to act as a stand alone Virtual Private > Network gateway. > > > > The IETF Secretariat. > > > > _______________________________________________ > 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 julien.bournelle@gmail.com Thu Jul 9 00:28:36 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 16CF33A67DD for ; Thu, 9 Jul 2009 00:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 f27UTH6xW7uY for ; Thu, 9 Jul 2009 00:28:34 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 2F6F728C14C for ; Thu, 9 Jul 2009 00:28:34 -0700 (PDT) Received: by bwz25 with SMTP id 25so3337781bwz.37 for ; Thu, 09 Jul 2009 00:28:58 -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=Orn8+Box9NYDu3BstbbhE4HGni683dBxudlcX/sWAR8=; b=EnsEtxI9zg7aLZ4FbM5XedWSiGAKLxILJb7pLHKf9+fVHXPA0oJ2QAw2L6rKvTlIAr aPqJ+xx/Ijuitcb7X3wnYcfUiblUAUo7X+I6TQHxuQtOzfBExzIoMRodE7JaetPprV5P mHZfcVj3gzD61wIpeoBODotSV1/CAI5UoXzcs= 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=MW1ARrQHkSVpGSINNwx/3xu6HmXrgplb9sd6oEuVlwptBdYqRDXI6WYIUkrysHxi+F 0leuQlwwvyDDNSCRJZOxm7WKptqkWicDCsCeWm1rshewGa5zj1uWcjwJyyHW/BFi+fj3 +B8qbFREhMD1CL3riVWa+M/CyfBs76OBqiiYU= MIME-Version: 1.0 Received: by 10.204.58.9 with SMTP id e9mr439532bkh.23.1247124537990; Thu, 09 Jul 2009 00:28:57 -0700 (PDT) In-Reply-To: References: <20090610092653.601A33A6E07@core3.amsl.com> <1CE00542-32BF-4344-884C-CCDC763FA853@gmail.com> <605467.44209.qm@web111405.mail.gq1.yahoo.com> <0E6B99B1-F87F-47FD-9C3B-9417AFED18E5@gmail.com> <5e2406980907080053s27947281i495195c060b10976@mail.gmail.com> <121392FB-EC60-4651-B60C-9FB4E65CE5CB@gmail.com> <5e2406980907080503w1eb1ad03o89a4601375c74ecb@mail.gmail.com> Date: Thu, 9 Jul 2009 09:28:57 +0200 Message-ID: <5e2406980907090028i5ba97861m77cc03dd7e3e0a83@mail.gmail.com> From: Julien Bournelle To: jouni Content-Type: multipart/alternative; boundary=001636c5bcc513df4e046e40cffd Cc: dime@ietf.org Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01 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, 09 Jul 2009 07:28:36 -0000 --001636c5bcc513df4e046e40cffd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Wed, Jul 8, 2009 at 9:03 PM, jouni wrote: > Hi Julien, > > On Jul 8, 2009, at 3:03 PM, Julien Bournelle wrote: > > Hi jouni, >> >> On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen >> wrote: >> Hi Julien, >> >> Well, the IANA allocation rules were crafted so that other SDOs could >> easily allocate their own flags once they document flag usage (the document >> can be any publicly available proper spec/document, not just RFC). Having >> said that, allocating flags "ahead" without relevant documentation which >> properly describe the use and need is not really what we want. And having >> said that, I basically self-conclude most flags the current I-D proposes are >> not needed ;) >> >> >> not sure to catch your conclusion ! :) >> > > ;) Meaning.. SDOs could (should) go and allocate feature vector flag bits > on their own directly from IANA, once they have appropriate documentation.. > without getting involved in IETF WG level process. ok, I see. Maybe we could add a little section explaining this. > > Regarding the proper documentation, I realize that > draft-korhonen-dime-mip6-feature-bits does not really do a good job at > explaining "use & need" for some flags it aims to allocate. i'll re-read the current draft and provide comments ASAP. regards, Julien > > > > JOuni > > > > >> >> >> Cheers, >> Jouni >> >> >> >> On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote: >> >> Hello, >> >> one question maybe is if it is the IETF or IANA which will be used to >> register specifc SDO flags ? >> >> Maybe we could have a specific range for such allocation ? >> >> Any comments ? >> >> Julien >> >> On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen >> wrote: >> >> Could you point me at the relevant Wimax documents regarding the flags >> below? >> >> Cheers, >> Jouni >> >> >> On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote: >> >> >> Hi Jouni, >> Can you please add >> IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as: >> IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100) >> ) >> >> The need for this came out in a contribution we made to WiMAX NWG's >> IPv4/v6 Transition subteam on the scenarios for DSMIP. >> >> Regards, >> >> Behcet >> >> >> >> ----- Original Message ---- >> From: jouni korhonen >> To: dime@ietf.org >> Sent: Wednesday, June 10, 2009 4:55:36 AM >> Subject: [Dime] Fwd: New Version Notification for >> draft-korhonen-dime-mip6-feature-bits-01 >> >> Hi all, >> >> I have updated the additional feature bits draft. I did remove some stuff >> so >> that the draft now only reserves MIP6-Feature-Vector flag bits and nothing >> more. >> I'll forward the draft soon to RFC editor so if anyone has comments, >> please be >> quick :) >> >> Cheers, >> Jouni >> >> Begin forwarded message: >> >> From: IETF I-D Submission Tool >> Date: June 10, 2009 12:26:53 PM GMT+03:00 >> To: jouni.nospam@gmail.com >> Subject: New Version Notification for >> draft-korhonen-dime-mip6-feature-bits-01 >> >> >> A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has >> been >> successfuly submitted by Jouni Korhonen and posted to the IETF repository. >> >> Filename: draft-korhonen-dime-mip6-feature-bits >> Revision: 01 >> Title: Diameter MIP6 Feature Vector Additional Bit Allocations >> Creation_date: 2009-06-10 >> WG ID: Independent Submission >> Number_of_pages: 5 >> >> Abstract: >> During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 >> Home Agent and the Authentication, Authorization, and Accounting >> server may exchange a set of authorized mobility capabilities. This >> document defines new mobility capability flags that are used to >> authorize per Mobile Node route optimization, Multiple Care-of >> Address and user plane traffic encryption support. Furthermore, this >> document also defines a capability flag of indicating whether the >> Home Agent is authorized to act as a stand alone Virtual Private >> Network gateway. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> 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 >> >> >> >> > --001636c5bcc513df4e046e40cffd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Wed, Jul 8, 2009 at 9:03 PM, jo= uni <jouni.n= ospam@gmail.com> wrote:
Hi Julien,


On Jul 8, 2009, at 3:03 PM, Julien Bournelle wrote:

Hi jouni,

On Wed, Jul 8, 2009 at 10:24 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:<= br> Hi Julien,

Well, the IANA allocation rules were crafted so that other SDOs could easil= y allocate their own flags once they document flag usage (the document can = be any publicly available proper spec/document, not just RFC). Having said = that, allocating flags "ahead" without relevant documentation whi= ch properly describe the use and need is not really what we want. And havin= g said that, I basically self-conclude most flags the current I-D proposes = are not needed ;)


=A0not sure to catch your conclusion ! :)

;) =A0Meaning.. SDOs could (should) go and allocate feature vector flag bit= s on their own directly from IANA, once they have appropriate documentation= .. without getting involved in IETF WG level process.

=A0ok, I see. Maybe we could add a little section explaining this.
=A0

Regarding the proper documentation, I realize that draft-korhonen-dime-mip6= -feature-bits does not really do a good job at explaining "use & n= eed" for some flags it aims to allocate.

i'll= re-read the current draft and provide comments ASAP.

regards,

=A0Julien

=A0



JOuni






Cheers,
=A0 =A0 =A0 Jouni



On Jul 8, 2009, at 10:53 AM, Julien Bournelle wrote:

Hello,

=A0one question maybe is if it is the IETF or IANA which will be used to re= gister specifc SDO flags ?

=A0Maybe we could have a specific range for such allocation ?

=A0Any comments ?

=A0Julien

On Wed, Jul 8, 2009 at 8:05 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
Could you point me at the relevant Wimax documents regarding the flags belo= w?

Cheers,
=A0 =A0 =A0Jouni


On Jul 7, 2009, at 5:39 PM, Behcet Sarikaya wrote:


Hi Jouni,
=A0Can you please add
IP4_IN_IP6_TUNNELING_SUPPORTED flag (which could be defined as:
IP4_IN_IP6_TUNNELING_SUPPORTED (0x0000000000000100)
)

The need for this came out in a contribution we made to WiMAX NWG's IPv= 4/v6 Transition subteam on the scenarios for DSMIP.

Regards,

Behcet



----- Original Message ----
From: jouni korhonen <jouni.nospam@gmail.com>
To: dime@ietf.org Sent: Wednesday, June 10, 2009 4:55:36 AM
Subject: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-= feature-bits-01

Hi all,

I have updated the additional feature bits draft. I did remove some stuff s= o
that the draft now only reserves MIP6-Feature-Vector flag bits and nothing = more.
I'll forward the draft soon to RFC editor so if anyone has comments, pl= ease be
quick :)

Cheers,
=A0Jouni

Begin forwarded message:

From: IETF I-D Submission Tool
Date: June 10, 2009 12:26:53 PM GMT+03:00
To: jouni.nospa= m@gmail.com
Subject: New Version Notification for
draft-korhonen-dime-mip6-feature-bits-01


A new version of I-D, draft-korhonen-dime-mip6-feature-bits-01.txt has been=
successfuly submitted by Jouni Korhonen and posted to the IETF repository.<= br>
Filename: =A0 =A0draft-korhonen-dime-mip6-feature-bits
Revision: =A0 =A001
Title: =A0 =A0 =A0 =A0Diameter MIP6 Feature Vector Additional Bit Allocatio= ns
Creation_date: =A0 =A02009-06-10
WG ID: =A0 =A0 =A0 =A0Independent Submission
Number_of_pages: 5

Abstract:
During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6
Home Agent and the Authentication, Authorization, and Accounting
server may exchange a set of authorized mobility capabilities. =A0This
document defines new mobility capability flags that are used to
authorize per Mobile Node route optimization, Multiple Care-of
Address and user plane traffic encryption support. =A0Furthermore, this
document also defines a capability flag of indicating whether the
Home Agent is authorized to act as a stand alone Virtual Private
Network gateway.



The IETF Secretariat.



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






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





--001636c5bcc513df4e046e40cffd-- From Marco.Liebsch@nw.neclab.eu Fri Jul 10 07:59:45 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 E5BA43A6E57 for ; Fri, 10 Jul 2009 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 jxA2h0-jae-e for ; Fri, 10 Jul 2009 07:59:45 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D229428C347 for ; Fri, 10 Jul 2009 07:59:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id D385C2C02047C for ; Fri, 10 Jul 2009 16:59:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF946vXC2j+U for ; Fri, 10 Jul 2009 16:59:35 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id B53A52C0203FF for ; Fri, 10 Jul 2009 16:59:30 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:59:30 +0200 Message-ID: <4A575744.108@nw.neclab.eu> Date: Fri, 10 Jul 2009 16:59:16 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 14:59:30.0740 (UTC) FILETIME=[07351F40:01CA016F] Subject: [Dime] Diameter query for mobility anchor resolution 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, 10 Jul 2009 14:59:46 -0000 Hello, during last IETF, I got the chance to present an idea about mobility anchor resolution by means of a Diameter Server query (draft-liebsch-dime-pmip6-lmaresolve-00.txt). One use case I referred to was the resolution of mobile nodes' Home Network Prefix into the routable address of its mobility anchor. Such function is needed to coordinate route optimization in Proxy Mobile IPv6 where state information of mobile nodes can be distributed between multiple mobility anchors. During the meeting we discussed also the possibility to add a general query mechanism to Diameter to support such resolution. Regarding the example use case from above, the NetExt WG has been formed now and has route optimization (aka localized routing) on its charter. Two individual drafts for localized routing refer to the need of anchor resolution: http://www.ietf.org/internet-drafts/draft-loureiro-netext-pmipv6-ro-00.txt http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-02.txt Since DIME is about to update its charter, I'd like to point to the abovementioned topic again, which may be of interest to the group. marco From vfajardo@research.telcordia.com Fri Jul 10 09:04:28 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 0D1E33A6C82 for ; Fri, 10 Jul 2009 09:04:28 -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=1.752, 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 OiPvkVpAU6eF for ; Fri, 10 Jul 2009 09:04:27 -0700 (PDT) Received: from mail.mailsnare.net (g78.mailsnare.net [209.236.228.78]) by core3.amsl.com (Postfix) with ESMTP id D890A28C340 for ; Fri, 10 Jul 2009 09:04:14 -0700 (PDT) X-Virus-Scanned: by ClamAV at mailsnare.net Received: from [192.4.8.194] (unknown [192.4.8.194]) by mail.mailsnare.net (Postfix) with ESMTP id 6D7D141746; Fri, 10 Jul 2009 16:04:42 +0000 (UTC) Message-ID: <4A576684.7070802@research.telcordia.com> Date: Fri, 10 Jul 2009 12:04:20 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Glen Zorn References: <005901c9e81f$e49b8f40$add2adc0$@net> In-Reply-To: <005901c9e81f$e49b8f40$add2adc0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, 'Victor Fajardo' Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20 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, 10 Jul 2009 16:04:28 -0000 Hi Glen, Sorry for the late response. The editorials are ok. > > > TECHNICAL > > Section 1.2 > I think that the definition of "Diameter Client" is a bit too restrictive: > it's not hard to imagine Diameter clients that are not strictly speaking > devices or don't sit at the edge of a network or do not (directly) perform > access control functions. I suggest rewriting the definition in terms of > Diameter Node, maybe something like: > "A Diameter Client is a Diameter Node that supports Diameter client > applications as well as the base protocol. Diameter Clients are often > implemented in devices situated at the edge of a network and provide access > control services for that network. Typical examples of Diameter Clients > include the Network Access Server (NAS) and the Mobile IP Foreign Agent > (FA)." > your suggestion looks good to me. -- victor > In the definition of "Downstream", a more general statement might be > obtained by replacing "access device" with "Diameter Client" > > The definition of "Session state" doesn't really make sense to me: it > doesn't actually define session state, but does define a stateful agent. > > In the definition of "Upstream", a more general statement might be obtained > by replacing "access device" with "Diameter Client" > > > > From vfajardo@research.telcordia.com Fri Jul 10 09:05:27 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 A61D33A6C82 for ; Fri, 10 Jul 2009 09:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.431 X-Spam-Level: X-Spam-Status: No, score=-1.431 tagged_above=-999 required=5 tests=[AWL=1.168, 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 lncILZgthOrK for ; Fri, 10 Jul 2009 09:05:27 -0700 (PDT) Received: from mail.mailsnare.net (g78.mailsnare.net [209.236.228.78]) by core3.amsl.com (Postfix) with ESMTP id E88E23A693A for ; Fri, 10 Jul 2009 09:05:26 -0700 (PDT) X-Virus-Scanned: by ClamAV at mailsnare.net Received: from [192.4.8.194] (unknown [192.4.8.194]) by mail.mailsnare.net (Postfix) with ESMTP id 0551241734; Fri, 10 Jul 2009 16:05:54 +0000 (UTC) Message-ID: <4A5766CD.1020506@research.telcordia.com> Date: Fri, 10 Jul 2009 12:05:33 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Glen Zorn References: <005901c9e81f$e49b8f40$add2adc0$@net> <004801c9edaf$2d2551d0$876ff570$@net> In-Reply-To: <004801c9edaf$2d2551d0$876ff570$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, 'Victor Fajardo' Subject: Re: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 21-30 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, 10 Jul 2009 16:05:27 -0000 > TECHNICAL > > Section 2 > --------- > I don't really understand this section, nor even why it is included For > example: > > Diameter Clients MUST support the base protocol, which includes > accounting. In addition, they MUST fully support each Diameter > application that is needed to implement the client's service, e.g., > NASREQ and/or Mobile IPv4. A Diameter Client that does not support > both NASREQ and Mobile IPv4, MUST be referred to as "Diameter X > Client" where X is the application which it supports, and not a > "Diameter Client". > > There are a ton of Diameter applications; what's so special about NASREQ & > MIPv4? Even if there is a rationale for keeping this part of the original > text, section 2 in bis doesn't seem like any improvement of section 2 of RFC > 3588. > I definitely agree. NASREQ and Mobile IPv4 should be struck out in the last sentence. Pls check out the latest draft rev for the updated text. -- victor From root@core3.amsl.com Fri Jul 10 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 E93293A6E6B; Fri, 10 Jul 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: <20090710161501.E93293A6E6B@core3.amsl.com> Date: Fri, 10 Jul 2009 09:15:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-18.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, 10 Jul 2009 16:15: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 Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-18.txt Pages : 159 Date : 2009-07-10 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-18.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-rfc3588bis-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10090110.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Sun Jul 12 01:18:04 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 003253A6A25 for ; Sun, 12 Jul 2009 01:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.872 X-Spam-Level: X-Spam-Status: No, score=-0.872 tagged_above=-999 required=5 tests=[AWL=-0.873, 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 TVPzbdReN9gW for ; Sun, 12 Jul 2009 01:18:03 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 949B53A683D for ; Sun, 12 Jul 2009 01:18:02 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2009 08:18:30 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp009) with SMTP; 12 Jul 2009 10:18:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18sUdRkrdgsXQ7hkV2bxLonGWH/Wbjb8LyKMDmP+p ethLztmR97XKoP From: "Hannes Tschofenig" To: "'Mark Jones'" , References: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034C95@m679t05.fpmis.bridgewatersys.com> Date: Sun, 12 Jul 2009 11:20:48 +0300 Message-ID: <186801ca02c9$aa058150$501ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E0F60BAF2FA7C46BBB5474DF8A89BCD022F034C95@m679t05.fpmis.bridgewatersys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acn4zMguFnarNKd4QT6lWGKyxVbNXQJ+baWw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Subject: Re: [Dime] Review of draft-ietf-dime-diameter-cmd-iana 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, 12 Jul 2009 08:18:04 -0000 Hi Mark, Thanks for the review. >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Mark Jones >Sent: 29 June, 2009 18:18 >To: dime@ietf.org >Subject: [Dime] Review of draft-ietf-dime-diameter-cmd-iana > >I realize that this is past the review deadline but hope it is >not too late for consideration. My comments on the Abstract >and Introduction are editorial but the meat of it (the IANA >considerations) looks fine to me. > >Abstract: >--- >Suggest rewording: > RFC 3588 illustrates the conditions that > lead to the need to define a new Diameter application or a new > command code. >To: > RFC3588 illustrates the conditions which require the definition of > a new Diameter application or a new ommand. Fixed. >--- >Suggest rewording: > This document aligns the extensibility rules of Diameter application > with the Diameter commands offering ways to >To: > This document aligns the extensibility rules for Diameter >command codes > with those defined for Diameter application identifiers and offers a > consistent way to Fixed. >=== > >1. Introduction > >Suggest rewording: > This is achieved by splitting the command code space into an IANA > administered code space, and a vendors-specific code space with > different rules of allocation as per [RFC5226]. >To: > This is achieved by splitting the command code space into an IETF > code space, and a vendors-specific code space with different rules > of allocation as per [RFC5226]. > Fixed. >The whole command code space is still under IANA administration, right? Yes. I changed the wording to make it more clear. > >--- > >Typo: > s/[I-D.ietf-dime-rfc3588bis]./[I-D.ietf-dime-rfc3588bis] Update here: http://www.tschofenig.priv.at/svn/draft-romascanu-diameter-cmd-iana/draft-ie tf-dime-diameter-cmd-iana-01.txt Ciao Hannes > >--- > >Regards >Mark >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From gwz@net-zen.net Sun Jul 12 03:12: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 094D23A68A7 for ; Sun, 12 Jul 2009 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_20=-0.74, 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 0iniGT8AXWoO for ; Sun, 12 Jul 2009 03:12:30 -0700 (PDT) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 510563A680F for ; Sun, 12 Jul 2009 03:12:30 -0700 (PDT) Received: (qmail 713 invoked from network); 12 Jul 2009 10:12:59 -0000 Received: from unknown (124.122.161.145) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 12 Jul 2009 10:12:58 -0000 From: "Glen Zorn" To: Date: Sun, 12 Jul 2009 17:08:49 +0700 Organization: Network Zen Message-ID: <003001ca02d8$c209e3e0$461daba0$@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: AcoC2L4CQziXdBlZSeWDUQrFdIkP5w== Content-Language: en-us x-cr-hashedpuzzle: BO90 Bo9c CJDl CyeU EWd8 E1gx FSz1 FgXd GKrz H2SL H33B IBfq IgKZ IoAw I2Fh I+4D; 1; ZABpAG0AZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {5164FFE3-9123-4BF7-A484-7F2FF3FE9DC9}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Sun, 12 Jul 2009 10:08:45 GMT; UAByAG8AYgBsAGUAbQBzACAAdwBpAHQAaAAgAGYAbwByAG0AYQB0AHQAaQBuAGcAIABpAG4AIABoAHQAdABwADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMALwBkAHIAYQBmAHQALQBpAGUAdABmAC0AZABpAG0AZQAtAGQAaQBhAG0AZQB0AGUAcgAtAHEAbwBzAC0AMAA4AC4AdAB4AHQA x-cr-puzzleid: {5164FFE3-9123-4BF7-A484-7F2FF3FE9DC9} Subject: [Dime] Problems with formatting in http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-08.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: Sun, 12 Jul 2009 10:12:31 -0000 The ASCII art is all screwed up, as are the tables in the IANA Considerations section. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From glenzorn@comcast.net Sun Jul 12 04:41:55 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 55C733A68FD for ; Sun, 12 Jul 2009 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaU9qWq4HVsc for ; Sun, 12 Jul 2009 04:41:54 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5AA763A67B3 for ; Sun, 12 Jul 2009 04:41:53 -0700 (PDT) Received: from OMTA20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Ezgl1c0011YDfWL56ziQmQ; Sun, 12 Jul 2009 11:42:24 +0000 Received: from gwzPC ([124.122.161.145]) by OMTA20.westchester.pa.mail.comcast.net with comcast id EzjR1c00438XUcC3gzjXXB; Sun, 12 Jul 2009 11:43:36 +0000 From: "Glen Zorn" To: Date: Sun, 12 Jul 2009 18:38:02 +0700 Message-ID: <004c01ca02e5$3dac0350$b90409f0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004D_01CA031F.EA0ADB50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoC5GQt1WNWtYmFQSewcVo25StBbwAAJf4w Content-Language: en-us Subject: [Dime] FW: I-D Action:draft-huang-dime-pcn-collection-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: Sun, 12 Jul 2009 11:41:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004D_01CA031F.EA0ADB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI. BTW, the authors would like to 1) discuss the draft at the Stockholm meeting and 2) request that the draft be considered as WG work item. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Sunday, July 12, 2009 6:30 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-huang-dime-pcn-collection-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Diameter Precongestion Notification (PCN) Data Collection Application Author(s) : F. Huang, et al. Filename : draft-huang-dime-pcn-collection-01.txt Pages : 15 Date : 2009-07-12 Pre-Congestion notification (PCN) is a technique for maintaining QoS for inelastic flows in a DIFFServ domain. The PCN architecture requires that egress nodes send reports of congestion-related events (flow admission state change, excess flow) reliably to a policy decision point. The ITU-T is working on a variant of this architecture which places the policy decision point in a central node rather than ingress or egress nodes of the network. In this case the policy decision point must request and obtain certain data from an ingress node when it receives an excess flow report affecting that ingress node. This memo defines a Diameter application to support egress node reporting and data collection from the ingress node. The nature of the data flows requires the policy decision point to act both as server and as client. Hence this memo draws upon the precedent established by the Rw application (RFC 5431 and ITU-T Recommendation Q.3303.3). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huang-dime-pcn-collection-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_000_004D_01CA031F.EA0ADB50 Content-Type: Message/External-body; name="draft-huang-dime-pcn-collection-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-huang-dime-pcn-collection-01.txt" Content-Type: text/plain Content-ID: <2009-07-12042336.I-D@ietf.org> ------=_NextPart_000_004D_01CA031F.EA0ADB50 Content-Type: text/plain; name="ATT00074.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00074.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_004D_01CA031F.EA0ADB50-- From julien.bournelle@gmail.com Mon Jul 13 02:12:55 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 A0DDA28C225 for ; Mon, 13 Jul 2009 02:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.028, 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 ehkFiY+3bpul for ; Mon, 13 Jul 2009 02:12:54 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 4967E3A6BCE for ; Mon, 13 Jul 2009 02:12:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so2048755fxm.37 for ; Mon, 13 Jul 2009 02:13:22 -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=42kyf+dS9WQ/Irsfv/KnaUC+AIQ/+I7E6ohAMjJ3Nz0=; b=vZBvh/T500mVFOgi4iBdyJAP8iiC0Auz/f9tr8Tp30paVSLHRRQajPBDrcpscYwa2c gsUU+aDcOff1oihxtdYk/83HskdoQlzRoar1EZO+N+/cfGZiSK9LIPSmPoFY0qIAdop9 Fx8riNHl2JinUTHYfBYuBlD/HhughdZ+yFasY= 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=lSde/eEaGyJQbEIAu61VbBPoGskF8IW5umfK1dGgb4o8442QNRILDz9jIupbSTlMEX iqeFPH9uvKRAje23Ipeqdq9qqnWThgNet184XF7+A1krW7rXBy1Bd/kJsel2k9Z65E+S FUjUjxlD21qL9Z6trTgzN462r6rApdAGYoJVI= MIME-Version: 1.0 Received: by 10.204.116.212 with SMTP id n20mr5007814bkq.138.1247476402138; Mon, 13 Jul 2009 02:13:22 -0700 (PDT) In-Reply-To: <4A52A538.4040703@nict.go.jp> References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> Date: Mon, 13 Jul 2009 11:13:22 +0200 Message-ID: <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e6d999dad0ad77046e92bb19 Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 13 Jul 2009 09:12:55 -0000 --0016e6d999dad0ad77046e92bb19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, On Tue, Jul 7, 2009 at 3:30 AM, Sebastien Decugis wrot= e: > Hi Julien, > > Julien Bournelle a =E9crit : > > Ok, now I see your point. It is more a "internal routing issue" i.e. > > how does the PROXY_A knows > > if the DER message is to be routed to SERVER_B or locally handled ? Am > > I right ? > Well, if you consider that the NAS *always* send all the messages to the > proxy_A, then yes it's an internal issue in that proxy. But, isn't the NAI set to keyname-NAI which contains the local domain as "domain" ? If this is the case, we don't have anymore the internal issue in the proxy= . However, this seems cleaner to pass the message to the ERP stack than to the local EAP stack. Other views on this ? > But if the NAS has to select to send the message to either the local EAP > server, or a local proxy (usually for users belonging to foreign > domains), then the issue is in the NAS, not the proxy. but here, this is a different issue. And in this case, having an app-id doesn't help very much. It only helps if you assume that you have only ONE local ERP server in the domain. But you also may assume that you have ONE AAA proxy. We have to divide the two issues IMHO. Regards, Julien > > > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016e6d999dad0ad77046e92bb19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

=A0
On Tue, Jul 7, 2009 at 3:30= AM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi Julien,

Julien Bournelle a =E9crit :
> =A0Ok, now I see your point. It is more a "inte= rnal routing issue" i.e.
> how does the PROXY_A knows
> if the DER message is to be routed to SERVER_B or locally handled ? Am=
> I right ?
Well, if you consider that the NAS *always* send all the messages to = the
proxy_A, then yes it's an internal issue in that proxy.

=A0But, isn't the NAI set to keyname-NAI which contains the local= domain as "domain" ?
=A0
=A0If this is the case, we don= 9;t have anymore the internal issue in the proxy.

=A0However, this seems cleaner to pass the message to the ERP stack tha= n to the local EAP stack.

=A0Other views on this ?


=

But if the NAS has to select to send the message to either the local EAP server, or a local proxy (usually for users belonging to foreign
domains), then the issue is in the NAS, not the proxy.

=A0but here, this is a different issue. And in this case, having an ap= p-id doesn't help very much. It only helps if you assume that you have = only ONE local ERP server in the domain. But you also may assume that you h= ave ONE AAA proxy.

=A0We have to divide the two issues IMHO.

=A0Regards,

=A0= Julien


Sebastien.

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


--0016e6d999dad0ad77046e92bb19-- From root@core3.amsl.com Mon Jul 13 10:30:06 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 9FB7128C563; Mon, 13 Jul 2009 10:30:03 -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: <20090713173005.9FB7128C563@core3.amsl.com> Date: Mon, 13 Jul 2009 10:30:03 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-cmd-iana-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, 13 Jul 2009 17:30:06 -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 : Updated IANA Considerations for Diameter Command Code Allocations Author(s) : D. Romascanu, H. Tschofenig Filename : draft-ietf-dime-diameter-cmd-iana-01.txt Pages : 10 Date : 2009-07-13 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cmd-iana-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-diameter-cmd-iana-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13101938.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 11: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 D1CE128C4D8; Mon, 13 Jul 2009 11: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: <20090713180001.D1CE128C4D8@core3.amsl.com> Date: Mon, 13 Jul 2009 11:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18: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 Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-09.txt Pages : 16 Date : 2009-07-13 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13105155.I-D@ietf.org> --NextPart-- From tom.taylor@rogers.com Mon Jul 13 11:02: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 1A82E28C364 for ; Mon, 13 Jul 2009 11:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 MqkaJqDgUigz for ; Mon, 13 Jul 2009 11:02:32 -0700 (PDT) Received: from smtp128.rog.mail.re2.yahoo.com (smtp128.rog.mail.re2.yahoo.com [206.190.53.33]) by core3.amsl.com (Postfix) with SMTP id 258C928C356 for ; Mon, 13 Jul 2009 11:01:58 -0700 (PDT) Received: (qmail 17711 invoked from network); 13 Jul 2009 18:02:23 -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=dxfMrD6tRmAQ+A4Eo5+8B7ZiCGhPOvDwrobgDK1RKWZg7PGSwUXeplUgWwz5pPlzAqC0+KQzBsRDQNwtUhbgKuJ2yyVwWkVF2l5PqAzTEIQbw7bFy6K+xqNf+jtvJH6EmGaHW1x9NAUfAcjL3rFWJKblNw/uUZW3faEymoWyEoo= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp128.rog.mail.re2.yahoo.com with SMTP; 13 Jul 2009 18:02:23 -0000 X-YMail-OSG: BOm5yBQVM1nJKSIgwWYSLvOs8g1F46puXiLZfhFKT1bZwPW63ZUU1F3H.k8fqKZK9A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5B76AD.302@rogers.com> Date: Mon, 13 Jul 2009 14:02:21 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: jouni korhonen References: <001101c9ebf2$d0af4450$720dccf0$@net> <4A35BC11.2060005@nict.go.jp> <3D3C75174CB95F42AD6BCC56E5555B4501712480@FIESEXC015.nsn-intra.net> <2BD72045-AD95-48A6-9DC3-B8454D2D26F5@gmail.com> In-Reply-To: <2BD72045-AD95-48A6-9DC3-B8454D2D26F5@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-tsou-dime-realm-based-redirect-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: Mon, 13 Jul 2009 18:02:33 -0000 Jouni, I'd be interested in what you mean by a back-to-back type solution. Can you give more details? jouni korhonen wrote: > Well.. I don't personally know of any concrete requirements, yet. > However, a plethora of (mobile) operators have just started to work on > their Diameter based roaming recommendations (LTE roaming), so I would > say that not too many (mobile) operator has yet realized what they will > exactly need at Diameter level. > > Still, the concept proposed by this draft could be an useful tool. Not > necessarily in the "problem context" the draft presents and the solution > could be different. One thing I was thinking here is whether the > redirection could be achieved transparently. For example a back-to-back > type solution could probably work and would not require support from > originating hosts or agents beyond those doing the redirection.. > > Cheers, > Jouni > ... From root@core3.amsl.com Mon Jul 13 11: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 852613A6E71; Mon, 13 Jul 2009 11: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: <20090713183001.852613A6E71@core3.amsl.com> Date: Mon, 13 Jul 2009 11:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-09.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18: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 Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-09.txt Pages : 58 Date : 2009-07-13 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13111931.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 14: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 CFEC928C63A; Mon, 13 Jul 2009 14: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: <20090713214501.CFEC928C63A@core3.amsl.com> Date: Mon, 13 Jul 2009 14:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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, 13 Jul 2009 21: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 : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-13.txt Pages : 42 Date : 2009-07-13 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-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-qos-attributes-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13144331.I-D@ietf.org> --NextPart-- From tom.taylor@rogers.com Mon Jul 13 18:27:19 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 06E573A6CA2 for ; Mon, 13 Jul 2009 18:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 khb-QAjld4jf for ; Mon, 13 Jul 2009 18:27:17 -0700 (PDT) Received: from smtp109.rog.mail.re2.yahoo.com (smtp109.rog.mail.re2.yahoo.com [68.142.225.207]) by core3.amsl.com (Postfix) with SMTP id 81C303A6E21 for ; Mon, 13 Jul 2009 18:27:17 -0700 (PDT) Received: (qmail 3671 invoked from network); 14 Jul 2009 01:27:46 -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:Content-Type:Content-Transfer-Encoding; b=Jm0OrJ8/GhjHyaMWtA5M3ZMfxtduvuVFjAORb2deyQQ5RQUKALbNZdFfDr20DzYmRb8xY3lQqgmVjIkanb9HObkGsbOuxKen8ahnEZpqr/BiOEJPXtEU+eT6WJd6SgbuTzuwGXZOmAjV0zwAb2FQbBObC3mU4OoqqSjsbgnKaPk= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 14 Jul 2009 01:27:46 -0000 X-YMail-OSG: aHst5cIVM1mV_OkvG_He8YzvN4k30TvclQy5s72xSa.43uKIi_AQOP8Gwx7rINN7GQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5BDF11.1040706@rogers.com> Date: Mon, 13 Jul 2009 21:27:45 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 01:27:19 -0000 I updated this based on comments received from Glen Zorn, Sebastien Decugis, and Wolfgang Steigerwald. The basic approach was to create a Standards Track document updating RFC 3588, using a new Result-Code value, and including Error-Reporting-Host so legacy systems don't get confused. -------- Original Message -------- Subject: New Version Notification for draft-tsou-dime-realm-based-redirect-01 Date: Mon, 13 Jul 2009 17:19:39 -0700 (PDT) From: IETF I-D Submission Tool To: tom.taylor@rogers.com CC: tena@huawei.com A new version of I-D, draft-tsou-dime-realm-based-redirect-01.txt has been successfuly submitted by Tom Taylor and posted to the IETF repository. Filename: draft-tsou-dime-realm-based-redirect Revision: 01 Title: Realm-Based Redirection In Diameter Creation_date: 2009-07-14 WG ID: Independent Submission Number_of_pages: 5 Abstract: 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. The IETF Secretariat. From sdecugis@nict.go.jp Mon Jul 13 18:28: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 0B1FB28C458 for ; Mon, 13 Jul 2009 18:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=0.240, 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 NFU5goxx4SR1 for ; Mon, 13 Jul 2009 18:28:34 -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 6EBD528C41C for ; Mon, 13 Jul 2009 18:28:33 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n6E1Ss8M015058; Tue, 14 Jul 2009 10:28:54 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n6E1SsOj014735; Tue, 14 Jul 2009 10:28:54 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n6E1SseA014732; Tue, 14 Jul 2009 10:28:54 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id BC8AC2C4BF; Tue, 14 Jul 2009 10:28:54 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id B671F2C493; Tue, 14 Jul 2009 10:28:54 +0900 (JST) Message-ID: <4A5BDF43.50900@nict.go.jp> Date: Tue, 14 Jul 2009 10:28:35 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> In-Reply-To: <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 14 Jul 2009 01:28:35 -0000 Hi, > But, isn't the NAI set to keyname-NAI which contains the local domain > as "domain" ? > > If this is the case, we don't have anymore the internal issue in the > proxy. Sure, but once again, it means that local EAP messages are also sent to the proxy, not directly to the EAP server. This is unrelated to the situation I exposed in the opening mail. > > > But if the NAS has to select to send the message to either the > local EAP > server, or a local proxy (usually for users belonging to foreign > domains), then the issue is in the NAS, not the proxy. > > > > but here, this is a different issue. And in this case, having an > app-id doesn't help very much. No, this *is* the issue for which I opened the thread. An the separate application-id *does* help separate the messages between ERP proxy(es) and EAP proxy(es) that do very different processing on the messages, so it is logical to separate them IMHO. > It only helps if you assume that you have only ONE local ERP server in > the domain. The issue when there are several ERP proxies must be studied, true. A solution could be that all the keys are always distributed to all the proxies. We'd need a new command for this purpose. > But you also may assume that you have ONE AAA proxy. I don't agree. EAP and ERP proxy are very different in nature. We should not impose that they are collocated. > We have to divide the two issues IMHO. What is the first issue exactly? I opened the thread only about the second (routing in the NAS). Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Jul 13 21:54: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 56CEC3A6903 for ; Mon, 13 Jul 2009 21:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 NwRxUfvOtPgr for ; Mon, 13 Jul 2009 21:54:40 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 7602F3A6AC8 for ; Mon, 13 Jul 2009 21:54:03 -0700 (PDT) Received: (qmail 24706 invoked from network); 14 Jul 2009 04:53:28 -0000 Received: from unknown (124.120.216.207) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 14 Jul 2009 04:53:28 -0000 From: "Glen Zorn" To: "'Tom Taylor'" References: <4A5BDF11.1040706@rogers.com> In-Reply-To: <4A5BDF11.1040706@rogers.com> Date: Tue, 14 Jul 2009 11:49:14 +0700 Organization: Network Zen Message-ID: <000301ca043e$72cc8550$58658ff0$@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: AcoEIk4mvXYLJe7ISve4/r3epj3ulQAEMSBg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 04:54:44 -0000 Tom Taylor [mailto://tom.taylor@rogers.com] writes: > I updated this based on comments received from Glen Zorn, Sebastien > Decugis, and > Wolfgang Steigerwald. The basic approach was to create a Standards > Track > document updating RFC 3588, using a new Result-Code value, and > including > Error-Reporting-Host so legacy systems don't get confused. Section 2.1.1. says "the redirect agent MUST insert a Redirect-Realm AVP containing the realm from the routing table entry in its answer message instead of one or more Redirect-Host AVPs" but section 2.1.2. says: A Diameter node conforming to this specification which receives an answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION SHOULD attempt to reroute the request to the indicated realm rather than the individual host(s) specified in Redirect-Host AVP(s) in the redirect indication. The former implies that no Redirect-Host AVPs would be present in the message but the latter suggests the opposite. Which one is it? Section 2.2 says: The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It specifies a realm to which a node receiving a redirect indication containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION and this AVP SHOULD route the original request. The M and V flags for the Redirect-Realm AVP MUST NOT be set. Of course, it's not possible for a Diameter message to be routed to a realm: it has to be sent to a Diameter node. How is the node to be chosen? What happens if the selected node is unavailable? What happens if the receiver doesn't know about any nodes in the realm. Also, AVPs don't route requests ;-). In section 2.2, s/containingthe/containing the/ > > -------- Original Message -------- > Subject: New Version Notification for > draft-tsou-dime-realm-based-redirect-01 > Date: Mon, 13 Jul 2009 17:19:39 -0700 (PDT) > From: IETF I-D Submission Tool > To: tom.taylor@rogers.com > CC: tena@huawei.com > > > A new version of I-D, draft-tsou-dime-realm-based-redirect-01.txt has > been > successfuly submitted by Tom Taylor and posted to the IETF repository. > > Filename: draft-tsou-dime-realm-based-redirect > Revision: 01 > Title: Realm-Based Redirection In Diameter > Creation_date: 2009-07-14 > WG ID: Independent Submission > Number_of_pages: 5 > > Abstract: > 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. > > > > The IETF Secretariat. > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Mon Jul 13 22:04: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 AD9433A6903 for ; Mon, 13 Jul 2009 22:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=0.248, 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 BVpCZzlZYJOW for ; Mon, 13 Jul 2009 22:04:23 -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 380AA3A68BB for ; Mon, 13 Jul 2009 22:03:55 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n6E54NRu003597; Tue, 14 Jul 2009 14:04:23 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n6E54N6J003460; Tue, 14 Jul 2009 14:04:23 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n6E54Nl3003457; Tue, 14 Jul 2009 14:04:23 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 543572C38F; Tue, 14 Jul 2009 14:04:23 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 48A582C38E; Tue, 14 Jul 2009 14:04:23 +0900 (JST) Message-ID: <4A5C11C4.6070609@nict.go.jp> Date: Tue, 14 Jul 2009 14:04:04 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Glen Zorn References: <4A5BDF11.1040706@rogers.com> <000301ca043e$72cc8550$58658ff0$@net> In-Reply-To: <000301ca043e$72cc8550$58658ff0$@net> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] Re: [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 05:04:24 -0000 Hi, > Section 2.2 says: > The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It > specifies a realm to which a node receiving a redirect indication > containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION > and this AVP SHOULD route the original request. The M and V flags > for the Redirect-Realm AVP MUST NOT be set. > Of course, it's not possible for a Diameter message to be routed to a realm: > it has to be sent to a Diameter node. How is the node to be chosen? What > happens if the selected node is unavailable? What happens if the receiver > doesn't know about any nodes in the realm. I was assuming that the mechanism(s) described in RFC3588 section 5.2 would be implicitly used here (Ex: NAPTR requests). The node receiving this indication may also already have a routing entry for the new (intermediate) destination realm. My 2 cents... Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From gwz@net-zen.net Mon Jul 13 23: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 8FEE53A6C06 for ; Mon, 13 Jul 2009 23:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 zWUy97uEX2qy for ; Mon, 13 Jul 2009 23:10:57 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id BB8703A6A48 for ; Mon, 13 Jul 2009 23:10:57 -0700 (PDT) Received: (qmail 28085 invoked from network); 14 Jul 2009 05:43:44 -0000 Received: from unknown (124.120.216.207) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 14 Jul 2009 05:43:43 -0000 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <4A5BDF11.1040706@rogers.com> <000301ca043e$72cc8550$58658ff0$@net> <4A5C11C4.6070609@nict.go.jp> In-Reply-To: <4A5C11C4.6070609@nict.go.jp> Date: Tue, 14 Jul 2009 12:39:30 +0700 Organization: Network Zen Message-ID: <000401ca0445$783ae2a0$68b0a7e0$@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: AcoEQJIo5VBnuyXjTUa/7dYoo44CaQABKXQg Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] Re: [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 06:10:58 -0000 Sebastien Decugis [mailto:sdecugis@nict.go.jp] writes: > Hi, > > > Section 2.2 says: > > The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It > > specifies a realm to which a node receiving a redirect indication > > containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION > > and this AVP SHOULD route the original request. The M and V flags > > for the Redirect-Realm AVP MUST NOT be set. > > Of course, it's not possible for a Diameter message to be routed to a > realm: > > it has to be sent to a Diameter node. How is the node to be chosen? > What > > happens if the selected node is unavailable? What happens if the > receiver > > doesn't know about any nodes in the realm. > I was assuming that the mechanism(s) described in RFC3588 section 5.2 > would be implicitly used here (Ex: NAPTR requests). That's what I would assume, to, but I don't think that you should need to make any assumptions. ... From gwz@net-zen.net Tue Jul 14 05:08:17 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 D53F83A699C for ; Tue, 14 Jul 2009 05:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 Y0KKEdfB7-X4 for ; Tue, 14 Jul 2009 05:08:16 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id C23713A68E2 for ; Tue, 14 Jul 2009 05:08:16 -0700 (PDT) Received: (qmail 31610 invoked from network); 14 Jul 2009 11:40:29 -0000 Received: from unknown (124.120.216.207) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 14 Jul 2009 11:40:28 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Victor Fajardo'" References: <20090701090005.623B33A6BFA@core3.amsl.com> <004301c9fa30$3327cb70$99776250$@net> In-Reply-To: <004301c9fa30$3327cb70$99776250$@net> Date: Tue, 14 Jul 2009 18:36:12 +0700 Organization: Network Zen Message-ID: <003c01ca0477$4d7960a0$e86c21e0$@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: Acn6KmUw24vAxoN/QRubwazt8kSh2wABalDAApHK52A= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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, 14 Jul 2009 12:08:18 -0000 Proto write-up, anyone? ~ gwz Half a loaf is better than no loafing at all. --T-Bone Slim > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Wednesday, July 01, 2009 4:42 PM > To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'Victor Fajardo' > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib- > 01.txt > > I have addressed all the comments received during WGLC. Can we take > the > next step down the long & winding road to RFC publication? > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, July 01, 2009 4:00 PM > > To: i-d-announce@ietf.org > > Cc: dime@ietf.org > > Subject: I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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 : Diameter Credit Control Application MIB > > Author(s) : G. Zorn, S. Comerica > > Filename : draft-ietf-dime-diameter-cc-appl-mib-01.txt > > Pages : 20 > > Date : 2009-07-01 > > > > Along with providing support for certain basic authentication, > > authorization and accounting functions, the Diameter base protocol is > > intended to provide a framework for AAA applications. > > > > This document defines the Management Information Base (MIB) module > > which describes the minimum set of objects needed to manage an > > implementation of the Diameter Credit Control Application. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl- > > mib-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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From hannes.tschofenig@nsn.com Tue Jul 14 05:21: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 905123A6A98 for ; Tue, 14 Jul 2009 05:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-0.829, 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 9DpgMzuYdPo3 for ; Tue, 14 Jul 2009 05:21:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 606F83A6822 for ; Tue, 14 Jul 2009 05:21:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6EC0oi3010587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2009 14:00:50 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6EC0nXs015770; Tue, 14 Jul 2009 14:00:50 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 14:00:50 +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: Tue, 14 Jul 2009 15:03:09 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450187F528@FIESEXC015.nsn-intra.net> In-Reply-To: <003c01ca0477$4d7960a0$e86c21e0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-01.txt Thread-Index: Acn6KmUw24vAxoN/QRubwazt8kSh2wABalDAApHK52AAAO4swA== References: <20090701090005.623B33A6BFA@core3.amsl.com> <004301c9fa30$3327cb70$99776250$@net> <003c01ca0477$4d7960a0$e86c21e0$@net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Glen Zorn" , "Victor Fajardo" X-OriginalArrivalTime: 14 Jul 2009 12:00:50.0077 (UTC) FILETIME=[BAD8C4D0:01CA047A] Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib-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, 14 Jul 2009 12:21:21 -0000 I was on vacation and came back on Monday. Trying to catch up with my DIME and IETF activities in general.=20 So, everything will be taken care of=20 >-----Original Message----- >From: ext Glen Zorn [mailto:gwz@net-zen.net]=20 >Sent: 14 July, 2009 14:36 >To: Tschofenig, Hannes (NSN - FI/Espoo); 'Victor Fajardo' >Cc: dime@ietf.org >Subject: RE: [Dime] I-D=20 >Action:draft-ietf-dime-diameter-cc-appl-mib-01.txt > >Proto write-up, anyone? > >~ gwz > >Half a loaf is better than no loafing at all. > --T-Bone Slim > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf=20 >> Of Glen Zorn >> Sent: Wednesday, July 01, 2009 4:42 PM >> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'Victor Fajardo' >> Cc: dime@ietf.org >> Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-cc-appl-mib- >> 01.txt >>=20 >> I have addressed all the comments received during WGLC. Can we take=20 >> the next step down the long & winding road to RFC publication? >>=20 >> > -----Original Message----- >> > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-=20 >> > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org >> > Sent: Wednesday, July 01, 2009 4:00 PM >> > To: i-d-announce@ietf.org >> > Cc: dime@ietf.org >> > Subject: I-D Action:draft-ietf-dime-diameter-cc-appl-mib-01.txt >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts=20 >> > directories. >> > This draft is a work item of the Diameter Maintenance and=20 >Extensions=20 >> > Working Group of the IETF. >> > >> > >> > Title : Diameter Credit Control Application MIB >> > Author(s) : G. Zorn, S. Comerica >> > Filename : draft-ietf-dime-diameter-cc-appl-mib-01.txt >> > Pages : 20 >> > Date : 2009-07-01 >> > >> > Along with providing support for certain basic authentication,=20 >> > authorization and accounting functions, the Diameter base protocol=20 >> > is intended to provide a framework for AAA applications. >> > >> > This document defines the Management Information Base (MIB) module=20 >> > which describes the minimum set of objects needed to manage an=20 >> > implementation of the Diameter Credit Control Application. >> > >> > A URL for this Internet-Draft is: >> >=20 >http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-cc-appl >> > - >> > mib-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=20 >> > implementation to automatically retrieve the ASCII version of the=20 >> > Internet-Draft. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > From gwz@net-zen.net Tue Jul 14 05:32:55 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 803463A6BE6 for ; Tue, 14 Jul 2009 05:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 Z1SrUcAMvXHJ for ; Tue, 14 Jul 2009 05:32:54 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id A45DF3A67C1 for ; Tue, 14 Jul 2009 05:32:54 -0700 (PDT) Received: (qmail 4393 invoked from network); 14 Jul 2009 11:32:50 -0000 Received: from unknown (124.120.216.207) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 14 Jul 2009 11:32:50 -0000 From: "Glen Zorn" To: Date: Tue, 14 Jul 2009 18:28:35 +0700 Organization: Network Zen Message-ID: <003a01ca0476$3c121330$b4363990$@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: AcoEdjgeYe6pFhwlRUuzXPh+kpCEXw== Content-Language: en-us Subject: [Dime] Comments on section 9 of draft-ietf-dime-rfc3588bis 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, 14 Jul 2009 12:32:55 -0000 TECHNICAL Section 9.7.1 ------------- Second paragraph says: The AVP listed below SHOULD include service-specific accounting AVPs, as described in Section 9.3. This doesn't make much sense. I _think_ that what is meant is that the "* [ AVP ]" set of AVPs should include service-specific AVPs but I had to read it about 3 times to get that understanding (if it is correct). If my understanding _is_ correct, suggest changing to The ACR command SHOULD include service-specific accounting AVPs, as described in Section 9.3. Section 9.7.2 ------------- Second paragraph says "Only the target Diameter Server, known as the home Diameter Server, SHOULD respond with the Accounting-Answer command." I don't think that the target and home Diameter servers are synonymous. Suggest changing to "Only the target Diameter Server SHOULD respond with the Accounting-Answer command." Third paragraph says The AVP listed below SHOULD include service-specific accounting AVPs, as described in Section 9.3. suggest changing to The ACA command SHOULD include service-specific accounting AVPs, as described in Section 9.3. EDITORIAL Section 9 --------- First sentence: s/server directed model/server-directed model/ Second sentence: s/fault resilience/fault-resilience Last sentence: s/the used devices/the devices used/ Section 9.1 ------------ Section heading: s/Server Directed Model/Server-directed Model/ First sentence: s/server directed model/server-directed model/ Section 9.2 ----------- Change "receives a successful authentication and/or authorization messages" to "receives a successful authentication and/or authorization message" Section 9.4 ----------- The first paragraph says: Diameter Base protocol mechanisms are used to overcome small message loss and network faults of temporary nature. I have no idea what this means. Second sentence of the second paragraph, s/sending of same record/sending of the same record/ Section 9.5 ----------- Paragraph 3, second sentence says "If the authorization server has not directed interim accounting to be enabled for the session, two accounting records MUST be generated for each service of type session." What does "two accounting records MUST be generated for each service of type session" mean? Section 9.6 ----------- Paragraph 3, second sentence: s/the Acct-Multi-Session- Id AVP is used/the Acct-Multi-Session-Id AVP is used/ ~gwz When the government fears the people, you have liberty. When the people fear the government, you have tyranny. -- Thomas Jefferson From tom.taylor@rogers.com Tue Jul 14 06:53: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 090BE3A6CE5 for ; Tue, 14 Jul 2009 06:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 egpH0fnpBLtV for ; Tue, 14 Jul 2009 06:53:00 -0700 (PDT) Received: from smtp132.rog.mail.re2.yahoo.com (smtp132.rog.mail.re2.yahoo.com [206.190.53.37]) by core3.amsl.com (Postfix) with SMTP id E12A23A692B for ; Tue, 14 Jul 2009 06:52:59 -0700 (PDT) Received: (qmail 68725 invoked from network); 14 Jul 2009 13:52:46 -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=ip7Tu0E6gyO4BvbsH/QGYbV11tkGkf/IUH4pncaawI28qENCI6KphaxovT5FVrEb6XPH3bt0LWO3DKmGazE8tBSr8oX0hwTo3ml2Mc1zk76wjaSGafgvk/3UUazm89UH48gBx7rwf4cpyuxVMdoEDoVm6LitUm8hLcxg+iaooBs= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp132.rog.mail.re2.yahoo.com with SMTP; 14 Jul 2009 13:52:46 -0000 X-YMail-OSG: 7a2srEUVM1l3z97u_Ft6Ya5BtAYKon5VvDqeUw7S1Rsryp74.GUnmOSELUm8RBLiUg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5C8DAD.9000600@rogers.com> Date: Tue, 14 Jul 2009 09:52:45 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Glen Zorn References: <4A5BDF11.1040706@rogers.com> <000301ca043e$72cc8550$58658ff0$@net> In-Reply-To: <000301ca043e$72cc8550$58658ff0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 13:53:01 -0000 That 2.1.2 text is a leftover -- I thought I deleted the reference to Redirect-Host AVPs, but I guess I only amended the earlier part of the para. Will fix. I'll improve 2.2. Thanks for your quick review. Tom Glen Zorn wrote: > Tom Taylor [mailto://tom.taylor@rogers.com] writes: > >> I updated this based on comments received from Glen Zorn, Sebastien >> Decugis, and >> Wolfgang Steigerwald. The basic approach was to create a Standards >> Track >> document updating RFC 3588, using a new Result-Code value, and >> including >> Error-Reporting-Host so legacy systems don't get confused. > > Section 2.1.1. says "the redirect agent MUST insert a Redirect-Realm AVP > containing the realm from the routing table entry in its answer message > instead of one or more Redirect-Host AVPs" but section 2.1.2. says: > A Diameter node conforming to this specification which receives an > answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION > SHOULD attempt to reroute the request to the indicated realm rather > than the individual host(s) specified in Redirect-Host AVP(s) in the > redirect indication. > The former implies that no Redirect-Host AVPs would be present in the > message but the latter suggests the opposite. Which one is it? > > Section 2.2 says: > The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It > specifies a realm to which a node receiving a redirect indication > containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION > and this AVP SHOULD route the original request. The M and V flags > for the Redirect-Realm AVP MUST NOT be set. > Of course, it's not possible for a Diameter message to be routed to a realm: > it has to be sent to a Diameter node. How is the node to be chosen? What > happens if the selected node is unavailable? What happens if the receiver > doesn't know about any nodes in the realm. Also, AVPs don't route requests > ;-). > > In section 2.2, s/containingthe/containing the/ > >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-tsou-dime-realm-based-redirect-01 >> Date: Mon, 13 Jul 2009 17:19:39 -0700 (PDT) >> From: IETF I-D Submission Tool >> To: tom.taylor@rogers.com >> CC: tena@huawei.com >> >> >> A new version of I-D, draft-tsou-dime-realm-based-redirect-01.txt has >> been >> successfuly submitted by Tom Taylor and posted to the IETF repository. >> >> Filename: draft-tsou-dime-realm-based-redirect >> Revision: 01 >> Title: Realm-Based Redirection In Diameter >> Creation_date: 2009-07-14 >> WG ID: Independent Submission >> Number_of_pages: 5 >> >> Abstract: >> 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. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > > From tom.taylor@rogers.com Tue Jul 14 07:01: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 449883A6E95 for ; Tue, 14 Jul 2009 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 m9s0jjPR4UHi for ; Tue, 14 Jul 2009 07:01:14 -0700 (PDT) Received: from smtp118.rog.mail.re2.yahoo.com (smtp118.rog.mail.re2.yahoo.com [68.142.225.234]) by core3.amsl.com (Postfix) with SMTP id 577D63A6AA3 for ; Tue, 14 Jul 2009 07:01:14 -0700 (PDT) Received: (qmail 28949 invoked from network); 14 Jul 2009 13:53:45 -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=2Y5eCc+kbiig0Sq/IATT0+NPnXy74aris8BAGSEbPWCSYXm2vT35uysmGMcFtjxrWcn+tEK6+wxZ0+JpU3/F16+tEzGAWYiIC7/OYfIhxxeLLFqk6nMJccxa1WbzWpc2Cp3smL5nglaDmjf6F5c9IaxkddivevQRe9OtHh0ofQ4= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp118.rog.mail.re2.yahoo.com with SMTP; 14 Jul 2009 13:53:44 -0000 X-YMail-OSG: 5p29ePIVM1lMMDnJTuvs23_ek0M2V1J2EBvUnjpWN.e5uqSCDeUz9DGC.R..7DShsA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A5C8DE6.6060500@rogers.com> Date: Tue, 14 Jul 2009 09:53:42 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Sebastien Decugis References: <4A5BDF11.1040706@rogers.com> <000301ca043e$72cc8550$58658ff0$@net> <4A5C11C4.6070609@nict.go.jp> In-Reply-To: <4A5C11C4.6070609@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] [SPAM] Re: [Fwd: New Version Notification for draft-tsou-dime-realm-based-redirect-01] 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, 14 Jul 2009 14:01:15 -0000 That's what I intended. Thanks for looking at it and commenting. Tom Sebastien Decugis wrote: > Hi, > >> Section 2.2 says: >> The Redirect-Realm AVP (code TBD) is of type DiameterIdentity. It >> specifies a realm to which a node receiving a redirect indication >> containingthe result code value DIAMETER_REALM_REDIRECT_INDICATION >> and this AVP SHOULD route the original request. The M and V flags >> for the Redirect-Realm AVP MUST NOT be set. >> Of course, it's not possible for a Diameter message to be routed to a realm: >> it has to be sent to a Diameter node. How is the node to be chosen? What >> happens if the selected node is unavailable? What happens if the receiver >> doesn't know about any nodes in the realm. > I was assuming that the mechanism(s) described in RFC3588 section 5.2 > would be implicitly used here (Ex: NAPTR requests). > The node receiving this indication may also already have a routing entry > for the new (intermediate) destination realm. > > My 2 cents... > Sebastien. > From Hannes.Tschofenig@gmx.net Tue Jul 14 07:16: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 38E183A6EB8 for ; Tue, 14 Jul 2009 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_40=-0.185] 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 N2r59VpVrvXU for ; Tue, 14 Jul 2009 07:16:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4EA4E3A6824 for ; Tue, 14 Jul 2009 07:16:13 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2009 12:29:21 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp033) with SMTP; 14 Jul 2009 14:29:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zksBRNL0zRvPADuAWtNUadAiWS/i8o8WD/hlaMr 6yhiRNPNXDQeMw From: "Hannes Tschofenig" To: Date: Tue, 14 Jul 2009 15:31:39 +0300 Message-ID: <09d501ca047f$0a5c9dc0$0301a8c0@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: AcoEfwlPgfh4X/YQTyGjnAAdj5nHWA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 Subject: [Dime] Yes, I was on vacation! 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, 14 Jul 2009 14:16:15 -0000 Hi all, I was on vacation and have a couple of things to catch up, including putting the agenda for the meeting together. Apologies for the delays. Ciao Hannes From gwz@net-zen.net Tue Jul 14 08:40:54 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 E12723A69B1 for ; Tue, 14 Jul 2009 08:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 D3N9x3Fy3Fcs for ; Tue, 14 Jul 2009 08:40:54 -0700 (PDT) Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id 0F9C93A6945 for ; Tue, 14 Jul 2009 08:40:54 -0700 (PDT) Received: (qmail 13895 invoked from network); 14 Jul 2009 11:39:54 -0000 Received: from unknown (124.120.216.207) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 14 Jul 2009 11:39:53 -0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Victor Fajardo'" References: <20090701084501.72D6C3A6CF0@core3.amsl.com> <002101c9fa28$4d565870$e8030950$@net> In-Reply-To: <002101c9fa28$4d565870$e8030950$@net> Date: Tue, 14 Jul 2009 18:35:38 +0700 Organization: Network Zen Message-ID: <003b01ca0477$3880b9a0$a9822ce0$@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: Acn6KEuNc8wfqCeQQmGgwY2WGFgMSgAAGDPAApOdPyA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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, 14 Jul 2009 15:40:55 -0000 Any chance of movement on this? ~ gwz Half a loaf is better than no loafing at all. --T-Bone Slim > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Wednesday, July 01, 2009 3:45 PM > To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'Victor Fajardo' > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol- > mib-01.txt > > I have addressed all the comments received during WGLC. Can we take > the > next step down the long & winding road to RFC publication? > > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, July 01, 2009 3:45 PM > > To: i-d-announce@ietf.org > > Cc: dime@ietf.org > > Subject: I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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 : Diameter Base Protocol MIB > > Author(s) : G. Zorn, S. Comerica > > Filename : draft-ietf-dime-diameter-base-protocol-mib- > > 01.txt > > Pages : 51 > > Date : 2009-07-01 > > > > Along with providing support for certain basic authentication, > > authorization and accounting functions, the Diameter protocol is > > designed to provide a framework for AAA applications. > > > > This document defines the Management Information Base (MIB) module > > which describes the minimum set of objects needed to manage an > > implementation of the Diameter protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base- > > protocol-mib-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. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From gwz@net-zen.net Tue Jul 14 10:14: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 2633028C33D for ; Tue, 14 Jul 2009 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 NKJ7tB-H-2kg for ; Tue, 14 Jul 2009 10:14:20 -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 14F503A6835 for ; Tue, 14 Jul 2009 10:14:20 -0700 (PDT) Received: (qmail 942 invoked from network); 14 Jul 2009 15:27:50 -0000 Received: from unknown (124.120.216.207) by p3plsmtpa01-01.prod.phx3.secureserver.net (72.167.82.81) with ESMTP; 14 Jul 2009 15:27:49 -0000 From: "Glen Zorn" To: Date: Tue, 14 Jul 2009 22:23:33 +0700 Organization: Network Zen Message-ID: <006501ca0497$0f4ba930$2de2fb90$@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: AcoElwwOT7uhgGGWRseAyCKKFK5FOw== Content-Language: en-us Subject: [Dime] Comment on section 9.8.3 of rfc3588bis 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, 14 Jul 2009 17:14:21 -0000 This section says: The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting- Record-Number AVPs is also globally unique, and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD. Unfortunately, this ain't necessarily true. Imagine an accounting application that doesn't deal with user sessions, but instead reports data on network conditions (say traffic volume) that is then used for making admission control decisions. "Sessions" are irrelevant & therefore, so is Session-Id so we can pick any globally unique value. Let's pick the MAC address of the client. Since sessions are irrelevant, so is session lifetime so let's make sessions last forever. Furthermore, we're reporting instantaneous snapshots of network traffic, so it makes perfect sense to use the Accounting-Record-Type of EVENT_RECORD. We now have a situation where _all_ the accounting requests have the same Accounting-Record-Number value (0) and, although the Session-Id value is globally and eternally unique, the combination of Accounting-Record-Number and Session-Id is not (I know that this may sound contrived, but it's actually come up recently). I'm pretty sure this is legal because the definition of EVENT_RECORD says: An Accounting Event Record is used to indicate that a one-time event has occurred (meaning that the start and end of the event are simultaneous). This record contains all information relevant to the service, and is the only record of the service. Note the use of the word "service"; if it said "session", there would be no problem (in this case), since that would force the change of the Session-Id value after every EVENT_RECORD was sent, but it doesn't say "session" (unlike the rest of the accounting record type definitions). However, that would basically outlaw more than one EVENT_RECORD from occurring in a single session, which I believe was the intent of the original definition but isn't particularly useful. Instead, my proposal is to change section 9.8.3 to say: The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. The combination of the Session-Id and Accounting-Record-Number AVPs MUST be globally unique, and can thus be used to match accounting records with confirmations. Assuming that there is only one EVENT_RECORD per session, an easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From julien.bournelle@gmail.com Wed Jul 15 02:50: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 6B6863A6859 for ; Wed, 15 Jul 2009 02:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026, 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 xP4xmFQ2Q0Z9 for ; Wed, 15 Jul 2009 02:50:15 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id AA07B3A67F7 for ; Wed, 15 Jul 2009 02:50:14 -0700 (PDT) Received: by fxm18 with SMTP id 18so3335264fxm.37 for ; Wed, 15 Jul 2009 02:47:01 -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=as/Z4YbvuwZpYLDEVeBN9YIkZm6wgSGoxoN/T3r8+HU=; b=FQUR5IJnUjFwnz9m/8TgG9i1/FkWjx9OSEJTgVUfpgAnc3UgVGrzmFMGS7UfBBAOiG XlXMDDUv7zoesBNcrfBuEcxQRsXDG7u/HTLSQg9oxLHgw4p2ZzWZ0PEQi2VuqG+EE5PU nLd3ArqcdTf7jFAbI4CSuKD11+snGce9MTqCs= 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=UGyik2iY8B121eJSRnv146624LlajQ1gEkEF4HeClSwpcyHIImNbUN4LtxD7nnoZE+ BTPqlQTPZTMZxWeFCDQMHxpv1HisQlZM37GLYzGMU0nzHtnZ7dAUHqWhQQCTWg4e+Dyk CkJ4rs832DJ6RCThkuVQfeChEx60cfbihJmEc= MIME-Version: 1.0 Received: by 10.204.115.143 with SMTP id i15mr7438148bkq.103.1247650763718; Wed, 15 Jul 2009 02:39:23 -0700 (PDT) In-Reply-To: <4A5BDF43.50900@nict.go.jp> References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> Date: Wed, 15 Jul 2009 11:39:21 +0200 Message-ID: <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016e6d647b19366d1046ebb547e Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 15 Jul 2009 09:50:16 -0000 --0016e6d647b19366d1046ebb547e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Tue, Jul 14, 2009 at 3:28 AM, Sebastien Decugis wrote: > Hi, > > > But, isn't the NAI set to keyname-NAI which contains the local domain > > as "domain" ? > > > > If this is the case, we don't have anymore the internal issue in the > > proxy. > > Sure, but once again, it means that local EAP messages are also sent to > the proxy, not directly to the EAP server. This is unrelated to the > situation I exposed in the opening mail. the situation that you exposed was that the AAA proxy can't know from the app-id of the DER message that it is for ERP. This was my understsanding of your internal routing issue. > > > > > > > But if the NAS has to select to send the message to either the > > local EAP > > server, or a local proxy (usually for users belonging to foreign > > domains), then the issue is in the NAS, not the proxy. > > > > > > > > but here, this is a different issue. And in this case, having an > > app-id doesn't help very much. > No, this *is* the issue for which I opened the thread. An the separate > application-id *does* help separate the messages between ERP proxy(es) > and EAP proxy(es) that do very different processing on the messages, so > it is logical to separate them IMHO. I understand this. I just mentionned below that this could be solved by the NAI assuming ERP and AAA proxy are colocated. > > > > It only helps if you assume that you have only ONE local ERP server in > > the domain. > The issue when there are several ERP proxies must be studied, true. A > solution could be that all the keys are always distributed to all the > proxies. We'd need a new command for this purpose. I'm not in favor of this. This will overload the network with AAA signalling which is undesirable. > > > > But you also may assume that you have ONE AAA proxy. > I don't agree. EAP and ERP proxy are very different in nature. We should > not impose that they are collocated. > > > We have to divide the two issues IMHO. > What is the first issue exactly? I opened the thread only about the > second (routing in the NAS). Read the thread and you'll find the two issues that can be separated. Regards, Julien > > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016e6d647b19366d1046ebb547e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Tue, Jul 14, 2009 at 3:28 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi,

> =A0But, isn't the NAI set to keyname-NAI which contains the local = domain
> as "domain" ?
>
> =A0If this is the case, we don't have anymore the internal issue i= n the
> proxy.

Sure, but once again, it means that local EAP messages are also sent = to
the proxy, not directly to the EAP server. This is unrelated to the
situation I exposed in the opening mail.

the situation= that you exposed was that the AAA proxy can't know from the app-id of = the DER message that it is for ERP. This was my understsanding of your inte= rnal routing issue.
=A0

>
>
> =A0 =A0 But if the NAS has to select to send the message to either the=
> =A0 =A0 local EAP
> =A0 =A0 server, or a local proxy (usually for users belonging to forei= gn
> =A0 =A0 domains), then the issue is in the NAS, not the proxy.
>
>
>
> =A0but here, this is a different issue. And in this case, having an > app-id doesn't help very much.
No, this *is* the issue for which I opened the thread. An the separat= e
application-id *does* help separate the messages between ERP proxy(es)
and EAP proxy(es) that do very different processing on the messages, so
it is logical to separate them IMHO.

=A0I understand t= his. I just mentionned below that this could be solved by the NAI assuming = ERP and AAA proxy are colocated.
=A0


> It only helps if you assume that you have only ONE local ERP server in=
> the domain.
The issue when there are several ERP proxies must be studied, true. A=
solution could be that all the keys are always distributed to all the
proxies. We'd need a new command for this purpose.
I'm not in favor of this. This will overload the network with AAA sign= alling which is undesirable.
=A0


> But you also may assume that you have ONE AAA proxy.
I don't agree. EAP and ERP proxy are very different in nature. We= should
not impose that they are collocated.

> =A0We have to divide the two issues IMHO.
What is the first issue exactly? I opened the thread only about the second (routing in the NAS).

Read the thread and you&#= 39;ll find the two issues that can be separated.

=A0Regards,

= =A0Julien
=A0


Best regards,
Sebastien.

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


--0016e6d647b19366d1046ebb547e-- From Hannes.Tschofenig@gmx.net Wed Jul 15 13:27:37 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 22BCE3A6A3E for ; Wed, 15 Jul 2009 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.034 X-Spam-Level: X-Spam-Status: No, score=-1.034 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_40=-0.185] 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 CUP6qqsaDAnd for ; Wed, 15 Jul 2009 13:27:36 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D24D93A6808 for ; Wed, 15 Jul 2009 13:27:35 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 20:26:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp059) with SMTP; 15 Jul 2009 22:26:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vZbA2ZMEvBV0YDnBfhMqPmgWQe9U+Q7U3b9e4vd bsn9CDCF+D/O1I From: "Hannes Tschofenig" To: Date: Wed, 15 Jul 2009 23:29:17 +0300 Message-ID: <024a01ca058a$ed63b200$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AcoFiuzls5N2OYpDS/yHGO0WdM8qUw== Importance: High X-Y-GMX-Trusted: 0 X-FuHaFi: 0.79 Subject: [Dime] Agenda (v1) 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, 15 Jul 2009 20:27:37 -0000 Hi all, here is a first try for the agenda: http://www.ietf.org/proceedings/09jul/agenda/dime.txt Please take a look at it - you might find your name on it. Ciao Hannes From sdecugis@nict.go.jp Wed Jul 15 18:58:04 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 DB6C728C1C2 for ; Wed, 15 Jul 2009 18:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Qb-Kb+3xNpT7 for ; Wed, 15 Jul 2009 18:58:03 -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 3D95328C1C6 for ; Wed, 15 Jul 2009 18:58:02 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n6G1wTif014236; Thu, 16 Jul 2009 10:58:29 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n6G1wTRC023401; Thu, 16 Jul 2009 10:58:29 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n6G1wT0I023398; Thu, 16 Jul 2009 10:58:29 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 68E4DA2E8; Thu, 16 Jul 2009 10:58:29 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 611C15361; Thu, 16 Jul 2009 10:58:29 +0900 (JST) Message-ID: <4A5E8943.4090607@nict.go.jp> Date: Thu, 16 Jul 2009 10:58:27 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> In-Reply-To: <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 16 Jul 2009 01:58:04 -0000 Hi Julien, all, Julien Bournelle a écrit : > the situation that you exposed was that the AAA proxy can't know from > the app-id of the DER message that it is for ERP. This was my > understsanding of your internal routing issue. Sorry for the quiproquo, I guess my original text was not so clear then. "The routing issue is that the DER message in situation (br) is *identical* to the DER message in situation (a) in terms of Diameter routing, but the two messages (a) and (br) must be routed to different AAA entities, respectively SERVER_A and PROXY_A." I was really talking about the NAS that must route the message either to the local proxy or local server. I hope this clarifies. > No, this *is* the issue for which I opened the thread. An the separate > application-id *does* help separate the messages between ERP proxy(es) > and EAP proxy(es) that do very different processing on the > messages, so > it is logical to separate them IMHO. > > > I understand this. I just mentionned below that this could be solved > by the NAI assuming ERP and AAA proxy are colocated. (NAI => NAS I suppose) But again, even if the ERP local server is collocated with the AAA (i.e. EAP ?) proxy, the NAS still have to choose to send the message to this proxy or to the local EAP server. > The issue when there are several ERP proxies must be studied, true. A > solution could be that all the keys are always distributed to all the > proxies. We'd need a new command for this purpose. > > > I'm not in favor of this. This will overload the network with AAA > signalling which is undesirable. I also don't like this approach, but I think it must be considered anyway in the "pros and cons". Also, I was not sure if this mail from Glen was pointing to that direction or not: http://www.ietf.org/mail-archive/web/dime/current/msg03706.html > > We have to divide the two issues IMHO. > What is the first issue exactly? I opened the thread only about the > second (routing in the NAS). > > > Read the thread and you'll find the two issues that can be separated. I am very stupid, or really need vacation, but I still don't find two issues here. Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sunseawq@huawei.com Wed Jul 15 23:09: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 132213A676A for ; Wed, 15 Jul 2009 23:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.137, 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 Mw5F2yScfbBx for ; Wed, 15 Jul 2009 23:09:25 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E69CA3A68D0 for ; Wed, 15 Jul 2009 23:08:58 -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 <0KMV00BQG2EC7H@szxga03-in.huawei.com> for dime@ietf.org; Thu, 16 Jul 2009 14:08:36 +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 <0KMV00FWH2ECU4@szxga03-in.huawei.com> for dime@ietf.org; Thu, 16 Jul 2009 14:08:36 +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 <0KMV007PA2EBVZ@szxml06-in.huawei.com> for dime@ietf.org; Thu, 16 Jul 2009 14:08:36 +0800 (CST) Date: Thu, 16 Jul 2009 14:08:35 +0800 From: Qin Wu To: Hannes Tschofenig , dime@ietf.org Message-id: <033001ca05db$daebe5b0$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.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <024a01ca058a$ed63b200$1116a20a@nsnintra.net> Subject: Re: [Dime] Agenda (v1) 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, 16 Jul 2009 06:09:26 -0000 Hi, Chair: May I ask 5~10 minutes to discuss the topic on Diameter Attribute-Value Pairs for Cryptographic Key Transport? The URL for this I-D is: http://tools.ietf.org/html/draft-wu-dime-local-keytran-02 Thanks! Regards! -Qin ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Thursday, July 16, 2009 4:29 AM Subject: [Dime] Agenda (v1) > Hi all, > > here is a first try for the agenda: > http://www.ietf.org/proceedings/09jul/agenda/dime.txt > > Please take a look at it - you might find your name on it. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From hannes.tschofenig@nsn.com Thu Jul 16 01:31:42 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 821E33A68C7 for ; Thu, 16 Jul 2009 01:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=-0.839, 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 MDTTHQ+ZBqXa for ; Thu, 16 Jul 2009 01:31:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id EB9CF3A67BE for ; Thu, 16 Jul 2009 01:31:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6G7viGc032646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Jul 2009 09:57:44 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6G7vRBn017860; Thu, 16 Jul 2009 09:57:44 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 09:57:41 +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: Thu, 16 Jul 2009 11:00:02 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450187FAF4@FIESEXC015.nsn-intra.net> In-Reply-To: <033001ca05db$daebe5b0$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Agenda (v1) Thread-Index: AcoF3BpOtyahBrZxSCKKMmBxYpblAQADyepg References: <024a01ca058a$ed63b200$1116a20a@nsnintra.net> <033001ca05db$daebe5b0$260ca40a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Qin Wu" , "Hannes Tschofenig" , X-OriginalArrivalTime: 16 Jul 2009 07:57:41.0848 (UTC) FILETIME=[18692D80:01CA05EB] Subject: Re: [Dime] Agenda (v1) 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, 16 Jul 2009 08:31:42 -0000 Sure.=20 =20 I put you on the agenda.=20 >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 >Behalf Of ext Qin Wu >Sent: 16 July, 2009 09:09 >To: Hannes Tschofenig; dime@ietf.org >Subject: Re: [Dime] Agenda (v1) > >Hi, Chair: >May I ask 5~10 minutes to discuss the topic on Diameter=20 >Attribute-Value Pairs for Cryptographic Key Transport? >The URL for this I-D is: >http://tools.ietf.org/html/draft-wu-dime-local-keytran-02 >Thanks! > >Regards! >-Qin >----- Original Message ----- >From: "Hannes Tschofenig" >To: >Sent: Thursday, July 16, 2009 4:29 AM >Subject: [Dime] Agenda (v1) > > >> Hi all,=20 >>=20 >> here is a first try for the agenda: >> http://www.ietf.org/proceedings/09jul/agenda/dime.txt >>=20 >> Please take a look at it - you might find your name on it.=20 >>=20 >> Ciao >> Hannes >>=20 >>=20 >> _______________________________________________ >> 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 julien.bournelle@gmail.com Thu Jul 16 02:29: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 455E93A6CBC for ; Thu, 16 Jul 2009 02:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 xqewxgQI2u4l for ; Thu, 16 Jul 2009 02:29:14 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 226F03A6A38 for ; Thu, 16 Jul 2009 02:29:12 -0700 (PDT) Received: by fxm18 with SMTP id 18so3967236fxm.37 for ; Thu, 16 Jul 2009 02:29:43 -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=831rSC1IFfrOvc25xjjncm3SIXUGH9t51qW0UAX/33U=; b=vgpktMqRuUcAbXvbmwEGAxr6iSI4VLDOBF/rSGZnQce5rSXwjOXxgapYDWc49GxjOB FGkK41+9yw8gOq26lXwS5oYNQL+QM13IrrZgt4XZE0Jct3VpBfwsEg+tVe/szXbpw37u Ju29FPY4lJVtOncAD2kslIdLIiCt3v9fEHOgI= 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=BdcmBK62XAvDXuqnAlxCsnw1f7ZCgGk9nutveQduWqKV4JYe2eL1qishe4/wAdONbW B86/RmgRRLSJ4lOvI43vZoujtUTpMNkaVfxaKwLEEYFKxl32P+e4/YQE2teHwwk5uMgK lbCQTqQxujt/7TN9+auca4GhxIhKcKEZv2dhM= MIME-Version: 1.0 Received: by 10.204.124.19 with SMTP id s19mr8597388bkr.6.1247736582554; Thu, 16 Jul 2009 02:29:42 -0700 (PDT) In-Reply-To: <4A5E8943.4090607@nict.go.jp> References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> <4A5E8943.4090607@nict.go.jp> Date: Thu, 16 Jul 2009 11:29:39 +0200 Message-ID: <5e2406980907160229j24933405j391f6605f3012bbf@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=001636c596e3c726a4046ecf4f85 Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 16 Jul 2009 09:29:15 -0000 --001636c596e3c726a4046ecf4f85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, On Thu, Jul 16, 2009 at 3:58 AM, Sebastien Decugis wro= te: > Hi Julien, all, > > Julien Bournelle a =E9crit : > > the situation that you exposed was that the AAA proxy can't know from > > the app-id of the DER message that it is for ERP. This was my > > understsanding of your internal routing issue. > Sorry for the quiproquo, I guess my original text was not so clear then. > > "The routing issue is that the DER message in situation (br) is > *identical* to the DER message in situation (a) in terms of Diameter > routing, but the two messages (a) and (br) must be routed to different > AAA entities, respectively SERVER_A and PROXY_A." > > I was really talking about the NAS that must route the message either to > the local proxy or local server. > I hope this clarifies. no, I thought we agree on the issues but I'm afraid that we don't. The routing will be based on the NAI (Network Access identifier) provided by the terminal. If the realm part corresponds to the domain A, the message is routed to SERVER_A else to PROXY_A. So what's the issue ? > > > > > No, this *is* the issue for which I opened the thread. An the > separate > > application-id *does* help separate the messages between ERP > proxy(es) > > and EAP proxy(es) that do very different processing on the > > messages, so > > it is logical to separate them IMHO. > > > > > > I understand this. I just mentionned below that this could be solved > > by the NAI assuming ERP and AAA proxy are colocated. > (NAI =3D> NAS I suppose) no. NAI > > But again, even if the ERP local server is collocated with the AAA (i.e. > EAP ?) proxy, the NAS still have to choose to send the message to this > proxy or to the local EAP server. it doesn't choose. It performs routing based on the NAI. > > > > The issue when there are several ERP proxies must be studied, true.= A > > solution could be that all the keys are always distributed to all t= he > > proxies. We'd need a new command for this purpose. > > > > > > I'm not in favor of this. This will overload the network with AAA > > signalling which is undesirable. > I also don't like this approach, but I think it must be considered > anyway in the "pros and cons". > Also, I was not sure if this mail from Glen was pointing to that > direction or not: > http://www.ietf.org/mail-archive/web/dime/current/msg03706.html > > > > We have to divide the two issues IMHO. > > What is the first issue exactly? I opened the thread only about the > > second (routing in the NAS). > > > > > > Read the thread and you'll find the two issues that can be separated. > I am very stupid, or really need vacation, but I still don't find two > issues here. hmm. Assuming ERP/EAP/AAA are colocated. The terminal has been authenticate= d by a NAS. First Issue: you have multiple local ERP/AAA servers in the visited domain: how does the new NAS know which one has the keying material ? Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER message to this AAA server. How does the AAA server knows if this DER message is for EAP processing or ERP processing ? I'm afraid that we have this "cycling" discussion because architecture is not well established... Hope this clarifies, Regards, Julien > > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --001636c596e3c726a4046ecf4f85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jul 16, 2009 at 3:58 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi Julien, all,

Julien Bournelle a =E9crit :
> the situation that you exposed was that the AAA prox= y can't know from
> the app-id of the DER message that it is for ERP. This was my
> understsanding of your internal routing issue.
Sorry for the quiproquo, I guess my original text was not so clear th= en.

"The routing issue is that the DER message in situation (br) is
*identical* to the DER message in situation (a) in terms of Diameter
routing, but the two messages (a) and (br) must be routed to different
AAA entities, respectively SERVER_A and PROXY_A."

I was really talking about the NAS that must route the message either= to
the local proxy or local server.
I hope this clarifies.

=A0no, I thought we agree on th= e issues but I'm afraid that we don't.

=A0The routing will = be based on the NAI (Network Access identifier) provided by the terminal. I= f the realm part corresponds to the domain A, the message is routed to SERV= ER_A else to PROXY_A. So what's the issue ?
=A0



> =A0 =A0 No, this *is* the issue for which I opened the thread. An the = separate
> =A0 =A0 application-id *does* help separate the messages between ERP p= roxy(es)
> =A0 =A0 and EAP proxy(es) that do very different processing on the
> =A0 =A0 messages, so
> =A0 =A0 it is logical to separate them IMHO.
>
>
> =A0I understand this. I just mentionned below that this could be solve= d
> by the NAI assuming ERP and AAA proxy are colocated.
(NAI =3D> NAS I suppose)

no. NAI

But again, even if the ERP local server is collocated with the AAA (i.e. EAP ?) proxy, the NAS still have to choose to send the message to this
proxy or to the local EAP server.

it doesn't choos= e. It performs routing based on the NAI.
=A0


> =A0 =A0 The issue when there are several ERP proxies must be studied, = true. A
> =A0 =A0 solution could be that all the keys are always distributed to = all the
> =A0 =A0 proxies. We'd need a new command for this purpose.
>
>
> I'm not in favor of this. This will overload the network with AAA<= br> > signalling which is undesirable.
I also don't like this approach, but I think it must be considere= d
anyway in the "pros and cons".
Also, I was not sure if this mail from Glen was pointing to that
direction or not:
http://www.ietf.org/mail-archive/web/dime/current/msg037= 06.html

> =A0 =A0 > =A0We have to divide the two issues IMHO.
> =A0 =A0 What is the first issue exactly? I opened the thread only abou= t the
> =A0 =A0 second (routing in the NAS).
>
>
> Read the thread and you'll find the two issues that can be separat= ed.
I am very stupid, or really need vacation, but I still don't find= two
issues here.


hmm. Assuming ERP/EAP/AAA are colocat= ed. The terminal has been authenticated by a NAS.

First Issue: you h= ave multiple local ERP/AAA servers in the visited domain: how does the new = NAS know which one has the keying material ?

Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER messag= e to this AAA server. How does the AAA server knows if this DER message is = for EAP processing or ERP processing ?
=A0
I'm afraid that we hav= e this "cycling" discussion because architecture is not well esta= blished...

=A0Hope this clarifies,

=A0Regards,

=A0Julien



Sebastien.

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


--001636c596e3c726a4046ecf4f85-- From sdecugis@nict.go.jp Thu Jul 16 18:25: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 E65633A69DC for ; Thu, 16 Jul 2009 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.058 X-Spam-Level: X-Spam-Status: No, score=-1.058 tagged_above=-999 required=5 tests=[AWL=0.297, 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 SK+UAU+RyAB5 for ; Thu, 16 Jul 2009 18:25: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 3554E28C242 for ; Thu, 16 Jul 2009 18:25:19 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id n6H1PoTn015451; Fri, 17 Jul 2009 10:25:50 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id n6H1PnKJ015600; Fri, 17 Jul 2009 10:25:49 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id n6H1PnCG015597; Fri, 17 Jul 2009 10:25:49 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id C19F016006; Fri, 17 Jul 2009 10:25:49 +0900 (JST) Received: from [133.243.146.166] (5gou2f-dhcp06.nict.go.jp [133.243.146.166]) by mail2.nict.go.jp (NICT Mail) with ESMTP id BA27816004; Fri, 17 Jul 2009 10:25:49 +0900 (JST) Message-ID: <4A5FD319.1050608@nict.go.jp> Date: Fri, 17 Jul 2009 10:25:45 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> <4A5E8943.4090607@nict.go.jp> <5e2406980907160229j24933405j391f6605f3012bbf@mail.gmail.com> In-Reply-To: <5e2406980907160229j24933405j391f6605f3012bbf@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 17 Jul 2009 01:25:22 -0000 Hi Julien, Julien Bournelle a écrit : > > I was really talking about the NAS that must route the message > either to > the local proxy or local server. > I hope this clarifies. > > > no, I thought we agree on the issues but I'm afraid that we don't. > > The routing will be based on the NAI (Network Access identifier) > provided by the terminal. If the realm part corresponds to the domain > A, the message is routed to SERVER_A else to PROXY_A. So what's the > issue ? Ok, now I feel we are moving forward :) The issue is that with ERP, the realm part of the NAI is domain A, but the message must be routed to the proxy_A, not the server_A! which basically does not happen with the behavior you describe. And that is the routing issue I was talking about in the initial mail of this thread. :) Do we agree now on this ? > > > > No, this *is* the issue for which I opened the thread. An > the separate > > application-id *does* help separate the messages between ERP > proxy(es) > > and EAP proxy(es) that do very different processing on the > > messages, so > > it is logical to separate them IMHO. > > > > > > I understand this. I just mentionned below that this could be > solved > > by the NAI assuming ERP and AAA proxy are colocated. > (NAI => NAS I suppose) > > > no. NAI Ok, sorry. I read too quickly, now I understand. > > > But again, even if the ERP local server is collocated with the AAA > (i.e. > EAP ?) proxy, the NAS still have to choose to send the message to this > proxy or to the local EAP server. > > > it doesn't choose. It performs routing based on the NAI. I totally agree. And this is the reason for the issue (cause we don't want to change this behavior). > > hmm. Assuming ERP/EAP/AAA are colocated. The terminal has been > authenticated by a NAS. > > First Issue: you have multiple local ERP/AAA servers in the visited > domain: how does the new NAS know which one has the keying material ? Oh, OK, sorry! I thought this issue was ruled out. I totally agree that this is an issue that must be solved. Anyway I think we agreed it is not related to the new app-id discussion. I propose we have a different thread to handle this issue : case of several ER servers in the domain, with only one bootstrapped for the peer. > Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER > message to this AAA server. How does the AAA server knows if this DER > message is for EAP processing or ERP processing ? I was not aware of this issue. By simply looking at the EAP content (EAP code), or matching the user name with either user table or key cache, it should be easy to retrieve the correct application, IMHO. The application ID purpose was not for internal routing inside a peer (at least not in my initial idea), but for routing in the Diameter network. I hope it is now clarified from the first answer in this mail? > I'm afraid that we have this "cycling" discussion because architecture > is not well established... Hmmm yes it is possible :) But I still don't see what could clarify it... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From julien.bournelle@gmail.com Fri Jul 17 02:24:19 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 9D9023A6A12 for ; Fri, 17 Jul 2009 02:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 0y2phmCYaDAY for ; Fri, 17 Jul 2009 02:24:18 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id B619B3A6A38 for ; Fri, 17 Jul 2009 02:23:52 -0700 (PDT) Received: by bwz28 with SMTP id 28so609791bwz.37 for ; Fri, 17 Jul 2009 02:24:22 -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=LZ0Ase+kjjgcZ2zLxW7z0X9BdTbSeRahEffSUMAxlLs=; b=MODoUY1ZRDIZt/TLbYywqsOiu/I49D+zGd9UDORIdJnZXuWUycI7nipDVhg6Ak+yWj dcMnanqAWr2JkIq0sxaIqPjRV/bGfylOMzoqKi8nQFXsZxF1dXO1t4VFiuPZYchtVLgW IJgNouIF+6CcI91oGV9KA3U+vcrYODXx/tpzY= 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=H2hxHgsz6YZRBP9TuuT1gWbUeH2mNFayp4WtDgcFz+XUy+Rf+4Mi20x/MvFVVJtz4N nmjfgWkr55PTuOGL1ym7WRMvnQXJGnxrD4h7Of00BYNC3Bbb/uYk/60HgcGMtjwNa+L5 X2R0mCzEcfrrCW2NPeTNrIR4Vl/0k24qTo9oo= MIME-Version: 1.0 Received: by 10.204.65.65 with SMTP id h1mr727006bki.26.1247822662619; Fri, 17 Jul 2009 02:24:22 -0700 (PDT) In-Reply-To: <4A5FD319.1050608@nict.go.jp> References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> <4A5E8943.4090607@nict.go.jp> <5e2406980907160229j24933405j391f6605f3012bbf@mail.gmail.com> <4A5FD319.1050608@nict.go.jp> Date: Fri, 17 Jul 2009 11:24:22 +0200 Message-ID: <5e2406980907170224s1744a91cnb849dc41b7b7321c@mail.gmail.com> From: Julien Bournelle To: Sebastien Decugis Content-Type: multipart/alternative; boundary=001636c5ad4d8c5164046ee35aca Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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, 17 Jul 2009 09:24:19 -0000 --001636c5ad4d8c5164046ee35aca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello, On Fri, Jul 17, 2009 at 3:25 AM, Sebastien Decugis wro= te: > Hi Julien, > > Julien Bournelle a =E9crit : > > > > I was really talking about the NAS that must route the message > > either to > > the local proxy or local server. > > I hope this clarifies. > > > > > > no, I thought we agree on the issues but I'm afraid that we don't. > > > > The routing will be based on the NAI (Network Access identifier) > > provided by the terminal. If the realm part corresponds to the domain > > A, the message is routed to SERVER_A else to PROXY_A. So what's the > > issue ? > > Ok, now I feel we are moving forward :) > > The issue is that with ERP, the realm part of the NAI is domain A, but > the message must be routed to the proxy_A, not the server_A! which > basically does not happen with the behavior you describe. > > And that is the routing issue I was talking about in the initial mail of > this thread. :) > > Do we agree now on this ? If PROXY_A and SERVER_A are not collocated and PROXY_A is collocated with the ERP server, yes, we have an issue. If the SERVER_A is collocated with the ERP server, we don't have the issue = ! :) The issue would be: how does the SERVER_A receives from PROXY_A the ERP stuff ? > > > > > > First Issue: you have multiple local ERP/AAA servers in the visited > > domain: how does the new NAS know which one has the keying material ? > > > Oh, OK, sorry! I thought this issue was ruled out. I totally agree that > this is an issue that must be solved. Anyway I think we agreed it is not > related to the new app-id discussion. I propose we have a different > thread to handle this issue : case of several ER servers in the domain, > with only one bootstrapped for the peer. Yes we agree. This is an issue and App-Id doesn't help. > > > > Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER > > message to this AAA server. How does the AAA server knows if this DER > > message is for EAP processing or ERP processing ? > I was not aware of this issue. By simply looking at the EAP content (EAP > code), or matching the user name with either user table or key cache, it > should be easy to retrieve the correct application, IMHO. The > application ID purpose was not for internal routing inside a peer (at > least not in my initial idea), but for routing in the Diameter network. > I hope it is now clarified from the first answer in this mail? App-Id is also used in a internal AAA server to pass the message to the correct Application. As you know, the same AAA server with a Diameter Base Protocol stack could implement different Diameter Application on top of the Base Protocol. Finally, for this reason, I tend to think that having a App-Id for ERP woul= d be beneficial to avoid overload the EAP Application. > > > > I'm afraid that we have this "cycling" discussion because architecture > > is not well established... > Hmmm yes it is possible :) But I still don't see what could clarify it... For example, does the local ERP server is colocated within local AAA/EAP server or in the local AAA/EAP proxy ? Regards, Julien > > > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --001636c5ad4d8c5164046ee35aca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello,

On Fri, Jul 17, 2009 at 3:25 AM, S= ebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi Julien,

Julien Bournelle a =E9crit :
>
> =A0 =A0 I was really talking about the NAS tha= t must route the message
> =A0 =A0 either to
> =A0 =A0 the local proxy or local server.
> =A0 =A0 I hope this clarifies.
>
>
> =A0no, I thought we agree on the issues but I'm afraid that we don= 't.
>
> =A0The routing will be based on the NAI (Network Access identifier) > provided by the terminal. If the realm part corresponds to the domain<= br> > A, the message is routed to SERVER_A else to PROXY_A. So what's th= e
> issue ?

Ok, now I feel we are moving forward :)

The issue is that with ERP, the realm part of the NAI is domain A, but
the message must be routed to the proxy_A, not the server_A! which
basically does not happen with the behavior you describe.

And that is the routing issue I was talking about in the initial mail of this thread. :)

Do we agree now on this ?

If PROXY_A and SERVER_A are = not collocated and PROXY_A is collocated with the ERP server, yes, we have = an issue.

If the SERVER_A is collocated with the ERP server, we don&= #39;t have the issue ! :)

The issue would be: how does the SERVER_A receives from PROXY_A the ERP= stuff ?
<snip>
>

> First Issue: you have multiple local ERP/AAA servers in the visited > domain: how does the new NAS know which one has the keying material ?<= /div>
=A0

Oh, OK, sorry! I thought this issue was ruled out. I totally agree th= at
this is an issue that must be solved. Anyway I think we agreed it is not related to the new app-id discussion. I propose we have a different
thread to handle this issue : case of several ER servers in the domain,
with only one bootstrapped for the peer.

Yes we agree.= This is an issue and App-Id doesn't help.
=A0


> Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER
> message to this AAA server. How does the AAA server knows if this DER<= br> > message is for EAP processing or ERP processing ?
I was not aware of this issue. By simply looking at the EAP content (= EAP
code), or matching the user name with either user table or key cache, it should be easy to retrieve the correct application, IMHO. The
application ID purpose was not for internal routing inside a peer (at
least not in my initial idea), but for routing in the Diameter network.
I hope it is now clarified from the first answer in this mail?
=


App-Id is also used in a internal AAA server to pass the messa= ge to the correct Application. As you know, the same AAA server with a Diam= eter Base Protocol stack could implement different Diameter Application on = top of the Base Protocol.

Finally, for this reason, I tend to think that having a App-Id for ERP = would be beneficial to avoid overload the EAP Application.
=A0


> I'm afraid that we have this "cycling" discussion becaus= e architecture
> is not well established...
Hmmm yes it is possible :) But I still don't see what could clari= fy it...

For example, does the local ERP server is col= ocated within local AAA/EAP server or in the local AAA/EAP proxy ?

=A0Regards,

=A0Julien
=A0


Best regards,
Sebastien.

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


--001636c5ad4d8c5164046ee35aca-- From vfajardo@research.telcordia.com Fri Jul 17 10:30:54 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 04B553A6EAC for ; Fri, 17 Jul 2009 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qilKQmKYtHh for ; Fri, 17 Jul 2009 10:30:53 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 1068E3A6972 for ; Fri, 17 Jul 2009 10:30:52 -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 n6HHUwr7028748; Fri, 17 Jul 2009 13:30:58 -0400 (EDT) From: "Victor Fajardo" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Qin Wu'" , "'Hannes Tschofenig'" , References: <024a01ca058a$ed63b200$1116a20a@nsnintra.net> <033001ca05db$daebe5b0$260ca40a@china.huawei.com> <3D3C75174CB95F42AD6BCC56E5555B450187FAF4@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450187FAF4@FIESEXC015.nsn-intra.net> Date: Fri, 17 Jul 2009 13:30:58 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <021b01ca0704$5db4e400$191eac00$@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: AcoF3BpOtyahBrZxSCKKMmBxYpblAQADyepgAEYrdlA= Content-Language: en-us Subject: Re: [Dime] Agenda (v1) 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: Fri, 17 Jul 2009 17:30:54 -0000 I think we can skip the base protocol presentation. Most of the folks who promised to review bis as part of the WGLC has done so .. even though most of it is partial. The latest version reflects their comments/discussion. We can open up this time slots for other presenters. -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, July 16, 2009 4:00 AM To: ext Qin Wu; Hannes Tschofenig; dime@ietf.org Subject: Re: [Dime] Agenda (v1) Sure. I put you on the agenda. >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Qin Wu >Sent: 16 July, 2009 09:09 >To: Hannes Tschofenig; dime@ietf.org >Subject: Re: [Dime] Agenda (v1) > >Hi, Chair: >May I ask 5~10 minutes to discuss the topic on Diameter >Attribute-Value Pairs for Cryptographic Key Transport? >The URL for this I-D is: >http://tools.ietf.org/html/draft-wu-dime-local-keytran-02 >Thanks! > >Regards! >-Qin >----- Original Message ----- >From: "Hannes Tschofenig" >To: >Sent: Thursday, July 16, 2009 4:29 AM >Subject: [Dime] Agenda (v1) > > >> Hi all, >> >> here is a first try for the agenda: >> http://www.ietf.org/proceedings/09jul/agenda/dime.txt >> >> Please take a look at it - you might find your name on it. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From sdecugis@nict.go.jp Sat Jul 18 04:54:47 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 F38AC3A6945 for ; Sat, 18 Jul 2009 04:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] 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 azKKqkfqpPYB for ; Sat, 18 Jul 2009 04:54:46 -0700 (PDT) Received: from sd-1637.dedibox.fr (sd-1637.dedibox.fr [88.191.18.91]) by core3.amsl.com (Postfix) with ESMTP id E593A3A68E9 for ; Sat, 18 Jul 2009 04:54:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sd-1637.dedibox.fr (Postfix) with ESMTP id 9D691A3C0F; Sat, 18 Jul 2009 13:52:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-1637.dedibox.fr Received: from sd-1637.dedibox.fr ([127.0.0.1]) by localhost (sd-1637.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKIdrLRIwiqN; Sat, 18 Jul 2009 13:52:29 +0200 (CEST) Received: from [192.168.1.104] (p1120-ipbf702hodogaya.kanagawa.ocn.ne.jp [124.100.104.120]) by sd-1637.dedibox.fr (Postfix) with ESMTPSA id 53566A3BF5; Sat, 18 Jul 2009 13:52:28 +0200 (CEST) Message-ID: <4A61B774.600@nict.go.jp> Date: Sat, 18 Jul 2009 20:52:20 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Julien Bournelle References: <4A4B1F2E.1020602@nict.go.jp> <5e2406980907030140l7c541725s3641b86ddefa2069@mail.gmail.com> <4A52A538.4040703@nict.go.jp> <5e2406980907130213i3a58a11ewd360a2e94baf27dc@mail.gmail.com> <4A5BDF43.50900@nict.go.jp> <5e2406980907150239p2df3c38tcb877be8a6215ff@mail.gmail.com> <4A5E8943.4090607@nict.go.jp> <5e2406980907160229j24933405j391f6605f3012bbf@mail.gmail.com> <4A5FD319.1050608@nict.go.jp> <5e2406980907170224s1744a91cnb849dc41b7b7321c@mail.gmail.com> In-Reply-To: <5e2406980907170224s1744a91cnb849dc41b7b7321c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] ERP & routing issue, take 2. 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: Sat, 18 Jul 2009 11:54:47 -0000 Hi, > > Do we agree now on this ? > > > If PROXY_A and SERVER_A are not collocated and PROXY_A is collocated > with the ERP server, yes, we have an issue. > > If the SERVER_A is collocated with the ERP server, we don't have the > issue ! :) > > The issue would be: how does the SERVER_A receives from PROXY_A the > ERP stuff ? Yes, now we are speaking of the same thing :) I had not considered so far that ERP server could be collocated with the EAP server, sorry! It would eliminate the routing issue(s) without the need for a new Application ID, as you mention. I personally prefer the separation as a new application, that allows more flexibility anyway (not forcing the collocaiton of the servers, and surcharge of the machine). > > Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER > > message to this AAA server. How does the AAA server knows if > this DER > > message is for EAP processing or ERP processing ? > I was not aware of this issue. By simply looking at the EAP > content (EAP > code), or matching the user name with either user table or key > cache, it > should be easy to retrieve the correct application, IMHO. The > application ID purpose was not for internal routing inside a peer (at > least not in my initial idea), but for routing in the Diameter > network. > I hope it is now clarified from the first answer in this mail? > > > > App-Id is also used in a internal AAA server to pass the message to > the correct Application. I guess this point is purely implementation-dependant, but I agree that a separate App ID is a great help for the implementors :) > As you know, the same AAA server with a Diameter Base Protocol stack > could implement different Diameter Application on top of the Base > Protocol. > > Finally, for this reason, I tend to think that having a App-Id for ERP > would be beneficial to avoid overload the EAP Application. Yes :) And also avoid overload of the box, not forcing the collocation for those who want to separate the EAP and ERP servers. > > I'm afraid that we have this "cycling" discussion because > architecture > > is not well established... > Hmmm yes it is possible :) But I still don't see what could > clarify it... > > > For example, does the local ERP server is colocated within local > AAA/EAP server or in the local AAA/EAP proxy ? True :) I always assumed it was a separate entity so far (from my comprehension of ERP). But if a constraint is added that it is collocated with one of these entities, it is true that it will influence the design of Diameter ERP, and should be decided before going further in Diameter ERP. Of course, if Diameter ERP is able to accomodate ERP server as a completely separate entity, it is very easy to collocate it with something else later... We should probably bring this discussion once again in the HOKEY mailing-list? Best regards, Sebastien. From anders.gs.svensson@ericsson.com Sun Jul 19 03:45: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 A0BBB3A6C1C for ; Sun, 19 Jul 2009 03:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rc4XYIbqz57 for ; Sun, 19 Jul 2009 03:45:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 597D23A6864 for ; Sun, 19 Jul 2009 03:45:44 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-cc-4a62f956b9cf Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7C.91.14528.659F26A4; Sun, 19 Jul 2009 12:45:42 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 12:45:42 +0200 Received: from seasc0634.dyn.rnd.as.sw.ericsson.se.ericsson.com ([130.100.104.75]) by esealmw115.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 12:45:42 +0200 From: Anders G S Svensson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19042.63829.422881.368329@seasc0634.dyn.rnd.as.sw.ericsson.se> Date: Sun, 19 Jul 2009 12:45:41 +0200 To: dime@ietf.org X-Mailer: VM 7.19 under Emacs 21.3.1 X-OriginalArrivalTime: 19 Jul 2009 10:45:42.0516 (UTC) FILETIME=[10324B40:01CA085E] X-Brightmail-Tracker: AAAAAA== Subject: [Dime] rfc3588bis-18 comments/questions (message / grouped avp grammar; peer election) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: anders.gs.svensson@ericsson.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 10:45:46 -0000 I have some comments/questions on http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-18.txt. ======================= 3.2 and 4.4 specify command-def = command-name "::=" diameter-message command-name = diameter-name diameter-name = ALPHA *(ALPHA / DIGIT / "-") and grouped-avp-def = name "::=" avp name-fmt = ALPHA *(ALPHA / DIGIT / "-") name = name-fmt respectively but most specifications in the document include angle brackets around command-name/name. For example: ::= < Diameter Header: 257, REQ > These brackets would complicate the parsing a bit since could be interpreted as a "fixed" in a previous command-def until "::=" is parsed. ======================= 3.2 and 4.4 also specify diameter-message = header [ *fixed] [ *required] [ *optional] and avp = header [ *fixed] [ *required] [ *optional] respectively but the distinction between required and optional is a bit unclear. The production for qual has a comment that min on an optional avp must be 0 if present but there's no corresponding comment that min on a required should be at least 1 if present. In any case, I find comment ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). on the qual production a bit cryptic. All the optional rule states is ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. The AVP can ; appear anywhere in the message. so if the comments are explaining to me that optional doesn't mean what the word and ABNF would usually convey then I don't see it. The only point I can see being made (implicitly) is that an avp-name in a 'required' rule *can* evaluate to an avp name included in a fixed or required rule. Is there really a required/optional distinction here or is the distinction just between fixed or not? ======================= 5.6.1 notes that it's not possible to know the identify of a peer initiating a connection until a CER is received from it, motivating the R-Conn-CER event in the Peer State Machine. However, the same problem exists on the initiating side: the peer's identity isn't truly known until the CEA is received. As a result, the election mandated by a R-Conn-CER event in state Wait-I-CEA can't take place since one party in the election isn't yet known. Am I missing something here? /Anders From vfajardo@research.telcordia.com Mon Jul 20 11:22: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 7742A3A6CFD for ; Mon, 20 Jul 2009 11:22:14 -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 1pEj7DkX6oC8 for ; Mon, 20 Jul 2009 11:22:07 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 466023A6D7C for ; Mon, 20 Jul 2009 11:22:07 -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 n6KIFaLP008889; Mon, 20 Jul 2009 14:15:39 -0400 (EDT) From: "Victor Fajardo" To: , References: <19042.63829.422881.368329@seasc0634.dyn.rnd.as.sw.ericsson.se> In-Reply-To: <19042.63829.422881.368329@seasc0634.dyn.rnd.as.sw.ericsson.se> Date: Mon, 20 Jul 2009 14:15:36 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <023e01ca0966$1624b8e0$426e2aa0$@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: AcoIXhcKRc/CecYCRUSde6yCh5LDWgBBB8vw Content-Language: en-us Subject: Re: [Dime] rfc3588bis-18 comments/questions (message / grouped avp grammar; peer election) 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: Mon, 20 Jul 2009 18:22:14 -0000 Hi Anders, Thanks for the comments. Replies inline: ======================= 3.2 and 4.4 specify command-def = command-name "::=" diameter-message command-name = diameter-name diameter-name = ALPHA *(ALPHA / DIGIT / "-") and grouped-avp-def = name "::=" avp name-fmt = ALPHA *(ALPHA / DIGIT / "-") name = name-fmt respectively but most specifications in the document include angle brackets around command-name/name. For example: ::= < Diameter Header: 257, REQ > These brackets would complicate the parsing a bit since could be interpreted as a "fixed" in a previous command-def until "::=" is parsed. [Victor]: I'm not really sure what you mean. Is this an implementation specific parsing algo that feed's of the actual text in the document ? If so, that maybe a implementation specific issue. ======================= 3.2 and 4.4 also specify diameter-message = header [ *fixed] [ *required] [ *optional] and avp = header [ *fixed] [ *required] [ *optional] respectively but the distinction between required and optional is a bit unclear. The production for qual has a comment that min on an optional avp must be 0 if present but there's no corresponding comment that min on a required should be at least 1 if present. In any case, I find comment ; NOTE: "[" and "]" have a different meaning ; than in ABNF (see the optional rule, above). on the qual production a bit cryptic. All the optional rule states is ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. The AVP can ; appear anywhere in the message. so if the comments are explaining to me that optional doesn't mean what the word and ABNF would usually convey then I don't see it. The only point I can see being made (implicitly) is that an avp-name in a 'required' rule *can* evaluate to an avp name included in a fixed or required rule. Is there really a required/optional distinction here or is the distinction just between fixed or not? [Victor]: I can understand that text is really a bit vague. That needs to be fixed. Anyway, if I understand your last question correctly, a "[..]" is present in [*required] to provide rules when designing a command ABNF, i.e. it is possible that a command ABNF may did not define any required avps (min==0 for required). Within the "diameter-message" ruleset, "[..]" for *required and *optional are the same but they refer to the ruleset when designing message. ======================= 5.6.1 notes that it's not possible to know the identify of a peer initiating a connection until a CER is received from it, motivating the R-Conn-CER event in the Peer State Machine. However, the same problem exists on the initiating side: the peer's identity isn't truly known until the CEA is received. As a result, the election mandated by a R-Conn-CER event in state Wait-I-CEA can't take place since one party in the election isn't yet known. Am I missing something here? [Victor]: 5.6.1 seems clear to me. I'm not sure if waiting for a CEA to correctly identify a peer your connecting to is logical. You have to know who you want to talk to so you can connect to begin with. That's why we have peer discovery. Typically, the host identity in the CEA should match the identity of the host you connected to. Regards, victor /Anders _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From hannes.tschofenig@nsn.com Mon Jul 20 12:22:17 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 2D3C03A6D8D for ; Mon, 20 Jul 2009 12:22:17 -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 n5NRCcOwZ+Z5 for ; Mon, 20 Jul 2009 12:22:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 35CE728C1C8 for ; Mon, 20 Jul 2009 12:22:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6KJLqli019433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 20 Jul 2009 21:21:52 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6KJLqPr021544; Mon, 20 Jul 2009 21:21:52 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 21:21:51 +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: Mon, 20 Jul 2009 22:24:14 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45018ADBC6@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-tsou-dime-realm-based-redirect-01.txt Thread-Index: AcoJb6qhyMz52EUpT/GT1YfeZFAlLQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 20 Jul 2009 19:21:51.0700 (UTC) FILETIME=[55AE8140:01CA096F] Subject: [Dime] draft-tsou-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: Mon, 20 Jul 2009 19:22:17 -0000 Hi all,=20 we issued a HUM on the mailing list (see http://www.ietf.org/mail-archive/web/dime/current/msg03595.html) regarding draft-tsou-dime-realm-based-redirect-01.txt. We got a positive response from Glen Zorn, Sebastien Decugis, and Wolfgang Steigerwald. There were no objections. Although the feedback is quite weak but good enough we and Dan believe.=20 We hope that Glen, Sebastien, and Wolfgang help in reviewing the document.=20 @Tina & Tom: Please submit the document as a DIME WG item.=20 Ciao Hannes & Victor From anders.gs.svensson@ericsson.com Mon Jul 20 15:52:05 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 D72AB3A6BC5 for ; Mon, 20 Jul 2009 15:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.684 X-Spam-Level: X-Spam-Status: No, score=-3.684 tagged_above=-999 required=5 tests=[AWL=-2.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35] 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 ejlqjIrpMK5j for ; Mon, 20 Jul 2009 15:52:04 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 3F77F3A6783 for ; Mon, 20 Jul 2009 15:52:03 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-7c-4a64f11513ea Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id E5.F7.18827.511F46A4; Tue, 21 Jul 2009 00:35:01 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:35:01 +0200 Received: from seasc0634.dyn.rnd.as.sw.ericsson.se.ericsson.com ([130.100.104.75]) by esealmw115.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 00:35:00 +0200 From: Anders G S Svensson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19044.61712.545527.994764@seasc0634.dyn.rnd.as.sw.ericsson.se> Date: Tue, 21 Jul 2009 00:34:56 +0200 To: , In-Reply-To: <023e01ca0966$1624b8e0$426e2aa0$@telcordia.com> References: <19042.63829.422881.368329@seasc0634.dyn.rnd.as.sw.ericsson.se> <023e01ca0966$1624b8e0$426e2aa0$@telcordia.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-OriginalArrivalTime: 20 Jul 2009 22:35:00.0438 (UTC) FILETIME=[511B9760:01CA098A] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Dime] rfc3588bis-18 comments/questions (message / grouped avp grammar; peer election) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: anders.gs.svensson@ericsson.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:52:05 -0000 Hi Victor. Thanks for the reply. Response below. > ======================= > 3.2 and 4.4 specify > > command-def = command-name "::=" diameter-message > command-name = diameter-name > diameter-name = ALPHA *(ALPHA / DIGIT / "-") > > and > > grouped-avp-def = name "::=" avp > name-fmt = ALPHA *(ALPHA / DIGIT / "-") > name = name-fmt > > respectively but most specifications in the document include angle > brackets around command-name/name. For example: > > ::= < Diameter Header: 257, REQ > > > These brackets would complicate the parsing a bit since could be > interpreted as a "fixed" in a previous command-def until "::=" is > parsed. > > [Victor]: I'm not really sure what you mean. Is this an implementation > specific parsing algo that feed's of the actual text in the document ? If > so, that maybe a implementation specific issue. Yes, the parsing is of definitions written according to the grammar. My point was simply that angle brackets around command-name aren't specified in the grammar but are present in all the definitions in the document. > ======================= > 3.2 and 4.4 also specify > > diameter-message = header [ *fixed] [ *required] [ *optional] > > and > > avp = header [ *fixed] [ *required] [ *optional] > > respectively but the distinction between required and optional is a > bit unclear. The production for qual has a comment that min on an > optional avp must be 0 if present but there's no corresponding comment > that min on a required should be at least 1 if present. > > In any case, I find comment > > ; NOTE: "[" and "]" have a different meaning > ; than in ABNF (see the optional rule, above). > > on the qual production a bit cryptic. All the optional rule states is > > ; The avp-name in the 'optional' rule cannot > ; evaluate to any AVP Name which is included > ; in a fixed or required rule. The AVP can > ; appear anywhere in the message. > > so if the comments are explaining to me that optional doesn't mean > what the word and ABNF would usually convey then I don't see it. The > only point I can see being made (implicitly) is that an avp-name in a > 'required' rule *can* evaluate to an avp name included in a fixed or > required rule. > > Is there really a required/optional distinction here or is the > distinction just between fixed or not? > > > [Victor]: I can understand that text is really a bit vague. That needs to be > fixed. Anyway, if I understand your last question correctly, a "[..]" is > present in [*required] to provide rules when designing a command ABNF, i.e. > it is possible that a command ABNF may did not define any required avps Yes, this I understand. However, I took the comment's "[" and "]" to refer to the literal tokens in the optional production: optional = [qual] "[" avp-name "]" Possibly the wrong reading but, as you say, the text is quite vague. My point here was that if I can specify *{XXX} for a "required" AVP then it doesn't seem particularly required. (Since 0 occurrences is acceptable.) I'm missing a statement that min must be at least 1 for a required avp. > (min==0 for required). Within the "diameter-message" ruleset, "[..]" for > *required and *optional are the same but they refer to the ruleset when > designing message. > > > > ======================= > 5.6.1 notes that it's not possible to know the identify of a peer > initiating a connection until a CER is received from it, motivating > the R-Conn-CER event in the Peer State Machine. However, the same > problem exists on the initiating side: the peer's identity isn't truly > known until the CEA is received. As a result, the election mandated by > a R-Conn-CER event in state Wait-I-CEA can't take place since one > party in the election isn't yet known. > > Am I missing something here? > > > [Victor]: 5.6.1 seems clear to me. I'm not sure if waiting for a CEA to > correctly identify a peer your connecting to is logical. You have to know > who you want to talk to so you can connect to begin with. That's why we have Well, I have to know the peer's IP address and port to connect. I don't have to know, and can't know for certain, what Origin-Host the peer will identify itself as, and it's this that's needed to perform the election. Anders > peer discovery. Typically, the host identity in the CEA should match the > identity of the host you connected to. > > Regards, > victor > > > /Anders > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From vfajardo@research.telcordia.com Tue Jul 21 06:09:52 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 AF6CD3A68E8 for ; Tue, 21 Jul 2009 06:09:52 -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 jnuQGqgeSLUm for ; Tue, 21 Jul 2009 06:09:45 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 89F5C3A6AD0 for ; Tue, 21 Jul 2009 06:09:45 -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 n6LD8dab002223; Tue, 21 Jul 2009 09:08:39 -0400 (EDT) From: "Victor Fajardo" To: , References: <19042.63829.422881.368329@seasc0634.dyn.rnd.as.sw.ericsson.se> <023e01ca0966$1624b8e0$426e2aa0$@telcordia.com> <19044.61712.545527.994764@seasc0634.dyn.rnd.as.sw.ericsson.se> In-Reply-To: <19044.61712.545527.994764@seasc0634.dyn.rnd.as.sw.ericsson.se> Date: Tue, 21 Jul 2009 09:08:39 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <02b901ca0a04$60029790$2007c6b0$@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: AcoJilKiqAtByiCXQr6HCDIeeX90zAAdtF3w Content-Language: en-us Subject: Re: [Dime] rfc3588bis-18 comments/questions (message / grouped avp grammar; peer election) 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, 21 Jul 2009 13:09:52 -0000 Hi Andes, Comments inline: > ======================= > 3.2 and 4.4 specify > > command-def = command-name "::=" diameter-message > command-name = diameter-name > diameter-name = ALPHA *(ALPHA / DIGIT / "-") > > and > > grouped-avp-def = name "::=" avp > name-fmt = ALPHA *(ALPHA / DIGIT / "-") > name = name-fmt > > respectively but most specifications in the document include angle > brackets around command-name/name. For example: > > ::= < Diameter Header: 257, REQ > > > These brackets would complicate the parsing a bit since could be > interpreted as a "fixed" in a previous command-def until "::=" is > parsed. > > [Victor]: I'm not really sure what you mean. Is this an implementation > specific parsing algo that feed's of the actual text in the document ? If > so, that maybe a implementation specific issue. Yes, the parsing is of definitions written according to the grammar. My point was simply that angle brackets around command-name aren't specified in the grammar but are present in all the definitions in the document. [Victor]: I see. Seems all diameter related documents follow this convention of "" in their definition. Not really sure what about the origins nor the reasoning behind this practice but we may need to update the grammar to maintain the well-known practice ... unless you see something else wrong with it (other than complicating your parser). > ======================= > 3.2 and 4.4 also specify > > diameter-message = header [ *fixed] [ *required] [ *optional] > > and > > avp = header [ *fixed] [ *required] [ *optional] > > respectively but the distinction between required and optional is a > bit unclear. The production for qual has a comment that min on an > optional avp must be 0 if present but there's no corresponding comment > that min on a required should be at least 1 if present. > > In any case, I find comment > > ; NOTE: "[" and "]" have a different meaning > ; than in ABNF (see the optional rule, above). > > on the qual production a bit cryptic. All the optional rule states is > > ; The avp-name in the 'optional' rule cannot > ; evaluate to any AVP Name which is included > ; in a fixed or required rule. The AVP can > ; appear anywhere in the message. > > so if the comments are explaining to me that optional doesn't mean > what the word and ABNF would usually convey then I don't see it. The > only point I can see being made (implicitly) is that an avp-name in a > 'required' rule *can* evaluate to an avp name included in a fixed or > required rule. > > Is there really a required/optional distinction here or is the > distinction just between fixed or not? > > > [Victor]: I can understand that text is really a bit vague. That needs to be > fixed. Anyway, if I understand your last question correctly, a "[..]" is > present in [*required] to provide rules when designing a command ABNF, i.e. > it is possible that a command ABNF may did not define any required avps Yes, this I understand. However, I took the comment's "[" and "]" to refer to the literal tokens in the optional production: optional = [qual] "[" avp-name "]" Possibly the wrong reading but, as you say, the text is quite vague. My point here was that if I can specify *{XXX} for a "required" AVP then it doesn't seem particularly required. (Since 0 occurrences is acceptable.) I'm missing a statement that min must be at least 1 for a required avp. [Victor]: Now that you mention it, I wonder if the "[..]" in "diameter-message = header [ *fixed] [ *required] [ *optional]" really follows the "[qual] [ avp-name ]" ruleset or where those "[..]" place there to delineate fixed, required and optional avp types given that the 'qaul' is inside the braces. If this is the case then this is what we may want to clarify. > (min==0 for required). Within the "diameter-message" ruleset, "[..]" for > *required and *optional are the same but they refer to the ruleset when > designing message. > > > > ======================= > 5.6.1 notes that it's not possible to know the identify of a peer > initiating a connection until a CER is received from it, motivating > the R-Conn-CER event in the Peer State Machine. However, the same > problem exists on the initiating side: the peer's identity isn't truly > known until the CEA is received. As a result, the election mandated by > a R-Conn-CER event in state Wait-I-CEA can't take place since one > party in the election isn't yet known. > > Am I missing something here? > > > [Victor]: 5.6.1 seems clear to me. I'm not sure if waiting for a CEA to > correctly identify a peer your connecting to is logical. You have to know > who you want to talk to so you can connect to begin with. That's why we have Well, I have to know the peer's IP address and port to connect. I don't have to know, and can't know for certain, what Origin-Host the peer will identify itself as, and it's this that's needed to perform the election. [Victor]: Then perhaps we should mandate the use or host/identities when peer makes connection attempts as is already implied by the discovery schemes (and common practice). It may also be useful since we can validate the origin-host against the identity that we use to initiate the connection to. I know that some implementations does this already but I'm not sure if there's going to be problems during deployment when a node's may not be completely in sync with the responsible DNS, i.e. a node may have several registered names, which one does it use for origin-host, or is this a policy/configuration issue and specs should not really worry about it. Regards, Victor Anders > peer discovery. Typically, the host identity in the CEA should match the > identity of the host you connected to. > > Regards, > victor > > > /Anders > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From dromasca@avaya.com Tue Jul 21 06:58: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 280A13A6E64 for ; Tue, 21 Jul 2009 06:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 y6jCSA1Tk7oj for ; Tue, 21 Jul 2009 06:58: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 BF37528C2C8 for ; Tue, 21 Jul 2009 06:57:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,240,1246852800"; d="scan'208";a="167780795" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 21 Jul 2009 09:57:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2009 09:57:49 -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, 21 Jul 2009 15:57:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-nai-routing-02.txt thread-index: AcoKCzmD/o25/cLgS0qHbop+DGf4yw== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-nai-routing-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, 21 Jul 2009 13:58:01 -0000 I have reviewed draft-ietf-dime-nai-routing-02.txt. I believe that the document is stable and clear, and good enough to go directly to IETF Last Call.=20 I have two editorial comments. Please consider them together with the other LC comments:=20 1. The document should update either 3588 or 3588bis, but not both. The reason is that when 3588bis will be approved it will obsolete 3588. I suggest that by now we keep only 3588 and we mention in a note to the RFC Editor that in case 3588bis is approved prior to the approval of this document 3588bis replaces 3588 in the header, as well as in the document text and references. =20 2. Running id-nits results in the following comment:=20 -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) I am sending this to IETF Last Call.=20 Thanks and Regards, Dan From wwwrun@core3.amsl.com Tue Jul 21 09:57:22 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 B5E5E28C322; Tue, 21 Jul 2009 09:57:22 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090721165722.B5E5E28C322@core3.amsl.com> Date: Tue, 21 Jul 2009 09:57:22 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-diameter-qos (Diameter Quality of Service Application) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:57:22 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Quality of Service Application ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15820&rfc_flag=0 From wwwrun@core3.amsl.com Tue Jul 21 09:58:14 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 39BC128C325; Tue, 21 Jul 2009 09:58:14 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090721165814.39BC128C325@core3.amsl.com> Date: Tue, 21 Jul 2009 09:58:14 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-nai-routing (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 Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:58:14 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter User-Name and Realm Based Request Routing Clarifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18114&rfc_flag=0 From jouni.nospam@gmail.com Tue Jul 21 13:56: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 142073A6E92 for ; Tue, 21 Jul 2009 13:56:11 -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 2X6QkXzntvJS for ; Tue, 21 Jul 2009 13:56:10 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 2C7CE3A6E90 for ; Tue, 21 Jul 2009 13:56:10 -0700 (PDT) Received: from a88-114-70-156.elisa-laajakaista.fi (a88-114-70-156.elisa-laajakaista.fi [88.114.70.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id E9C0F2166F9; Tue, 21 Jul 2009 23:56:04 +0300 (EEST) Message-Id: <0125D215-E3FF-42BA-B4B1-3C2FE679153A@gmail.com> From: jouni To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 23:56:04 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-nai-routing-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, 21 Jul 2009 20:56:11 -0000 Hi Dan, Thanks for the review. See my comments inline. On Jul 21, 2009, at 4:57 PM, Romascanu, Dan (Dan) wrote: > I have reviewed draft-ietf-dime-nai-routing-02.txt. I believe that > the > document is stable and clear, and good enough to go directly to IETF > Last Call. > > I have two editorial comments. Please consider them together with the > other LC comments: > > 1. The document should update either 3588 or 3588bis, but not both. > The > reason is that when 3588bis will be approved it will obsolete 3588. I > suggest that by now we keep only 3588 and we mention in a note to the > RFC Editor that in case 3588bis is approved prior to the approval of > this document 3588bis replaces 3588 in the header, as well as in the > document text and references. This sounds feasible. > > 2. Running id-nits results in the following comment: > > -- Obsolete informational reference (is this intentional?): RFC 2486 > (Obsoleted by RFC 4282) This is intentional. We specifically talk about the RFC2486 that is referenced in RFC3588. > > I am sending this to IETF Last Call. > > Thanks and Regards, > > Dan Cheers, Jouni > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dongsun@alcatel-lucent.com Tue Jul 21 21:16:04 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 684DD3A67A1 for ; Tue, 21 Jul 2009 21:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 LFzEo4a1U+ZH for ; Tue, 21 Jul 2009 21:16:03 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1CDDB3A635F for ; Tue, 21 Jul 2009 21:16:02 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n6M4FvFL018777; Tue, 21 Jul 2009 23:15:58 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n6M4FufM006667; Tue, 21 Jul 2009 23:15:56 -0500 (CDT) Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 21 Jul 2009 23:15:56 -0500 From: "Sun, Dong (Dong)" To: "'Romascanu, Dan (Dan)'" , "'dime@ietf.org'" Date: Tue, 21 Jul 2009 23:15:53 -0500 Thread-Topic: AD review for draft-ietf-dime-diameter-qos-08.txt Thread-Index: Acn07ujvnQJ7sPNtQsW/Hl4BloxxigVdECnA Message-ID: <38A3C77CC1D12D4DB6632EFEE8128BFE132F8F9749@USNAVSXCHMBSA1.ndc.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: 'Avri Doria' Subject: Re: [Dime] AD review for draft-ietf-dime-diameter-qos-08.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, 22 Jul 2009 04:16:04 -0000 Dan, I am taking a crack at your comments. See inline... Avri, I though you authored the security section. Could you take a look at commen= ts T8/9/10 and respond? Regards, Dong=20 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Rom= ascanu, Dan (Dan) Sent: Wednesday, June 24, 2009 1:12 PM To: dime@ietf.org Subject: [Dime] AD review for draft-ietf-dime-diameter-qos-08.txt Please find below the AS review for draft-ietf-dime-diameter-qos-08.txt. I believe that there is a need for a revised ID before going to IETF Last C= all in order to clarify a number of questions and fix a few more.=20 The comments below are divided into Technical and Editorial. T1. Can the QoS application support multiple concurrent sessions between an= NE and an AE? I think that we need to clarify and add adequate text. >>yes. The QoS application session can be associated with a subscriber. Wil= l add some texts as the last paragraph in section 4.2: "The QoS authorization session is typically established per subscriber base= (i.e.all requests with the same user ID), but it is also possible to be es= tablished on per node or per request base. The concurrent sessions between = an NE and an AE are identified by different Session-ID. " T2. Can an NE work with multiple AEs? The security considerations section m= entions this as a problem but provides no hints as to how to solve it. I th= ink that we need to clarify and add adequate text. >> suggest to remove following sentences from section 11 since they are inc= orrect.=20 "Lastly, there can be security vulnerability to the applications traversing a Network Element when a resource on a Network Element is controlled by multiple Authorizing Entities. The operation of a Network Element may be disrupted due to conflicting directives from multiple Authorizing Entities. Care must be taken in deployment to ensure that Network Elements are impacted by misconfiguration." The following texts will be added into section 4.2.2 (at the end of the sec= tion). "In the case Multiple AEs control the same NE, the NE should make the selec= tion on the authorization decision to be enforced based on the priority of = the request. " T3. Are different modes of operation supported for a given NE? I think that= we need to clarify and add adequate text. >> yes. The operation mode is on per session. It is descrbed under section = 4.2.=20 T4. The Terminology section mentions that an AE corresponds to an RFC 2573 PDP and an NE corresponds to an RFC 2573 PEP. I am wondering why we go= through the pain of inventing a new set of terms (AE, NE) and we do not ju= st use the 2573 terminology all over.=20 >> one of reasons to define new terms is to have a clear scope of the funct= ionality. I think the AE and NE are well defined. If the linkage to PDP/PEP= causes the confusion, the sentence could be removed. But I personally feel= it is ok to leave it as now. =20 T5. In Section 2 - 'For example, a SIP Agent is one kind of Application End= point.' - is this a SIP User Agent?=20 >> yes. T6.In section 4.2.1=20 The AE's identity, information about the application session and/or identity and credentials of the QoS RRE, requested QoS parameters, signaling session identifier and/or QoS enabled data flows identifiers MAY be encapsulated into respective Diameter AVPs and included in the Diameter message sent to the AE. =20 Why is this a MAY? Is there another way to pass AE identity information at = session establishment (assuming we are doing Diameter and not something els= e) >> The MAY here means not every parameter has to be included. Concerning AE= 's ID, it may not need if the security is not a concern in the deployment. T7. In the table the data type of the QoS-Authorization-Data attribute is G= rouped, while in the textual description it shows as OctetString >> I think it should be OctetString. Otherwise, we need to define what're i= n the grouped AVP. T8. I find the security considerations section weak. I suggest that for eac= h threat the security mechanisms within Diameter or external to Diameter th= at can be used for protection be explicitly mentioned.=20 >> I am neither security expert nor the author of this section.=20 Avri, could you take care of this comment as well T9/T10. I will incorporat= e into next version. T9. Logging for security events related to authentication and authorization= should be enhanced by sending alerts to a management system (if available) T10. 'Failing to provide the required credentials should be subject to logg= ing.'. Why is this a non-capitalized should and not a capitalized MUST?=20 E1. Potential problems detected by idnits:=20 >> I will fix all nits in next version. Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but = was first submitted before 10 November 2008. Should you add the disclaime= r? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." Checking references for intended status: Proposed Standard =20 ------------------------------------------------------------------------ ---- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) ... =3D=3D Outdated reference: A later version (-12) exists of draft-ietf-dime-qos-attributes-11 =3D=3D Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-10 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) =3D=3D Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-19 -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) E2. In section 3.1=20 Note that the parameters passed to the Traffic Control function may be different from requested QoS (depending on the authorization decision).=20 should rather be Note that the parameters passed to the Traffic Control function may be different from the ones in the requested QoS (de= pending on the authorization decision).=20 >>ok E3. In section 3.2.2 page 13: either Push mode or Pull mode may be used Better to use MAY with 2119 capitalization >>ok E4. The language used in the requirements in section 3.4 is confusing. Many of the requirements are being expressed on the 'QoS AAA protocol' - sh= ould not they be rather on the 'Diameter QoS application'?=20 >>ok E5. The term 'Bearer' in the Bearer Gating requirement should probably be r= eplaced with some other more IP-friendly term >> how about 'media'? E6. In the Accounting Correlation requirement 'may' should be capitalized t= o MAY >>ok E7. In the 'Interaction with other AAA Applications' required should be ca= pitalized to REQUIRED >>ok E8.=20 Authentication of the QoS reservation requesting entity to the AE is necessary if a particular Diameter QoS application protocol run cannot be related (or if there is no intention to relate it) to a prior authentication.=20 Something is missing or wrong here. What is a 'Diameter QoS application pro= tocol run'?=20 >> might be an editing nit. will delete them. E9. In Section 4.2.1 The NE generates a QAR message in which the required objects from the QoS signaling message that is converted to Diameter AVPs. Bad syntax makes this phrase impossible to understand. >> revised as: "The NE converts the required objects from the QoS signaling message to Dia= meter AVPs and generates a QAR message" E10. In Section 4.2.2 The indication of QoS reservation and activation of the data flow can be provided by the QoS-Install-Answer message immediately. In the case of successful enforcement, the Result-Code (=3D DIAMETER_SUCCESS, (see Section 7.1)) information is provided in the QIA message. Note that the reserved QoS resources reported in the QIA message MAY be different than those initially authorized with the QIR message, due to the QoS signaling specific behavior (e.g., receiver-initiated reservations with One-Path-With-Advertisements) or specific process of QoS negotiation along the data path. When path coupled signaling is used for QoS reservation along the data path, QAR/QAA may be used to update the results of QoS reservation and enforcement following the establishment of data flows. The usage of keywords seems to be wrong in this paragraph. The first MAY sh= ould rather be a 'may' while in the last phrase the 'may' seems to indicate= a requirement, so it should rather be capitalized as MAY. >> Ok. E11. Last sentence in section 4.2.3 s/or globally routable IP address/or a = globally routable IP address/ >> ok. E12. In section 5 s/Diameter nodes conforming to this specification MAY adv= ertise support by including/Diameter nodes conforming to this specification= MAY advertise support for the Diameter QoS Application by including/ =20 >>ok E13. It is recommended to put all the ABNF definitions in section 5 in an A= nnex that can also include in one place the copyright notice.=20 >> you mean all the message content? Seems not the common way for Diameter = specs. E14. In section 6/1 s/This MUST be supported/These MUST be supported/ >> ok =20 Thanks and Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dromasca@avaya.com Wed Jul 22 01:08: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 B595F3A68E9 for ; Wed, 22 Jul 2009 01:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 oq1GGH4A5maV for ; Wed, 22 Jul 2009 01:08:57 -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 CADD33A6889 for ; Wed, 22 Jul 2009 01:08:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,245,1246852800"; d="scan'208";a="177622355" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jul 2009 04:07:42 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jul 2009 04:07:42 -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, 22 Jul 2009 10:07:29 +0200 Message-ID: In-Reply-To: <0125D215-E3FF-42BA-B4B1-3C2FE679153A@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] AD review of draft-ietf-dime-nai-routing-02.txt thread-index: AcoKRa4klSvdEMMNQaCQY+1a9R3jUQAXbhtg References: <0125D215-E3FF-42BA-B4B1-3C2FE679153A@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni" Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-nai-routing-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: Wed, 22 Jul 2009 08:08:57 -0000 =20 > -----Original Message----- > From: jouni [mailto:jouni.nospam@gmail.com]=20 > > > > 2. Running id-nits results in the following comment: > > > > -- Obsolete informational reference (is this intentional?): RFC 2486 > > (Obsoleted by RFC 4282) >=20 > This is intentional. We specifically talk about the RFC2486=20 > that is referenced in RFC3588. >=20 Fine with me.=20 Dan From dromasca@avaya.com Wed Jul 22 01:54:28 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 6EB263A68C5 for ; Wed, 22 Jul 2009 01:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 6B0VdK5n164y for ; Wed, 22 Jul 2009 01:54:27 -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 3A1E23A692D for ; Wed, 22 Jul 2009 01:54:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,245,1246852800"; d="scan'208";a="167867450" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Jul 2009 04:45:48 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Jul 2009 04:45:48 -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, 22 Jul 2009 10:45:35 +0200 Message-ID: In-Reply-To: <38A3C77CC1D12D4DB6632EFEE8128BFE132F8F9749@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review for draft-ietf-dime-diameter-qos-08.txt thread-index: Acn07ujvnQJ7sPNtQsW/Hl4BloxxigVdECnAABFWpvA= References: <38A3C77CC1D12D4DB6632EFEE8128BFE132F8F9749@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> From: "Romascanu, Dan (Dan)" To: "Sun, Dong (Dong)" , Cc: Avri Doria Subject: Re: [Dime] AD review for draft-ietf-dime-diameter-qos-08.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, 22 Jul 2009 08:54:28 -0000 Dong, I have sent dime-diameter-qos-09 to IETF Last Call.=20 I will submit my comments on this version as IETF Last Call version, to be considered together with the other IETF LC comments.=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com]=20 > Sent: Wednesday, July 22, 2009 7:16 AM > To: Romascanu, Dan (Dan); 'dime@ietf.org' > Cc: 'Avri Doria' > Subject: RE: AD review for draft-ietf-dime-diameter-qos-08.txt >=20 > Dan, >=20 > I am taking a crack at your comments. See inline... >=20 From dromasca@avaya.com Wed Jul 22 04:27:23 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 73D703A6EE6 for ; Wed, 22 Jul 2009 04:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.430, 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 fC5KUyfYKyZr for ; Wed, 22 Jul 2009 04:27:22 -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 90C5E3A6A90 for ; Wed, 22 Jul 2009 04:27:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,247,1246852800"; d="scan'208";a="167878953" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 22 Jul 2009 07:26:53 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jul 2009 07:26:53 -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, 22 Jul 2009 13:26:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-dime-pmip6-02.txt thread-index: AcoKv0wzBD14oqc0Q9uJ14rHeyN8Ig== From: "Romascanu, Dan (Dan)" To: Subject: [Dime] AD review of draft-ietf-dime-pmip6-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: Wed, 22 Jul 2009 11:27:23 -0000 Please find below the AD review of draft-ietf-dime-pmip6-02.txt. I believe that this I-D is stable and clear enough, and it can be submitted to IETF Last Call. Please consider the following comments together with the other IETF Last Call comments. 1. Section 4.8 describes the usage of the Service-Selection AVP and is normative as far as I understand. As this AVP is re-used from [I-D. ietf-dime-mip6-split] I believe that that I-D should be a normative reference rather than an informative reference. I do not see any problem with this, as [I-D. ietf-dime-mip6-split] is also aiming to be a PS and is ahead of this I-D, already in the RFC Editor queue.=20 2. Please expand DHCP at its first occurrence in the text.=20 3. Running id-nits results in a number of I-Ds having more recent versions, I guess the RFC Editor will catch those when the document will be in their hands.=20 Regards, Dan =20 From wwwrun@core3.amsl.com Wed Jul 22 12:06:34 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 B8C803A69F3; Wed, 22 Jul 2009 12:06:34 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090722190634.B8C803A69F3@core3.amsl.com> Date: Wed, 22 Jul 2009 12:06:34 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] Last Call: draft-ietf-dime-pmip6 (Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server) to Proposed Standard X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:06:34 -0000 The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dime-pmip6-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18113&rfc_flag=0 From jouni.nospam@gmail.com Thu Jul 23 04:21: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 845543A69AF for ; Thu, 23 Jul 2009 04:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 GOMqbQt7I0cx for ; Thu, 23 Jul 2009 04:21:43 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 796833A685F for ; Thu, 23 Jul 2009 04:21:43 -0700 (PDT) Received: by fxm18 with SMTP id 18so747972fxm.37 for ; Thu, 23 Jul 2009 04:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=5t+3ViosmYE6dLUNq+WGyoSOOgK5m+G0wuJjIQDwE28=; b=mCzix8KawMjDPYEwtLtbVqBOHpslNYqDhqBCBeXLRDXOw8kYAlJidryIGbWAyHjEn8 xnA/pwzh3BFyAoier2pZY2VhlHNKk149GlZRGBnMqraf5vlcFrCKX27AO3uPAK3Mv2kq AbCXEwQfWBcsKmzYppl/utH26TzG+5t2evGDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=wL//KFAtRepoFs72KH0jKnV7kVzL1dKQ5BFkjZYzcxLOL99rQsg9QdU/y59W+6HXmj 4OkUYnisOBF/8inKRjzeLDkNlP9xo7CbWcPPnN7NgzRS0MT5W9HGlLQp+O6GKjn6tsJ2 zTqMB+qn+dezSQ7oh9UWsU9UZHIKKugQ32Phs= Received: by 10.204.53.141 with SMTP id m13mr1909766bkg.11.1248341839706; Thu, 23 Jul 2009 02:37:19 -0700 (PDT) Received: from a88-112-140-13.elisa-laajakaista.fi (a88-112-140-13.elisa-laajakaista.fi [88.112.140.13]) by mx.google.com with ESMTPS id b17sm2356311fka.6.2009.07.23.02.37.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 02:37:19 -0700 (PDT) Message-Id: From: jouni korhonen To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 12:37:17 +0300 References: X-Mailer: Apple Mail (2.935.3) Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-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, 23 Jul 2009 11:21:44 -0000 Thanks Dan again for the review and progressing the I-D. On Jul 22, 2009, at 2:26 PM, Romascanu, Dan (Dan) wrote: > Please find below the AD review of draft-ietf-dime-pmip6-02.txt. I > believe that this I-D is stable and clear enough, and it can be > submitted to IETF Last Call. Please consider the following comments > together with the other IETF Last Call comments. > > 1. Section 4.8 describes the usage of the Service-Selection AVP and is > normative as far as I understand. As this AVP is re-used from [I-D. > ietf-dime-mip6-split] I believe that that I-D should be a normative > reference rather than an informative reference. I do not see any > problem > with this, as [I-D. ietf-dime-mip6-split] is also aiming to be a PS > and > is ahead of this I-D, already in the RFC Editor queue. Fine with me (don't know why it actually was informative in the first place). We'll change this. > > 2. Please expand DHCP at its first occurrence in the text. Ack. > > 3. Running id-nits results in a number of I-Ds having more recent > versions, I guess the RFC Editor will catch those when the document > will > be in their hands. Ack. Cheers, Jouni > > Regards, > > Dan > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From vfajardo@research.telcordia.com Fri Jul 24 07:07: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 1773928C0EC; Fri, 24 Jul 2009 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 cQKI2L6QJsKE; Fri, 24 Jul 2009 07:07:56 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id CCB773A67E3; Fri, 24 Jul 2009 07:07:55 -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 n6OE4gSp008715; Fri, 24 Jul 2009 10:04:42 -0400 (EDT) From: "Victor Fajardo" To: "'Romascanu, Dan \(Dan\)'" , Date: Fri, 24 Jul 2009 10:04:39 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <03f101ca0c67$b1512390$13f36ab0$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F2_01CA0C46.2A3F8390" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoMZ606EfpWIG5UQ6CsnyjHaDWC/A== Content-Language: en-us Cc: dime@ietf.org Subject: [Dime] PROTO Writeup for draft-ietf-dime-diameter-cmd-iana-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: Fri, 24 Jul 2009 14:07:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03F2_01CA0C46.2A3F8390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PROTO Writeup for "Updated IANA Considerations for Diameter Command Code Allocations" ============================================================================ ========= http://www.ietf.org/id/draft-ietf-dime-diameter-cmd-iana-01.txt (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Victor Fajardo (vfajardo@research.telcordia.com). Yes, this version is ready for publication. I have reviewed this document. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This content of this document has been subject of a design team and is part of the Diameter extensibility story. There has been sufficient review and discussion about this topic in DIME. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No further review is required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid agreement behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened appeal or extreme discontent with this document. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. No nits have been found. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. There is no problem with the normative references. No DOWNREF is necessary. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Yes, the IANA consideration section is in-sync with the body of the document. This document changes the allocation policy of an existing registry established with RFC 3588. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This document does not contain parts that are written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 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. Dan Romascanu is the responsible AD. ------=_NextPart_000_03F2_01CA0C46.2A3F8390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PROTO Writeup for "Updated IANA Considerations = for Diameter Command Code Allocations"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

http://www.ietf.org/id/draft-ietf-dime-diameter-cmd-ian= a-01.txt

 

   (1.a)  Who is the Document = Shepherd for this document?  Has the

          = Document Shepherd personally reviewed this version of the

          = document and, in particular, does he or she believe this

          = version is ready for forwarding to the IESG for publication?

 

Victor Fajardo (vfajardo@research.telcordia.com). =

Yes, this version is ready for publication. I have = reviewed this document.

 

   (1.b)  Has the document had = adequate review both from key WG members

          = and from key non-WG members?  Does the Document Shepherd have

          = any concerns about the depth or breadth of the reviews that

          = have been performed?

 

This content of this document has been subject of a = design team and is part of the

Diameter extensibility story. There has been = sufficient review and discussion

about this topic in DIME.

 

 

   (1.c)  Does the Document Shepherd = have concerns that the document

     =      needs more review from a particular or = broader perspective,

          = e.g., security, operational complexity, someone familiar with

          = AAA, internationalization, or XML?

 

No further review is required.

 

   (1.d)  Does the Document Shepherd = have any specific concerns or

          = issues with this document that the Responsible Area Director

          = and/or the IESG should be aware of?  For example, perhaps he

          = or she is uncomfortable with certain parts of the document, or

          = has concerns whether there really is a need for it.  In any

          = event, if the WG has discussed those issues and has indicated

          = that it still wishes to advance the document, detail those

          = concerns here.  Has an IPR disclosure related to this document

          = been filed?  If so, please include a reference to the

          = disclosure and summarize the WG discussion and conclusion on

          = this issue.

 

There are no concerns with this document. =

 

   (1.e)  How solid is the WG = consensus behind this document?  Does it

          = represent the strong concurrence of a few individuals, with

          = others being silent, or does the WG as a whole understand and

          = agree with it?

 

There is solid agreement behind this document. =

 

   (1.f)  Has anyone threatened an = appeal or otherwise indicated extreme

          = discontent?  If so, please summarize the areas of conflict in

          = separate email messages to the Responsible Area Director.  (It

          = should be in a separate email because this questionnaire is

          = entered into the ID Tracker.)

 

Nobody has threatened appeal or extreme discontent = with this document.

 

   (1.g)  Has the Document Shepherd = personally verified that the

          = document satisfies all ID nits?  (See

          = http://www.ietf.org/ID-Checklist.html and

          = http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are

          = not enough; this check needs to be thorough.  Has the document

     =      met all formal review criteria it needs = to, such as the MIB

          = Doctor, media type, and URI type reviews?  If the document

          = does not already indicate its intended status at the top of

          = the first page, please indicate the intended status here.

 

No nits have been found.

 

   (1.h)  Has the document split its = references into normative and

          = informative?  Are there normative references to documents that

          = are not ready for advancement or are otherwise in an unclear

          = state?  If such normative references exist, what is the

          = strategy for their completion?  Are there normative references

          = that are downward references, as described in [RFC3967]?  If

          = so, list these downward references to support the Area

          = Director in the Last Call procedure for them [RFC3967].

 

The document has references split into normative = and informative references.

There is no problem with the normative references. = No DOWNREF is necessary.

 

 

   (1.i)  Has the Document Shepherd = verified that the document's IANA

          = Considerations section exists and is consistent with the body

          = of the document?  If the document specifies protocol

          = extensions, are reservations requested in appropriate IANA

          = registries?  Are the IANA registries clearly identified?  If

          = the document creates a new registry, does it define the

          = proposed initial contents of the registry and an allocation

          = procedure for future registrations?  Does it suggest a

          = reasonable name for the new registry?  See [RFC2434].  If the

          = document describes an Expert Review process, has the Document

          = Shepherd conferred with the Responsible Area Director so that

          = the IESG can appoint the needed Expert during IESG Evaluation?

 

Yes, the IANA consideration section is in-sync with = the body of the document.

This document changes the allocation policy of an = existing registry established

with RFC 3588.

 

   (1.j)  Has the Document Shepherd = verified that sections of the

          = document that are written in a formal language, such as XML

          = code, BNF rules, MIB definitions, etc., validate correctly in

          = an automated checker?

 

This document does not contain parts that are = written in a formal language.

 

   (1.k)  The IESG approval = announcement includes a Document

      Announcement = Write-Up.  Please provide such a Document

      Announcement = Writeup?  Recent examples can be found in the

      "Action" = announcements for approved documents.  The approval

      announcement = contains the following sections:

 

      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

         &= nbsp;      policy change in the IANA = consideration section and

         &= nbsp;      has been discussed for some time. =

 

 

      = Personnel

 

    Victor Fajardo is the document = shepherd for this document.

    Dan Romascanu is the responsible = AD.

------=_NextPart_000_03F2_01CA0C46.2A3F8390-- From vfajardo@research.telcordia.com Sat Jul 25 13:42:39 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 ED3C63A6A5C for ; Sat, 25 Jul 2009 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-1.040, 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 gg4kDXM0zW-g for ; Sat, 25 Jul 2009 13:42:38 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id A35C73A696C for ; Sat, 25 Jul 2009 13:42:38 -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 n6PKgcs6012001 for ; Sat, 25 Jul 2009 16:42:38 -0400 (EDT) From: "Victor Fajardo" To: Date: Sat, 25 Jul 2009 16:42:38 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <041a01ca0d68$733ce150$59b6a3f0$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041B_01CA0D46.EC2B4150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoNaHJaURHtRKa5SBqrlkGfH7ICaQ== Content-Language: en-us Subject: [Dime] Slides pls. 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: Sat, 25 Jul 2009 20:42:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_041B_01CA0D46.EC2B4150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, For those presenting, pls send me slides by Monday (July 27th). Regards Victor ------=_NextPart_000_041B_01CA0D46.EC2B4150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

For those presenting, pls send me slides by Monday = (July 27th).

 

Regards

Victor

 

------=_NextPart_000_041B_01CA0D46.EC2B4150-- From root@core3.amsl.com Mon Jul 27 01: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 DF8023A6BA7; Mon, 27 Jul 2009 01: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: <20090727084501.DF8023A6BA7@core3.amsl.com> Date: Mon, 27 Jul 2009 01:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-base-protocol-mib-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: Mon, 27 Jul 2009 08:45: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 Base Protocol MIB Author(s) : G. Zorn, S. Comerica Filename : draft-ietf-dime-diameter-base-protocol-mib-02.txt Pages : 51 Date : 2009-07-27 Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-base-protocol-mib-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-diameter-base-protocol-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27014042.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 27 02: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 863D53A69EF; Mon, 27 Jul 2009 02: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: <20090727093001.863D53A69EF@core3.amsl.com> Date: Mon, 27 Jul 2009 02:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-capablities-update-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09: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 : The Diameter Capabilities Update Application Author(s) : G. Zorn, J. Kang Filename : draft-ietf-dime-capablities-update-00.txt Pages : 7 Date : 2009-07-27 This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-capablities-update-00.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-capablities-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27022824.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 27 23: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 B34C83A689A; Mon, 27 Jul 2009 23: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: <20090728064501.B34C83A689A@core3.amsl.com> Date: Mon, 27 Jul 2009 23:45:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 06: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 : Realm-Based Redirection In Diameter Author(s) : T. Tsou, T. Taylor Filename : draft-ietf-dime-realm-based-redirect-00.txt Pages : 5 Date : 2009-07-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-00.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-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27234009.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Jul 30 04: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 9CCC628C18C; Thu, 30 Jul 2009 04: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: <20090730110001.9CCC628C18C@core3.amsl.com> Date: Thu, 30 Jul 2009 04:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [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: Thu, 30 Jul 2009 11: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, 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. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-realm-based-redirect-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-30035559.I-D@ietf.org> --NextPart-- From tom.taylor@rogers.com Thu Jul 30 05:17:17 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 33F6628C218 for ; Thu, 30 Jul 2009 05:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 S2mOMGdCXuWr for ; Thu, 30 Jul 2009 05:17:16 -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 49B1B3A6C61 for ; Thu, 30 Jul 2009 05:17:16 -0700 (PDT) Received: (qmail 27544 invoked from network); 30 Jul 2009 12:17:15 -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:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W2x/CCMxo0XHCjGRbI1Y2W0ofrvo5k21EgpTnFIg5YQfv62g3WahBHxOsz95N8D878B6nxvNhiswoQa5YhalRCrqbfebEDy1TngjI5gJePE73IHGis7NuikBcKxAVKKZ8Ta94b/pkOTEJZDuSOHMdco7EiQqS4UMFiHxj168dSg= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2009 12:17:15 -0000 X-YMail-OSG: ZlBHvtMVM1nbvCtvmgOkAjDintQi8Qe9vWlREjdBoaGcdFqOrjR3lYQBIJZpzq9Zzw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A718F4A.90406@rogers.com> Date: Thu, 30 Jul 2009 14:17:14 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "dime@ietf.org" References: <20090730110001.9CCC628C18C@core3.amsl.com> In-Reply-To: <20090730110001.9CCC628C18C@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 30 Jul 2009 12:17:17 -0000 Changes from 00 to 01: - Added Redirect-Realm-Usage based on meeting discussion. - Added associated behaviour. - Added mention that the receiving node will use normal discovery procedures to locate a host in the returned domain. - Deleted mention of Redirect-Host in the receiving node behaviour. Internet-Drafts@ietf.org wrote: > 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. > > From vfajardo@research.telcordia.com Thu Jul 30 05:56:18 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 69AB828C1AA for ; Thu, 30 Jul 2009 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 CUlzfdZ52u+L for ; Thu, 30 Jul 2009 05:56:17 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 89D9A28C1A8 for ; Thu, 30 Jul 2009 05:56:17 -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 n6UCuJbw020691; Thu, 30 Jul 2009 08:56:19 -0400 (EDT) From: "Victor Fajardo" To: "'Tom Taylor'" , References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> In-Reply-To: <4A718F4A.90406@rogers.com> Date: Thu, 30 Jul 2009 08:56:19 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <000001ca1115$21bf21c0$653d6540$@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: AcoRD7AXPNS5kkbtTR+XEwJIaCFtgwABQNqQ Content-Language: en-us 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: Thu, 30 Jul 2009 12:56:18 -0000 Hi Tom, It was not clear to me if we really wanted to add Redirect-Realm-Usage. I don't mind adding it if there are real use cases that needs this. But typically, adding a 'usage' constraint complicates routing decisions and nodes have to keep extra state. So is there any use case that justifies adding realm usage constraints ? -- victor -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Thursday, July 30, 2009 8:17 AM To: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt Changes from 00 to 01: - Added Redirect-Realm-Usage based on meeting discussion. - Added associated behaviour. - Added mention that the receiving node will use normal discovery procedures to locate a host in the returned domain. - Deleted mention of Redirect-Host in the receiving node behaviour. Internet-Drafts@ietf.org wrote: > 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. > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From tom.taylor@rogers.com Thu Jul 30 06:01:13 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 40BD43A686D for ; Thu, 30 Jul 2009 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 D-oyAW4Z664C for ; Thu, 30 Jul 2009 06:01:12 -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 4B93B28C177 for ; Thu, 30 Jul 2009 06:01:12 -0700 (PDT) Received: (qmail 68196 invoked from network); 30 Jul 2009 13:01:11 -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=ksp2jBxh/dAX2MrMRKERpZV+Bk9PRB2Eo8f7h4K7668qsB6LsEpvaboMazTUiJmqBsILy8cNM1IiRRrE0Uvdvh1lE4M1e7rJIcdojoGRd0tlLHzFi5W0sj+63FCv1+rLU/fNO0MelE9GJ5UTgMJUqLkJIAnPUSIPqZnG+Rct3xo= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp120.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2009 13:01:11 -0000 X-YMail-OSG: uEBjR8MVM1l0S8aCkZFX5jrdEbbWBcHh.0KFI3n7N4Wds7B.Qphpjz9fHcnwThXhtg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A719995.3090101@rogers.com> Date: Thu, 30 Jul 2009 15:01:09 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: vfajardo@research.telcordia.com References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <000001ca1115$21bf21c0$653d6540$@telcordia.com> In-Reply-To: <000001ca1115$21bf21c0$653d6540$@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: Thu, 30 Jul 2009 13:01:13 -0000 Wolfgang indicated he had some possible use cases in private conversation. Victor Fajardo wrote: > Hi Tom, > > It was not clear to me if we really wanted to add Redirect-Realm-Usage. I > don't mind adding it if there are real use cases that needs this. But > typically, adding a 'usage' constraint complicates routing decisions and > nodes have to keep extra state. So is there any use case that justifies > adding realm usage constraints ? > > -- victor > > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tom > Taylor > Sent: Thursday, July 30, 2009 8:17 AM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt > > Changes from 00 to 01: > > - Added Redirect-Realm-Usage based on meeting discussion. > - Added associated behaviour. > - Added mention that the receiving node will use normal discovery procedures > to > locate a host in the returned domain. > - Deleted mention of Redirect-Host in the receiving node behaviour. > > Internet-Drafts@ietf.org wrote: >> 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. >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From Hannes.Tschofenig@gmx.net Thu Jul 30 06:07:09 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 86B183A6B62 for ; Thu, 30 Jul 2009 06:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 y6mU0B1WpVzS for ; Thu, 30 Jul 2009 06:07:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 485E63A67C1 for ; Thu, 30 Jul 2009 06:07:07 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2009 13:07:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp038) with SMTP; 30 Jul 2009 15:07:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18zoPwnC8wzZL8o4NinYi5HkKtWu8+iIUHvHr2AeJ icFCnqtNFy9iSO From: "Hannes Tschofenig" To: "'Tom Taylor'" , References: <20090730110001.9CCC628C18C@core3.amsl.com><4A718F4A.90406@rogers.com><000001ca1115$21bf21c0$653d6540$@telcordia.com> <4A719995.3090101@rogers.com> Date: Thu, 30 Jul 2009 16:09:37 +0300 Message-ID: <007801ca1116$fe21c860$0301a8c0@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 Thread-Index: AcoRFdR2J5gEUCnAQS+tmuvJ9KE3vQAAR1WQ In-Reply-To: <4A719995.3090101@rogers.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 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: Thu, 30 Jul 2009 13:07:09 -0000 Maybe Wolfgang can give us some more details about his thoughts then. >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Tom Taylor >Sent: 30 July, 2009 16:01 >To: vfajardo@research.telcordia.com >Cc: dime@ietf.org >Subject: Re: [Dime] I-D >Action:draft-ietf-dime-realm-based-redirect-01.txt > >Wolfgang indicated he had some possible use cases in private >conversation. > >Victor Fajardo wrote: >> Hi Tom, >> >> It was not clear to me if we really wanted to add >> Redirect-Realm-Usage. I don't mind adding it if there are real use >> cases that needs this. But typically, adding a 'usage' constraint >> complicates routing decisions and nodes have to keep extra state. So >> is there any use case that justifies adding realm usage constraints ? >> >> -- victor >> >> >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> Of Tom Taylor >> Sent: Thursday, July 30, 2009 8:17 AM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D >> Action:draft-ietf-dime-realm-based-redirect-01.txt >> >> Changes from 00 to 01: >> >> - Added Redirect-Realm-Usage based on meeting discussion. >> - Added associated behaviour. >> - Added mention that the receiving node will use normal discovery >> procedures to locate a host in the returned domain. >> - Deleted mention of Redirect-Host in the receiving node behaviour. >> >> Internet-Drafts@ietf.org wrote: >>> 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. >>> >>> >> _______________________________________________ >> 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 sdecugis@nict.go.jp Thu Jul 30 06:17:19 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 C1D573A6B8B for ; Thu, 30 Jul 2009 06:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3] 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 UA1vgRbvo7eh for ; Thu, 30 Jul 2009 06:17:19 -0700 (PDT) Received: from sd-1637.dedibox.fr (sd-1637.dedibox.fr [88.191.18.91]) by core3.amsl.com (Postfix) with ESMTP id CD02C3A6A74 for ; Thu, 30 Jul 2009 06:17:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sd-1637.dedibox.fr (Postfix) with ESMTP id 885ACA3C02; Thu, 30 Jul 2009 15:17:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-1637.dedibox.fr Received: from sd-1637.dedibox.fr ([127.0.0.1]) by localhost (sd-1637.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bowlP4wNiuSr; Thu, 30 Jul 2009 15:17:13 +0200 (CEST) Received: from [130.129.23.193] (dhcp-17c1.meeting.ietf.org [130.129.23.193]) by sd-1637.dedibox.fr (Postfix) with ESMTPSA id 3BABFA3BF3; Thu, 30 Jul 2009 15:17:13 +0200 (CEST) Message-ID: <4A719D4B.4000700@nict.go.jp> Date: Thu, 30 Jul 2009 15:16:59 +0200 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tom Taylor References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> In-Reply-To: <4A718F4A.90406@rogers.com> Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 30 Jul 2009 13:17:19 -0000 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 : > Changes from 00 to 01: > > - Added Redirect-Realm-Usage based on meeting discussion. > - Added associated behaviour. > - Added mention that the receiving node will use normal discovery > procedures to locate a host in the returned domain. > - Deleted mention of Redirect-Host in the receiving node behaviour. > > Internet-Drafts@ietf.org wrote: >> 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. >> >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From tom.taylor@rogers.com Thu Jul 30 06:20: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 6DBB13A6802 for ; Thu, 30 Jul 2009 06:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 PWV8tPD9Lz8L for ; Thu, 30 Jul 2009 06:20:49 -0700 (PDT) Received: from smtp115.rog.mail.re2.yahoo.com (smtp115.rog.mail.re2.yahoo.com [68.142.225.231]) by core3.amsl.com (Postfix) with SMTP id 7BA723A6C57 for ; Thu, 30 Jul 2009 06:20:49 -0700 (PDT) Received: (qmail 35529 invoked from network); 30 Jul 2009 13:20:49 -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=w0DmPyon5UbyPP0AH7fI9rHFy9uuVv5T5KiKws5dhQO8f8nZ/QGjbIzKCxjxKz4Mtuz9OWvbrPLPplVsJouDXrwDj1bhwPVyM5naI0FWU6RJ250eXe+1F+vOjtDOvrBg1pDYXrdUcyfPLJ24h4TeFS3j3WuawJhvI5aiQc0YsEo= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp115.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2009 13:20:48 -0000 X-YMail-OSG: hfnK5M8VM1nGLQ0QEcOl3d5qPdjxEy2jz1wx90sAUTzOvXbsJ_GEI6OYZSFzuSbQUg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A719E2F.9010709@rogers.com> Date: Thu, 30 Jul 2009 15:20:47 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Sebastien Decugis References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> In-Reply-To: <4A719D4B.4000700@nict.go.jp> 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: Thu, 30 Jul 2009 13:20:50 -0000 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 : ... From sdecugis@nict.go.jp Thu Jul 30 06:24:47 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 519083A6818 for ; Thu, 30 Jul 2009 06:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 OJS0ddMWcwTq for ; Thu, 30 Jul 2009 06:24:46 -0700 (PDT) Received: from sd-1637.dedibox.fr (sd-1637.dedibox.fr [88.191.18.91]) by core3.amsl.com (Postfix) with ESMTP id 9553C3A6802 for ; Thu, 30 Jul 2009 06:24:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sd-1637.dedibox.fr (Postfix) with ESMTP id 30378A3C02; Thu, 30 Jul 2009 15:24:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at sd-1637.dedibox.fr Received: from sd-1637.dedibox.fr ([127.0.0.1]) by localhost (sd-1637.dedibox.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9dF8hFuTFf1; Thu, 30 Jul 2009 15:24:45 +0200 (CEST) Received: from [130.129.23.193] (dhcp-17c1.meeting.ietf.org [130.129.23.193]) by sd-1637.dedibox.fr (Postfix) with ESMTPSA id ADF02A3BF3; Thu, 30 Jul 2009 15:24:45 +0200 (CEST) Message-ID: <4A719F10.6090701@nict.go.jp> Date: Thu, 30 Jul 2009 15:24:32 +0200 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Tom Taylor References: <20090730110001.9CCC628C18C@core3.amsl.com> <4A718F4A.90406@rogers.com> <4A719D4B.4000700@nict.go.jp> <4A719E2F.9010709@rogers.com> In-Reply-To: <4A719E2F.9010709@rogers.com> Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 30 Jul 2009 13:24:47 -0000 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 : > ... > From vfajardo@research.telcordia.com Thu Jul 30 12:25: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 CE1F43A71EA for ; Thu, 30 Jul 2009 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-0.669, 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 aJXSMZWn+NUX for ; Thu, 30 Jul 2009 12:25:02 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id 180C13A71D1 for ; Thu, 30 Jul 2009 12:25:02 -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 n6UJP3nX003506 for ; Thu, 30 Jul 2009 15:25:03 -0400 (EDT) From: "Victor Fajardo" To: Date: Thu, 30 Jul 2009 15:25:02 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <000801ca114b$6fef65e0$4fce31a0$@telcordia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CA1129.E8DDC5E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoRS2+4mrPeNVMtQ6yHILxXqrX8pw== Content-Language: en-us Subject: [Dime] DIME Meeting Minutes - IETF#75 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: Thu, 30 Jul 2009 19:25:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01CA1129.E8DDC5E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit .. has been uploaded. http://www.ietf.org/proceedings/75/minutes/dime.txt thanks, victor ------=_NextPart_000_0009_01CA1129.E8DDC5E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

.. has been uploaded.

 

http://www.i= etf.org/proceedings/75/minutes/dime.txt

 

thanks,

victor

------=_NextPart_000_0009_01CA1129.E8DDC5E0-- From Mark.Jones@bridgewatersystems.com Fri Jul 31 01:39: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 E11113A6D31 for ; Fri, 31 Jul 2009 01:39:34 -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 Wc2nklvSZOpL for ; Fri, 31 Jul 2009 01:39:34 -0700 (PDT) Received: from cernan.electric.net (cernan.electric.net [72.35.23.19]) by core3.amsl.com (Postfix) with ESMTP id 88C2928C238 for ; Fri, 31 Jul 2009 01:38:47 -0700 (PDT) Received: from 1MWndY-000652-Uu by cernan.electric.net with emc1-ok (Exim 4.69) (envelope-from ) id 1MWndY-00065C-VT for dime@ietf.org; Fri, 31 Jul 2009 01:38:48 -0700 Received: by emcmailer; Fri, 31 Jul 2009 01:38:48 -0700 Received: from [72.35.6.119] (helo=mail.bridgewatersystems.com) by cernan.electric.net with esmtps (TLSv1:RC4-MD5:128) (Exim 4.69) (envelope-from ) id 1MWndY-000652-Uu for dime@ietf.org; Fri, 31 Jul 2009 01:38:48 -0700 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Fri, 31 Jul 2009 04:38:48 -0400 From: Mark Jones To: "dime@ietf.org" Date: Fri, 31 Jul 2009 04:38:48 -0400 Thread-Topic: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-01.txt Thread-Index: AcoRGSINzFk2PGiZQgCoxoKcTJBf/AAmcIoo Message-ID: <4E0F60BAF2FA7C46BBB5474DF8A89BCD2DD476072E@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> In-Reply-To: <4A719F10.6090701@nict.go.jp> 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) 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: Fri, 31 Jul 2009 08:39:35 -0000 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 =3D Redirect-Realm-Usage =3D ALL_REALM The other question I had on this draft was how one advertises support for t= he 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 functiona= ltiy) is advertised in Diameter is through the use of application ids in CE= R/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 =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 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 =E9crit : > ... > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime= From vfajardo@research.telcordia.com Fri Jul 31 05:33: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 D086A3A6E2E for ; Fri, 31 Jul 2009 05:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.706, 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 CtI2ds+4YpYV for ; Fri, 31 Jul 2009 05:33:26 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id CE0EC3A6E27 for ; Fri, 31 Jul 2009 05:33: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 n6VCXFbW000494; Fri, 31 Jul 2009 08:33:21 -0400 (EDT) From: "Victor Fajardo" 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> Date: Fri, 31 Jul 2009 08:33:15 -0400 Organization: Applied Research, Telcordia Technologies Message-ID: <001b01ca11db$16e4bdc0$44ae3940$@telcordia.com> 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: AcoRGSINzFk2PGiZQgCoxoKcTJBf/AAmcIooAAnhMbA= Content-Language: en-us 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: Fri, 31 Jul 2009 12:33:26 -0000 Hi Mark, ALL_REALM usage is reasonable. However, is there any other possible = values for 'usage' beyond all realm ? I'm trying to see if we can simplify = things and maybe not have a 'usage' value if we don't need to. Of course, I = don't mind having a 'usage' value if we really need it. Regarding advertisement of this functionality, I agree the draft should clarify this.=20 Regards, Victor -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = Mark Jones Sent: Friday, July 31, 2009 4:39 AM To: dime@ietf.org Subject: Re: [Dime] I-D = Action:draft-ietf-dime-realm-based-redirect-01.txt 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 =3D Redirect-Realm-Usage =3D 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 =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 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 =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