From dime-bounces@ietf.org Wed Jul 2 09:00:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81FC3A6C91; Wed, 2 Jul 2008 09:00:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C1C3A6C9C for ; Wed, 2 Jul 2008 09:00:56 -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 0IKlXeaZ49sD for ; Wed, 2 Jul 2008 09:00:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3ED213A6C97 for ; Wed, 2 Jul 2008 09:00:54 -0700 (PDT) Received: (qmail invoked by alias); 02 Jul 2008 16:01:02 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp003) with SMTP; 02 Jul 2008 18:01:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX198AQVHtTl8FTHyOuP7ryvUcQYfNlBPpXmVxo0vrM u+L8DuT6Tv0J/+ Message-ID: <486BA636.10706@gmx.net> Date: Wed, 02 Jul 2008 19:00:54 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: [Dime] [Fwd: Posting of IPR Disclosure] regarding draft-ietf-dime-mip6-split X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org FYI, https://datatracker.ietf.org/ipr/964/ Ciao Hannes -------- Original Message -------- Subject: Posting of IPR Disclosure Date: Wed, 2 Jul 2008 08:54:50 -0700 (PDT) From: IETF Secretariat To: Hannes.Tschofenig@gmx.net,jouni.korhonen@teliasonera.com,julien.bournelle@orange-ftgroup.com,gerardo.giaretta@gmail.com,madjid.nakhjiri@motorola.com CC: dromasca@avaya.com,rbonica@juniper.net,dave@frascone.com,Hannes.Tschofenig@gmx.net Dear Hannes Tschofenig, Jouni Korhonen, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri: An IPR disclosure that pertains to your Internet-Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split) was submitted to the IETF Secretariat on 2008-06-23 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Nortel Networks Statement about IPR claimed in draft-ietf-dime-mip6-split." The IETF Secretariat _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 4 11:54:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4033A6918; Fri, 4 Jul 2008 11:54:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B653A6918 for ; Fri, 4 Jul 2008 11:54: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=[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 Jyz9DqaWllmH for ; Fri, 4 Jul 2008 11:54:53 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D947A3A68AB for ; Fri, 4 Jul 2008 11:54:52 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 18:54:59 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp009) with SMTP; 04 Jul 2008 20:54:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19LkFZx/vdLJHLgFkvfD4kH6WDqAYoPIxsyn2Nr6q OVvUQTfftkkOgF Message-ID: <486E71FB.3050300@gmx.net> Date: Fri, 04 Jul 2008 21:54:51 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Subject: [Dime] draft-korhonen-dime-nai-routing-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I am a bit surprised about this document given the discussions we had in the context of http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03. My impression was that we need to provide the text relevant to this aspect within RFC 3588bis. In fact, I naively thought that this has already been done... Without going into the details of the NAI decoration itself, which is discussed already in RFC 4282 and RFC 5113, the real content is quite short. The backwards compatibility considerations make me a bit nervous Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 4 14:30:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41D73A6BCF; Fri, 4 Jul 2008 14:30:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC583A6BCF for ; Fri, 4 Jul 2008 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 sLzZU080O1kv for ; Fri, 4 Jul 2008 14:30:32 -0700 (PDT) Received: from sehan002bb.han.telia.se (sehan002bb.han.telia.se [131.115.18.153]) by core3.amsl.com (Postfix) with ESMTP id 177B23A6BCE for ; Fri, 4 Jul 2008 14:30:31 -0700 (PDT) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jul 2008 23:30:37 +0200 Received: from 131.115.14.48 ([131.115.14.48]) by SEHAN021MB.tcad.telia.se ([131.115.18.162]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Jul 2008 21:30:36 +0000 From: "Korhonen, Jouni /TeliaSonera Finland Oyj" To: "Hannes Tschofenig" , thread-topic: [Dime] draft-korhonen-dime-nai-routing-00.txt thread-index: AcjeHTKCKUrl4HsvRJix2LpKPm+9kQ== X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 5 Jul 2008 00:30:28 +0300 Message-ID: <2e6601c8de1d$3282dbca$300e7383@tcad.telia.se> X-Mailer: EAS Version 1.00 MIME-Version: 1.0 Content-Language: i-default X-OriginalArrivalTime: 04 Jul 2008 21:30:37.0686 (UTC) FILETIME=[3357A960:01C8DE1D] Subject: Re: [Dime] draft-korhonen-dime-nai-routing-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGkgSGFubmVzLAoKT3VyIGltcHJlc3Npb24gYWZ0ZXIgcHJldmlvdXMgZGlzY3Vzc2lvbiB3YXMg cmF0aGVyIGNsZWFyIHRoYXQgcm91dGluZyBpc3N1ZXMgd291bGQgbm90IGJlIHBhcnQgb2YgcmZj MzU4OGJpcyBhbmQgc3BsaXR0aW5nIHRoZSBjb25jZXB0cyBvZiBkcmFmdC10c291IGludG8gc21h bGxlciBpc3N1ZXMgd2FzIGVuY291cmFnZWQuIEF0IGxlYXN0IGkgd2FzIHRvbGQgc28uIEkgd291 bGQgYmUgaGFwcHksIGlmIHdlIGNvdWxkIGhhdmUgdGhlIGNvbnRlbnQgZGVzY3JpYmVkIGluIHRo aXMgZHJhZnQgYXMgYSBwYXJ0IG9mIHRoZSByZmMzNTg4YmlzLgoKQmFja3dhcmRzIGNvbXBhdGli aWxpdHkgaXNzdWVzIGFyZSBpbWhvIGNsZWFyLi4gV2l0aCBleGlzdGluZyBhcHBzIGFuZCByZmMz NTg4IHlvdSBqdXN0IGRvbid0IGhhdmUgcXVhcmFudGVlcy4gU28geW91IGJldHRlciBvbmx5IGFw cGx5IGVuaGFuY2VkIHJvdXRpbmcgdG8gbmV3bHkgZGVmaW5lZCBhcHBsaWNhdGlvbnMgdGhhdCBj YW4gYmUgZXhwbGljaXQgb24gdGhlIHJvdXRpbmcgYmVoYXZpb3IuCgpBbmQgd2hhdCBpcyB3cm9u ZyB3aXRoIHNob3J0IGRyYWZ0cz8gSGVyZSB3ZSBqdXN0IGhhdmUgb25lIGlzc3VlIHRoYXQgd2Ug d2FudCB0byBiZSBleHBsaWNpdCBhYm91dC4KCkNoZWVycywKICAgICAgICAgSm91bmkKCgotLS0g YWxrdXBlcsOkaW5lbiB2aWVzdGkgLS0tCkzDpGhldHTDpGrDpDogIkhhbm5lcyBUc2Nob2Zlbmln IiA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD4KQWloZTogW0RpbWVdIGRyYWZ0LWtvcmhvbmVu LWRpbWUtbmFpLXJvdXRpbmctMDAudHh0ClDDpGl2w6Rtw6TDpHLDpDogNC4gaGVpbsOka3V1dGEg MjAwOApBaWthOiAyMTo1NToxNgoKCkkgYW0gYSBiaXQgc3VycHJpc2VkIGFib3V0IHRoaXMgZG9j dW1lbnQgZ2l2ZW4gdGhlIGRpc2N1c3Npb25zIHdlIGhhZCBpbiAKdGhlIGNvbnRleHQgb2YgCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzb3UtZGltZS1iYXNlLXJvdXRpbmctZXh0 LTAzLiBNeSAKaW1wcmVzc2lvbiB3YXMgdGhhdCB3ZSBuZWVkIHRvIHByb3ZpZGUgdGhlIHRleHQg cmVsZXZhbnQgdG8gdGhpcyBhc3BlY3QgCndpdGhpbiBSRkMgMzU4OGJpcy4gSW4gZmFjdCwgSSBu YWl2ZWx5IHRob3VnaHQgdGhhdCB0aGlzIGhhcyBhbHJlYWR5IApiZWVuIGRvbmUuLi4KCldpdGhv dXQgZ29pbmcgaW50byB0aGUgZGV0YWlscyBvZiB0aGUgTkFJIGRlY29yYXRpb24gaXRzZWxmLCB3 aGljaCBpcyAKZGlzY3Vzc2VkIGFscmVhZHkgaW4gUkZDIDQyODIgYW5kIFJGQyA1MTEzLCB0aGUg cmVhbCBjb250ZW50IGlzIHF1aXRlIApzaG9ydC4KClRoZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0 eSBjb25zaWRlcmF0aW9ucyBtYWtlIG1lIGEgYml0IG5lcnZvdXMKCkNpYW8KSGFubmVzCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpEaU1FIG1haWxpbmcg bGlzdApEaU1FQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpEaU1F IG1haWxpbmcgbGlzdApEaU1FQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Fri Jul 4 15:21:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215F63A6847; Fri, 4 Jul 2008 15:21:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFC63A6847 for ; Fri, 4 Jul 2008 15:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_24=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 2M3iLcH0wkBv for ; Fri, 4 Jul 2008 15:21:23 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D5A3F3A67D9 for ; Fri, 4 Jul 2008 15:21:22 -0700 (PDT) Received: (qmail invoked by alias); 04 Jul 2008 22:21:29 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp015) with SMTP; 05 Jul 2008 00:21:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Hhd0sHBjH6ci6ovUrDBZlzYVFK5P1jS5zLcMLlz QaB1EFyC7R5rXP Message-ID: <486EA262.4000901@gmx.net> Date: Sat, 05 Jul 2008 01:21:22 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Korhonen, Jouni /TeliaSonera Finland Oyj" References: <2e6601c8de1d$3282dbca$300e7383@tcad.telia.se> In-Reply-To: <2e6601c8de1d$3282dbca$300e7383@tcad.telia.se> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: dime@ietf.org Subject: Re: [Dime] draft-korhonen-dime-nai-routing-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SGkgSm91bmksCgpLb3Job25lbiwgSm91bmkgL1RlbGlhU29uZXJhIEZpbmxhbmQgT3lqIHdyb3Rl Ogo+IEhpIEhhbm5lcywKPgo+IE91ciBpbXByZXNzaW9uIGFmdGVyIHByZXZpb3VzIGRpc2N1c3Np b24gd2FzIHJhdGhlciBjbGVhciB0aGF0IHJvdXRpbmcgaXNzdWVzIHdvdWxkIG5vdCBiZSBwYXJ0 IG9mIHJmYzM1ODhiaXMgYW5kIHNwbGl0dGluZyB0aGUgY29uY2VwdHMgb2YgZHJhZnQtdHNvdSBp bnRvIHNtYWxsZXIgaXNzdWVzIHdhcyBlbmNvdXJhZ2VkLiBBdCBsZWFzdCBpIHdhcyB0b2xkIHNv LiBJIHdvdWxkIGJlIGhhcHB5LCBpZiB3ZSBjb3VsZCBoYXZlIHRoZSBjb250ZW50IGRlc2NyaWJl ZCBpbiB0aGlzIGRyYWZ0IGFzIGEgcGFydCBvZiB0aGUgcmZjMzU4OGJpcy4KPiAgIApJbnRlcmVz dGluZy4gSSB0aG91Z2h0IHRoYXQgdGhlIGNvbnRlbnQgb2YgInJvdXRlIHBpbm5pbmciIHdvdWxk IGJlIApzZXBhcmF0ZWQgZnJvbSB0aGUgcmVtYWluaW5nIGRlc2NyaXB0aW9uLgoKCj4gQmFja3dh cmRzIGNvbXBhdGliaWxpdHkgaXNzdWVzIGFyZSBpbWhvIGNsZWFyLi4gV2l0aCBleGlzdGluZyBh cHBzIGFuZCByZmMzNTg4IHlvdSBqdXN0IGRvbid0IGhhdmUgcXVhcmFudGVlcy4gU28geW91IGJl dHRlciBvbmx5IGFwcGx5IGVuaGFuY2VkIHJvdXRpbmcgdG8gbmV3bHkgZGVmaW5lZCBhcHBsaWNh dGlvbnMgdGhhdCBjYW4gYmUgZXhwbGljaXQgb24gdGhlIHJvdXRpbmcgYmVoYXZpb3IuCj4gICAK SGF2aW5nIHRoaXMgdG8gd29yayBvbmx5IGZvciBuZXcgYXBwbGljYXRpb25zIHNvdW5kcyBPSyBh bHRob3VnaCBpdCAKcmFpc2VzIHRoZSBxdWVzdGlvbiBvbiB3aGF0IHRvZG8gd2l0aCBEaWFtZXRl ciBFQVAsIGZvciBleGFtcGxlLiBXb3VsZCAKeW91IGV4cGVjdCBEaWFtZXRlciBhcHBsaWNhdGlv biBkZXNpZ25lcnMgdG8gZ28gZm9yIHRoZSBuZXcgcm91dGluZyAKc3R5bGUgZm9yIGV2ZXJ5IG5l dyBEaWFtZXRlciBhcHBsaWNhdGlvbnMgb3Igb25seSBzZWxlY3RpdmVseSAob3IgZXZlbiAKdG8g ZGVmaW5lIHR3byBhcHBsaWNhdGlvbiBJRHMgLS0gb25lIGZvbGxvd2luZyB0aGUgb2xkIHN0eWxl IGFuZCBhbm90aGVyIApvbmUgZm9yIHRoZSBuZXcgc3R5bGUpLiBDb25zaWRlciwgZm9yIGV4YW1w bGUsIHRoZSBjdXJyZW50IERpYW1ldGVyIApNSVB2NiBIQTwtPkFBQVMgd29yay4KCj4gQW5kIHdo YXQgaXMgd3Jvbmcgd2l0aCBzaG9ydCBkcmFmdHM/IEhlcmUgd2UganVzdCBoYXZlIG9uZSBpc3N1 ZSB0aGF0IHdlIHdhbnQgdG8gYmUgZXhwbGljaXQgYWJvdXQuCj4gICAKTm90aGluZyB3cm9uZyB3 aXRoIHNob3J0IGRyYWZ0cy4gSSB3YXMganVzdCB3b25kZXJpbmcgd2hldGhlciB5b3UgaGF2ZSAK dGhvdWdodCB0aGF0IHRoZSBkaXNjdXNzaW9uIHdvdWxkIGJlIHRvbyBsb25nIGZvciB0aGUgUkZD IDM1ODhiaXMgCmRvY3VtZW50IGFuZCB0aGVyZWZvcmUgaXQgd2FzIHB1dCBpbnRvIGEgc2VwYXJh dGUgZHJhZnQuCgpDaWFvCkhhbm5lcwo+IENoZWVycywKPiAgICAgICAgICBKb3VuaQo+Cj4KPiAt LS0gYWxrdXBlcsOkaW5lbiB2aWVzdGkgLS0tCj4gTMOkaGV0dMOkasOkOiAiSGFubmVzIFRzY2hv ZmVuaWciIDxIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Pgo+IEFpaGU6IFtEaW1lXSBkcmFmdC1r b3Job25lbi1kaW1lLW5haS1yb3V0aW5nLTAwLnR4dAo+IFDDpGl2w6Rtw6TDpHLDpDogNC4gaGVp bsOka3V1dGEgMjAwOAo+IEFpa2E6IDIxOjU1OjE2Cj4KPgo+IEkgYW0gYSBiaXQgc3VycHJpc2Vk IGFib3V0IHRoaXMgZG9jdW1lbnQgZ2l2ZW4gdGhlIGRpc2N1c3Npb25zIHdlIGhhZCBpbiAKPiB0 aGUgY29udGV4dCBvZiAKPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c291LWRp bWUtYmFzZS1yb3V0aW5nLWV4dC0wMy4gTXkgCj4gaW1wcmVzc2lvbiB3YXMgdGhhdCB3ZSBuZWVk IHRvIHByb3ZpZGUgdGhlIHRleHQgcmVsZXZhbnQgdG8gdGhpcyBhc3BlY3QgCj4gd2l0aGluIFJG QyAzNTg4YmlzLiBJbiBmYWN0LCBJIG5haXZlbHkgdGhvdWdodCB0aGF0IHRoaXMgaGFzIGFscmVh ZHkgCj4gYmVlbiBkb25lLi4uCj4KPiBXaXRob3V0IGdvaW5nIGludG8gdGhlIGRldGFpbHMgb2Yg dGhlIE5BSSBkZWNvcmF0aW9uIGl0c2VsZiwgd2hpY2ggaXMgCj4gZGlzY3Vzc2VkIGFscmVhZHkg aW4gUkZDIDQyODIgYW5kIFJGQyA1MTEzLCB0aGUgcmVhbCBjb250ZW50IGlzIHF1aXRlIAo+IHNo b3J0Lgo+Cj4gVGhlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGNvbnNpZGVyYXRpb25zIG1ha2Ug bWUgYSBiaXQgbmVydm91cwo+Cj4gQ2lhbwo+IEhhbm5lcwo+Cj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBEaU1FIG1haWxpbmcgbGlzdAo+IERpTUVA aWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUKPiAg IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRGlNRSBt YWlsaW5nIGxpc3QKRGlNRUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RpbWUK From dime-bounces@ietf.org Sat Jul 5 02:20:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4040A3A6893; Sat, 5 Jul 2008 02:20:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52DA03A6810 for ; Sat, 5 Jul 2008 02:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkVWgHifIgUh for ; Sat, 5 Jul 2008 02:20:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2719F3A6893 for ; Sat, 5 Jul 2008 02:20:23 -0700 (PDT) Received: (qmail invoked by alias); 05 Jul 2008 09:20:22 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp025) with SMTP; 05 Jul 2008 11:20:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VAq52LVPVQnuzFVT1QIPGjkpo4pEU/QUAjA1bjN HvFAe/bufDZf4f Message-ID: <486F3CCD.8040600@gmx.net> Date: Sat, 05 Jul 2008 12:20:13 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Subject: [Dime] Diameter Extensibility Design Team: Status Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, in February this year we created a design team to re-visit the Diameter extensibility rules. After some discussions and many phone conferences it seems that we have reached a tentative conclusion among a fair number of the design team members. I have tried to capture the conclusion on the DIME WG Wiki, see http://www3.tools.ietf.org/wg/dime/trac/wiki/DiameterExtensibility I would like to share the tentative result already now with the working group so that we can discuss it on the list and publish a more readable strawman proposal within the RFC 3588bis and the Diameter Design Guidelines documents in time for the draft submission deadlines. Your comments to these extensibility rules are important. Please take a look at them. This topic will be on our agenda for the next DIME face-to-face meeting. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Jul 5 22:15:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56CD3A68A6; Sat, 5 Jul 2008 22:15:02 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1D4B63A68A6; Sat, 5 Jul 2008 22: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: <20080706051502.1D4B63A68A6@core3.amsl.com> Date: Sat, 5 Jul 2008 22:15:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-10.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-10.txt Pages : 38 Date : 2008-07-05 Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider (MSP). This document specifies the interaction between a Mobile IP Home Agent and that Diameter server. Several different mechanisms for authenticating a Mobile Node are supported. The usage of the Internet Key Exchange v2 (IKEv2) protocol allows different mechanisms, such as the Extensible Authentication Protocol (EAP), certificates and pre-shared secrets to be used. Furthermore, another method makes use of the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-05221154.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Sun Jul 6 00:36:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBEDD3A68C9; Sun, 6 Jul 2008 00:36:33 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC543A68C9 for ; Sun, 6 Jul 2008 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.975, 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 KsQH476fur4F for ; Sun, 6 Jul 2008 00:36:32 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E8CF93A68B5 for ; Sun, 6 Jul 2008 00:36:31 -0700 (PDT) Received: (qmail invoked by alias); 06 Jul 2008 07:36:32 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp011) with SMTP; 06 Jul 2008 09:36:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18v42N935UvE2n2H8RTweT43Mzs4vmBMXyJE0QmV6 Yg61/q7VwOPegc Message-ID: <487075F8.8070006@gmx.net> Date: Sun, 06 Jul 2008 10:36:24 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Subject: [Dime] Diameter MIPv6 Split Document: Feedback needed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, we have recently received an IPR disclosure for http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt See http://www.ietf.org/mail-archive/web/dime/current/msg02573.html So, now we have two options: a) Ignore the IPR disclosure and go forward with the publication procedure b) Think about the document a bit and potentiallly change some parts. I thought a little bit about the document and the concepts of most parts of the document dates back already many, many years and is not really suprising in any way when you have read the related documents (such as Diameter Mobile IPv4, Diameter EAP, or MIPv6 bootstrapping). In the process of working on the document there was, however, one part that surprised me, namely the excitement for getting some of the MIP6-Feature-Vectors flags put into the document even though they do not really constitute a core part of the protocol. I would therefore suggest to move these flags/codes into a separate document. Thoughts? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 04:42:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749A53A683E; Tue, 8 Jul 2008 04:42:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCD93A683E for ; Tue, 8 Jul 2008 04:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-1.140, 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 0auxj8gFW+3w for ; Tue, 8 Jul 2008 04:42:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0EE363A6810 for ; Tue, 8 Jul 2008 04:42:44 -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 m68BgoX9013252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 13:42:50 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68BgmT2012354; Tue, 8 Jul 2008 13:42:50 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 13:42:36 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 13:42:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 14:42:33 +0300 Message-ID: In-Reply-To: <487075F8.8070006@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter MIPv6 Split Document: Feedback needed Thread-Index: AcjfOwqXhXU9o9hzTDemag+MZF9W+gBs7D/A References: <487075F8.8070006@gmx.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hannes Tschofenig" , X-OriginalArrivalTime: 08 Jul 2008 11:42:34.0677 (UTC) FILETIME=[B6AEBE50:01C8E0EF] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.006 X-TM-AS-Result: No--20.250700-8.000000-31 Subject: Re: [Dime] Diameter MIPv6 Split Document: Feedback needed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I was asked what specific content would actually be separated from the current document. So, here is my guess: The following text from Section 6.15: RO_SUPPORTED (0x0000000200000000) Route optimization is supported. When the HA sets this bit, it indicates support for the route optimization. If this bit is unset in the returned Mobility-Capability AVP, the AAAH does not authorize route optimization for the MN. In a case the HA or the AAAH cannot authorize the use of route optimization then the HA SHOULD send a Binding Acknowledgement with a Status Code set to ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This Status Code indicates that the binding registration succeeded but the HA will fail all possible subsequent route optimization attempts because of subscription or operator policy. USER_TRAFFIC_ENCRYPTION (0x0000000400000000) User plane traffic encryption is supported. When the HA sets this bit, it indicates support for the user plane traffic encryption between the MN and the HA. If this bit is unset in the returned Mobility-Capability AVP, the AAAH does not authorize user plane traffic encryption because of subscription or operator policy. In the case the AAAH cannot authorize the use of user plane traffic encryption then the HA SHOULD send a Binding Acknowledgement with a Status Code set to ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION (status code TBD). This Status Code indicates that the binding registration succeeded but the HA will silently discard all encrypted user plane packets sent by the MN to the HA. VPN_GW_MODE (0x0000000800000000) The HA is supposed to act as a IPSec VPN gateway for the user. When the HA sets this bit, it indicates support for acting as a standalone IPSec VPN gateway. If this bit is unset in the returned Mobility-Capability AVP, the AAAH does not authorize the HA to act as a standalone IPSec VPN gateway for the MN because of subscription or operator policy. MCOA_SUPPORTED (0x0000001000000000) Multiple Care-of Addresses (MCoA) [21] are supported. When the HA sets this bit, it indicates support for the MCoA. If this bit is unset in the returned Mobility-Capability AVP, the AAAH does not authorize the use of MCoA for the MN. In a case the HA or the AAAH cannot authorize the use of the MCoA then the HA SHOULD send a Binding Acknowledgement with a Status Code set to ACCEPTED_BUT_NO_MCOA (status code TBD). This Status Code indicates that the binding registration succeeded but the HA will fail all possible subsequent attempts to use MCoA because of subscription or operator policy. >From Section 9.5: Token | Value | Description ---------------------------------+----------------------+------------ RO_SUPPORTED | 0x0000000200000000 | RFC TBD USER_TRAFFIC_ENCRYPTION | 0x0000000400000000 | RFC TBD VPN_GW_MODE | 0x0000000800000000 | RFC TBD MCOA_SUPPORTED | 0x0000001000000000 | RFC TBD And Section 9.6 This specification defines new Mobile IPv6 [1] Status Code values. The Status Code must be allocated from the range 0-127: Status Code | Value | Description ----------------------------------------+---------------+------------ ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION | is set to TBD | RFC TBD ACCEPTED_BUT_NO_TRAFFIC_ENCRYPTION | is set to TBD | RFC TBD ACCEPTED_BUT_NO_MCOA | is set to TBD | RFC TBD Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of ext Hannes Tschofenig >Sent: 06 July, 2008 10:36 >To: dime@ietf.org >Subject: [Dime] Diameter MIPv6 Split Document: Feedback needed > >Hi all, > >we have recently received an IPR disclosure for >http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt >See http://www.ietf.org/mail-archive/web/dime/current/msg02573.html > >So, now we have two options: > >a) Ignore the IPR disclosure and go forward with the >publication procedure >b) Think about the document a bit and potentiallly change some parts. > >I thought a little bit about the document and the concepts of >most parts of the document dates back already many, many years >and is not really suprising in any way when you have read the >related documents (such as Diameter Mobile IPv4, Diameter EAP, >or MIPv6 bootstrapping). > >In the process of working on the document there was, however, >one part that surprised me, namely the excitement for getting >some of the MIP6-Feature-Vectors flags put into the document >even though they do not really constitute a core part of the protocol. > >I would therefore suggest to move these flags/codes into a >separate document. > >Thoughts? > >Ciao >Hannes > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 06:34:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A313A68FA; Tue, 8 Jul 2008 06:34:46 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5433A68FA for ; Tue, 8 Jul 2008 06:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-1.100, 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 f3jXojJ3T32L for ; Tue, 8 Jul 2008 06:34:44 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id AF1C53A67F9 for ; Tue, 8 Jul 2008 06:34:41 -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 m68DYmbc025751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 15:34:49 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68DYmwg026862 for ; Tue, 8 Jul 2008 15:34:48 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 15:34:48 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 15:34:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 16:34:47 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Status: July 2008 Thread-Index: Acjg/2Ot0nnt5FTURim3YhD2ukYtPQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Jul 2008 13:34:48.0323 (UTC) FILETIME=[643F9530:01C8E0FF] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.006 X-TM-AS-Result: No--10.542000-8.000000-31 Subject: [Dime] DIME Status: July 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, Here is a short status update for DIME: * RFC3588bis The design team was able to produce some recommendations, which are summarized here: http://www.ietf.org/mail-archive/web/dime/current/msg02577.html For the final submission deadline Victor is going to update the draft. The plan is to start WGLC right before or shortly after the meeting. * Diameter Application Design Guidelines This document will be updated based on the knowledge we gained during the work in the design team. I believe that this document needs a few more cycles to get completed since we need to get as much feedback from other standardization folks as possible to ensure it is really a helpful document. * Diameter API Dan has provided IESG comments to Dave and he has to submit a new draft before the publication process can continue. The document is, however, quite far in the publication status. * draft-ietf-dime-mip6-integrated Dave has requested publication of this document. The first mail got lost somehow for some unreaons but now the status is official in the tracker. After the publication was requested Jouni noticed a few minor issues and those will be addressed as part of the larger set of IESG comments. * draft-ietf-dime-qos-parameters Dave has requested publication for this one as well. The document was thrown over the wall to the IESG. * draft-ietf-dime-qos-attributes This document experienced quite some changes after the 1st WGLC based on the feedback we got. With the change of the way how data traffic is being classified I would strongely request folks to read through it so that we can issue a 2nd WGLC and finish it. * draft-ietf-dime-mip6-split This document is also getting to an end. Jouni submitted -10 just recently and we are essentially ready for a 2nd WGLC (a short one). Unfortunately, we ran into this IPR issue and I am soliciting feedback on the approach we should take with respect to the document: http://www.ietf.org/mail-archive/web/dime/current/msg02579.html * draft-ietf-dime-diameter-qos This document finished WGLC without further comments. Here was the announcement: http://www.ietf.org/mail-archive/web/dime/current/msg02462.html I will re-read the document before Dave sents it to the IESG. * draft-sun-dime-itu-t-rw-00.txt Dan has done an AD review of the document, see http://www.ietf.org/mail-archive/web/dime/current/msg02562.html. An updated document is needed. After the submission deadline is over it would therefore be IMPORTANT to read the following documents: - RFC 3588bis - Diameter QoS attributes - Diameter MIPv6 split scenario document Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 06:59:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C64128C16A; Tue, 8 Jul 2008 06:59:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D28528C16A for ; Tue, 8 Jul 2008 06:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.962, 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 kXqyDPzeMQHm for ; Tue, 8 Jul 2008 06:59:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 6BC2C28C0DF for ; Tue, 8 Jul 2008 06:59:07 -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 m68DxDMn010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 15:59:13 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68Dx9Jr000950; Tue, 8 Jul 2008 15:59:13 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 15:59:11 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 15:59:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 16:59:10 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Dime] draft-asveren-dime-cong-02 Thread-Index: AcjhAsufr2Xv5rScS3qI/DyuJwbt+A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "TANG Alan" X-OriginalArrivalTime: 08 Jul 2008 13:59:11.0086 (UTC) FILETIME=[CC1F80E0:01C8E102] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.007 X-TM-AS-Result: No--16.431000-8.000000-31 Cc: dime@ietf.org Subject: Re: [Dime] draft-asveren-dime-cong-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Alan, that's very interesting feedback. Did you had a chance to talk to Tolga about this. Maybe it is worth for both of you to also take a look at a recently submitted RADEXT draft: http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.t xt Ciao Hannes TANG Alan wrote: Hi, Diameter Gurus: I see that the following draft has expired. http://tools.ietf.org/html/draft-asveren-dime-cong-02 It was said that this draft work has been suspended. As overload control mechanism is very essential for the commercialization of the Diameter products, would it be possible to have this draft work re-started and re-prioritized? Thanks in advance! Regards, Alan Tang Alcatel-Lucent Tel: +86 532 8861 5363 Fax: +86 532 8861 9276 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 07:06:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B26E3A6867; Tue, 8 Jul 2008 07:06:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3828E3A6867 for ; Tue, 8 Jul 2008 07:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.455 X-Spam-Level: X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[AWL=1.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZfNW0joVA7O for ; Tue, 8 Jul 2008 07:06:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2C5E83A6810 for ; Tue, 8 Jul 2008 07:06:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m68E6TKV009535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 16:06:29 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68E6Tvm011309 for ; Tue, 8 Jul 2008 16:06:29 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:06:27 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:06:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 17:06:25 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF#72 DIME Agenda Thread-Index: AcjhA87YCIosAt4sRzOeg2vyYQvg0w== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Jul 2008 14:06:26.0254 (UTC) FILETIME=[CF80DEE0:01C8E103] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.007 X-TM-AS-Result: No--2.624000-8.000000-31 Subject: [Dime] IETF#72 DIME Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The agenda for this meeting is roughly split into two parts: * Open issues with current charter items. We are not going to use our face-to-face time to tell you what changes a draft has seen in the last few months! We hope that we do not have many open issues to discuss with the current charter items; but we never know. ***To the draft authors***: Please post a mail to the list after the submission deadline regarding the open issues. * Recharter Discussion See my other mail about rechartering. The idea would be to discuss the documents on the mailing list briefly and, >>>>if there is interest from the group<<<<<, then present them at the meeting. I got a request for the presentation of a -00 draft, namely http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-00.txt The document is, however, somewhat related to the following document: http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 Hence, it is also related to the rechartering discussion. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 07:08:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3133A6867; Tue, 8 Jul 2008 07:08:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6EB3A689A for ; Tue, 8 Jul 2008 07:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ7q-IX3XB4M for ; Tue, 8 Jul 2008 07:08:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 080163A6867 for ; Tue, 8 Jul 2008 07:08:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m68E8Ctu010973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 16:08:12 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68E8A2O013648 for ; Tue, 8 Jul 2008 16:08:12 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:08:09 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:08:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 17:07:23 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Rechartering Thread-Index: AcjhA/HMKtifQ+FeQLC0JhaTh3mUYw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Jul 2008 14:08:08.0180 (UTC) FILETIME=[0C418B40:01C8E104] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.007 X-TM-AS-Result: No--6.237000-8.000000-31 Subject: [Dime] DIME Rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org It is fair to say that we are about to finish our current charter items. That's great. We started talking about new charter items already last year. Now, it is time to make some decisions. Here is a proposal on what we should do: Dave and I will post mails regarding the drafts various folks have proposed (IF THEY ARE STILL ACTIVE!!!) We would particularly like to know the following aspects: * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * What are the concerns with certain documents? * Is there a dependency with another IETF working group or with another SDO? Note that for some older documents we have already asked the group for feedback. We need to take this response into consideration as well. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 07:13:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811903A6A5C; Tue, 8 Jul 2008 07:13:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271263A6A5C for ; Tue, 8 Jul 2008 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-1.064, 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 8AV+GGqdGi58 for ; Tue, 8 Jul 2008 07:13:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 9E58C3A6A02 for ; Tue, 8 Jul 2008 07:13:05 -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 m68EDDSI020045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jul 2008 16:13:13 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m68EDD4i016032 for ; Tue, 8 Jul 2008 16:13:13 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:13:13 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 16:13:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 17:13:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet Draft Final Submission Cut-Off Date: 14th July 2008, 17:00 PDT Thread-Index: AcjhBMEQX27JqNL4SrKqLvHvEqljFw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Jul 2008 14:13:12.0338 (UTC) FILETIME=[C18C5F20:01C8E104] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16018.007 X-TM-AS-Result: No--6.186000-8.000000-31 Subject: [Dime] Internet Draft Final Submission Cut-Off Date: 14th July 2008, 17:00 PDT X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, PLEASE do not forget to resubmit your documents in time for the deadline. If your document expires we have to interpret this as a lack of interest to progress it and therefore we are not going to consider that specific document during the rechartering discussions. When you re-submit your document please also let us know what your plans with the document are (and sometimes a bit of history does not hurt either). Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 07:33:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5553A6982; Tue, 8 Jul 2008 07:33:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00F03A68D6 for ; Tue, 8 Jul 2008 07:33: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 G2xWJThxU8nm for ; Tue, 8 Jul 2008 07:33:11 -0700 (PDT) Received: from mail.alcatel-sbell.com.cn (cnrelay03.alcatel-sbell.com.cn [211.144.215.19]) by core3.amsl.com (Postfix) with ESMTP id BC7173A68A0 for ; Tue, 8 Jul 2008 07:33:09 -0700 (PDT) Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id m68EVtGH010212; Tue, 8 Jul 2008 22:31:57 +0800 Received: from CNSHGSMBS04.ad4.ad.alcatel.com ([172.24.146.175]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 8 Jul 2008 22:33:13 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 8 Jul 2008 22:33:12 +0800 Message-ID: <198A33EB1E9E344EBC566802C7761D6B0144E898@CNSHGSMBS04.ad4.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] draft-asveren-dime-cong-02 Thread-Index: AcjhAsufr2Xv5rScS3qI/DyuJwbt+AAAu75Q References: From: "TANG Alan" To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-OriginalArrivalTime: 08 Jul 2008 14:33:13.0121 (UTC) FILETIME=[8D455110:01C8E107] X-imss-version: 2.051 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.1500 0.1500) Cc: dime@ietf.org Subject: Re: [Dime] draft-asveren-dime-cong-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, Ciao, Hannes: Thank you for your response! I did contact Tolga for this issue. Actually it was Tolga who suggested me to raise this issue to the DIME mailing list. Once the work item for Diameter overload control is restarted we can provide our comments in detail. Thank you for the RADEXT draft document. I briefly took a look at that document. I think using an application request to detect the overloading status of a RADIUS server might be more appropriate for RADIUS than for Diameter, mainly because there is no full heart beat (watch dog) message for the RADIUS protocol which builds on connectionless transport protocol UDP. But for Diameter I think that re-using the existing heart beat message (DWR/A) to convey the loading status is better than introducing additional application request messages, which will make the existing logic more complicated and there will be interworking issues among multiple versions of the application protocols. Regards, Alan > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] > Sent: Tuesday, July 08, 2008 8:59 AM > To: TANG Alan > Cc: dime@ietf.org > Subject: Re: [Dime] draft-asveren-dime-cong-02 > > Hi Alan, > > that's very interesting feedback. Did you had a chance to talk to Tolga > about this. > > Maybe it is worth for both of you to also take a look at a recently > submitted RADEXT draft: > http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.t > xt > > Ciao > Hannes > > TANG Alan wrote: > > Hi, Diameter Gurus: > > I see that the following draft has expired. > http://tools.ietf.org/html/draft-asveren-dime-cong-02 > > It was said that this draft work has been suspended. As overload > control > mechanism is very essential for the commercialization of the > Diameter > products, would it be possible to have this draft work > re-started and > re-prioritized? > > Thanks in advance! > > Regards, > > Alan Tang > Alcatel-Lucent > Tel: +86 532 8861 5363 > Fax: +86 532 8861 9276 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 09:05:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74483A686C; Tue, 8 Jul 2008 09:05:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71BF3A686C for ; Tue, 8 Jul 2008 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCiZckc9+8gE for ; Tue, 8 Jul 2008 09:05:42 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by core3.amsl.com (Postfix) with ESMTP id AC9B33A6810 for ; Tue, 8 Jul 2008 09:05:42 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so1230884wxd.31 for ; Tue, 08 Jul 2008 09:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=gMmfc3nwIjLWV4yfP/08liaAkkZlpaj5cXCZFKaLlYk=; b=YrMWaPUOlfShrQzpvjH5+DbL2g4XPg3uCV9y2Q1wKshZQPBk7WBX6QXD+M03jTvCVL 5sNXx/S7Hf65UWOfik2N+DQWufB8QEvSjVpTx1zGI9vXxD8NWA4uRfaPPe5J55bi42ZL QQkb+vd9PlgcNoZ48FEod1kFNgK5suPbNzfKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Qfw8UWkHwNituD8wm68Sd27N7fJSLzPW77vUE1UVw8Bl2ovm5FE+Nx+dNKly8XDE8O vjfcqcbD8MixxIEqIqhavx7Jqv6D8fk/7eKgzu+VKC1Ug9ssfZ74vWbX0OaqA0pmwFqm GYYn2BkcsIGqdUlpts/l292+D2uJRHqOWpTeU= Received: by 10.100.46.10 with SMTP id t10mr5180008ant.22.1215533151529; Tue, 08 Jul 2008 09:05:51 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Tue, 8 Jul 2008 09:05:51 -0700 (PDT) Message-ID: <5e2406980807080905g56d2bd49j3d09d67831961807@mail.gmail.com> Date: Tue, 8 Jul 2008 18:05:51 +0200 From: "Julien Bournelle" To: "Hannes Tschofenig" In-Reply-To: <487075F8.8070006@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487075F8.8070006@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Diameter MIPv6 Split Document: Feedback needed X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi hannes, I understand your view but what bothers me is that we can't know for sure that the patent is on this MIP6-Feature-Flag AVP since the patent is unfortunatly unpublished. Maybe we have a third option: c/ wait publication of this patent. My 2 cents, Julien On Sun, Jul 6, 2008 at 9:36 AM, Hannes Tschofenig wrote: > Hi all, > > we have recently received an IPR disclosure for > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-10.txt > See http://www.ietf.org/mail-archive/web/dime/current/msg02573.html > > So, now we have two options: > > a) Ignore the IPR disclosure and go forward with the publication procedure > b) Think about the document a bit and potentiallly change some parts. > > I thought a little bit about the document and the concepts of most parts of > the document dates back already many, many years and is not really suprising > in any way when you have read the related documents (such as Diameter Mobile > IPv4, Diameter EAP, or MIPv6 bootstrapping). > > In the process of working on the document there was, however, one part that > surprised me, namely the excitement for getting some of the > MIP6-Feature-Vectors flags put into the document even though they do not > really constitute a core part of the protocol. > > I would therefore suggest to move these flags/codes into a separate > document. > > Thoughts? > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 12:16:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C4C28C276; Tue, 8 Jul 2008 12:16:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE0C28C230 for ; Tue, 8 Jul 2008 12:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqVCFOMLeEnk for ; Tue, 8 Jul 2008 12:16:50 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 8AEC728C27D for ; Tue, 8 Jul 2008 12:16:50 -0700 (PDT) Received: (qmail 38759 invoked by uid 60001); 8 Jul 2008 19:16:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=pjRAb+1mHQcax5uj0H7JbkuX9+foyo+i+4N+2I831Yx5mfondkxuzj6600oy8j7+xmwjCfILHOzjHbiGIuTmFMbb2Ev4pYXgmOVH6PbAHcppZ1CH1mtFLt7m45p0L7O/l49cXKn9a3/LQ/iG9NFwHdCnVPG2DJ+8eM5drysyMaE=; Received: from [206.16.17.212] by web84306.mail.re1.yahoo.com via HTTP; Tue, 08 Jul 2008 12:16:59 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 8 Jul 2008 12:16:59 -0700 (PDT) From: Behcet Sarikaya To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" MIME-Version: 1.0 Message-ID: <653639.38563.qm@web84306.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0037650144==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0037650144== Content-Type: multipart/alternative; boundary="0-4123974-1215544619=:38563" --0-4123974-1215544619=:38563 Content-Type: text/plain; charset=us-ascii Hi Hannes, It is true that new charter items discussion started last year but I don't think we had time to discuss various proposals. In IETF-71 only advancing the existing work got discussed. So my suggestion is to discuss various proposals first. My 2 cents. Behcet ----- Original Message ---- From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: dime@ietf.org Sent: Tuesday, July 8, 2008 9:07:23 AM Subject: [Dime] DIME Rechartering It is fair to say that we are about to finish our current charter items. That's great. We started talking about new charter items already last year. Now, it is time to make some decisions. Here is a proposal on what we should do: Dave and I will post mails regarding the drafts various folks have proposed (IF THEY ARE STILL ACTIVE!!!) We would particularly like to know the following aspects: * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * What are the concerns with certain documents? * Is there a dependency with another IETF working group or with another SDO? Note that for some older documents we have already asked the group for feedback. We need to take this response into consideration as well. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --0-4123974-1215544619=:38563 Content-Type: text/html; charset=us-ascii
Hi Hannes,
  It is true that new charter items discussion started last year but I don't think we had time to discuss various proposals. In IETF-71 only advancing the existing work got discussed.
  So my suggestion is to discuss various proposals first.

My 2 cents.

Behcet

----- Original Message ----
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: dime@ietf.org
Sent: Tuesday, July 8, 2008 9:07:23 AM
Subject: [Dime] DIME Rechartering

It is fair to say that we are about to finish our current charter items.
That's great. We started talking about new charter items already last
year. Now, it is time to make some decisions.

Here is a proposal on what we should do: Dave and I will post mails
regarding the drafts various folks have proposed (IF THEY ARE STILL
ACTIVE!!!)

We would particularly like to know the following aspects:
* Who is able to be editor of the document?
* Who is interested to help the editor with the work on the draft by
co-authoring it?
* Who is able to provide reviews?
* Who is unable to actively help with a specific document but supports
the work?
* What are the concerns with certain documents?
* Is there a dependency with another IETF working group or with another
SDO?

Note that for some older documents we have already asked the group for
feedback. We need to take this response into consideration as well.

Ciao
Hannes & Dave

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--0-4123974-1215544619=:38563-- --===============0037650144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0037650144==-- From dime-bounces@ietf.org Tue Jul 8 12:21:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EFB3A6980; Tue, 8 Jul 2008 12:21:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F6B3A6980 for ; Tue, 8 Jul 2008 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 u1knEQ2+smnd for ; Tue, 8 Jul 2008 12:21:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D9B373A67B2 for ; Tue, 8 Jul 2008 12:21:20 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2008 19:21:29 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp008) with SMTP; 08 Jul 2008 21:21:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19gVjdlLIJgQkEbXMO/NrhfbMPrlkXZdWvq6pd3dw VSYNjFLw5NlqlQ Message-ID: <4873BE39.8030201@gmx.net> Date: Tue, 08 Jul 2008 22:21:29 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Behcet Sarikaya References: <653639.38563.qm@web84306.mail.re1.yahoo.com> In-Reply-To: <653639.38563.qm@web84306.mail.re1.yahoo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I was, for example, referring to http://tools.ietf.org/html/draft-bodin-dime-auditing-reqs-03. We discussed it several times and there was also interest from the group to work on it. Nevertheless, I am looking forward to have discussions on various drafts. Do you have anything you would like see us doing in the group in the near future? Ciao Hannes Behcet Sarikaya wrote: > Hi Hannes, > It is true that new charter items discussion started last year but I > don't think we had time to discuss various proposals. In IETF-71 only > advancing the existing work got discussed. > So my suggestion is to discuss various proposals first. > > My 2 cents. > > Behcet > > ----- Original Message ---- > From: "Tschofenig, Hannes (NSN - FI/Espoo)" > To: dime@ietf.org > Sent: Tuesday, July 8, 2008 9:07:23 AM > Subject: [Dime] DIME Rechartering > > It is fair to say that we are about to finish our current charter items. > That's great. We started talking about new charter items already last > year. Now, it is time to make some decisions. > > Here is a proposal on what we should do: Dave and I will post mails > regarding the drafts various folks have proposed (IF THEY ARE STILL > ACTIVE!!!) > > We would particularly like to know the following aspects: > * Who is able to be editor of the document? > * Who is interested to help the editor with the work on the draft by > co-authoring it? > * Who is able to provide reviews? > * Who is unable to actively help with a specific document but supports > the work? > * What are the concerns with certain documents? > * Is there a dependency with another IETF working group or with another > SDO? > > Note that for some older documents we have already asked the group for > feedback. We need to take this response into consideration as well. > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 8 15:27:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 491583A684B; Tue, 8 Jul 2008 15:27:29 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4093A684B for ; Tue, 8 Jul 2008 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSBBbCpAByEa for ; Tue, 8 Jul 2008 15:27:27 -0700 (PDT) Received: from web84303.mail.re1.yahoo.com (web84303.mail.re1.yahoo.com [69.147.74.182]) by core3.amsl.com (Postfix) with SMTP id 5F5D33A67B2 for ; Tue, 8 Jul 2008 15:27:27 -0700 (PDT) Received: (qmail 41274 invoked by uid 60001); 8 Jul 2008 22:27:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=JhFUOMqD90Nucl2aGcm/RQEdvqxZJAcFoTOQJgOgS/Kn+iMRiLLWoRt93U+Is28Gu4P6exwezsY14WEWMRkIOlEIeawHGTXs834QbxTlKscRTkbjQ2ZI2VGWKErL93XIhutkhfbkAqbjRXMm4ZVSgU0CyNFOxJLBq+OQHDXvzuY=; Received: from [206.16.17.212] by web84303.mail.re1.yahoo.com via HTTP; Tue, 08 Jul 2008 15:27:36 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 8 Jul 2008 15:27:36 -0700 (PDT) From: Behcet Sarikaya To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <19744.40646.qm@web84303.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] DIME Rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0917597932==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0917597932== Content-Type: multipart/alternative; boundary="0-1306710482-1215556056=:40646" --0-1306710482-1215556056=:40646 Content-Type: text/plain; charset=us-ascii Hi Hannes, Please see inline below. Regards, Behcet ----- Original Message ---- From: Hannes Tschofenig To: Behcet Sarikaya Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" ; dime@ietf.org Sent: Tuesday, July 8, 2008 2:21:29 PM Subject: Re: [Dime] DIME Rechartering I was, for example, referring to http://tools.ietf.org/html/draft-bodin-dime-auditing-reqs-03. We discussed it several times and there was also interest from the group to work on it. Nevertheless, I am looking forward to have discussions on various drafts. Do you have anything you would like see us doing in the group in the near future? [behcet] I would like to request a slot to present our draft on Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application at http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Our previous draft received some comments and we revised it and submitted it as a new draft. Also I am ready to comment on other rechartering proposals. --0-1306710482-1215556056=:40646 Content-Type: text/html; charset=us-ascii
Hi Hannes,
  Please see inline below.

Regards,

Behcet
----- Original Message ----
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>; dime@ietf.org
Sent: Tuesday, July 8, 2008 2:21:29 PM
Subject: Re: [Dime] DIME Rechartering

I was, for example, referring to
http://tools.ietf.org/html/draft-bodin-dime-auditing-reqs-03. We
discussed it several times and there was also interest from the group to
work on it.

Nevertheless, I am looking forward to have discussions on various
drafts. Do you have anything you would like see us doing in the group in
the near future?

[behcet] I would like to request a slot to present our draft on Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application at
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
Our previous draft received some comments and we revised it and submitted it as a new draft.

Also I am ready to comment on other rechartering proposals.



--0-1306710482-1215556056=:40646-- --===============0917597932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0917597932==-- From dime-bounces@ietf.org Tue Jul 8 22:11:59 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB6C3A69C6; Tue, 8 Jul 2008 22:11:59 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6343A6950 for ; Tue, 8 Jul 2008 22:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[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 Ku6+Dh76jNrf for ; Tue, 8 Jul 2008 22:11:58 -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 599833A696D for ; Tue, 8 Jul 2008 22:11:52 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id m691rLX0018450 for ; Wed, 9 Jul 2008 10:53:21 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id m691rKvx022658 for ; Wed, 9 Jul 2008 10:53:20 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id m691rKsK022655 for ; Wed, 9 Jul 2008 10:53:20 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 833F04429 for ; Wed, 9 Jul 2008 10:53:20 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id 64A28440E for ; Wed, 9 Jul 2008 10:53:20 +0900 (JST) Message-ID: <48741A0C.2090907@nict.go.jp> Date: Wed, 09 Jul 2008 10:53:16 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Subject: [Dime] [rfc3588bis] Diameter version in diameter header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello list, I think the description of the Diameter Version field in the Diameter Header (section 3) is incomplete, or at least unclear. More guidelines would be needed in the text on how to handle a message with a different version number. In particular, I have read in previous mail exchanges that an answer should be sent with the same command-code and Result-Code AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). This assumes that the implementation is able to extract at least the command-code and the 'R' flag from the message of unsupported version, to create the answer. So my question: what is supposed to be common to all Diameter future versions in the message header? Does the version number increments only when a new flag is defined? I would think that clarifying this part could be handled inside the current effort on extensibility. Do you have any thoughts? Thank you, 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 dime-bounces@ietf.org Tue Jul 8 23:09:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5EC03A683D; Tue, 8 Jul 2008 23:09:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E873A683D for ; Tue, 8 Jul 2008 23:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LkuIyeqg86SP for ; Tue, 8 Jul 2008 23:09:25 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id B0E933A6782 for ; Tue, 8 Jul 2008 23:09:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 24B4AC806E; Wed, 9 Jul 2008 02:09:33 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01129-14; Wed, 9 Jul 2008 02:09:32 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Wed, 9 Jul 2008 02:09:32 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 02:09:32 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jul 2008 11:39:26 +0530 From: Biplab Sarkar To: Sebastien Decugis In-Reply-To: <48741A0C.2090907@nict.go.jp> References: <48741A0C.2090907@nict.go.jp> Organization: Starent Networks Date: Wed, 09 Jul 2008 11:39:26 +0530 Message-Id: <1215583766.11609.9.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 09 Jul 2008 06:09:26.0961 (UTC) FILETIME=[577D1210:01C8E18A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] [rfc3588bis] Diameter version in diameter header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1009122524==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1009122524== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5w5QNwPKNGnPDOT13O4l" --=-5w5QNwPKNGnPDOT13O4l Content-Type: multipart/alternative; boundary="=-cObrmnnmEKTsUaan6+eu" --=-cObrmnnmEKTsUaan6+eu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi All, I believe between a pair of peers, some minimum version for communication has to be decided during the message exchange. This can be trivially done. A minimal message header needs to be ensured across all future diameter message versions. And this needs to be explicitly captured in the document. =20 Thanks & Regards Biplab On Wed, 2008-07-09 at 10:53 +0900, Sebastien Decugis wrote: > Hello list, >=20 > I think the description of the Diameter Version field in the Diameter=20 > Header (section 3) is incomplete, or at least unclear. More guidelines=20 > would be needed in the text on how to handle a message with a different=20 > version number. In particular, I have read in previous mail exchanges=20 > that an answer should be sent with the same command-code and Result-Code=20 > AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). This assumes that the=20 > implementation is able to extract at least the command-code and the 'R'=20 > flag from the message of unsupported version, to create the answer. So=20 > my question: what is supposed to be common to all Diameter future=20 > versions in the message header? Does the version number increments only=20 > when a new flag is defined? >=20 > I would think that clarifying this part could be handled inside the=20 > current effort on extensibility. >=20 > Do you have any thoughts? >=20 > Thank you, > Sebastien. >=20 --=-cObrmnnmEKTsUaan6+eu Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,

I believe between a pair of peers, some minimum version for communication h= as to be decided during the
message exchange. This can be trivially done. A minimal message header need= s to be ensured across all future diameter message
versions. And this needs to be explicitly captured in the document.  <= BR>
Thanks & Regards
Biplab

On Wed, 2008-07-09 at 10:53 +0900, Sebastien Decugis wrote: 
Hello list,

I think the description of the Diameter Version field in the Diameter=20
Header (section 3) is incomplete, or at least unclear. More guidelines=20
would be needed in the text on how to handle a message with a different=20
version number. In particular, I have read in previous mail exchanges=20
that an answer should be sent with the same command-code and Result-Code=20
AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). This assumes that the=20
implementation is able to extract at least the command-code and the 'R'=20
flag from the message of unsupported version, to create the answer. So=20
my question: what is supposed to be common to all Diameter future=20
versions in the message header? Does the version number increments only=20
when a new flag is defined?

I would think that clarifying this part could be handled inside the=20
current effort on extensibility.

Do you have any thoughts?

Thank you,
Sebastien.
--=-cObrmnnmEKTsUaan6+eu-- --=-5w5QNwPKNGnPDOT13O4l Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIdFYW3rQBTW1UPu4RAowUAJ9cg1wevUSz+2fuRupIeAuXhpGz3wCffRaC khOnXk4Gzx1WtGsniwIv8Y8= =EiLj -----END PGP SIGNATURE----- --=-5w5QNwPKNGnPDOT13O4l-- --===============1009122524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1009122524==-- From dime-bounces@ietf.org Tue Jul 8 23:53:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0283A696A; Tue, 8 Jul 2008 23:53:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22E3A3A696A for ; Tue, 8 Jul 2008 23:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RglqEX5e4xfX for ; Tue, 8 Jul 2008 23:53:05 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 559113A67C0 for ; Tue, 8 Jul 2008 23:53:05 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id nhcN1Z0040lTkoCA806000; Wed, 09 Jul 2008 06:53:16 +0000 Received: from gwzPC ([67.171.26.111]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id nitA1Z0012PpizF8QitEHe; Wed, 09 Jul 2008 06:53:15 +0000 X-Authority-Analysis: v=1.0 c=1 a=LTR9TC537vEA:10 a=CJdK-RWKb4sA:10 a=E4f75N-zmBb4dM7VpcwA:9 a=2jOJevGOlGswdNnZ95YA:7 a=A3N4QQJrVAJBlwFXUUT4PwzUH9cA:4 a=BDXKcin-EtgA:10 From: "Glen Zorn" To: "'Sebastien Decugis'" References: <48741A0C.2090907@nict.go.jp> In-Reply-To: <48741A0C.2090907@nict.go.jp> Date: Tue, 8 Jul 2008 23:52:53 -0700 Message-ID: <003701c8e190$69e2ca70$3da85f50$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acjhgl4NoZTQ7lU3TV6SFm5z15WT4QADFzNA Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] [rfc3588bis] Diameter version in diameter header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sebastien Decugis [mailto://sdecugis@nict.go.jp] writes: > Hello list, > > I think the description of the Diameter Version field in the Diameter > Header (section 3) is incomplete, or at least unclear. More guidelines > would be needed in the text on how to handle a message with a different > version number. In particular, I have read in previous mail exchanges > that an answer should be sent with the same command-code and Result- > Code > AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). What is unclear about that? > This assumes that the > implementation is able to extract at least the command-code and the 'R' > flag from the message of unsupported version, to create the answer. In other words, the message must be recognizable by the receiving peer as a Diameter message. This seems fairly reasonable to me. > So my question: what is supposed to be common to all Diameter future > versions in the message header? Does the version number increments only > when a new flag is defined? Section 4.3 of RFC 3588 says: "In the event that a new Basic AVP Data Format is needed, a new version of this RFC must be created." Since this RFC is the defining document for the Diameter protocol, presumably this would also cause the version number in the header to be incremented. As you point out, however, this should probably be expanded to mention changes to the base protocol header, and it might be nice to highlight which parts of the header must remain stable in order for the protocol to be called Diameter. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 9 02:56:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BF93A68AC; Wed, 9 Jul 2008 02:56:32 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37723A6A05 for ; Wed, 9 Jul 2008 02:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[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 StdCULOkNIsi for ; Wed, 9 Jul 2008 02:56:29 -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 EB5BF3A67D8 for ; Wed, 9 Jul 2008 02:56:28 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id m697cak2000573; Wed, 9 Jul 2008 16:38:36 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m697calR003787; Wed, 9 Jul 2008 16:38:36 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m697caeF003782; Wed, 9 Jul 2008 16:38:36 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id DC061437E; Wed, 9 Jul 2008 16:38:35 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id B4A94440E; Wed, 9 Jul 2008 16:38:35 +0900 (JST) Message-ID: <48746AF2.4040403@nict.go.jp> Date: Wed, 09 Jul 2008 16:38:26 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Glen Zorn References: <48741A0C.2090907@nict.go.jp> <003701c8e190$69e2ca70$3da85f50$@net> In-Reply-To: <003701c8e190$69e2ca70$3da85f50$@net> X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Cc: dime@ietf.org Subject: Re: [Dime] [rfc3588bis] Diameter version in diameter header X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org >> an answer should be sent with the same command-code and Result- >> Code AVP set to DIAMETER_UNSUPPORTED_VERSION (5011). >> > > What is unclear about that? > Nothing, sorry I am not native English speaker so my sentence was probably confusing. The unclear part was what follows... >> This assumes that the >> implementation is able to extract at least the command-code and the 'R' >> flag from the message of unsupported version, to create the answer. >> > > In other words, the message must be recognizable by the receiving peer as a > Diameter message. This seems fairly reasonable to me. > Yes, you are right, the length of the message must also be correct. Therefore the implementation must be able to interpret at minimum the first two bytes of the message -- with the exception of the "(r)eserved" flags which can be ignored. >> So my question: what is supposed to be common to all Diameter future >> versions in the message header? Does the version number increments only >> when a new flag is defined? >> > > Section 4.3 of RFC 3588 says: "In the event that a new Basic AVP Data Format > is needed, a new version of this RFC must be created." Since this RFC is > the defining document for the Diameter protocol, presumably this would also > cause the version number in the header to be incremented. I don't understand this remark. The data format is not explicitly included in the message, it is implied by the AVP code. Therefore even if a new AVP is defined with a new data format, it will not change at all the format of the message, so there would be no need to change the version number... The implementation is either capable of handling the AVP (and therefore its new base type) or not, with the consequences that are described in the document (depending on the 'M' flag value of the AVP). > As you point out, > however, this should probably be expanded to mention changes to the base > protocol header, and it might be nice to highlight which parts of the header > must remain stable in order for the protocol to be called Diameter. > Thank you :) In order to go forward, I would like to mention this also: Correct me if I am wrong, but an exchange with a peer always begins with a CER/CEA exchange. Therefore, the message received with a mismatching Diameter version information is supposed to be a CER. As Biplab mentions, it would be trivial to force the CER header format and negotiate the protocol version during this exchange (with a dedicated AVP for example). After a successful CER/CEA exchange (with correct version number), if a message is received with an unsupported version, I think it would be better to simply discard the message and close the transport connection. It may mean that the security layer is misbehaving, or that message boundaries were losts, or any other (probably) unrecoverable error. Trying to create an answer with a 5011 Result-Code from a message which is probably trash seems broken design to me... Any more thoughts? Thanks, 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 dime-bounces@ietf.org Wed Jul 9 06:30:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF5528C117; Wed, 9 Jul 2008 06:30:02 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4FE363A6A05; Wed, 9 Jul 2008 06:30:00 -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: <20080709133001.4FE363A6A05@core3.amsl.com> Date: Wed, 9 Jul 2008 06:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-11.txt Pages : 160 Date : 2008-07-09 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-09061934.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Sun Jul 13 10:00:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE8E3A6B91; Sun, 13 Jul 2008 10:00:02 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4D6C83A6B91; Sun, 13 Jul 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080713170001.4D6C83A6B91@core3.amsl.com> Date: Sun, 13 Jul 2008 10:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Quality of Service Application Author(s) : D. Sun, et al. Filename : draft-ietf-dime-diameter-qos-06.txt Pages : 56 Date : 2008-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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-13094527.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Sun Jul 13 10:12:07 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0533A69E3; Sun, 13 Jul 2008 10:12:07 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6C93A6827 for ; Sun, 13 Jul 2008 10:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 z80liZGRzAF6 for ; Sun, 13 Jul 2008 10:12:04 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9E4EA3A69E3 for ; Sun, 13 Jul 2008 10:12:03 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2008 17:12:24 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp058) with SMTP; 13 Jul 2008 19:12:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BLwV8t3/Buy171RrBDpE7NqY7Oyl2QB8y80LFI0 0ri+zGoAOAwrzV Message-ID: <487A377C.4050507@gmx.net> Date: Sun, 13 Jul 2008 20:12:28 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Subject: [Dime] [Fwd: I-D Action:draft-ietf-dime-diameter-qos-06.txt] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The draft update just reflects my updated authors address. Ciao Hannes -------- Original Message -------- Subject: I-D Action:draft-ietf-dime-diameter-qos-06.txt Date: Sun, 13 Jul 2008 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: dime@ietf.org 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-06.txt Pages : 56 Date : 2008-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-06.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 dime-bounces@ietf.org Sun Jul 13 13:00:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75D93A69EA; Sun, 13 Jul 2008 13:00:03 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6C54C3A68B3; Sun, 13 Jul 2008 13: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: <20080713200001.6C54C3A68B3@core3.amsl.com> Date: Sun, 13 Jul 2008 13:00:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-07.txt Pages : 17 Date : 2008-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-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-13125449.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Sun Jul 13 13:01:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78E43A6A64; Sun, 13 Jul 2008 13:01:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3AB43A6A60 for ; Sun, 13 Jul 2008 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cns7JCRWySe for ; Sun, 13 Jul 2008 13:01:24 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 051D83A689B for ; Sun, 13 Jul 2008 13:00:43 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2008 20:01:07 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp002) with SMTP; 13 Jul 2008 22:01:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Ga/RF/ojGp/Kb1obVtyzmBRUcs8XIH89ysA5wTq zjAyQeu7V7UQjt Message-ID: <487A5F05.4040107@gmx.net> Date: Sun, 13 Jul 2008 23:01:09 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Dime] [Fwd: New Version Notification for draft-ietf-dime-app-design-guide-07] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have updated the Diameter Design Guidelines draft based on the discussion on Diameter extensibility over the last few months. This is certainly not the last draft update, as noted in my status report. I am not happy with the structure and the presentation in the document. Additionally, I guess there is a lot of value to provide many more examples. If someone of you has some ideas on how to improve the document please drop a note. Ciao Hannes -------- Original Message -------- Subject: New Version Notification for draft-ietf-dime-app-design-guide-07 Date: Sun, 13 Jul 2008 12:54:49 -0700 (PDT) From: IETF I-D Submission Tool To: Hannes.Tschofenig@gmx.net CC: vfajardo@tari.toshiba.com,tasveren@sonusnet.com,glenn@aaa.lucent.com,john.loughney@nokia.com A new version of I-D, draft-ietf-dime-app-design-guide-07.txt has been successfuly submitted by Hannes Tschofenig and posted to the IETF repository. Filename: draft-ietf-dime-app-design-guide Revision: 07 Title: Diameter Applications Design Guidelines Creation_date: 2008-07-13 WG ID: dime Number_of_pages: 17 Abstract: The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol 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. The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 13 23:04:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4E23A6A73; Sun, 13 Jul 2008 23:04:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C963A6A46 for ; Sun, 13 Jul 2008 23:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OEM_S_DOL=1.2] 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 TRwxCD6OJJQi for ; Sun, 13 Jul 2008 23:04:08 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 1845E3A6A80 for ; Sun, 13 Jul 2008 23:04:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C0D1F9000C for ; Mon, 14 Jul 2008 02:04:29 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21465-01 for ; Mon, 14 Jul 2008 02:04:29 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 14 Jul 2008 02:04:29 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 02:04:29 -0400 Received: from [10.6.7.67] ([10.6.7.67]) by exchindia3.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 11:34:25 +0530 From: Biplab Sarkar To: dime@ietf.org Organization: Starent Networks Date: Mon, 14 Jul 2008 11:34:25 +0530 Message-Id: <1216015465.10553.13.camel@INDBNG1172.bng.ind.starentnetworks.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 14 Jul 2008 06:04:25.0903 (UTC) FILETIME=[781C03F0:01C8E577] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] DWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bsarkar@starentnetworks.com List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154776498==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0154776498== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PSUF7Ogt267h3yNFpo+8" --=-PSUF7Ogt267h3yNFpo+8 Content-Type: multipart/alternative; boundary="=-ngGi4w789eKLowgeB3bp" --=-ngGi4w789eKLowgeB3bp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, With reference to [RFC3588-bis11][5.5.1]. http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt I think the following statement needs be changed to. ---------------------------------------------------------------------------= ---------------------- 5.5.1. Device-Watchdog-Request The Device-Watchdog-Request (DWR), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3)=20 =EF=BB=BFincoming traffic was received from the peer. Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer. ---------------------------------------------------------------------------= --------------------- =20 The DWR-timer should be monitoring the incoming traffic from the peer and not the out going one. Any comments? Thanks & Regards Biplab --=-ngGi4w789eKLowgeB3bp Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,

With reference to [RFC3588-bis11][5.5.1].

http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.tx= t

I think the following statement needs be changed to.

---------------------------------------------------------------------------= ----------------------
5.5.1.  Device-Watchdog-Request

   The Device-Watchdog-Request (DWR), indicated by the Command-Co= de set
   to 280 and the Command Flags' 'R' bit set, is sent to a peer w= hen no
   traffic has been exchanged between = two peers (see Section 5.5.3)
   incoming traffic was received = from the peer.
   Upon detection of a transport failure, this message MUST NOT b= e sent
   to an alternate peer.
---------------------------------------------------------------------------= ---------------------


The DWR-timer should be monitoring the incoming traffic from the peer and n= ot the
out going one.

Any comments?

Thanks & Regards
Biplab

--=-ngGi4w789eKLowgeB3bp-- --=-PSUF7Ogt267h3yNFpo+8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIeuxp3rQBTW1UPu4RAgQpAJ9GBnTlUtjICGRCp5EHBN6mDxTdUgCgxoMu GneOK+MaCB+wJl6kTHskphU= =186r -----END PGP SIGNATURE----- --=-PSUF7Ogt267h3yNFpo+8-- --===============0154776498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0154776498==-- From dime-bounces@ietf.org Sun Jul 13 23:18:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EEB3A6A9F; Sun, 13 Jul 2008 23:18:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670413A6A9C for ; Sun, 13 Jul 2008 23:18:54 -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 2vcHoKsjTy0K for ; Sun, 13 Jul 2008 23:18:53 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 4BD143A6A9A for ; Sun, 13 Jul 2008 23:18:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0F43E9000C for ; Mon, 14 Jul 2008 02:19:15 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21032-13 for ; Mon, 14 Jul 2008 02:19:13 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 14 Jul 2008 02:19:13 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 02:19:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 11:49:09 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C05FDC3CA@exchindia3.starentnetworks.com> In-Reply-To: <1216015465.10553.13.camel@INDBNG1172.bng.ind.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DWR Thread-Index: Acjld5CRfgDaUro2QSurssse4oPBIwAAWVcg References: <1216015465.10553.13.camel@INDBNG1172.bng.ind.starentnetworks.com> From: "Gowda, Avinash" To: "Sarkar, Biplab" , X-OriginalArrivalTime: 14 Jul 2008 06:19:13.0525 (UTC) FILETIME=[892C6250:01C8E579] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] DWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1748592561==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1748592561== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E579.87554F3B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E579.87554F3B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmlwbGFiLA0KDQogDQoNCllvdXIgcHJvcG9zZWQgY2hhbmdlIGFuZCBleGlzdGluZyBzZW50 ZW5jZSBtZWFuIHRoZSBzYW1lLiBFeGNoYW5nZSB3b3JkIG1lYW5zIOKAnFRoZSBhY3Qgb2YgZ2l2 aW5nIHNvbWV0aGluZyBpbiByZXR1cm4gZm9yIHNvbWV0aGluZyByZWNlaXZlZOKAnS4NCg0KIA0K DQpJbiBteSBvcGluaW9uIHRoZSBleGlzdGluZyBzZW50ZW5jZSBicmluZ3Mgb3V0IHRoZSBjb3Jy ZWN0IG1lYW5pbmcuDQoNCiANCg0KQW55IGNvbW1lbnRzIG9uIHRoaXM/DQoNCiANCg0KVGhhbmtz LA0KDQpBdmluYXNoIEdvd2RhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkZyb206IGRpbWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJpcGxhYiBTYXJrYXINClNlbnQ6IE1vbmRheSwgSnVseSAxNCwgMjAw OCAxMTozNCBBTQ0KVG86IGRpbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFtEaW1lXSBEV1INCg0KIA0K DQpIaSBBbGwsDQoNCldpdGggcmVmZXJlbmNlIHRvIFtSRkMzNTg4LWJpczExXVs1LjUuMV0uDQoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZGltZS1yZmMz NTg4YmlzLTExLnR4dA0KDQpJIHRoaW5rIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IG5lZWRzIGJl IGNoYW5nZWQgdG8uDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjUuNS4xLiAgRGV2aWNlLVdhdGNoZG9nLVJlcXVlc3QNCg0KICAgVGhlIERldmljZS1XYXRjaGRv Zy1SZXF1ZXN0IChEV1IpLCBpbmRpY2F0ZWQgYnkgdGhlIENvbW1hbmQtQ29kZSBzZXQNCiAgIHRv IDI4MCBhbmQgdGhlIENvbW1hbmQgRmxhZ3MnICdSJyBiaXQgc2V0LCBpcyBzZW50IHRvIGEgcGVl ciB3aGVuIG5vDQogICB0cmFmZmljIGhhcyBiZWVuIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBwZWVy cyAoc2VlIFNlY3Rpb24gNS41LjMpIA0KICAg77u/aW5jb21pbmcgdHJhZmZpYyB3YXMgcmVjZWl2 ZWQgZnJvbSB0aGUgcGVlci4NCiAgIFVwb24gZGV0ZWN0aW9uIG9mIGEgdHJhbnNwb3J0IGZhaWx1 cmUsIHRoaXMgbWVzc2FnZSBNVVNUIE5PVCBiZSBzZW50DQogICB0byBhbiBhbHRlcm5hdGUgcGVl ci4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNClRoZSBEV1It dGltZXIgc2hvdWxkIGJlIG1vbml0b3JpbmcgdGhlIGluY29taW5nIHRyYWZmaWMgZnJvbSB0aGUg cGVlciBhbmQgbm90IHRoZQ0Kb3V0IGdvaW5nIG9uZS4NCg0KQW55IGNvbW1lbnRzPw0KDQpUaGFu a3MgJiBSZWdhcmRzDQpCaXBsYWINCg0K ------_=_NextPart_001_01C8E579.87554F3B Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt c29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0K PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpWZXJkYW5hOw0KCWNvbG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZv bnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KQHBhZ2UgU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAx LjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0K DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPWJsdWU+DQoNCjxk aXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPkhpIEJpcGxhYiw8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1WZXJkYW5hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 VmVyZGFuYTtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1WZXJkYW5h PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6VmVyZGFuYTtjb2xv cjpibHVlJz5Zb3VyIHByb3Bvc2VkIGNoYW5nZSBhbmQgZXhpc3RpbmcNCnNlbnRlbmNlIG1lYW4g dGhlIHNhbWUuIEV4Y2hhbmdlIHdvcmQgbWVhbnMg4oCcVGhlIGFjdCBvZiBnaXZpbmcgc29tZXRo aW5nDQppbiZuYnNwO3JldHVybiBmb3Igc29tZXRoaW5nIHJlY2VpdmVk4oCdLjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250 LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJk YW5hO2NvbG9yOmJsdWUnPkluIG15IG9waW5pb24gdGhlIGV4aXN0aW5nIHNlbnRlbmNlDQpicmlu Z3Mgb3V0IHRoZSBjb3JyZWN0IG1lYW5pbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFu YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7Y29s b3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+QW55 IGNvbW1lbnRzIG9uIHRoaXM/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9VmVyZGFuYT48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OlZlcmRhbmE7Y29sb3I6Ymx1ZSc+VGhh bmtzLDwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9Ymx1ZT48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJs dWUnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPVZlcmRhbmE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEwLjBwdDtmb250LWZhbWlseTpWZXJkYW5hO2NvbG9yOmJsdWUnPkF2aW5hc2ggR293ZGE8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdiBj bGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZv bnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4 PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZv bnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+ PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpUYWhvbWEnPiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcNClttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+T24gQmVo YWxmIE9mIDwvc3Bhbj48L2I+QmlwbGFiDQpTYXJrYXI8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9u dC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBNb25kYXksIEp1bHkgMTQsIDIwMDggMTE6 MzQNCkFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48 L2I+IGRpbWVAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ U3ViamVjdDo8L3NwYW4+PC9iPiBbRGltZV0gRFdSPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48Zm9udCBzaXplPTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkhpIEFsbCw8YnI+DQo8YnI+DQpXaXRoIHJl ZmVyZW5jZSB0byBbUkZDMzU4OC1iaXMxMV1bNS41LjFdLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZGltZS1yZmMzNTg4 YmlzLTExLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1kaW1lLXJmYzM1ODhiaXMtMTEudHh0PC9hPjxicj4NCjxicj4NCkkgdGhpbmsgdGhlIGZvbGxv d2luZyBzdGF0ZW1lbnQgbmVlZHMgYmUgY2hhbmdlZCB0by48YnI+DQo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KNS41LjEuJm5ic3A7IERldmljZS1X YXRjaGRvZy1SZXF1ZXN0PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoZSBEZXZpY2UtV2F0Y2hk b2ctUmVxdWVzdCAoRFdSKSwgaW5kaWNhdGVkIGJ5IHRoZSBDb21tYW5kLUNvZGUNCnNldDxicj4N CiZuYnNwOyZuYnNwOyB0byAyODAgYW5kIHRoZSBDb21tYW5kIEZsYWdzJyAnUicgYml0IHNldCwg aXMgc2VudCB0byBhIHBlZXIgd2hlbg0Kbm88YnI+DQombmJzcDsmbmJzcDsgPHM+PGZvbnQgY29s b3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+dHJhZmZpYyBoYXMgYmVlbg0KZXhjaGFu Z2VkIGJldHdlZW4gdHdvIHBlZXJzIChzZWUgU2VjdGlvbiA1LjUuMykgPC9zcGFuPjwvZm9udD48 L3M+PGJyPg0KJm5ic3A7Jm5ic3A7IDxmb250IGNvbG9yPXJlZD48c3BhbiBzdHlsZT0nY29sb3I6 cmVkJz7vu79pbmNvbWluZyB0cmFmZmljIHdhcw0KcmVjZWl2ZWQgZnJvbSB0aGUgcGVlci48L3Nw YW4+PC9mb250Pjxicj4NCiZuYnNwOyZuYnNwOyBVcG9uIGRldGVjdGlvbiBvZiBhIHRyYW5zcG9y dCBmYWlsdXJlLCB0aGlzIG1lc3NhZ2UgTVVTVCBOT1QgYmUNCnNlbnQ8YnI+DQombmJzcDsmbmJz cDsgdG8gYW4gYWx0ZXJuYXRlIHBlZXIuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0KVGhlIERXUi10aW1lciBzaG91bGQgYmUgbW9u aXRvcmluZyB0aGUgaW5jb21pbmcgdHJhZmZpYyBmcm9tIHRoZSBwZWVyIGFuZCBub3QNCnRoZTxi cj4NCm91dCBnb2luZyBvbmUuPGJyPg0KPGJyPg0KQW55IGNvbW1lbnRzPzxicj4NCjxicj4NClRo YW5rcyAmYW1wOyBSZWdhcmRzPGJyPg0KQmlwbGFiPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01C8E579.87554F3B-- --===============1748592561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1748592561==-- From dime-bounces@ietf.org Mon Jul 14 06:16:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815773A6A6A; Mon, 14 Jul 2008 06:16:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998103A6A5C for ; Mon, 14 Jul 2008 06:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 gGWJPO6TlmuP for ; Mon, 14 Jul 2008 06:16:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5449F3A68C9 for ; Mon, 14 Jul 2008 06:16:54 -0700 (PDT) Received: (qmail invoked by alias); 14 Jul 2008 13:17:19 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp003) with SMTP; 14 Jul 2008 15:17:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183ONsOis438DqVsN0utssJ+/+ylHmjmf4tXn01st S7FOO1h5mRnU+r Message-ID: <487B51E3.5030409@gmx.net> Date: Mon, 14 Jul 2008 16:17:23 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Dime] [Fwd: [MEXT] I-D Action:draft-ietf-mip6-radius-05.txt] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Please also take a look at the following document! -------- Original Message -------- Subject: [MEXT] I-D Action:draft-ietf-mip6-radius-05.txt Date: Mon, 14 Jul 2008 05:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: mext@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : RADIUS Mobile IPv6 Support Author(s) : A. Lior, et al. Filename : draft-ietf-mip6-radius-05.txt Pages : 50 Date : 2008-07-14 This document defines new attributes to facilitate Mobile IPv6 operations using RADIUS infrastructure. The operations include bootstrapping of information required by the Mobile Node and the interface between the Network Access Server, Home Agent and the RADIUS server used to assist MIP6 operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-05.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 dime-bounces@ietf.org Mon Jul 14 08:46:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4070B28C1C0; Mon, 14 Jul 2008 08:46:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6DC28C1AE for ; Mon, 14 Jul 2008 08:46:36 -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 Uz1gvF6zKB6G for ; Mon, 14 Jul 2008 08:46:34 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 0172228C164 for ; Mon, 14 Jul 2008 08:46:12 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6EFiwE8008891; Mon, 14 Jul 2008 10:46:30 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 10:44:58 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 10:44:56 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B1F77F@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-sun-dime-itu-t-rw-00.txt Thread-Index: AcjWCE4QZKGmlyHHRYO8OUF3ezBJYAPv2tIw References: From: "Sun, Dong \(Dong\)" To: "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 14 Jul 2008 15:44:58.0566 (UTC) FILETIME=[91FE9660:01C8E5C8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: dime@ietf.org Subject: Re: [Dime] AD Review of draft-sun-dime-itu-t-rw-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Dan, See my comments inline. I will upload the revised version before the end of today. Rgs, Dong -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, June 24, 2008 10:41 AM To: Sun, Dong (Dong) Cc: Hannes Tschofenig; dime@ietf.org Subject: AD Review of draft-sun-dime-itu-t-rw-00.txt Here is the Area Director Review of draft-sun-dime-itu-t-rw-00.txt. I have divided the commented in Technical and Editorial. A Revised-ID is needed before sending the document to IETF Last Call. T1. RFC 2434 was obsoleted by RFC 5226 >> done. T2.Section 4.1 - I do not believe that the document should ask IANA for the allocation of 'the next value' (probably the next available value), but rather just for the allocation of a value in the specified range. >>done. "the next value" is removed. T3. Section 4.3 needs to be re-written.- The nine values of the AVP codes should be TBD and assignment be required from IANA at the recommended values. The values in Table 1/Q.3303.3 in Section 7.3.1 of [Q.3303.3] can be recommended but the final assignment should be made by IANA after the document is approved (rationale - another ITU-T SG may have already asked for the assignment of the same values) >> The range of these AVP codes has been assigned to ITU for its specific use and the IETF is not responsible for nailing down the concrete AVPs within this range on behalf of ITU. In the ITU, there is a single authority being responsible for assigning the AVP codes for all pertinent applications. So there will not have overlapping problem. E1. I suggest that the title of the document should be consistent with the title of RFC5224 so instead of 'Diameter Policy Enforcement Interface: ITU-T Rw' rather 'Diameter ITU-T Rw Policy Enforcement Interface Application' >> done. E2. In the Introduction Section s/to send a request and receiving a response/to send a request and receive a response/ >> done. E3. Section 2 Additionally, the terms and acronyms defined in Section 4 of [Q.3303.3] are used in this document. Actually in [Q.3303.3] Section 3 defines terms and section 4 acronyms. >> done E4. I find section 3 pointless as it stands now. A one-two executive summary paragraph placing the interface described in the document in the context of Q.3303.1 and ITU-T Y.2111 and mentioning that the scope of the interface is to control policy enforcement functions in the transport devices, including QoS resource control, NAPT/NAT traversal control, etc. would be appropriate. >> done. E5. Section 4.1 - the reference is incorrect s/Section 3/[Q.3303.3] Section 7.2.1 >> done. E6. Section 7.4.2 - the references are incomplete - add to each that they refer to [Q.3303.3] >> done. Regards, Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 14 15:02:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49B428C353; Mon, 14 Jul 2008 15:02:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3E128C353 for ; Mon, 14 Jul 2008 15:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzPaTT1Gghjk for ; Mon, 14 Jul 2008 15:02:30 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1904228C0E2 for ; Mon, 14 Jul 2008 15:02:22 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6EM2ZDs008339 for ; Mon, 14 Jul 2008 17:02:48 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Jul 2008 17:02:45 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Jul 2008 17:02:44 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B1FA33@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-sun-dime-itu-t-rw-01.txt Thread-Index: Acjl/QkGfmXAbf02Q2GJwAojd0g29gAABqGg From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 14 Jul 2008 22:02:46.0267 (UTC) FILETIME=[58FF44B0:01C8E5FD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Dime] FW: New Version Notification - draft-sun-dime-itu-t-rw-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Fyi. A new version is uploaded according Dan's comments. Rgs, Dong -----Original Message----- From: Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org] Sent: Monday, July 14, 2008 6:00 PM To: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org; Hannes.Tschofenig@gmx.net; dromasca@avaya.com Subject: New Version Notification - draft-sun-dime-itu-t-rw-01.txt New version (-01) has been submitted for draft-sun-dime-itu-t-rw-01.txt. http://www.ietf.org/internet-drafts/draft-sun-dime-itu-t-rw-01.txt Sub state has been changed to AD Follow up from New Id Needed IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 14 18:47:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09E93A69D7; Mon, 14 Jul 2008 18:47:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8033A69D7 for ; Mon, 14 Jul 2008 18:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvxS9g8qMYoS for ; Mon, 14 Jul 2008 18:47:07 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id B42A53A6838 for ; Mon, 14 Jul 2008 18:46:58 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m6F1lIbl029505; Tue, 15 Jul 2008 10:47:18 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id EF3EC63E3; Tue, 15 Jul 2008 10:47:17 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E5A545E74; Tue, 15 Jul 2008 10:47:17 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1lHwx014361; Tue, 15 Jul 2008 10:47:17 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1lGYk014347; Tue, 15 Jul 2008 10:47:16 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1l6Gj018052; Tue, 15 Jul 2008 10:47:16 +0900 (JST) Message-ID: <487C029C.4020105@lab.ntt.co.jp> Date: Tue, 15 Jul 2008 10:51:24 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hannes Tschofenig Cc: tsunemasa@gmail.com, dime@ietf.org, christian.jacquenet@orange-ftgroup.com, Hiroshi Ohta Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, Thank you for your feedback. We just released a new version of ietf-mboned-multiaaa-framework (07). Please see responses to http://www.ietf.org/mail-archive/web/dime/current/msg02007.html inline. > > * Abstract: > > > "... and to invoice > such customers in a reliable and efficient manner. > " > changed to "There is indeed a need for service and content providers to identify users(if not authenticate, especially within the context of enforcing electronic payment schemes) and account for content and network usage. " > Hmmm. I guess that invoicing is largely outside the scope of IETF work. I am also not sure what reliable and efficient could mean in this context. > Changed to: "There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and account for content and network usage. " > * Section 2.1 Terminology > > > I suggest to replace most of the terms with references to existing documents. > Join and Leave definitions were updated to reference existing documents. > * Section 4.1 Framework > > " > The CP > hopes to collect accounting information related to the > access of their content. > " > > > Why would the CP "HOPE"? The content provider can decide what is wants to charge the user. > changed to: "As defined in [I-D.mboned-maccnt-req]the CP requires collection of accounting information related to the access of its content." > The CP may choose to authenticate > and authorize NSPs which are eligible to provide users > access to its contents. > " > The CP does not really authenticate or authorize NSPs. It has IP connectivity and obviously need to have a business contract for doing that. > > Additionally, I am curious why you use plural here (NSPs). > Authentication and authorization of NSP by CP is an optional part of the framework and therefore we use "may." The CP in some case may be linked to multiple NSPs as described in section 4.1 and there may be different trust relationships between different providers. CPs in some cases want to keep their content from being copied. > > " > When the CP cannot (e.g. error or > resource issues) or decides not (e.g. policy issues) to > deliver content, the CP is responsible for notifying the > NSP of the reason. It is up to the NSP how to relay or > translate the messages to the user. > " > > I doubt that the NSP cares. Why doesn't the CP send the message to the user right away. The user has interacted with the CP in the first place. > > In fact, I find Figure 1 strange since it shows that the user interacts indirectly with the CP rather than directly. There is something wrong. > > (Btw, the figure has no caption.) that is true in the case of unicast. Multicasting potentially can use a large amount of the NSP$B!G(Bs resources, and therefore the NSP should have the final decision of accepting or rejecting the request based on ability to fulfill the request. In the case of unicast if the CP accepts requests even though overloaded it will only end up dropping packets. However with multicasting accepting such requests when overloaded can result in a DOS attack on the NSP router. > > " > The NSP is responsible for managing its network resources. The NSP may perform admission control. It is also > responsible for relaying the AAA messages from the CP > whether the user is eligible to receive content > (authentication by proxy), > " > > Hmm. Why does the NSP relay AAA messages when the user interacts with the CP? > For the same reasons described above. > > " > In certain cases the CP and NSP may > have a contractual relationship in which the NSP is > authorized to make the content authorization decision based > on mutually predetermined criteria: in such cases the NSP- > AAA may also make the content authorization decision > without querying the CP-AAA. When the NSP cannot or > decides not to multicast to users, the NSP may notify the > users of the reason. It is recommended that the NSP notify > eligible users of the reason for not multicasting content > when it is due network or content unavailability, for > example. The NSP may choose not to notify ineligible users > of the reason for any case. > " > > > From a AAA point of view it does not really matter whether the NSP and the CP have a contract. I don't understand why the NSP will make the content authorization decision. What authorization decision would that be? > > The story that the NSP would notify the user about any content related issues seems really strange to me. The NSP does not make the content authorization decision, but multicast usage decision. However it relays the content authorization decision of the CP if its multicast usage decision is positive. > * Section 4.2 > " > The actual mapping rules for NSPs and CPs to map user IDs > with the IDs in other provider domains is a matter for the > providers. A solution should provide an API between the > providers to flexibly support various mapping methods. " > > > Why would one want to map identities? With the version you reviewed (v4) the explanations about mappings were insufficient. These reasons are addressed in the current draft$B!G(Bs sections 4.2.1 (CP-assigned user ID )$B!!(Band 4.2.2 (NSP-assigned user ID) > * Section 4.3 Accounting > > > " > Standardization of the logs or messages to share content > usage information is important to support a single NSP > sharing accounting information with multiple CPs or a > single CP receiving from multiple NSPs. > " > You envision that NSPs would send accounting information to the CP. > > > Just to understand you correctly did you have something like http://tools.ietf.org/wg/nsis/draft-dressler-nsis-metering-nslp-05.txt > > Imagine the following case that there are multiple networks between the CP and the end host. Would each intermediate domain send accounting records to the CP? Log standardization was removed in subsequent versions. > * Section 5.1 Basic Connection Model > > > " > First a user that requests content > sends an Access request to an NSP which then forwards it on > to the appropriate CP for Authentication and Authorization > purposes. > " > > > Why would a user send an "requst" to an NSP when it wants to get access to, for example, a video? > The user is not requesting content from NSP, but requesting multicast (S,G). Changed to: First a user requesting multicast content sends an access request (multicast (S,G)) to an NSP which then forwards it on to the appropriate CP for Authentication and Authorization purposes. > Figure 2 looks like something obtained from an ITU-T doc. > In the IETF you typically do not speak about interfaces but rather about protocols. > We envision protocol discussion to take place in solution documents, and interfaces appropriate for the framework level. > " > multicast AAA server > " > > > What is this? > > > " > ... access policy is downloaded to the > NAS (conditional access policy control function.) > " > > > What policies do you want to download? > Access control list for Joins Changed to: The multicast AAA function may be provided by a mAAA which may include the function by which the the access control list for Joins is downloaded to the NAS (called conditional access policy control function.) > > Figure 3: The entire discussion about Resource and Admission Control System (RACS) is most likely irrelevant for the AAA interaction. Are you referring to work outside the IETF or to the Diameter QoS work? http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt > > http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-05.txt The current version of our framework doc no longer refers to RACS, instead to MACF (multicast admission control function.) Solutions will be considered further in a solution draft. Thanks _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 14 18:50:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F533A6937; Mon, 14 Jul 2008 18:50:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D753A6937 for ; Mon, 14 Jul 2008 18:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id De9AOOKvQEBA for ; Mon, 14 Jul 2008 18:50:47 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id E5C7F3A6927 for ; Mon, 14 Jul 2008 18:50:46 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m6F1pBU8000193; Tue, 15 Jul 2008 10:51:11 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1969065FE; Tue, 15 Jul 2008 10:51:11 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 092A365FD; Tue, 15 Jul 2008 10:51:11 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1pAlF017265; Tue, 15 Jul 2008 10:51:10 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1pA8T017259; Tue, 15 Jul 2008 10:51:10 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1p4nk018440; Tue, 15 Jul 2008 10:51:09 +0900 (JST) Message-ID: <487C0389.6040300@lab.ntt.co.jp> Date: Tue, 15 Jul 2008 10:55:21 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org Cc: tsunemasa@gmail.com, christian.jacquenet@orange-ftgroup.com, Hiroshi Ohta Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Jouni, Thank you for your feedback. We just released a new version of ietf-mboned-multiaaa-framework including many of your suggestions. Responses inline: > > Some editorial comments: > > Section 1.1 > > o "...communication schemes of any kind, such as 1-to-n (case of > TV broadcasting services for example) or n-to-p (case of..." > > rather use one-to-many and many-to-many Changed as recommended. > o "...high-quality multicast transport using a Resource and > Admission Control System (RACS) with multicast..." > > I assume this refers to TiSPAN defined RACS functional entity. > I would like to see a reference here. We no longer refer to RACS. Now using a general word "MACF". > o "...presented in draft-ietf-mboned-maccnt-req-04.txt,..." > > Rather use the reference to [1] > o "...MACCNT-REQ-draft describes the requirements in CDN services > using IP multicast[1]. The requirements are derived from:..." > o "...Detailed requirements are presented in MACCNT-REQ-draft...." > > Again the reference.. Changed reference style throughout. eg. [I-D.mboned-maccnt-req] > Section 2.1 > > o " Note: The definition of a receiver (device) and a user > (human) should not be confused. " > > This note does not really fit into definitions as it is. Now it > looks like yet another definition, which is not the intent I > assume. Combined into the definition. > Section 2.2 > > o AAA, mAAA, NSP-AAA, CP-AAA, ID, API, IF, NAS, QoS > and RACS are missing Added (except RACS which no longer is in the draft.) > Section 3 > > o "...are divided between separate entities. The MACCNT-REQ- > draft provides more detail of the multiple versus single..." Added reference. > o "...entity CDS network models. " > > Expand CDS on the first use Done. > o "As such it should not be assumed that the entity > responsible for the multicasting structure and the entity > responsible for content serving are the same. Indeed > because the infrastructure for multicasting is expensive > and many content holders are not likely to be competent at > building and maintaining complicated infrastructures > necessary for multicasting, many content holders would > prefer to purchase transport and management services from a > network service provider and thus share the infrastructure > costs with other content holders." > > Consider revising.. to something like.. whatever.. > > "It should not be assumed that the entity responsible for > the multicasting infrastructure is not the same as the entity > responsible for serving the content. Content holders are not > likely to build and maintain their own multicast network > infrastructure that is not part of their expertise area. Rather > they are willing to purchase transport and management services > from dedicated network service providers."' Combined and shortened the two paragraphs to: "In many cases however the content provision and network provision roles are divided between separate entities. Commonly, Content Providers (CP) do not build and maintain their own multicast network infrastructure as that is not part of their expertise area. Rather CP often opt to purchase transport and management services from dedicated network service providers. " > o "...The use model of a single NSP providing multicasting > services to multiple CPs the following general requirements > from MACCNT-REQ-draft apply:..." > > References.. > > Expand CP on the first usage. Done > Reword to something like > > "In the usage model of where a single NSP provides multicast > services to multiple Content Providers (CP), the following > general requirements from [1] apply:.." Changed to: In the usage model of where a single NSP provides multicast services to multiple CPs, the following general requirements from [I-D.mboned-maccnt-req] apply: > o "When the NSP and CP are the same single entity the general > requirements are as follows." > > revise to > > "When the NSP and the CP are the same entity then the general > requirements are as follows:" Done. > Section 4.1 > > o "A general high-level framework can be represented as > follows." > > revise to.. something like > > "A general high-level framework is presented in the > Figure 1." Done > o For relationships use similar style as in previous sections. > e.g. 1:1 -> one-to-one or 1-to-1 etc.. Done > o Expand STB on the first use. > > o What is STB? It is mentioned only once in this document in this > section.. STB section was removed in version 6 so no longer relevant. > o "The CP is responsible for Authentication and Authorization.." > > use "authentication and authorization" Done. > o "...(authentication by proxy), and the NSP's relevant AAA.." > > Authentication via or through? The relevant sentence was removed in version 6 > o NSP-AAA and CP-AAA? > > o "...without querying the CP-AAA. When the NSP cannot or > decides not to multicast to users, the NSP may notify the..." > > I don't get what this is supposed to mean. We believe the wording as of v6 addresses the above concern. "When the CP cannot (e.g. error or resource issues) or decides not (e.g. policy issues) to deliver content, the CP is responsible for notifying the NSP of the reason. It is up to the NSP how to relay or translate the reasons for rejection to the user." > Section 4.2 > > o Heading -> "Multiple User Identities" > > o Expand ID on the first use. Done > Section 4.2 > > o References to [1].. and a consistent way of doing those would be > nice. > > o Reference to RFC3810 & RFC3376 no longer explicitly referenced. > o Expand API on the first use API removed from draft as of version 6. > Section 4.5 > > o References > > Section 4.7 > > o "reestablish" to "re-establish"? Relevant section deleted as of version 6. > Section 5 > > o "Section 3.1 introduces the high-level AAA framework for..." > > introduced Done > o "...access to the User. First a user that requests content..." > > revise to.. something like > > "...access to a user. First the user.." Done > o "...to the appropriate CP for Authentication and Authorization..." > > authorization and authorization Done > o Notation of relations.. 1:1 etc to similar as previously used > > Section 5.2 > > o References.. > > o Should these "well managed", "fully enabled AAA" etc be defined > in section 2.1 > > o "Section 3.1 intriduces" -> introduced > these are removed in the current version. > o "of a AAA" -> "of an AAA" it is generally read "Triple-A" so will leave as a > o In the figure 2 the caption is partial.. or parts of it is > before the figure.. should be fixed Changed caption formatting. > o Use consistent way of expanding abbreviations.. both types e.g. > Content Provider (CP) and CP (Content Provider) are used Not sure where this is referring to NP and NSP wording inconsistency was fixed in a prior version. > o Figure 3 has similar caption issues as figure 2 Changed caption formatting. > I got a bit stuck to general presentation of the draft. It needs > more work. For general readability of the draft I would suggest > paying attention to overall formatting. This may sound naive but > IMHO I would suggest using some tool that generates automatically > a proper layout, such as xml2rfc. > > > And then some remotely technical comments, if any. > > o It is rather unclear to me how the actual AAA transactions are > supposed to work (refer to fig. 1). CP auth/authz the user > and the CP also auth/authz the NSP? Are these separate? > What about user to NSP auth/authz? (this is then later > described better in section 5.1 but not where the fig.1 > is described) We removed mention of the messages in Figure 1 and added a new Figure 2 to 5.1 Basic Connection Model that includes the messages. > o "The actual mapping rules for NSPs and CPs to map user IDs > with the IDs in other provider domains is a matter for the > providers. A solution should provide an API between the > providers to flexibly support various mapping methods." The API discussion part was removed. > The inter-working could be explained a bit more carefully. > An example would be nice. Otherwise this is rather unambiguous. > > > o Standardization of logs? Do you mean coming up with a file > presentation format for user session tracking? Or rather > just defining that billing record format? Could any of the > existing ones be re-used or expanded? Believe this was removed in a previous version. Instead the draft discusses "accounting report messages" sent by NSP to CP discussed in section 4.3. > o "...This framework specifies an accounting API provided by the > NSP and accessed by the CP to allow for sharing user-..." > > I don't really find the API specification in this framework > draft The discussion of API was removed in a subsequent version after you reviewed. > o Does API here actually mean AAA interface or something else? > The use of API-term is somewhat confusing.. The discussion of API was removed in a subsequent version > o "content request" is AAA request? > No it is a request for a multicast channel. > o It would be nice to have a separate sections (or something) > going through each AAA interface (IFa, IFb, etc) We added titles above paragraphs and broke large paragraphs into smaller paragraphs as appropriate. Thanks _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 14 18:52:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3B23A6937; Mon, 14 Jul 2008 18:52:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B209E3A6927 for ; Mon, 14 Jul 2008 18:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akr6G3HwiX9R for ; Mon, 14 Jul 2008 18:52:37 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id CA97B3A6937 for ; Mon, 14 Jul 2008 18:52:36 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m6F1r161019986; Tue, 15 Jul 2008 10:53:01 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2CF7D65FE; Tue, 15 Jul 2008 10:53:01 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 26D7365FD; Tue, 15 Jul 2008 10:53:01 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1r0K0018613; Tue, 15 Jul 2008 10:53:00 +0900 (JST) Received: from imh.m.ecl.ntt.co.jp (imh0.m.ecl.ntt.co.jp [129.60.5.146]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1qxRl018606; Tue, 15 Jul 2008 10:52:59 +0900 (JST) Received: from [127.0.0.1] ([129.60.13.7]) by imh.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m6F1qpqZ018621; Tue, 15 Jul 2008 10:52:59 +0900 (JST) Message-ID: <487C03F4.1060604@lab.ntt.co.jp> Date: Tue, 15 Jul 2008 10:57:08 +0900 From: Hiroaki Sato User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org Cc: tsunemasa@gmail.com, christian.jacquenet@orange-ftgroup.com, Hiroshi Ohta Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tina Thank you for your feedback. We just released a new version of ietf-mboned-multiaaa-framework (07) including many of your suggestions. Response inline: > http://www.ietf.org/mail-archive/web/dime/current/msg01912.html > > > Hi all, > Here are my preliminary comments on this draft as promised. > 1. ".. activated to make sure a given requesting customer is (1) > what he claims to be (identification purposes)," in section 2.1 > is authentication, not authorization Edited to: The set of capabilities that need to be activated to make sure an authenticated user is fully entitled to access a set of services. > 2. It is not clear why RACS is not needed when NSP and CP are the same single entity The whole section was reorganized in a previous version so probably the above comment is no longer relevant. > > 3. Can mAAA push unsolicited access control information to NAS? A framework is necessary so the NSP can push access control information at its own initiative. Solutions will be considered further in a separate solution draft in the future. > 4. "Refer to section 3.3" in section 7. There is no section 3.3 Deleted this because the reference was from an earlier version and no longer made sense. Added to the security section: The user information related to authentication with the CP and the information related to user accounting shared between the NSP and the CP must be protected in some way. > B. R. > Tina Thank you _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 14 19:57:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904053A68E4; Mon, 14 Jul 2008 19:57:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4EF3A6774 for ; Mon, 14 Jul 2008 19:57:02 -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 4KcxI1nzNpvD for ; Mon, 14 Jul 2008 19:57:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1A2B93A6ACE for ; Mon, 14 Jul 2008 19:56: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 <0K4100FEU1JNRW@szxga03-in.huawei.com> for dime@ietf.org; Tue, 15 Jul 2008 10:57:23 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4100GO51JNN9@szxga03-in.huawei.com> for dime@ietf.org; Tue, 15 Jul 2008 10:57:23 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K41001TJ1JNLY@szxml03-in.huawei.com> for dime@ietf.org; Tue, 15 Jul 2008 10:57:23 +0800 (CST) Date: Tue, 15 Jul 2008 10:57:22 +0800 From: Tina TSOU To: "Sun, Dong (Dong)" , dime@ietf.org Message-id: <009201c8e626$814b98a0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <09C9068466B79E4C938DC7737562404D01B1FA33@ILEXC2U01.ndc.lucent.com> Cc: tsg11q5@itu.int Subject: [Dime] [Q5/11] Re: FW: New Version Notification - draft-sun-dime-itu-t-rw-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: , Content-Type: multipart/mixed; boundary="===============0126774012==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0126774012== Content-type: multipart/alternative; boundary="Boundary_(ID_Qd0MPR9AqPZF7bdlbQA2bg)" This is a multi-part message in MIME format. --Boundary_(ID_Qd0MPR9AqPZF7bdlbQA2bg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT To ITU-T Q.5/11 Rw Diameter people, If you have comments, you could make in this thread. B. R. Tina ----- Original Message ----- From: Sun, Dong (Dong) To: dime@ietf.org Sent: Tuesday, July 15, 2008 6:02 AM Subject: [Dime] FW: New Version Notification - draft-sun-dime-itu-t-rw-01.txt Fyi. A new version is uploaded according Dan's comments. Rgs, Dong -----Original Message----- From: Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org] Sent: Monday, July 14, 2008 6:00 PM To: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org; Hannes.Tschofenig@gmx.net; dromasca@avaya.com Subject: New Version Notification - draft-sun-dime-itu-t-rw-01.txt New version (-01) has been submitted for draft-sun-dime-itu-t-rw-01.txt. http://www.ietf.org/internet-drafts/draft-sun-dime-itu-t-rw-01.txt Sub state has been changed to AD Follow up from New Id Needed IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_Qd0MPR9AqPZF7bdlbQA2bg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
To ITU-T Q.5/11 Rw Diameter people,
If you have comments, you could make in this thread.
 
B. R.
Tina
----- Original Message -----
Sent: Tuesday, July 15, 2008 6:02 AM
Subject: [Dime] FW: New Version Notification - draft-sun-dime-itu-t-rw-01.txt


Fyi.
A new version is uploaded according Dan's comments.

Rgs,
Dong
-----Original Message-----
From: Internet-Draft@ietf.org [mailto:Internet-Draft@ietf.org]
Sent: Monday, July 14, 2008 6:00 PM
To: Sun, Dong (Dong); draft-sun-dime-itu-t-rw@tools.ietf.org;
Hannes.Tschofenig@gmx.net; dromasca@avaya.com
Subject: New Version Notification - draft-sun-dime-itu-t-rw-01.txt

New version (-01) has been submitted for draft-sun-dime-itu-t-rw-01.txt.
http://www.ietf.org/internet-drafts/draft-sun-dime-itu-t-rw-01.txt
Sub state has been changed to AD Follow up from New Id Needed

IETF Secretariat.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--Boundary_(ID_Qd0MPR9AqPZF7bdlbQA2bg)-- --===============0126774012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0126774012==-- From dime-bounces@ietf.org Tue Jul 15 01:19:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147E03A6976; Tue, 15 Jul 2008 01:19:32 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DE23A6976 for ; Tue, 15 Jul 2008 01:19:31 -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 VNwae-ernHKZ for ; Tue, 15 Jul 2008 01:19:27 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5220E3A6893 for ; Tue, 15 Jul 2008 01:19:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2E9F9C8046 for ; Tue, 15 Jul 2008 04:19:47 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22686-11 for ; Tue, 15 Jul 2008 04:19:46 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 15 Jul 2008 04:19:46 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jul 2008 04:19:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 13:49:42 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C05FDC4D0@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conflicting statements in RFC3588 and RFC3539 on Device-Watchdog Timeout. Thread-Index: AcjmU4ho3b+H+DHmS5KigI9ak0EzPw== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 15 Jul 2008 08:19:46.0640 (UTC) FILETIME=[8ADBE500:01C8E653] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: "Ranjan Rath, Rashmi" , "Krishnamoorthy, Balachandar" Subject: [Dime] Conflicting statements in RFC3588 and RFC3539 on Device-Watchdog Timeout. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0280196996==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0280196996== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E653.88A4EFDA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E653.88A4EFDA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 RFC3588 says in Section 5.1 that: =20 2. Three watchdog messages are exchanged with accepted round trip times, and the connection to the peer is considered stabilized. =20 RFC3539 says in Section 3.4.1 [3] that: =20 Note that where traffic is heavy, the application layer watchdog can take as long as 2Tw to determine that a peer has gone down. For peers receiving a high volume of AAA Requests, AAA Responses will continually reset the timer, so that after a failure it will take Tw for the lack of traffic to be noticed, and for the watchdog message to be sent. Another Tw will elapse before failover is initiated. =20 Which one should be taken into consideration while implementing Device-Watchdog Timeout? =20 Please help me to come out of this issue. =20 Thanks in advance, Avinash Gowda =20 ------_=_NextPart_001_01C8E653.88A4EFDA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

RFC3588 says in Section 5.1 = that:

 

2. Three watchdog messages are exchanged with accepted = round trip times, and the connection to the peer is considered = stabilized.

 

RFC3539 says in Section 3.4.1 [3] = that:

 

Note that where traffic is heavy, the application = layer watchdog can take as long as 2Tw to determine that a peer has gone = down. For peers receiving a high volume of AAA Requests, AAA Responses will = continually reset the timer, so that after a failure it will take Tw for the lack of traffic to be noticed, and for the watchdog message to be sent. Another = Tw will elapse before failover is initiated.

 

Which one should be taken into consideration while implementing Device-Watchdog Timeout?

 

Please help me to come out of this = issue.

 

Thanks in advance,

Avinash Gowda

 

------_=_NextPart_001_01C8E653.88A4EFDA-- --===============0280196996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0280196996==-- From dime-bounces@ietf.org Tue Jul 15 04:01:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8133A6991; Tue, 15 Jul 2008 04:01:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28EA93A6991 for ; Tue, 15 Jul 2008 04:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 iyaKOnfKm-MU for ; Tue, 15 Jul 2008 04:01:29 -0700 (PDT) Received: from web1110.biz.mail.sk1.yahoo.com (web1110.biz.mail.sk1.yahoo.com [74.6.114.42]) by core3.amsl.com (Postfix) with SMTP id 2C6CF3A6992 for ; Tue, 15 Jul 2008 04:01:03 -0700 (PDT) Received: (qmail 5310 invoked by uid 60001); 15 Jul 2008 11:01:30 -0000 X-YMail-OSG: XgrLwSMVM1mfeA0haSgy5Xe4AV2u.scrlz21D0u9gZFiPp2mv6YrzPSapiXm0eCjUg-- Received: from [202.144.125.181] by web1110.biz.mail.sk1.yahoo.com via HTTP; Tue, 15 Jul 2008 12:01:30 BST Date: Tue, 15 Jul 2008 12:01:30 +0100 (BST) From: Jaya Kumar Satri To: dime@ietf.org MIME-Version: 1.0 Message-ID: <310517.1511.qm@web1110.biz.mail.sk1.yahoo.com> Subject: [Dime] DCCA mailing list/ Discussion forum X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0046979081==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0046979081== Content-Type: multipart/alternative; boundary="0-528301256-1216119690=:1511" Content-Transfer-Encoding: 8bit --0-528301256-1216119690=:1511 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, Can anybody let me know if there is any mailing list/ Discussion forum for diameter credit control Application? Thanks & Regds., Jaya Kumar. --0-528301256-1216119690=:1511 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,
     Can anybody let me know if there is any mailing list/ Discussion forum for diameter credit control Application?
 
Thanks & Regds.,
Jaya Kumar.
--0-528301256-1216119690=:1511-- --===============0046979081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0046979081==-- From dime-bounces@ietf.org Tue Jul 15 10:30:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD3C3A6A37; Tue, 15 Jul 2008 10:30:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5183A6A37 for ; Tue, 15 Jul 2008 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 QJwbH+Hfij5m for ; Tue, 15 Jul 2008 10:30:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 98BD23A6931 for ; Tue, 15 Jul 2008 10:30:44 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 17:31:11 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp019) with SMTP; 15 Jul 2008 19:31:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/cDdEIin/c7Wzd6fOsacQyxsECRbVQxLc+n3UO6D GJNdgt/bL5fKch Message-ID: <487CDEDF.3060903@gmx.net> Date: Tue, 15 Jul 2008 20:31:11 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jaya Kumar Satri References: <310517.1511.qm@web1110.biz.mail.sk1.yahoo.com> In-Reply-To: <310517.1511.qm@web1110.biz.mail.sk1.yahoo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.76 Cc: dime@ietf.org Subject: Re: [Dime] DCCA mailing list/ Discussion forum X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We also discuss Diameter applications, including DCCA, in this mailing list. Ciao Hannes Jaya Kumar Satri wrote: > Hi, > Can anybody let me know if there is any mailing list/ Discussion > forum for diameter credit control Application? > > Thanks & Regds., > Jaya Kumar. > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:29:23 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F9B3A6B64; Tue, 15 Jul 2008 11:29:23 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065043A6B41 for ; Tue, 15 Jul 2008 11:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS51DRnzas15 for ; Tue, 15 Jul 2008 11:29:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C4AB23A6B64 for ; Tue, 15 Jul 2008 11:29:20 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:29:47 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp048) with SMTP; 15 Jul 2008 20:29:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/IEKYCdkXIrCqD5f2maeEZzYd9SnnXQA+g3BEnAh GMuAL7VnYAM/Vk Message-ID: <487CEC9C.4070306@gmx.net> Date: Tue, 15 Jul 2008 21:29:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Subject: [Dime] Rechartering: draft-sarikaya-dime-prefix-delegation-ps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-sarikaya-dime-prefix-delegation-ps-01.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:29:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 237733A6B64; Tue, 15 Jul 2008 11:29:33 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37053A6B64 for ; Tue, 15 Jul 2008 11:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Ib1768LHlkAI for ; Tue, 15 Jul 2008 11:29:31 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5CE123A6B41 for ; Tue, 15 Jul 2008 11:29:31 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:29:58 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp042) with SMTP; 15 Jul 2008 20:29:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18vBvo6PWEvMk8QqTcarpuIYJZVSv1zQt5VkQdQoE e2De9a3ixj6HPb Message-ID: <487CECA7.2020402@gmx.net> Date: Tue, 15 Jul 2008 21:29:59 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Subject: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:29:39 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABB928C12E; Tue, 15 Jul 2008 11:29:39 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D4F28C129 for ; Tue, 15 Jul 2008 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 hYs4isSGgoPF for ; Tue, 15 Jul 2008 11:29:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 573CF28C116 for ; Tue, 15 Jul 2008 11:29:37 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:30:04 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp040) with SMTP; 15 Jul 2008 20:30:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hQVlle80hNcYcop/AHKcXB95yPIfikmlYZyegsw 7ZqTWDEACCLLZS Message-ID: <487CECAD.9080101@gmx.net> Date: Tue, 15 Jul 2008 21:30:05 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: subashtc@cisco.com, Glen Subject: [Dime] Rechartering: draft-zorn-dime-diameter-cc-appl-mib X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/html/draft-zorn-dime-diameter-cc-appl-mib-03.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:29:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7314128C129; Tue, 15 Jul 2008 11:29:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B2928C114 for ; Tue, 15 Jul 2008 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 5Dl0gx3a6gRj for ; Tue, 15 Jul 2008 11:29:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 47EA728C116 for ; Tue, 15 Jul 2008 11:29:45 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:30:12 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp033) with SMTP; 15 Jul 2008 20:30:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PlX1II7MPOebJXipbKtU/K+4xbzVJ8HQPih5uZD YR5tlsGTfNBUKd Message-ID: <487CECB5.6050501@gmx.net> Date: Tue, 15 Jul 2008 21:30:13 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Cc: gwz@arubanetworks.com, subashtc@cisco.com Subject: [Dime] Rechartering: draft-zorn-dime-diameter-base-protocol-mib X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-zorn-dime-diameter-base-protocol-mib-03.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:31:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3493A68F4; Tue, 15 Jul 2008 11:31:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4D63A68E8 for ; Tue, 15 Jul 2008 11:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 mw2t9I8zg+6b for ; Tue, 15 Jul 2008 11:31:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 53F353A68C2 for ; Tue, 15 Jul 2008 11:31:14 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:31:38 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp008) with SMTP; 15 Jul 2008 20:31:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NF2hS8RdNY6UBKCCYwRN5c6fIoSVWhyFQ23EO7G 6pF6V7qt7HeuX+ Message-ID: <487CED0B.90103@gmx.net> Date: Tue, 15 Jul 2008 21:31:39 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: "julien.bournelle@orange-ftgroup.com" , riechsalz@gmail.com Subject: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help but supports it? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:31:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045BB3A68F4; Tue, 15 Jul 2008 11:31:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341BE3A68F4 for ; Tue, 15 Jul 2008 11:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 lx-eKNjbqX2e for ; Tue, 15 Jul 2008 11:31:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E61173A68E8 for ; Tue, 15 Jul 2008 11:31:27 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:31:55 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp058) with SMTP; 15 Jul 2008 20:31:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+mRxs19p+m61b/QhZDIvVeFOJ7pdjVXxIxmrCZ3d yl1U6FIFuZU1m8 Message-ID: <487CED1C.9050201@gmx.net> Date: Tue, 15 Jul 2008 21:31:56 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Subject: [Dime] Rechartering: draft-korhonen-dime-nai-routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-00.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help but supports it? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:32:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BBD3A6A37; Tue, 15 Jul 2008 11:32:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546D73A6A37 for ; Tue, 15 Jul 2008 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 JxhW1ysC8VYF for ; Tue, 15 Jul 2008 11:32:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 333D83A68E8 for ; Tue, 15 Jul 2008 11:32:06 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:32:32 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp067) with SMTP; 15 Jul 2008 20:32:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SRaFPH+bSfc7JcXm+wOIwjTTvRyXAu/qOmHkCh/ XG/LsWZHZEUk07 Message-ID: <487CED41.5020709@gmx.net> Date: Tue, 15 Jul 2008 21:32:33 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Cc: Lakshminath Dondeti Subject: [Dime] Rechartering: draft-dondeti-dime-erp-diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-dondeti-dime-erp-diameter-02.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help but supports it? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:36:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B50E3A68C2; Tue, 15 Jul 2008 11:36:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80FF3A68C2 for ; Tue, 15 Jul 2008 11:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 ut1Rc1oYvELE for ; Tue, 15 Jul 2008 11:36:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B44093A67CF for ; Tue, 15 Jul 2008 11:36:33 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:30:20 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp026) with SMTP; 15 Jul 2008 20:30:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197cQxIgFV7vfpzXAguOvFyDKAO23oXv+M1uhI6Uk G4d4G5lC1rnfjM Message-ID: <487CECBD.2050108@gmx.net> Date: Tue, 15 Jul 2008 21:30:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Cc: Patrick Stupar , subir@research.telcordia.com Subject: [Dime] Rechartering: draft-stupar-dime-mos-options X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-stupar-dime-mos-options-00.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 11:36:40 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416333A6AB9; Tue, 15 Jul 2008 11:36:40 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E263A6AFC for ; Tue, 15 Jul 2008 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 WUn+xZnwszhs for ; Tue, 15 Jul 2008 11:36:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8DF523A6A37 for ; Tue, 15 Jul 2008 11:36:38 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2008 18:30:26 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp023) with SMTP; 15 Jul 2008 20:30:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/wJwFWCQXwP5QtgdCVYnTcJmRNIXA/eu6rE2NVk4 1p65/f+763luF0 Message-ID: <487CECC3.2020509@gmx.net> Date: Tue, 15 Jul 2008 21:30:27 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Dime] Rechartering: draft-neumann-dime-webauth X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://tools.ietf.org/id/draft-neumann-dime-webauth-00.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 12:39:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D037F3A68F4; Tue, 15 Jul 2008 12:39:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1863A68F4 for ; Tue, 15 Jul 2008 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.589 X-Spam-Level: X-Spam-Status: No, score=-6.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAaCHsZjbIli for ; Tue, 15 Jul 2008 12:39:41 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C2D7B3A689F for ; Tue, 15 Jul 2008 12:39:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6FJe3B16380; Tue, 15 Jul 2008 19:40:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Jul 2008 14:39:02 -0500 Message-ID: In-Reply-To: <487CED0B.90103@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering: draft-korhonen-dime-pmip6 thread-index: AcjmqQf/zUWoVmwNQKmW4tKzGMftiwACScbQ References: <487CED0B.90103@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , Cc: julien.bournelle@orange-ftgroup.com Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Please see inline. Regards, Ahmad > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, July 15, 2008 1:32 PM > To: dime@ietf.org > Cc: jouni.korhonen@teliasonera.com; > julien.bournelle@orange-ftgroup.com; Muhanna, Ahmad > (RICH1:2H10); Chowdhury, Kuntal; riechsalz@gmail.com > Subject: Rechartering: draft-korhonen-dime-pmip6 > > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the > draft by co-authoring it? [Ahmad] YES. > > * Who is able to provide reviews? [Ahmad] Yes. > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or > with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. > By "finished" I mean "ready for WGLC".) > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 12:49:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C20728C149; Tue, 15 Jul 2008 12:49:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04BB3A687F for ; Tue, 15 Jul 2008 12:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeHdopu8Lz+N for ; Tue, 15 Jul 2008 12:49:48 -0700 (PDT) Received: from web84311.mail.re1.yahoo.com (web84311.mail.re1.yahoo.com [69.147.74.190]) by core3.amsl.com (Postfix) with SMTP id BF9E53A6AEE for ; Tue, 15 Jul 2008 12:49:47 -0700 (PDT) Received: (qmail 61629 invoked by uid 60001); 15 Jul 2008 19:50:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=UTsO6L09lGXYFYwx5PhY+FBcb8+LVglzNNgegVpcdsRZDuoYd1/z7AiKKAH5xcq8XDOyhLYudhUdy47UbQj4p412ZQ99mxBa/lrj7dLNjuFoz6CzrtRHBWk/oNoOE4vJWeY+l94AjFEr08b7TZKEQweGQBSM0nlmFrY4i3TeAYU=; Received: from [72.164.184.70] by web84311.mail.re1.yahoo.com via HTTP; Tue, 15 Jul 2008 12:50:15 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 15 Jul 2008 12:50:15 -0700 (PDT) From: Behcet Sarikaya To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <488797.58116.qm@web84311.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dime-prefix-delegation-ps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1292094963==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1292094963== Content-Type: multipart/alternative; boundary="0-489487785-1216151415=:58116" --0-489487785-1216151415=:58116 Content-Type: text/plain; charset=us-ascii Hi Hannes, This draft (draft-sarikaya-dime-prefix-delegation-ps-01.txt) has been revised and the new draft (draft-sarikaya-dimeradext-prefix-auth-ps-00.txt) was submitted as new version draft due to title change. So there is no need to have a rechartering item on this draft-sarikaya-dime-prefix-delegation-ps-01.txt draft. Regards, Behcet ----- Original Message ---- From: Hannes Tschofenig To: dime@ietf.org Cc: Behcet Sarikaya ; xiayangsong@huawei.com; "jouni.korhonen@teliasonera.com" Sent: Tuesday, July 15, 2008 1:29:48 PM Subject: Rechartering: draft-sarikaya-dime-prefix-delegation-ps Document: http://tools.ietf.org/id/draft-sarikaya-dime-prefix-delegation-ps-01.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) --0-489487785-1216151415=:58116 Content-Type: text/html; charset=us-ascii
Hi Hannes,
  This draft (draft-sarikaya-dime-prefix-delegation-ps-01.txt) has been revised and the new draft (draft-sarikaya-dimeradext-prefix-auth-ps-00.txt) was submitted as new version draft due to title change.
  So there is no need to have a rechartering item on this draft-sarikaya-dime-prefix-delegation-ps-01.txt draft.

Regards,

Behcet

----- Original Message ----
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: dime@ietf.org
Cc: Behcet Sarikaya <sarikaya@ieee.org>; xiayangsong@huawei.com; "jouni.korhonen@teliasonera.com" <jouni.korhonen@teliasonera.com>
Sent: Tuesday, July 15, 2008 1:29:48 PM
Subject: Rechartering: draft-sarikaya-dime-prefix-delegation-ps

Document:
http://tools.ietf.org/id/draft-sarikaya-dime-prefix-delegation-ps-01.txt

* Who is able to be editor of the document?

* Who is interested to help the editor with the work on the draft by
co-authoring it?

* Who is able to provide reviews?

* Who is unable to actively help with a specific document but supports
the work?

* Are there concerns regarding this document?

* Is there a dependency with another IETF working group or with another SDO?

* How long will it take to finish this document?
(A rough guess based on the current status of the document. By
"finished" I mean "ready for WGLC".)

--0-489487785-1216151415=:58116-- --===============1292094963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1292094963==-- From dime-bounces@ietf.org Tue Jul 15 13:44:01 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF2628C12F; Tue, 15 Jul 2008 13:44:01 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF1D28C12F for ; Tue, 15 Jul 2008 13:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edHkOwAFkp7N for ; Tue, 15 Jul 2008 13:43:59 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 13EB228C110 for ; Tue, 15 Jul 2008 13:43:59 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id qEAb1Z07C0vp7WLA6LkTr8; Tue, 15 Jul 2008 20:44:27 +0000 Received: from gwzPC ([72.164.184.70]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id qLjw1Z0071XZ4wg8RLkDTl; Tue, 15 Jul 2008 20:44:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=dsFOWZiooFQA:10 a=lONrmplabjwA:10 a=48vgC7mUAAAA:8 a=qsQZ8A9aGd5NprttWqsA:9 a=UtIh9vJFkgKc8tbY_Euryf9N77kA:4 a=lZB815dzVvQA:10 a=MxZ3bB5I4kYA:10 From: "Glen Zorn" To: "'Hannes Tschofenig'" , References: <487CECAD.9080101@gmx.net> In-Reply-To: <487CECAD.9080101@gmx.net> Date: Tue, 15 Jul 2008 14:43:11 -0600 Message-ID: <009f01c8e6bb$6d594960$480bdc20$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjmqM98zcj6CEdeT+KUhPoeaC0k2AAEiHxg Content-Language: en-us Cc: 'Glen' , subashtc@cisco.com Subject: Re: [Dime] Rechartering: draft-zorn-dime-diameter-cc-appl-mib X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > Document: > http://tools.ietf.org/html/draft-zorn-dime-diameter-cc-appl-mib-03.txt > > * Who is able to be editor of the document? I don't understand the question. If there is no editor, how does the document exist? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help with a specific document but supports > the work? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) If this & the other MIBs were actually WG items, I would probably be a bit more enthusiastic about working on these things... > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 16:08:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDD503A6B5B; Tue, 15 Jul 2008 16:08:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77C13A6B27 for ; Tue, 15 Jul 2008 16:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERbcaNJ3oIk5 for ; Tue, 15 Jul 2008 16:08:43 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.234]) by core3.amsl.com (Postfix) with ESMTP id 2BA3228C339 for ; Tue, 15 Jul 2008 16:07:37 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so5018002wra.17 for ; Tue, 15 Jul 2008 16:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=cXOTaeUDu9KQzArYMtU0nepSEV95TZW74VQKfbTO7k8=; b=qAOtzWxYJg1b5qNZqQsiR3NPUvGbiFFfZh+BtmS/HB5H0q37hhxzrAe1QJgOCkce6v Qmeg6u2Sl3DNj022EWUVquaF6xknLVFcyTiDTGC3tSueuiGBEnNQtXufxi7EqfLHj1ft zByhdq+hOg3OCYzogZhaQx80b8dOqy00xPdCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=QjVAod1yxvZd5KomaLMtjb/wqmS+PDL5a0Zq4nBBPEQ85vPxk1feVLsE/uPXimcXDB 7jKCa5L+Fvx5zyCXZ33c9qMuGMDGQ+hk2fgnHHO5f3nPby/q1TiibEPSP3O60a/vz6KK ZNOA/firjcXeDu1YcRpgYom1i9Xu1HcspglxE= Received: by 10.90.50.5 with SMTP id x5mr514879agx.62.1216163282194; Tue, 15 Jul 2008 16:08:02 -0700 (PDT) Received: by 10.90.65.17 with HTTP; Tue, 15 Jul 2008 16:08:02 -0700 (PDT) Message-ID: <9cf5ced20807151608s39d67eb7sb59b9860cc8bb7c6@mail.gmail.com> Date: Tue, 15 Jul 2008 19:08:02 -0400 From: "David Frascone" To: "Romascanu, Dan (Dan)" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 49c3f12550dbfffd Cc: dime@ietf.org Subject: Re: [Dime] AD review of draft-ietf-dime-diameter-api X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1615948195==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1615948195== Content-Type: multipart/alternative; boundary="----=_Part_13615_29599437.1216163282191" ------=_Part_13615_29599437.1216163282191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have generated a new draft, at http://dave.frascone.com/files/public/draft-ietf-diameter-api-07.txt It is being reviewed, and I will submit it after the reviews are completed. -Dave On Mon, Jun 16, 2008 at 9:11 AM, Romascanu, Dan (Dan) wrote: > Please find below the AD review of draft-ietf-dime-diameter-api. I have > divided the comments into Technical and Editorial. > > Although the document has reached a certain level of maturity it looks > like another I-D would be needed before we can go to IETF Last Call. I > suggest to address in the revised I-D also comments from other > reviewers, I have seen comments from Sebastien Decugis, there may be > other. > > Thanks and Regards, > > Dan > > Technical Comments > > T1. Section 1 - using the term 'standardized API' is not appropriate. > The WG charter speaks about 'An informational RFC on a Diameter API' and > the document itself targets Informational. It looks like the document > should not claim that the API described here is the 'standardized' API. > > T2. The typedef enum in Section 3.1.12 is copied twice, and never closes > - missing probably } AAAReturnCodes; > > T3. The data types in Section 3.1.14 do not correspond with the data > types defined in Section 4.2 of RFC3588 (missing Unsigned32, Unsigned64, > Float32, Float64) > > T4. The list of result codes returned from remote servers in Section > 3.1.18 does not seem to match anything from RFC3588. I am looking at > Section 7.1. Do I need to look into some other place? > > > Editorial Comments > > E1 Section 3.1.7 has the wrong title - it should probably be 'Server > Identifier' or 'Serving Peer Identifier' > > E2 - section 3.1.12 - > > AAA_ERR_NOMEM: This code is returned if the operation caused memory to > be exhausted. > > In reality it is not necessarily this operation that caused memory to be > exhausted. I believe that a more accurate description would be 'The code > is returned if there is no enough memory to execute the operation'. > > E3 - section 3.1.20 seems to have borrowed text from 3.1.19. It would > also benefit from a short explanation of each field > > E4 - The descriptions of the various functions in section 3.4 are > inconsistent in mentioning when fields refer to pointers (sometimes they > do , sometimes the do not) > > E5 - Section 3.7, pag. 40 - in the first paragraph, third sentence the > word 'directly' appears twice > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------=_Part_13615_29599437.1216163282191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I have generated a new draft, at http://dave.frascone.com/files/public/draft-ietf-diameter-api-07.txt

It is being reviewed, and I will submit it after the reviews are completed.

-Dave

On Mon, Jun 16, 2008 at 9:11 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
Please find below the AD review of draft-ietf-dime-diameter-api. I have
divided the comments into Technical and Editorial.

Although the document has reached a certain level of maturity it looks
like another I-D would be needed before we can go to IETF Last Call. I
suggest to address in the revised I-D also comments from other
reviewers, I have seen comments from Sebastien Decugis, there may be
other.

Thanks and Regards,

Dan

Technical Comments

T1. Section 1 - using the term 'standardized API' is not appropriate.
The WG charter speaks about 'An informational RFC on a Diameter API' and
the document itself targets Informational. It looks like the document
should not claim that the API described here is the 'standardized' API.

T2. The typedef enum in Section 3.1.12 is copied twice, and never closes
- missing probably } AAAReturnCodes;

T3. The data types in Section 3.1.14 do not correspond with the data
types defined in Section 4.2 of RFC3588 (missing Unsigned32, Unsigned64,
Float32, Float64)

T4. The list of result codes returned from remote servers in Section
3.1.18 does not seem to match anything from RFC3588. I am looking at
Section 7.1. Do I need to look into some other place?


Editorial Comments

E1 Section 3.1.7 has the wrong title - it should probably be 'Server
Identifier' or 'Serving Peer Identifier'

E2 - section 3.1.12 -

AAA_ERR_NOMEM:  This code is returned if the operation caused memory to
be exhausted.

In reality it is not necessarily this operation that caused memory to be
exhausted. I believe that a more accurate description would be 'The code
is returned if there is no enough memory to execute the operation'.

E3 - section 3.1.20 seems to have borrowed text from 3.1.19. It would
also benefit from a short explanation of each field

E4 - The descriptions of the various functions in section 3.4 are
inconsistent in mentioning when fields refer to pointers (sometimes they
do , sometimes the do not)

E5 - Section 3.7, pag. 40 - in the first paragraph, third sentence the
word 'directly' appears twice







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

------=_Part_13615_29599437.1216163282191-- --===============1615948195== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1615948195==-- From dime-bounces@ietf.org Tue Jul 15 18:10:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE593A6885; Tue, 15 Jul 2008 18:10:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF263A6885 for ; Tue, 15 Jul 2008 18:10: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 iU2LpAbShtvx for ; Tue, 15 Jul 2008 18:10:11 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id F0EBA3A67E2 for ; Tue, 15 Jul 2008 18:10:10 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m36so1702292rnd.18 for ; Tue, 15 Jul 2008 18:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Duu5aUIPyoJJvfvNQ6a4gUnM/JM/43yI6ggRqkg+cVw=; b=Pn/tFzT5Wt1IL2AZriZp8/qp2bTLlf1HsVVY8khLrz43i28ndW5HFKix106GpZY2aa dOzfX6JcTeWSBx3LX6fQalva8foquxIAtUI7kZpUlX989mT7t6/hUX1vXQVUbSa1E3Yz WHVAt4blx2SaYyrXAB+T0feKsLMdcaX8hmmY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NvSINu/OZyCuqmAbIUxtp3Ok31ES6hVdUv7jksZF/DoqUPNip1WllNUg4ikaYH2VgR hh3G1g5tE/DDE3J8HP+7yteocai8d6gkF0XwXiLjaibUySuBMoytEM1P9WXxiTnm+7ue umy9paWrGrj285ea9uQPa7SveSMUknEzhhFXY= Received: by 10.142.186.9 with SMTP id j9mr4893370wff.348.1216170638751; Tue, 15 Jul 2008 18:10:38 -0700 (PDT) Received: by 10.142.141.12 with HTTP; Tue, 15 Jul 2008 18:10:38 -0700 (PDT) Message-ID: Date: Tue, 15 Jul 2008 18:10:38 -0700 From: "Vijay Devarapalli" To: "Hannes Tschofenig" In-Reply-To: <487CED0B.90103@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487CED0B.90103@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I can review this document. Vijay On Tue, Jul 15, 2008 at 11:31 AM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 15 19:17:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1193A6908; Tue, 15 Jul 2008 19:17:32 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0F13A6908 for ; Tue, 15 Jul 2008 19:17:31 -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 vO7YkOzZOzNH for ; Tue, 15 Jul 2008 19:17:31 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BC2BC3A680C for ; Tue, 15 Jul 2008 19:17:30 -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 <0K42004C1U53T3@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Jul 2008 10:12:39 +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 <0K4200G2JU53EI@szxga03-in.huawei.com> for dime@ietf.org; Wed, 16 Jul 2008 10:12:39 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4200LAXU5342@szxml04-in.huawei.com> for dime@ietf.org; Wed, 16 Jul 2008 10:12:39 +0800 (CST) Date: Wed, 16 Jul 2008 10:12:39 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <009a01c8e6e9$6c3c2ab0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] draft-tsou-dime-capabilities-update-problem-statement X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2075200353==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2075200353== Content-type: multipart/alternative; boundary="Boundary_(ID_N7BYCEbavcLfcjb9aolmFg)" This is a multi-part message in MIME format. --Boundary_(ID_N7BYCEbavcLfcjb9aolmFg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Comments are welcome:-) It was submitted after -00 deadline, so I am not expected to be discussed in Dublin. However, your comments are very welcome;-) B. R. Tina Filename: draft-tsou-dime-capabilities-update-problem-statement Version: 00 Staging URL: http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt Title: Capabilities Update Problem Statement Creation_date: 2008-07-15 WG ID: Indvidual Submission Number_of_pages: 17 Abstract: This specification clarifies "Capabilities Update" in OPEN state defined in RFC 3588bis. Capabilities update in OPEN state can reuse commands CER/CEA commands for re-negotiation between Diameter peers when one of them changes its capabilities.It is a very important function in Diameter. However, RFC 3588 has defined a mechanism of containing capabilities list both in CER and CEA commands and the peer should update its local database whenever it receives CER/CEA. This makes the process complex and redundant when they are used in OPEN state. So this draft proposes a simpler solution based on CER/CEA commands to deal with this problem. --Boundary_(ID_N7BYCEbavcLfcjb9aolmFg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Comments are welcome:-)
It was submitted after -00 deadline, so = I am not=20 expected to be discussed in Dublin.
However, your comments are very=20 welcome;-)
 
B. R.
Tina

Filename:   =20 draft-tsou-dime-capabilities-update-problem-statement
Version: =   =20 00
Staging URL:    http://www3.ietf.org/proceedings/st= aging/draft-tsou-dime-capabilities-update-problem-statement-00.txtTitle:=20    Capabilities Update Problem Statement
Creation_date:=20    2008-07-15
WG ID:    Indvidual=20 Submission
Number_of_pages: 17
Abstract:
This specification = clarifies=20 "Capabilities Update" in OPEN state
defined in RFC 3588bis. =20 Capabilities update in OPEN state can reuse
commands CER/CEA commands = for=20 re-negotiation between Diameter peers
when one of them changes its=20 capabilities.It is a very important
function in = Diameter.

However, RFC=20 3588 has defined a mechanism of containing capabilities
list both in = CER and=20 CEA commands and the peer should update its
local database whenever = it=20 receives CER/CEA.  This makes the process
complex and redundant = when=20 they are used in OPEN state.  So this
draft proposes a simpler = solution=20 based on CER/CEA commands to deal
with this=20 problem.




--Boundary_(ID_N7BYCEbavcLfcjb9aolmFg)-- --===============2075200353== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2075200353==-- From dime-bounces@ietf.org Tue Jul 15 20:05:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7F13A6935; Tue, 15 Jul 2008 20:05:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183D53A691B for ; Tue, 15 Jul 2008 20:05:16 -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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] 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 0JW2fbyzh2s1 for ; Tue, 15 Jul 2008 20:05:15 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 273EB3A67D4 for ; Tue, 15 Jul 2008 20:05:15 -0700 (PDT) Received: from c-69-255-78-171.hsd1.md.comcast.net ([69.255.78.171]:49373 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KIxKm-0007NF-W2; Wed, 16 Jul 2008 03:05:41 +0000 Message-Id: <33E99E79-C03B-4C12-AE3A-E9ED7AF0DD00@g11.org.uk> From: ken carlberg To: Hannes Tschofenig In-Reply-To: <487CED0B.90103@gmx.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 23:05:38 -0400 References: <487CED0B.90103@gmx.net> X-Mailer: Apple Mail (2.926) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: dime@ietf.org, "julien.bournelle@orange-ftgroup.com" Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes, I think it would be more constructive to not send a "form" letter on all of these drafts, but rather sit down and bring up specific points. As an example, in your second question below, you ask who is willing to co-author the draft? Well, this particular draft has 5 co- authors already. Are you seriously asking for more? If anything, it would be nice to see the extent by which co-authors can be trimmed with the hopes that others will speak up from an outside perspective. (and please note, I have absolutely nothing against the current author list of the korhonen draft!!!...I'm just speaking in general terms) cheers, -ken On Jul 15, 2008, at 2:31 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with > another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:13:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3D128C1A5; Wed, 16 Jul 2008 01:13:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5C03A689C for ; Wed, 16 Jul 2008 01:13:50 -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 Qr8B5dAHE4go for ; Wed, 16 Jul 2008 01:13:49 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 7B96C3A6881 for ; Wed, 16 Jul 2008 01:13:49 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so128129and.122 for ; Wed, 16 Jul 2008 01:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BFU+Eo5xg29v+0V+5UclT2in3mXVGcRUeZwF7z2SB4w=; b=LfzH00Kk5OxC9TH2i6QO/WlvI1E62zRIjOwYFAiplhaWI7NQdKizY/qqEGTQZchnHZ L7P6Ub/xGwf/TnHEyJ10pDwq38QrZfKsEcbJWKfb39qEdDtPOKaXeFkCdENjwayVEaJF sB1ZB6UIV3sS6g5j5v0tKYcbSmrNMvNU1nAcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HmLDw+yCkFsWkhxNi34/Id8vGaMtg8SwbeXmlZ8ZvsR08FpfiPP6uzBm6DjaR5IU9D vBWcD4iRdsIEuPF7REEKXJFEsUjNAy0EseJuTiaFtIqirISjVYShQ717WCw2H2UU9FuS 4E4zSR59V1g+yn6hKcUDYJfnpc4JTRG1KP5r8= Received: by 10.100.251.5 with SMTP id y5mr1412371anh.125.1216196055368; Wed, 16 Jul 2008 01:14:15 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Wed, 16 Jul 2008 01:14:15 -0700 (PDT) Message-ID: <5e2406980807160114t13d41487v9342db007fe65a6e@mail.gmail.com> Date: Wed, 16 Jul 2008 10:14:15 +0200 From: "Julien Bournelle" To: "Hannes Tschofenig" In-Reply-To: <487CECA7.2020402@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487CECA7.2020402@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig wrote: > Document: > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help with a specific document but supports the > work? > > * Are there concerns regarding this document? As I said previously in the ML. I'm not convinced by this I-D. Basically I don't see the need for a specific Diameter Application for Prefix Delegation. Julien > > * Is there a dependency with another IETF working group or with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:14:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CD5D3A6978; Wed, 16 Jul 2008 01:14:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC533A689C for ; Wed, 16 Jul 2008 01:14:15 -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 7AO1rJmLz-UT for ; Wed, 16 Jul 2008 01:14:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 249D13A67F8 for ; Wed, 16 Jul 2008 01:14:13 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2008 08:14:42 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp026) with SMTP; 16 Jul 2008 10:14:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HwuQ6+dvHIn/bWO2koggO/sDWxa3phymqjZ1wIp x213F2SgE1MtUZ Message-ID: <487DADF1.60508@gmx.net> Date: Wed, 16 Jul 2008 11:14:41 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Subject: [Dime] Rechartering: draft-asveren-dime-cong-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Document: http://www.ietf.org/internet-drafts/draft-asveren-dime-cong-03.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help but supports it? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:14:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A433A6B28; Wed, 16 Jul 2008 01:14:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2DD3A6B28 for ; Wed, 16 Jul 2008 01:14:55 -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 1BfSBRk1xnYU for ; Wed, 16 Jul 2008 01:14:54 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id B77813A6881 for ; Wed, 16 Jul 2008 01:14:54 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so128299and.122 for ; Wed, 16 Jul 2008 01:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hicXG4a4jgOpvVTeDRCDKeea2EvqlNssXJIiMF29djo=; b=xhlv9m+XZwiqf7d958P4vPd0sRaeCt2078mVKd8UKZ9Qfl+vtSHwq1XuWnL7YqQPK7 c5kmNOpG7zQrq9WoBY1sF0uVfAyjfMkaFB3avPrFn15aDY9O7pEQpIuVS+5zxo2llE4T fDfmcMLBhp007KWuwtU9nLNbbRUW88NVmR0AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=f+wcEqfuReV2w3cgYcrYp+xjOi2R54p4mk+MeW8UXdH/ZT3Ys2qyMjr64UBiLbLZVU nMAwxIDFzvGpeQ3aiDDsSsGP9eyVLuzn26huEWRxAmwmeHFlcHxyeoVmLWPVxB8PI3HB AE0+lKz6cbUEnHmw5H9g0KSLltDCQjpBi/tAI= Received: by 10.100.7.1 with SMTP id 1mr615921ang.99.1216196121250; Wed, 16 Jul 2008 01:15:21 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Wed, 16 Jul 2008 01:15:21 -0700 (PDT) Message-ID: <5e2406980807160115v5afffa10y42ef3fded308524@mail.gmail.com> Date: Wed, 16 Jul 2008 10:15:21 +0200 From: "Julien Bournelle" To: "Hannes Tschofenig" In-Reply-To: <487CECB5.6050501@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487CECB5.6050501@gmx.net> Cc: gwz@arubanetworks.com, dime@ietf.org, subashtc@cisco.com Subject: Re: [Dime] Rechartering: draft-zorn-dime-diameter-base-protocol-mib X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Tue, Jul 15, 2008 at 8:30 PM, Hannes Tschofenig wrote: > Document: > http://tools.ietf.org/id/draft-zorn-dime-diameter-base-protocol-mib-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help with a specific document but supports the > work? I'm not a MIB expert so I can't review it but I think we need this document as a WG item. Julien > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:19:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894D13A6B74; Wed, 16 Jul 2008 01:19:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494423A6B74 for ; Wed, 16 Jul 2008 01:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ3gXXfFuQoe for ; Wed, 16 Jul 2008 01:19:19 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by core3.amsl.com (Postfix) with ESMTP id 581BC3A6B6A for ; Wed, 16 Jul 2008 01:19:19 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so5173090wra.17 for ; Wed, 16 Jul 2008 01:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fv2hY5i5go8Sn9B/ipQnGk/fnSg2vERAmulx+gjHwes=; b=arK+Jg2vpJM0msG9pCFEGs+PQsIAHlFsbG+aKtBN0npuHY/Dkx7anv0LGhZpy2YWPw J97r/4dhfPrz1ddbNRwctoAjcQ9Dmm0N8g3x+A0tb5Oni5iGYBv+pgDF8o3WZj9NiLz2 27aTL6CHJ5XFCiHGikD8Q++yDMoGYgHjL68LA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=DTTeglNfrSlZAXa99TaXaO9dKYpeOeFwdFVDjLQ7Yqk5hoN5aTwRkS4c9WVF3W8Gni /b3ZsBV2oaNFDbyiTUT0IczRaTbcnKZ85u7k8BS0wqC62fyJJjmiqLV5dQFpBqpPjaG8 7LuUjAvZglfoJ40nu1Ecju83KsfEzVtgAwkYw= Received: by 10.100.228.13 with SMTP id a13mr1459172anh.70.1216196385716; Wed, 16 Jul 2008 01:19:45 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Wed, 16 Jul 2008 01:19:45 -0700 (PDT) Message-ID: <5e2406980807160119g31b48b7bocb1fdffdc3ee7a35@mail.gmail.com> Date: Wed, 16 Jul 2008 10:19:45 +0200 From: "Julien Bournelle" To: "Hannes Tschofenig" In-Reply-To: <487CED0B.90103@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487CED0B.90103@gmx.net> Cc: dime@ietf.org, "julien.bournelle@orange-ftgroup.com" Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Tue, Jul 15, 2008 at 8:31 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? I think Jouni is a perfect editor for this document :) > > * Who is interested to help the editor with the work on the draft by > co-authoring it? I'm still interested in co-authoring this document and help Jouni on it. > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another SDO? This document is referenced in some 3GPP TS document (e.g. 3GPP TS 29.273). > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) I think this document is closed to a WGLC. Regards, Julien > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:20:58 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445D63A6B26; Wed, 16 Jul 2008 01:20:58 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97643A68E6 for ; Wed, 16 Jul 2008 01:20:56 -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 glWFx1WRhAKQ for ; Wed, 16 Jul 2008 01:20:56 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id E2F333A6B26 for ; Wed, 16 Jul 2008 01:20:55 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so129163and.122 for ; Wed, 16 Jul 2008 01:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7XLuHUAk66omrHiBxz/l500Uun0zeK2daJeK+TP2JSI=; b=OXVhjA1+A8phJWi6Xu2UOpzKa4UZbZY7bcNMPrcdQgohFzM0BbXkER9Tk8GQv0jICf ZITibcM35WobEiTvDqkruDNV8XkKhxBct02I1jAeVKOru92q3uKKm4NCi/LcTzCQZqI0 RU4SLjdz6wyRx/oKlU+yEIB2IpNm0VRA6lTSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HoONdPFJnBSjsXFxwFPZKpkZ5HFUjkb/oi1GeJituOEVsbhyjAWfNb8Ud/EblziKOs ZvD/T+Ce0qMR54/ArXlJ/G1O85O2JdGhyqmfgg+n0KGBfqhkAWIzWo3EFRpe25OnKbY6 +IHIIWQlrpi7oyTs2PlpSMfCJ1b+hE+7KVUGU= Received: by 10.101.67.11 with SMTP id u11mr1430611ank.118.1216196483219; Wed, 16 Jul 2008 01:21:23 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Wed, 16 Jul 2008 01:21:23 -0700 (PDT) Message-ID: <5e2406980807160121n3052c205xc9c752369ab6f033@mail.gmail.com> Date: Wed, 16 Jul 2008 10:21:23 +0200 From: "Julien Bournelle" To: "Hannes Tschofenig" In-Reply-To: <487CED41.5020709@gmx.net> MIME-Version: 1.0 Content-Disposition: inline References: <487CED41.5020709@gmx.net> Cc: Lakshminath Dondeti , dime@ietf.org Subject: Re: [Dime] Rechartering: draft-dondeti-dime-erp-diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi, On Tue, Jul 15, 2008 at 8:32 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-dondeti-dime-erp-diameter-02.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? I'm interested in helping the editor with this document. > * Who is able to provide reviews? I can provide reviews. Regards, Julien > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 01:25:54 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E79228C1CF; Wed, 16 Jul 2008 01:25:54 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B8C28C1B9 for ; Wed, 16 Jul 2008 01:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, GB_I_LETTER=-2] 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 Zd8ccwyXRjaF for ; Wed, 16 Jul 2008 01:25:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BC5FA28C1C7 for ; Wed, 16 Jul 2008 01:25:51 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2008 08:26:20 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp032) with SMTP; 16 Jul 2008 10:26:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+cJQIme2GceaBzdfcLRi1OJ1v8qJtG897FVSQ9te S7HG+neXfPqZ6i Message-ID: <487DB0AB.6090705@gmx.net> Date: Wed, 16 Jul 2008 11:26:19 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ken carlberg References: <487CED0B.90103@gmx.net> <33E99E79-C03B-4C12-AE3A-E9ED7AF0DD00@g11.org.uk> In-Reply-To: <33E99E79-C03B-4C12-AE3A-E9ED7AF0DD00@g11.org.uk> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: dime@ietf.org, "julien.bournelle@orange-ftgroup.com" Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Ken, my questions aim to figure out the level of commitment people are willing to give. I believe that there is a difference between willing to be the editor, work on the document as a co-author and comitting todo reviews. Btw, there is even no requirement for the current draft authors to be also authors of the WG document. I can give you examples where the main authors were removed from the draft when the document become a working group item. I also noticed that some of the draft authors (in general) haven't been particular active in the group. Ciao Hannes ken carlberg wrote: > Hannes, > > I think it would be more constructive to not send a "form" letter on > all of these drafts, but rather sit down and bring up specific > points. As an example, in your second question below, you ask who is > willing to co-author the draft? Well, this particular draft has 5 > co-authors already. Are you seriously asking for more? If anything, > it would be nice to see the extent by which co-authors can be trimmed > with the hopes that others will speak up from an outside perspective. > (and please note, I have absolutely nothing against the current author > list of the korhonen draft!!!...I'm just speaking in general terms) > > cheers, > > -ken > > > On Jul 15, 2008, at 2:31 PM, Hannes Tschofenig wrote: > >> Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt >> >> * Who is able to be editor of the document? >> >> * Who is interested to help the editor with the work on the draft by >> co-authoring it? >> >> * Who is able to provide reviews? >> >> * Who is unable to actively help but supports it? >> >> * Are there concerns regarding this document? >> >> * Is there a dependency with another IETF working group or with >> another SDO? >> >> * How long will it take to finish this document? >> (A rough guess based on the current status of the document. By >> "finished" I mean "ready for WGLC".) >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 02:52:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678FF3A6A53; Wed, 16 Jul 2008 02:52:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F37C3A6A53 for ; Wed, 16 Jul 2008 02:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, 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 oTgh6stPPdQA for ; Wed, 16 Jul 2008 02:52:42 -0700 (PDT) Received: from web1101.biz.mail.sk1.yahoo.com (web1101.biz.mail.sk1.yahoo.com [74.6.114.33]) by core3.amsl.com (Postfix) with SMTP id 233DE3A6995 for ; Wed, 16 Jul 2008 02:52:42 -0700 (PDT) Received: (qmail 39323 invoked by uid 60001); 16 Jul 2008 09:53:11 -0000 X-YMail-OSG: IGzW1AgVM1msWc8fZVLnsdthAIi7HDnZdXzqAuq_l7NcLET7ilqHCGxYvTCwEABvqexbx0xKnlY6O4lSXJ0dMFGyA7klVy8OCaw8gg-- Received: from [202.144.125.181] by web1101.biz.mail.sk1.yahoo.com via HTTP; Wed, 16 Jul 2008 10:53:11 BST Date: Wed, 16 Jul 2008 10:53:11 +0100 (BST) From: Jaya Kumar Satri To: dime@ietf.org MIME-Version: 1.0 Message-ID: <206912.36811.qm@web1101.biz.mail.sk1.yahoo.com> Subject: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1384905679==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1384905679== Content-Type: multipart/alternative; boundary="0-1014365027-1216201991=:36811" Content-Transfer-Encoding: 8bit --0-1014365027-1216201991=:36811 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user. 2) If in the initial CCR, these AVPs are absent. The behaviour of the CC application is not specifed. 3) Had those AVPs been Mandatory, the resultcode 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what should be done. How should Application behave in this scenario? Thanks & Regds., Jaya Kumar. --0-1014365027-1216201991=:36811 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,
    
1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user.
 
2) If in the initial CCR, these AVPs are absent. The behaviour of the CC application is not specifed.
 
3) Had those AVPs been Mandatory, the resultcode 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what should be done.
 
How should Application behave in this scenario?
 
Thanks & Regds.,
Jaya Kumar.
--0-1014365027-1216201991=:36811-- --===============1384905679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1384905679==-- From dime-bounces@ietf.org Wed Jul 16 02:59:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA273A6B78; Wed, 16 Jul 2008 02:59:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0AB3A6B88 for ; Wed, 16 Jul 2008 02:59:19 -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 tBh-5ZRrMRMH for ; Wed, 16 Jul 2008 02:59:18 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id A28E53A6B78 for ; Wed, 16 Jul 2008 02:59:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 646DC90032 for ; Wed, 16 Jul 2008 05:59:44 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23544-12 for ; Wed, 16 Jul 2008 05:59:43 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 05:59:43 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 05:59:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 15:29:39 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C05FDC5AA@exchindia3.starentnetworks.com> In-Reply-To: <206912.36811.qm@web1101.biz.mail.sk1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Thread-Index: AcjnKcq2EE6Mz9wtRryQv6zfPXE48QAAKdWQ References: <206912.36811.qm@web1101.biz.mail.sk1.yahoo.com> From: "Gowda, Avinash" To: "Jaya Kumar Satri" , X-OriginalArrivalTime: 16 Jul 2008 09:59:43.0749 (UTC) FILETIME=[ABD3DB50:01C8E72A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1710504538==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1710504538== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E72A.A9A7D32B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E72A.A9A7D32B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jaya Kumar, =20 Please refer RFC3588 Section 9.5. This may answer your question. =20 Even I am new to RFC4006. So this is just an attempt to discuss the things. =20 Thanks, Avinash Gowda ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jaya Kumar Satri Sent: Wednesday, July 16, 2008 3:23 PM To: dime@ietf.org Subject: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR =20 Hi, =20 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user. =20 2) If in the initial CCR, these AVPs are absent. The behaviour of the CC application is not specifed. =20 3) Had those AVPs been Mandatory, the resultcode 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what should be done. =20 How should Application behave in this scenario? =20 Thanks & Regds., Jaya Kumar. ------_=_NextPart_001_01C8E72A.A9A7D32B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jaya = Kumar,

 

Please refer RFC3588 Section 9.5. = This may answer your question.

 

Even I am new to RFC4006. So this = is just an attempt to discuss the things.

 

Thanks,

Avinash = Gowda

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jaya Kumar Satri
Sent: Wednesday, July 16, = 2008 3:23 PM
To: dime@ietf.org
Subject: [Dime] Absence = of User-Name/ Subscription-Id AVP in the Initial = CCR

 

Hi,

    

1) The AVPs 'User-Name' and 'Subscription-Id' are optional = AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user.

 

2) If in the initial CCR, these AVPs are absent. The behaviour = of the CC application is not specifed.

 

3) Had those AVPs been Mandatory, the resultcode = 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what = should be done.

 

How should Application behave in this = scenario?

 

Thanks & Regds.,

Jaya Kumar.

------_=_NextPart_001_01C8E72A.A9A7D32B-- --===============1710504538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1710504538==-- From dime-bounces@ietf.org Wed Jul 16 03:08:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EAFE3A6970; Wed, 16 Jul 2008 03:08:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1A728C1B9 for ; Wed, 16 Jul 2008 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 wqnRObCokM10 for ; Wed, 16 Jul 2008 03:08:41 -0700 (PDT) Received: from web1101.biz.mail.sk1.yahoo.com (web1101.biz.mail.sk1.yahoo.com [74.6.114.33]) by core3.amsl.com (Postfix) with SMTP id 5A0503A679C for ; Wed, 16 Jul 2008 03:08:41 -0700 (PDT) Received: (qmail 52620 invoked by uid 60001); 16 Jul 2008 10:09:10 -0000 X-YMail-OSG: 5YnMTmkVM1kx5OwYaieAlhxQPI_qNdp5gluXnQly Received: from [202.144.125.181] by web1101.biz.mail.sk1.yahoo.com via HTTP; Wed, 16 Jul 2008 11:09:10 BST Date: Wed, 16 Jul 2008 11:09:10 +0100 (BST) From: Jaya Kumar Satri To: "Gowda, Avinash" , dime@ietf.org In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C05FDC5AA$0001@exchindia3.starentnetworks.com> MIME-Version: 1.0 Message-ID: <778254.52189.qm@web1101.biz.mail.sk1.yahoo.com> Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0276208682==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0276208682== Content-Type: multipart/alternative; boundary="0-1700134028-1216202950=:52189" Content-Transfer-Encoding: 8bit --0-1700134028-1216202950=:52189 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Avinash, Thanks for the reply, but it does not answer my question. Thanks & Regds., Jaya Kumar. "Gowda, Avinash" wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} shape {behavior:url(#default#VML);} Hi Jaya Kumar, Please refer RFC3588 Section 9.5. This may answer your question. Even I am new to RFC4006. So this is just an attempt to discuss the things. Thanks, Avinash Gowda --------------------------------- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jaya Kumar Satri Sent: Wednesday, July 16, 2008 3:23 PM To: dime@ietf.org Subject: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Hi, 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user. 2) If in the initial CCR, these AVPs are absent. The behaviour of the CC application is not specifed. 3) Had those AVPs been Mandatory, the resultcode 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what should be done. How should Application behave in this scenario? Thanks & Regds., Jaya Kumar. "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." --0-1700134028-1216202950=:52189 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Avinash,
                 Thanks for the reply, but it does not answer my question.
Thanks & Regds.,
Jaya Kumar.

"Gowda, Avinash" <agowda@starentnetworks.com> wrote:
Hi Jaya Kumar,
 
Please refer RFC3588 Section 9.5. This may answer your question.
 
Even I am new to RFC4006. So this is just an attempt to discuss the things.
 
Thanks,
Avinash Gowda
From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jaya Kumar Satri
Sent: Wednesday, July 16, 2008 3:23 PM
To: dime@ietf.org
Subject: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR
 
Hi,
    
1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs according to the ABNF of CCR in rfc 4006. These are the AVPs required to identify the end user.
 
2) If in the initial CCR, these AVPs are absent. The behaviour of the CC application is not specifed.
 
3) Had those AVPs been Mandatory, the resultcode 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as those are optional, what should be done.
 
How should Application behave in this scenario?
 
Thanks & Regds.,
Jaya Kumar.
"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

--0-1700134028-1216202950=:52189-- --===============0276208682== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0276208682==-- From dime-bounces@ietf.org Wed Jul 16 03:17:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D453B3A6846; Wed, 16 Jul 2008 03:17:55 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07B93A6846 for ; Wed, 16 Jul 2008 03:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 sJPSIH65URFg for ; Wed, 16 Jul 2008 03:17:53 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 99A933A67F8 for ; Wed, 16 Jul 2008 03:17:52 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2008 10:18:20 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp025) with SMTP; 16 Jul 2008 12:18:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181erN+u/A1XhLm2JrdyHPHUc+VThxnpUq9tPqH+e pq9NmzXZEMtYpO Message-ID: <487DCAEB.2090408@gmx.net> Date: Wed, 16 Jul 2008 13:18:19 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Jaya Kumar Satri References: <778254.52189.qm@web1101.biz.mail.sk1.yahoo.com> In-Reply-To: <778254.52189.qm@web1101.biz.mail.sk1.yahoo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jaya, a briefly look at RFC 4006 and searched for Subscription-Id AVP. This AVP is optional in the ABNF but it has the M-bit set, see Section 8 of RFC 4006. Optional in the ABNF just means that the sender can decide whether it wants to place it in there. This makes a lot of sense if you actually have 2 options like here, namely Subscription-Id and User-Name. However, the M-bit indicates what is mandatory to understand for the receiving side (with respect to a specific Command in a specific Diameter application). The ABNF has some limits in describing options, I agree, and a protocol designer does not want to describe every combination as a separate Command. As such, when the Diameter client sents nothing then the Diameter server will be puzzled and return an error message. I would have to read through the text carefully to find text indicating that some form of user identification has to be provided. Ciao Hannes Jaya Kumar Satri wrote: > Hi Avinash, > Thanks for the reply, but it does not answer my question. > Thanks & Regds., > Jaya Kumar. > > */"Gowda, Avinash" /* wrote: > > Hi Jaya Kumar, > > Please refer RFC3588 Section 9.5. This may answer your question. > > Even I am new to RFC4006. So this is just an attempt to discuss > the things. > > Thanks, > Avinash Gowda > ------------------------------------------------------------------------ > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On > Behalf Of *Jaya Kumar Satri > *Sent:* Wednesday, July 16, 2008 3:23 PM > *To:* dime@ietf.org > *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the > Initial CCR > > Hi, > > 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs > according to the ABNF of CCR in rfc 4006. These are the AVPs > required to identify the end user. > > 2) If in the initial CCR, these AVPs are absent. The behaviour of > the CC application is not specifed. > > 3) Had those AVPs been Mandatory, the resultcode > 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as > those are optional, what should be done. > > How should Application behave in this scenario? > > Thanks & Regds., > Jaya Kumar. > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information transmitted > may not be used to create or change any contractual obligations of > Starent Networks, Corp. Any review, retransmission, dissemination > or other use of, or taking of any action in reliance upon this > e-mail and its attachments by persons or entities other than the > intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to > this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 03:26:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B286628C0F0; Wed, 16 Jul 2008 03:26:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A8C3A6846 for ; Wed, 16 Jul 2008 03:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eOEfoMLTOUM for ; Wed, 16 Jul 2008 03:26:39 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5363F3A679C for ; Wed, 16 Jul 2008 03:26:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 1F74490032 for ; Wed, 16 Jul 2008 06:27:05 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24097-10 for ; Wed, 16 Jul 2008 06:27:00 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 06:27:00 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 06:27:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 15:56:56 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C05FDC5B1@exchindia3.starentnetworks.com> In-Reply-To: <487DCAEB.2090408@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Thread-Index: AcjnLUzwa51K668eSWy2sRFeh76qXgAAF/mw References: <778254.52189.qm@web1101.biz.mail.sk1.yahoo.com> <487DCAEB.2090408@gmx.net> From: "Gowda, Avinash" To: "Hannes Tschofenig" , "Jaya Kumar Satri" X-OriginalArrivalTime: 16 Jul 2008 10:27:00.0352 (UTC) FILETIME=[7B51A800:01C8E72E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Even I have found in RFC4006 Section 9.2 that there is an error code to convey if user is not identified. DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in the credit-control server. I was referring SIP RFC also. In that also they send similar kind of error message for URA message not containing User-Name AVP. (RFC4740 Section 8.2). Thanks, Avinash Gowda -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wednesday, July 16, 2008 3:48 PM To: Jaya Kumar Satri Cc: Gowda, Avinash; dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Hi Jaya, a briefly look at RFC 4006 and searched for Subscription-Id AVP. This AVP is optional in the ABNF but it has the M-bit set, see Section 8 of RFC 4006. Optional in the ABNF just means that the sender can decide whether it wants to place it in there. This makes a lot of sense if you actually have 2 options like here, namely Subscription-Id and User-Name. However, the M-bit indicates what is mandatory to understand for the receiving side (with respect to a specific Command in a specific Diameter application). The ABNF has some limits in describing options, I agree, and a protocol designer does not want to describe every combination as a separate Command. As such, when the Diameter client sents nothing then the Diameter server will be puzzled and return an error message. I would have to read through the text carefully to find text indicating that some form of user identification has to be provided. Ciao Hannes Jaya Kumar Satri wrote: > Hi Avinash, > Thanks for the reply, but it does not answer my question. > Thanks & Regds., > Jaya Kumar. > > */"Gowda, Avinash" /* wrote: > > Hi Jaya Kumar, > > Please refer RFC3588 Section 9.5. This may answer your question. > > Even I am new to RFC4006. So this is just an attempt to discuss > the things. > > Thanks, > Avinash Gowda > ------------------------------------------------------------------------ > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On > Behalf Of *Jaya Kumar Satri > *Sent:* Wednesday, July 16, 2008 3:23 PM > *To:* dime@ietf.org > *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the > Initial CCR > > Hi, > > 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs > according to the ABNF of CCR in rfc 4006. These are the AVPs > required to identify the end user. > > 2) If in the initial CCR, these AVPs are absent. The behaviour of > the CC application is not specifed. > > 3) Had those AVPs been Mandatory, the resultcode > 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as > those are optional, what should be done. > > How should Application behave in this scenario? > > Thanks & Regds., > Jaya Kumar. > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information transmitted > may not be used to create or change any contractual obligations of > Starent Networks, Corp. Any review, retransmission, dissemination > or other use of, or taking of any action in reliance upon this > e-mail and its attachments by persons or entities other than the > intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to > this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 03:44:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995E828C0F0; Wed, 16 Jul 2008 03:44:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC6E3A67F8 for ; Wed, 16 Jul 2008 03:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 HiF0hyLX9kBP for ; Wed, 16 Jul 2008 03:44:50 -0700 (PDT) Received: from web1116.biz.mail.sk1.yahoo.com (web1116.biz.mail.sk1.yahoo.com [74.6.114.48]) by core3.amsl.com (Postfix) with SMTP id B31213A6B78 for ; Wed, 16 Jul 2008 03:44:50 -0700 (PDT) Received: (qmail 32473 invoked by uid 60001); 16 Jul 2008 10:45:19 -0000 X-YMail-OSG: eURKYv0VM1nGbHVcDtCnbpCIge64EQmgDtqUv_e9 Received: from [202.144.125.181] by web1116.biz.mail.sk1.yahoo.com via HTTP; Wed, 16 Jul 2008 11:45:19 BST Date: Wed, 16 Jul 2008 11:45:19 +0100 (BST) From: Jaya Kumar Satri To: Hannes Tschofenig In-Reply-To: <487DCAEB.2090408@gmx.net> MIME-Version: 1.0 Message-ID: <822046.30662.qm@web1116.biz.mail.sk1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660841594==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0660841594== Content-Type: multipart/alternative; boundary="0-1529212933-1216205119=:30662" Content-Transfer-Encoding: 8bit --0-1529212933-1216205119=:30662 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Hannes, I got it. Thank you for your guidance. Thanks & Regds., Jaya Kumar Hannes Tschofenig wrote: Hi Jaya, a briefly look at RFC 4006 and searched for Subscription-Id AVP. This AVP is optional in the ABNF but it has the M-bit set, see Section 8 of RFC 4006. Optional in the ABNF just means that the sender can decide whether it wants to place it in there. This makes a lot of sense if you actually have 2 options like here, namely Subscription-Id and User-Name. However, the M-bit indicates what is mandatory to understand for the receiving side (with respect to a specific Command in a specific Diameter application). The ABNF has some limits in describing options, I agree, and a protocol designer does not want to describe every combination as a separate Command. As such, when the Diameter client sents nothing then the Diameter server will be puzzled and return an error message. I would have to read through the text carefully to find text indicating that some form of user identification has to be provided. Ciao Hannes Jaya Kumar Satri wrote: > Hi Avinash, > Thanks for the reply, but it does not answer my question. > Thanks & Regds., > Jaya Kumar. > > */"Gowda, Avinash" /* wrote: > > Hi Jaya Kumar, > > Please refer RFC3588 Section 9.5. This may answer your question. > > Even I am new to RFC4006. So this is just an attempt to discuss > the things. > > Thanks, > Avinash Gowda > ------------------------------------------------------------------------ > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On > Behalf Of *Jaya Kumar Satri > *Sent:* Wednesday, July 16, 2008 3:23 PM > *To:* dime@ietf.org > *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the > Initial CCR > > Hi, > > 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs > according to the ABNF of CCR in rfc 4006. These are the AVPs > required to identify the end user. > > 2) If in the initial CCR, these AVPs are absent. The behaviour of > the CC application is not specifed. > > 3) Had those AVPs been Mandatory, the resultcode > 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as > those are optional, what should be done. > > How should Application behave in this scenario? > > Thanks & Regds., > Jaya Kumar. > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information transmitted > may not be used to create or change any contractual obligations of > Starent Networks, Corp. Any review, retransmission, dissemination > or other use of, or taking of any action in reliance upon this > e-mail and its attachments by persons or entities other than the > intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to > this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0-1529212933-1216205119=:30662 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Hannes,
                 I got it. Thank you for your guidance.
Thanks & Regds.,
Jaya Kumar
Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi Jaya,

a briefly look at RFC 4006 and searched for Subscription-Id AVP.

This AVP is optional in the ABNF but it has the M-bit set, see Section 8
of RFC 4006.

Optional in the ABNF just means that the sender can decide whether it
wants to place it in there. This makes a lot of sense if you actually
have 2 options like here, namely Subscription-Id and User-Name.

However, the M-bit indicates what is mandatory to understand for the
receiving side (with respect to a specific Command in a specific
Diameter application).

The ABNF has some limits in describing options, I agree, and a protocol
designer does not want to describe every combination as a separate
Command. As such, when the Diameter client sents nothing then the
Diameter server will be puzzled and return an error message. I would
have to read through the text carefully to find text indicating that
some form of user identification has to be provided.

Ciao
Hannes


Jaya Kumar Satri wrote:
> Hi Avinash,
> Thanks for the reply, but it does not answer my question.
> Thanks & Regds.,
> Jaya Kumar.
>
> */"Gowda, Avinash" /* wrote:
>
> Hi Jaya Kumar,
>
> Please refer RFC3588 Section 9.5. This may answer your question.
>
> Even I am new to RFC4006. So this is just an attempt to discuss
> the things.
>
> Thanks,
> Avinash Gowda
> ------------------------------------------------------------------------
> *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On
> Behalf Of *Jaya Kumar Satri
> *Sent:* Wednesday, July 16, 2008 3:23 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the
> Initial CCR
>
> Hi,
>
> 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs
> according to the ABNF of CCR in rfc 4006. These are the AVPs
> required to identify the end user.
>
> 2) If in the initial CCR, these AVPs are absent. The behaviour of
> the CC application is not specifed.
>
> 3) Had those AVPs been Mandatory, the resultcode
> 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as
> those are optional, what should be done.
>
> How should Application behave in this scenario?
>
> Thanks & Regds.,
> Jaya Kumar.
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information transmitted
> may not be used to create or change any contractual obligations of
> Starent Networks, Corp. Any review, retransmission, dissemination
> or other use of, or taking of any action in reliance upon this
> e-mail and its attachments by persons or entities other than the
> intended recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by replying to
> this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of this
> message and any attachments without reading or disclosing their
> contents. Thank you."
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--0-1529212933-1216205119=:30662-- --===============0660841594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0660841594==-- From dime-bounces@ietf.org Wed Jul 16 03:47:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A853A6B78; Wed, 16 Jul 2008 03:47:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125FE3A6963 for ; Wed, 16 Jul 2008 03:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, 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 9MMXiev5jhHu for ; Wed, 16 Jul 2008 03:47:10 -0700 (PDT) Received: from web1101.biz.mail.sk1.yahoo.com (web1101.biz.mail.sk1.yahoo.com [74.6.114.33]) by core3.amsl.com (Postfix) with SMTP id DD7663A6923 for ; Wed, 16 Jul 2008 03:47:10 -0700 (PDT) Received: (qmail 75954 invoked by uid 60001); 16 Jul 2008 10:47:39 -0000 X-YMail-OSG: I2iOlKwVM1kdZSceAPftzPz0E7Puq1oteFg0lH3fAeZycgMx.H3wRZx9vu0vhUSFNLX06w8rEruQnb.aQN8tK5WQqsMCMeFz69ivMWu5qn0gl4RgEWa6V9I7300- Received: from [202.144.125.181] by web1101.biz.mail.sk1.yahoo.com via HTTP; Wed, 16 Jul 2008 11:47:39 BST Date: Wed, 16 Jul 2008 11:47:39 +0100 (BST) From: Jaya Kumar Satri To: "Gowda, Avinash" In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C05FDC5B1$0001@exchindia3.starentnetworks.com> MIME-Version: 1.0 Message-ID: <809440.75538.qm@web1101.biz.mail.sk1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1871822707==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1871822707== Content-Type: multipart/alternative; boundary="0-143358997-1216205259=:75538" Content-Transfer-Encoding: 8bit --0-143358997-1216205259=:75538 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Gowda, If the User-Name is specified and it is not recognised by Server, only then can the resultcode - 'DIAMETER_USER_UNKNOWN' be used. Thanks & Regds., Jaya Kumar "Gowda, Avinash" wrote: Even I have found in RFC4006 Section 9.2 that there is an error code to convey if user is not identified. DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in the credit-control server. I was referring SIP RFC also. In that also they send similar kind of error message for URA message not containing User-Name AVP. (RFC4740 Section 8.2). Thanks, Avinash Gowda -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Wednesday, July 16, 2008 3:48 PM To: Jaya Kumar Satri Cc: Gowda, Avinash; dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Hi Jaya, a briefly look at RFC 4006 and searched for Subscription-Id AVP. This AVP is optional in the ABNF but it has the M-bit set, see Section 8 of RFC 4006. Optional in the ABNF just means that the sender can decide whether it wants to place it in there. This makes a lot of sense if you actually have 2 options like here, namely Subscription-Id and User-Name. However, the M-bit indicates what is mandatory to understand for the receiving side (with respect to a specific Command in a specific Diameter application). The ABNF has some limits in describing options, I agree, and a protocol designer does not want to describe every combination as a separate Command. As such, when the Diameter client sents nothing then the Diameter server will be puzzled and return an error message. I would have to read through the text carefully to find text indicating that some form of user identification has to be provided. Ciao Hannes Jaya Kumar Satri wrote: > Hi Avinash, > Thanks for the reply, but it does not answer my question. > Thanks & Regds., > Jaya Kumar. > > */"Gowda, Avinash" /* wrote: > > Hi Jaya Kumar, > > Please refer RFC3588 Section 9.5. This may answer your question. > > Even I am new to RFC4006. So this is just an attempt to discuss > the things. > > Thanks, > Avinash Gowda > ------------------------------------------------------------------------ > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On > Behalf Of *Jaya Kumar Satri > *Sent:* Wednesday, July 16, 2008 3:23 PM > *To:* dime@ietf.org > *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the > Initial CCR > > Hi, > > 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs > according to the ABNF of CCR in rfc 4006. These are the AVPs > required to identify the end user. > > 2) If in the initial CCR, these AVPs are absent. The behaviour of > the CC application is not specifed. > > 3) Had those AVPs been Mandatory, the resultcode > 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as > those are optional, what should be done. > > How should Application behave in this scenario? > > Thanks & Regds., > Jaya Kumar. > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information transmitted > may not be used to create or change any contractual obligations of > Starent Networks, Corp. Any review, retransmission, dissemination > or other use of, or taking of any action in reliance upon this > e-mail and its attachments by persons or entities other than the > intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to > this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you." > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0-143358997-1216205259=:75538 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Gowda,
                 If the User-Name is specified and it is not recognised by Server, only then can the resultcode - 'DIAMETER_USER_UNKNOWN' be used.
 
Thanks & Regds.,
Jaya Kumar

"Gowda, Avinash" <agowda@starentnetworks.com> wrote:
Even I have found in RFC4006 Section 9.2 that there is an error code to
convey if user is not identified.

DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in the
credit-control server.

I was referring SIP RFC also. In that also they send similar kind of
error message for URA message not containing User-Name AVP. (RFC4740
Section 8.2).

Thanks,
Avinash Gowda

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wednesday, July 16, 2008 3:48 PM
To: Jaya Kumar Satri
Cc: Gowda, Avinash; dime@ietf.org
Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the
Initial CCR

Hi Jaya,

a briefly look at RFC 4006 and searched for Subscription-Id AVP.

This AVP is optional in the ABNF but it has the M-bit set, see Section 8

of RFC 4006.

Optional in the ABNF just means that the sender can decide whether it
wants to place it in there. This makes a lot of sense if you actually
have 2 options like here, namely Subscription-Id and User-Name.

However, the M-bit indicates what is mandatory to understand for the
receiving side (with respect to a specific Command in a specific
Diameter application).

The ABNF has some limits in describing options, I agree, and a protocol
designer does not want to describe every combination as a separate
Command. As such, when the Diameter client sents nothing then the
Diameter server will be puzzled and return an error message. I would
have to read through the text carefully to find text indicating that
some form of user identification has to be provided.

Ciao
Hannes


Jaya Kumar Satri wrote:
> Hi Avinash,
> Thanks for the reply, but it does not answer my
question.
> Thanks & Regds.,
> Jaya Kumar.
>
> */"Gowda, Avinash" /* wrote:
>
> Hi Jaya Kumar,
>
> Please refer RFC3588 Section 9.5. This may answer your question.
>
> Even I am new to RFC4006. So this is just an attempt to discuss
> the things.
>
> Thanks,
> Avinash Gowda
>
------------------------------------------------------------------------
> *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On
> Behalf Of *Jaya Kumar Satri
> *Sent:* Wednesday, July 16, 2008 3:23 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the
> Initial CCR
>
> Hi,
>
> 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs
> according to the ABNF of CCR in rfc 4006. These are the AVPs
> required to identify the end user.
>
> 2) If in the initial CCR, these AVPs are absent. The behaviour of
> the CC application is not specifed.
>
> 3) Had those AVPs been Mandatory, the resultcode
> 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as
> those are optional, what should be done.
>
> How should Application behave in this scenario?
>
> Thanks & Regds.,
> Jaya Kumar.
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information transmitted
> may not be used to create or change any contractual obligations of
> Starent Networks, Corp. Any review, retransmission, dissemination
> or other use of, or taking of any action in reliance upon this
> e-mail and its attachments by persons or entities other than the
> intended recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by replying to
> this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of this
> message and any attachments without reading or disclosing their
> contents. Thank you."
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--0-143358997-1216205259=:75538-- --===============1871822707== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1871822707==-- From dime-bounces@ietf.org Wed Jul 16 04:21:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338F23A6A30; Wed, 16 Jul 2008 04:21:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9298E3A6A30 for ; Wed, 16 Jul 2008 04:21:27 -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=[AWL=-0.000, 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 seAM+6wVszsr for ; Wed, 16 Jul 2008 04:21:26 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id EF7823A69C9 for ; Wed, 16 Jul 2008 04:21:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 05395C8016 for ; Wed, 16 Jul 2008 07:21:52 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25183-12 for ; Wed, 16 Jul 2008 07:21:51 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 07:21:51 -0400 (EDT) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 07:21:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 16:51:46 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C05FDC5CE@exchindia3.starentnetworks.com> In-Reply-To: <809440.75538.qm@web1101.biz.mail.sk1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR Thread-Index: AcjnMWVJJHPsy3jySyKqcWJYWoiSuAAACI/g References: <69FADB84C90B1248A7DE59422771FA0C05FDC5B1$0001@exchindia3.starentnetworks.com> <809440.75538.qm@web1101.biz.mail.sk1.yahoo.com> From: "Gowda, Avinash" To: "Jaya Kumar Satri" X-OriginalArrivalTime: 16 Jul 2008 11:21:51.0040 (UTC) FILETIME=[24B8CC00:01C8E736] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Cc: dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2063480072==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2063480072== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E736.22922311" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E736.22922311 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct. If User-Name is not present and if we are expecting that AVP to be present in the message then this Result-Code sounds good. No other Result-Code matches this scenario in RFC4006. :-) =20 Thanks, Avinash Gowda ________________________________ From: Jaya Kumar Satri [mailto:jayakumar.satri@xaltedcorp.com]=20 Sent: Wednesday, July 16, 2008 4:18 PM To: Gowda, Avinash Cc: dime@ietf.org Subject: RE: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR =20 Hi Gowda,=20 If the User-Name is specified and it is not recognised by Server, only then can the resultcode - 'DIAMETER_USER_UNKNOWN' be used. =20 Thanks & Regds., Jaya Kumar "Gowda, Avinash" wrote: Even I have found in RFC4006 Section 9.2 that there is an error code to convey if user is not identified. =09 DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in the credit-control server. =09 I was referring SIP RFC also. In that also they send similar kind of error message for URA message not containing User-Name AVP. (RFC4740 Section 8.2). =09 Thanks, Avinash Gowda =09 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Wednesday, July 16, 2008 3:48 PM To: Jaya Kumar Satri Cc: Gowda, Avinash; dime@ietf.org Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the Initial CCR =09 Hi Jaya, =09 a briefly look at RFC 4006 and searched for Subscription-Id AVP. =09 This AVP is optional in the ABNF but it has the M-bit set, see Section 8 =09 of RFC 4006. =09 Optional in the ABNF just means that the sender can decide whether it=20 wants to place it in there. This makes a lot of sense if you actually=20 have 2 options like here, namely Subscription-Id and User-Name. =09 However, the M-bit indicates what is mandatory to understand for the=20 receiving side (with respect to a specific Command in a specific Diameter application). =09 The ABNF has some limits in describing options, I agree, and a protocol=20 designer does not want to describe every combination as a separate=20 Command. As such, when the Diameter client sents nothing then the=20 Diameter server will be puzzled and return an error message. I would=20 have to read through the text carefully to find text indicating that=20 some form of user identification has to be provided. =09 Ciao Hannes =09 =09 Jaya Kumar Satri wrote: > Hi Avinash, > Thanks for the reply, but it does not answer my question. > Thanks & Regds., > Jaya Kumar. > > */"Gowda, Avinash" /* wrote: > > Hi Jaya Kumar, >=20 > Please refer RFC3588 Section 9.5. This may answer your question. >=20 > Even I am new to RFC4006. So this is just an attempt to discuss > the things. >=20 > Thanks, > Avinash Gowda > =09 ------------------------------------------------------------------------ > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *On > Behalf Of *Jaya Kumar Satri > *Sent:* Wednesday, July 16, 2008 3:23 PM > *To:* dime@ietf.org > *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in the > Initial CCR >=20 > Hi, >=20 > 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs > according to the ABNF of CCR in rfc 4006. These are the AVPs > required to identify the end user. >=20 > 2) If in the initial CCR, these AVPs are absent. The behaviour of > the CC application is not specifed. >=20 > 3) Had those AVPs been Mandatory, the resultcode > 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But as > those are optional, what should be done. >=20 > How should Application behave in this scenario? >=20 > Thanks & Regds., > Jaya Kumar. > "This email message and any attachments are confidential > information of Starent Networks, Corp. The information transmitted > may not be used to create or change any contractual obligations of > Starent Networks, Corp. Any review, retransmission, dissemination > or other use of, or taking of any action in reliance upon this > e-mail and its attachments by persons or entities other than the > intended recipient is prohibited. If you are not the intended > recipient, please notify the sender immediately -- by replying to > this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this > message and any attachments without reading or disclosing their > contents. Thank you." > > > =09 ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 =20 ------_=_NextPart_001_01C8E736.22922311 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct. If User-Name is not = present and if we are expecting that AVP to be present in the message then this = Result-Code sounds good. No other Result-Code matches this scenario in RFC4006. = J

 

Thanks,

Avinash = Gowda

From: Jaya = Kumar Satri [mailto:jayakumar.satri@xaltedcorp.com]
Sent: Wednesday, July 16, = 2008 4:18 PM
To: Gowda, Avinash
Cc: dime@ietf.org
Subject: RE: [Dime] = Absence of User-Name/ Subscription-Id AVP in the Initial = CCR

 

Hi Gowda,

           = ;      If the User-Name is specified and it is not recognised by Server, only = then can the resultcode - 'DIAMETER_USER_UNKNOWN' be = used.

 

Thanks & Regds.,

Jaya Kumar


"Gowda, Avinash" <agowda@starentnetworks.com> = wrote:

Even I have = found in RFC4006 Section 9.2 that there is an error code to
convey if user is not identified.

DIAMETER_USER_UNKNOWN 5030 - The specified end user is unknown in = the
credit-control server.

I was referring SIP RFC also. In that also they send similar kind of
error message for URA message not containing User-Name AVP. (RFC4740
Section 8.2).

Thanks,
Avinash Gowda

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wednesday, July 16, 2008 3:48 PM
To: Jaya Kumar Satri
Cc: Gowda, Avinash; = dime@ietf.org
Subject: Re: [Dime] Absence of User-Name/ Subscription-Id AVP in the
Initial CCR

Hi Jaya,

a briefly look at RFC 4006 and searched for Subscription-Id AVP.

This AVP is optional in the ABNF but it has the M-bit set, see Section = 8

of RFC 4006.

Optional in the ABNF just means that the sender can decide whether it =
wants to place it in there. This makes a lot of sense if you actually =
have 2 options like here, namely Subscription-Id and User-Name.

However, the M-bit indicates what is mandatory to understand for the =
receiving side (with respect to a specific Command in a specific
Diameter application).

The ABNF has some limits in describing options, I agree, and a protocol =
designer does not want to describe every combination as a separate
Command. As such, when the Diameter client sents nothing then the
Diameter server will be puzzled and return an error message. I would =
have to read through the text carefully to find text indicating that =
some form of user identification has to be provided.

Ciao
Hannes


Jaya Kumar Satri wrote:
> Hi Avinash,
> Thanks for the reply, but it does not answer my
question.
> Thanks & Regds.,
> Jaya Kumar.
>
> */"Gowda, = Avinash" /* wrote:
>
> Hi Jaya Kumar,
>
> Please refer RFC3588 Section 9.5. This may answer your = question.
>
> Even I am new to RFC4006. So this is just an attempt to discuss
> the things.
>
> Thanks,
> Avinash Gowda
>
------------------------------------------------------------------------<= br> > *From:* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] = *On
> Behalf Of *Jaya Kumar Satri
> *Sent:* Wednesday, July 16, 2008 3:23 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Absence of User-Name/ Subscription-Id AVP in = the
> Initial CCR
>
> Hi,
>
> 1) The AVPs 'User-Name' and 'Subscription-Id' are optional AVPs
> according to the ABNF of CCR in rfc 4006. These are the AVPs
> required to identify the end user.
>
> 2) If in the initial CCR, these AVPs are absent. The behaviour = of
> the CC application is not specifed.
>
> 3) Had those AVPs been Mandatory, the resultcode
> 'DIAMETER_MISSING_AVP' can be given in the Answer Message. But = as
> those are optional, what should be done.
>
> How should Application behave in this scenario?
>
> Thanks & Regds.,
> Jaya Kumar.
> "This email message and any attachments are confidential
> information of Starent Networks, Corp. The information = transmitted
> may not be used to create or change any contractual obligations = of
> Starent Networks, Corp. Any review, retransmission, = dissemination
> or other use of, or taking of any action in reliance upon this
> e-mail and its attachments by persons or entities other than = the
> intended recipient is prohibited. If you are not the intended
> recipient, please notify the sender immediately -- by replying = to
> this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of = this
> message and any attachments without reading or disclosing their
> contents. Thank you."
>
>
>
------------------------------------------------------------------------<= br> >
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>

 

------_=_NextPart_001_01C8E736.22922311-- --===============2063480072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2063480072==-- From dime-bounces@ietf.org Wed Jul 16 06:07:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDFD3A6BA6; Wed, 16 Jul 2008 06:07:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB233A6BA6 for ; Wed, 16 Jul 2008 06:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zztkKRa2TGzo for ; Wed, 16 Jul 2008 06:07:04 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id F0D453A6BA1 for ; Wed, 16 Jul 2008 06:07:03 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6GD7UeY026405; Wed, 16 Jul 2008 09:07:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 09:07:29 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012055A1@sonusmail04.sonusnet.com> In-Reply-To: <487DADF1.60508@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering: draft-asveren-dime-cong-03.txt Thread-Index: AcjnHAGEkT+DnXvKRZeoyFRr9V/B4wAJuIcg References: <487DADF1.60508@gmx.net> From: "Asveren, Tolga" To: "Hannes Tschofenig" , Subject: Re: [Dime] Rechartering: draft-asveren-dime-cong-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org inline... Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, July 16, 2008 4:15 AM > To: dime@ietf.org > Cc: Victor Fajardo; Asveren, Tolga > Subject: Rechartering: draft-asveren-dime-cong-03.txt > > Document: http://www.ietf.org/internet-drafts/draft-asveren-dime-cong- > 03.txt > > * Who is able to be editor of the document? [TOLGA] I am. > > * Who is interested to help the editor with the work on the draft by > co-authoring it? [TOLGA] Victor? :-) > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) [TOLGA] With proper input/feedback I think we can have this ready for WGLC around IETF74. Disclaimer: I assume we will follow a "common sense" approach rather than being very "scientific" with lots of simulations etc... > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 06:09:31 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5B53A6BB0; Wed, 16 Jul 2008 06:09:31 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7D13A6B76 for ; Wed, 16 Jul 2008 06:09:30 -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 T4Gcy6ty4vXP for ; Wed, 16 Jul 2008 06:09:29 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.228]) by core3.amsl.com (Postfix) with ESMTP id 980553A67B0 for ; Wed, 16 Jul 2008 06:09:29 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so2699001wxd.31 for ; Wed, 16 Jul 2008 06:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=/Oba8Wc7XCIiNDRw07H9uhTqzaSaM9Srv5AlkU9Lj+c=; b=fNSeO4DBbA7/nEdkLYoxfg0A/61RYfk/w0rfJ5IoBig4+IAZ4+FHp2jYcIXX5d0eYR Il1F9zwRTEz+KuGihDfJkTiVSVapwpwzkAn0BCv3+mHbKHLL9a1yDbLCR33INDVeFIWN XYeHI5kw3hX26twGMH/+qobzxrCxaMbRhzj5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=wQ/S4NdxLow3+105yzMU+jYu4m955en7v1l+mWbHe1l7C0pK6qg3YGGHww5Ogzj/oz IqOspiVnqoj1ahTnnIEws7jPmp+F7WrAFEnxsaZF0gHuWy1CBAvNHiUzz3U2xwHKoe+q y6jcuOwkde8mZyL7J/e+GpGDyH1RDiKolnVug= Received: by 10.100.10.11 with SMTP id 11mr1967951anj.94.1216213796103; Wed, 16 Jul 2008 06:09:56 -0700 (PDT) Received: by 10.100.240.7 with HTTP; Wed, 16 Jul 2008 06:09:56 -0700 (PDT) Message-ID: Date: Wed, 16 Jul 2008 16:09:56 +0300 From: "Gil Shafran" To: "Tina TSOU" In-Reply-To: <009a01c8e6e9$6c3c2ab0$7427460a@china.huawei.com> MIME-Version: 1.0 References: <009a01c8e6e9$6c3c2ab0$7427460a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] draft-tsou-dime-capabilities-update-problem-statement X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160866939==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1160866939== Content-Type: multipart/alternative; boundary="----=_Part_28467_20324018.1216213796097" ------=_Part_28467_20324018.1216213796097 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I think there is a backward compatibility issue with the 'update' CEA defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains some required AVPs of which the M bit must be set (e.g. Vendor-Id, Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct CEA parsing, based on the peer's state, is abit vague. Specially when peer state machine implementations producing equivalent results are considered compliant. Best regards, Gil On Wed, Jul 16, 2008 at 5:12 AM, Tina TSOU wrote: > Comments are welcome:-) > It was submitted after -00 deadline, so I am not expected to be discussed > in Dublin. > However, your comments are very welcome;-) > > B. R. > Tina > > Filename: draft-tsou-dime-capabilities-update-problem-statement > Version: 00 > Staging URL: > http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt > Title: Capabilities Update Problem Statement > Creation_date: 2008-07-15 > WG ID: Indvidual Submission > Number_of_pages: 17 > Abstract: > This specification clarifies "Capabilities Update" in OPEN state > defined in RFC 3588bis. Capabilities update in OPEN state can reuse > commands CER/CEA commands for re-negotiation between Diameter peers > when one of them changes its capabilities.It is a very important > function in Diameter. > > However, RFC 3588 has defined a mechanism of containing capabilities > list both in CER and CEA commands and the peer should update its > local database whenever it receives CER/CEA. This makes the process > complex and redundant when they are used in OPEN state. So this > draft proposes a simpler solution based on CER/CEA commands to deal > with this problem. > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > ------=_Part_28467_20324018.1216213796097 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I think there is a backward compatibility issue with the 'update' CEA defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains some required AVPs of which the M bit must be set (e.g. Vendor-Id, Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct CEA parsing, based on the peer's state, is abit vague. Specially when peer state machine implementations producing equivalent results are considered compliant.

Best regards,
Gil

On Wed, Jul 16, 2008 at 5:12 AM, Tina TSOU <tena@huawei.com> wrote:
Comments are welcome:-)
It was submitted after -00 deadline, so I am not expected to be discussed in Dublin.
However, your comments are very welcome;-)
 
B. R.
Tina

Filename:    draft-tsou-dime-capabilities-update-problem-statement
Version:    00
Staging URL:    http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt
Title:    Capabilities Update Problem Statement
Creation_date:    2008-07-15
WG ID:    Indvidual Submission
Number_of_pages: 17
Abstract:
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis.  Capabilities update in OPEN state can reuse
commands CER/CEA commands for re-negotiation between Diameter peers
when one of them changes its capabilities.It is a very important
function in Diameter.

However, RFC 3588 has defined a mechanism of containing capabilities
list both in CER and CEA commands and the peer should update its
local database whenever it receives CER/CEA.  This makes the process
complex and redundant when they are used in OPEN state.  So this
draft proposes a simpler solution based on CER/CEA commands to deal
with this problem.





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


------=_Part_28467_20324018.1216213796097-- --===============1160866939== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1160866939==-- From dime-bounces@ietf.org Wed Jul 16 06:47:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4FC3A6BA1; Wed, 16 Jul 2008 06:47:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775C83A6B9D for ; Wed, 16 Jul 2008 06:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 Vg8VG2UrJHYM for ; Wed, 16 Jul 2008 06:47:14 -0700 (PDT) Received: from ricky.india.internal.net (unknown [59.145.147.70]) by core3.amsl.com (Postfix) with ESMTP id C99273A6846 for ; Wed, 16 Jul 2008 06:47:13 -0700 (PDT) Received: from YOGESH ([172.16.12.166]) by ricky.india.internal.net (8.12.10/8.12.10) with ESMTP id m6GDmatg024915; Wed, 16 Jul 2008 19:18:40 +0530 Message-Id: <200807161348.m6GDmatg024915@ricky.india.internal.net> From: "Yogesh V. Ranade" To: "'Hannes Tschofenig'" , Date: Wed, 16 Jul 2008 19:20:57 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjnHCvMNq/pezRdQkqV/5e8DNTvigALcyHA In-Reply-To: <487DADF1.60508@gmx.net> X-Cyberoam-Version: 9.5.3.22 X-Cyberoam-smtpxy-version: 0.0.3.0 X-Cyberoam-AV-Status: Clean X-Cyberoam-Proto: SMTP X-Cyberoam-AV-Policy: None X-Cyberoam-AS-Policy: Global Spam Policy Subject: Re: [Dime] Rechartering: draft-asveren-dime-cong-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I am interested in helping the editor by reviewing the document and providing inputs. Regards, Yogesh > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Wednesday, July 16, 2008 1:45 PM > To: dime@ietf.org > Subject: [Dime] Rechartering: draft-asveren-dime-cong-03.txt > > Document: > http://www.ietf.org/internet-drafts/draft-asveren-dime-cong-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or > with another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 08:15:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461FD3A6938; Wed, 16 Jul 2008 08:15:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875AB3A6993 for ; Wed, 16 Jul 2008 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb5hHVXDKSBf for ; Wed, 16 Jul 2008 08:15:25 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 7FB3A3A687D for ; Wed, 16 Jul 2008 08:15:25 -0700 (PDT) Received: (qmail 53556 invoked by uid 60001); 16 Jul 2008 15:15:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ae8T3y5s6HHYD2YsZNdkfROT8tdNw70AVSVPIfuUIRyNpxmIWFO4fYla4othlke1YAXcKAMpKRWPvq0KDanE17k1m8Vzy+/lV/096nTpTh+q8aocbI2muZZaAUSGN+yVNSCWzKG1WyRDPEgd3uOYEk+BQ/WF8gA7wO0v4A13R1E=; Received: from [72.164.184.70] by web84306.mail.re1.yahoo.com via HTTP; Wed, 16 Jul 2008 08:15:54 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Wed, 16 Jul 2008 08:15:54 -0700 (PDT) From: Behcet Sarikaya To: Julien Bournelle , Hannes Tschofenig MIME-Version: 1.0 Message-ID: <447547.52534.qm@web84306.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2138690894==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2138690894== Content-Type: multipart/alternative; boundary="0-228052241-1216221354=:52534" --0-228052241-1216221354=:52534 Content-Type: text/plain; charset=us-ascii Hi Julien, ----- Original Message ---- From: Julien Bournelle To: Hannes Tschofenig Cc: dime@ietf.org Sent: Wednesday, July 16, 2008 3:14:15 AM Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Hi, On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig wrote: > Document: > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help with a specific document but supports the > work? > > * Are there concerns regarding this document? As I said previously in the ML. I'm not convinced by this I-D. Basically I don't see the need for a specific Diameter Application for Prefix Delegation. [behcet] The new draft is about Prefix Authorization. Prefix Authorization is well within AAA domain capabilities. Are you saying no to this? Regards, Behcet --0-228052241-1216221354=:52534 Content-Type: text/html; charset=us-ascii
Hi Julien,

----- Original Message ----
From: Julien Bournelle <julien.bournelle@gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Cc: dime@ietf.org
Sent: Wednesday, July 16, 2008 3:14:15 AM
Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

Hi,

On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig
<Hannes.Tschofenig@gmx.net> wrote:
> Document:
> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>
> * Who is able to be editor of the document?
>
> * Who is interested to help the editor with the work on the draft by
> co-authoring it?
>
> * Who is able to provide reviews?
>
> * Who is unable to actively help with a specific document but supports the
> work?
>
> * Are there concerns regarding this document?

As I said previously in the ML. I'm not convinced by this I-D. Basically
I don't see the need for a specific Diameter Application for Prefix Delegation.

[behcet] The new draft is about Prefix Authorization. Prefix Authorization is well within AAA domain capabilities. Are you saying no to this?

Regards,

Behcet
--0-228052241-1216221354=:52534-- --===============2138690894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2138690894==-- From dime-bounces@ietf.org Wed Jul 16 08:28:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1D328C0E3; Wed, 16 Jul 2008 08:28:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8CC28C0E0 for ; Wed, 16 Jul 2008 08:28:02 -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 3mVrSuFiuxrR for ; Wed, 16 Jul 2008 08:28:01 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 680B53A69E9 for ; Wed, 16 Jul 2008 08:28:01 -0700 (PDT) Received: from [88.114.68.141] (a88-114-68-141.elisa-laajakaista.fi [88.114.68.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 20453139B02; Wed, 16 Jul 2008 18:28:26 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <487CED1C.9050201@gmx.net> References: <487CED1C.9050201@gmx.net> Message-Id: <674D5832-C44C-4BF6-A424-D53CDD93957D@iki.fi> From: Jouni Korhonen Date: Wed, 16 Jul 2008 18:28:26 +0300 To: Hannes Tschofenig , dime@ietf.org X-Mailer: Apple Mail (2.753.1) Subject: Re: [Dime] Rechartering: draft-korhonen-dime-nai-routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Jul 15, 2008, at 9:31 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-nai- > routing-00.txt > > * Who is able to be editor of the document? I am able to take the editor role of this draft. > * Who is interested to help the editor with the work on the draft > by co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with > another SDO? Not direct (as by reference yet) but few SDOs do rely on the functionality described in this I-D. > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) I was hoping to get the material into a stable state by the end of 2008. Cheers, Jouni > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 08:33:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4D128C0DF; Wed, 16 Jul 2008 08:33:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F4E28C104 for ; Wed, 16 Jul 2008 08:33:53 -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 1Hwp3dRzo7zC for ; Wed, 16 Jul 2008 08:33:52 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by core3.amsl.com (Postfix) with ESMTP id 21E9928C0DF for ; Wed, 16 Jul 2008 08:33:52 -0700 (PDT) Received: from [88.114.68.141] (a88-114-68-141.elisa-laajakaista.fi [88.114.68.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 6C8C8216955; Wed, 16 Jul 2008 18:34:15 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <487CED0B.90103@gmx.net> References: <487CED0B.90103@gmx.net> Message-Id: From: Jouni Korhonen Date: Wed, 16 Jul 2008 18:34:15 +0300 To: Hannes Tschofenig , dime@ietf.org, julien.bournelle@orange-ftgroup.com, riechsalz@gmail.com X-Mailer: Apple Mail (2.753.1) Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Jul 15, 2008, at 9:31 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? I can take the editor role. > * Who is interested to help the editor with the work on the draft > by co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with > another SDO? 3GPP Rel-8 has a dependency on this I-D. > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) "must" be completed by the end of 2008 ;) Cheers, Jouni > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 08:38:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E333A680C; Wed, 16 Jul 2008 08:38:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3663A680C for ; Wed, 16 Jul 2008 08:38:45 -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 NpXhs9WrdVP5 for ; Wed, 16 Jul 2008 08:38:45 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id CC4463A67B5 for ; Wed, 16 Jul 2008 08:38:44 -0700 (PDT) Received: from [88.114.68.141] (a88-114-68-141.elisa-laajakaista.fi [88.114.68.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id BFC1B139BA4; Wed, 16 Jul 2008 18:39:03 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <487CECBD.2050108@gmx.net> References: <487CECBD.2050108@gmx.net> Message-Id: From: Jouni Korhonen Date: Wed, 16 Jul 2008 18:39:03 +0300 To: Hannes Tschofenig , dime@ietf.org, Patrick Stupar , subir@research.telcordia.com X-Mailer: Apple Mail (2.753.1) Subject: Re: [Dime] Rechartering: draft-stupar-dime-mos-options X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org On Jul 15, 2008, at 9:30 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-stupar-dime-mos- > options-00.txt > > * Who is able to be editor of the document? I can volunteer.. if no one else wants. > * Who is interested to help the editor with the work on the draft > by co-authoring it? I am. > * Who is able to provide reviews? I am. > * Who is unable to actively help with a specific document but > supports the work? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with > another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 08:43:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC73A3A67B5; Wed, 16 Jul 2008 08:43:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094213A679F for ; Wed, 16 Jul 2008 08:43:16 -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 VAQKxae0MWuE for ; Wed, 16 Jul 2008 08:43:15 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 18A7D3A67B5 for ; Wed, 16 Jul 2008 08:43:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 98C17C8006 for ; Wed, 16 Jul 2008 11:43:41 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31473-16 for ; Wed, 16 Jul 2008 11:43:40 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 16 Jul 2008 11:43:40 -0400 (EDT) Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Jul 2008 11:43:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Jul 2008 11:43:40 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266601512CE8@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Rechartering: draft-korhonen-dime-nai-routing Thread-Index: AcjmqRXeQwswfoNLSOmLuvUZQ4TM8QAsOj3A References: <487CED1C.9050201@gmx.net> From: "Chowdhury, Kuntal" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 16 Jul 2008 15:43:40.0770 (UTC) FILETIME=[B8735C20:01C8E75A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] Rechartering: draft-korhonen-dime-nai-routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Please see inline... -Kuntal > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, July 15, 2008 1:32 PM > To: dime@ietf.org > Subject: [Dime] Rechartering: draft-korhonen-dime-nai-routing > > Document: http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-00.txt > > * Who is able to be editor of the document? > [KC>] Jouni has volunteered for this already. > * Who is interested to help the editor with the work on the draft by > co-authoring it? > [KC>] I am interested in keeping my co-authorship of this document. So, I will work with other co-authors to share the load. > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > [KC>] There is a definite requirement by 3GPP. Other SDOs: WiMAX, 3GPP2 etc. will need this in the very near future (if not already in their IETF dependency list). > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > [KC>] The document should go for WGLC soon. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 08:43:20 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CF028C0FF; Wed, 16 Jul 2008 08:43:20 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83E928C0DF for ; Wed, 16 Jul 2008 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.241, 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 M6sHYqMAPC4m for ; Wed, 16 Jul 2008 08:43:17 -0700 (PDT) Received: from web1105.biz.mail.sk1.yahoo.com (web1105.biz.mail.sk1.yahoo.com [74.6.114.37]) by core3.amsl.com (Postfix) with SMTP id A063D28C0D6 for ; Wed, 16 Jul 2008 08:43:17 -0700 (PDT) Received: (qmail 6862 invoked by uid 60001); 16 Jul 2008 15:43:47 -0000 X-YMail-OSG: vWHZCUAVM1kDfiIsBueEKC24BirimUmREXGf0TxJ Received: from [202.144.125.181] by web1105.biz.mail.sk1.yahoo.com via HTTP; Wed, 16 Jul 2008 16:43:47 BST Date: Wed, 16 Jul 2008 16:43:47 +0100 (BST) From: Jaya Kumar Satri To: Hannes Tschofenig , dime@ietf.org In-Reply-To: <487CECAD.9080101@gmx.net> MIME-Version: 1.0 Message-ID: <342700.1299.qm@web1105.biz.mail.sk1.yahoo.com> Cc: Glen , subashtc@cisco.com Subject: Re: [Dime] Rechartering: draft-zorn-dime-diameter-cc-appl-mib X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1891625276==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1891625276== Content-Type: multipart/alternative; boundary="0-1164607496-1216223027=:1299" Content-Transfer-Encoding: 8bit --0-1164607496-1216223027=:1299 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I am interested in providing reviews. Hannes Tschofenig wrote: Document: http://tools.ietf.org/html/draft-zorn-dime-diameter-cc-appl-mib-03.txt * Who is able to be editor of the document? * Who is interested to help the editor with the work on the draft by co-authoring it? * Who is able to provide reviews? * Who is unable to actively help with a specific document but supports the work? * Are there concerns regarding this document? * Is there a dependency with another IETF working group or with another SDO? * How long will it take to finish this document? (A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".) _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --0-1164607496-1216223027=:1299 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I am interested in providing reviews.

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Document:
http://tools.ietf.org/html/draft-zorn-dime-diameter-cc-appl-mib-03.txt

* Who is able to be editor of the document?

* Who is interested to help the editor with the work on the draft by
co-authoring it?

* Who is able to provide reviews?

* Who is unable to actively help with a specific document but supports
the work?

* Are there concerns regarding this document?

* Is there a dependency with another IETF working group or with another SDO?

* How long will it take to finish this document?
(A rough guess based on the current status of the document. By
"finished" I mean "ready for WGLC".)


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

--0-1164607496-1216223027=:1299-- --===============1891625276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1891625276==-- From dime-bounces@ietf.org Wed Jul 16 08:47:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447E73A6A32; Wed, 16 Jul 2008 08:47:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158113A6A32 for ; Wed, 16 Jul 2008 08:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 XGqLDR4Sh5XS for ; Wed, 16 Jul 2008 08:47:42 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 0F7AF3A6A23 for ; Wed, 16 Jul 2008 08:47:42 -0700 (PDT) Received: from [88.114.68.141] (a88-114-68-141.elisa-laajakaista.fi [88.114.68.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 884E013940E; Wed, 16 Jul 2008 18:48:07 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v753.1) In-Reply-To: <487CED41.5020709@gmx.net> References: <487CED41.5020709@gmx.net> Message-Id: From: Jouni Korhonen Date: Wed, 16 Jul 2008 18:48:07 +0300 To: Hannes Tschofenig , dime@ietf.org, Lakshminath Dondeti X-Mailer: Apple Mail (2.753.1) Subject: Re: [Dime] Rechartering: draft-dondeti-dime-erp-diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I can provide reviews for sure. Cheers, Jouni On Jul 15, 2008, at 9:32 PM, Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-dondeti-dime-erp- > diameter-02.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft > by co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with > another SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 10:52:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C038928C1AF; Wed, 16 Jul 2008 10:52:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CA828C1A9 for ; Wed, 16 Jul 2008 10:52:29 -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 tgTq4K6gsKDI for ; Wed, 16 Jul 2008 10:52:29 -0700 (PDT) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 0FDA028C1A7 for ; Wed, 16 Jul 2008 10:52:29 -0700 (PDT) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Wed, 16 Jul 2008 13:52:54 -0400 From: Mark Jones To: "dime@ietf.org" , ext Hannes Tschofenig Date: Wed, 16 Jul 2008 13:52:53 -0400 Thread-Topic: Rechartering: draft-korhonen-dime-nai-routing Thread-Index: AcjmqRlcIIdEcMiDQ96kxIxWh+QYPAAwXEfg Message-ID: References: <487CED1C.9050201@gmx.net> In-Reply-To: <487CED1C.9050201@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Dime] Rechartering: draft-korhonen-dime-nai-routing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes, Please see my answers inline... > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On BehalfOf > Hannes Tschofenig > Sent: Tuesday, July 15, 2008 1:32 PM > To: dime@ietf.org > Subject: [Dime] Rechartering: draft-korhonen-dime-nai-routing > > Document: http://tools.ietf.org/id/draft-korhonen-dime-nai-routing-00.txt > > * Who is able to be editor of the document? > [mj] Jouni is our man. > * Who is interested to help the editor with the work on the draft by > co-authoring it? > [mj] I've been contributing to earlier versions and have volunteered to co-author. > * Who is able to provide reviews? > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > [mj] 3GPP has the clearest requirement at the moment. I'd expect other SDOs to add dependencies as interfaces from 3GPP to non-3GPP networks are elaborated. > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > [mj] The draft is in good shape now and a WGLC within the next month or two is feasible. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 12:40:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA7A3A6906; Wed, 16 Jul 2008 12:40:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3F73A67F2 for ; Wed, 16 Jul 2008 12:40:55 -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 oe5O3X34b5iU for ; Wed, 16 Jul 2008 12:40:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0CEE83A6906 for ; Wed, 16 Jul 2008 12:40:53 -0700 (PDT) Received: (qmail invoked by alias); 16 Jul 2008 19:41:22 -0000 Received: from p57B250A2.dip.t-dialin.net (EHLO anonymous) [87.178.80.162] by mail.gmx.net (mp052) with SMTP; 16 Jul 2008 21:41:22 +0200 X-Authenticated: #8754011 X-Provags-ID: V01U2FsdGVkX1+ZishpqeWZLhWsQ2xKA0l4zpuoGspVvQu+4tr8Rg +lcx8qeEFuae+e From: "Bibi Blocksberg" To: Date: Wed, 16 Jul 2008 21:41:24 +0200 Message-ID: <000901c8e77b$ee64b470$cb2e1d50$@de> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjnWUWFCoIyk3pbRqKSXzbMTSHbkAAApPhAAAeFtIA= Content-Language: de X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: [Dime] Diameter application for PMIP6 (chargeable-User-ID) question X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, I've one question regarding the draft 'korhonen-dime-pmip6-03.txt' (http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt). If the MAG performs a user-authentication toward the HAAA server, it uses the User-Name AVP to identify the MN. After a successful authentication the HAAA server replies with a Chargeable-User-Identity. My question: Should the MAG use the Chargeable-User-Identity for the PBU and its MN-ID option, or should the MAG use the content of the User-Name AVP as MN-ID option in the PBU? Section 6.2 on page 14 says that the User-Name AVP must contain the MN identity if the LMA sends a Diameter message toward the HAAA server. The value for the User-Name AVP the LMA has extracted from the received PBU (MN-ID option). In my view it isn't clear if the User-Name AVP toward the HAAA server should contain the Chargeable-User-ID AVP content to authorize the PBU, or if the AA-Request and its User-Name AVP contains the NAI, which was initially used to authenticate the MN by the MAG? If the User-Name AVP toward the HAA server contains the Chargeable-User-ID AVP content, then the real identity of the MN can be concealed from the LMA, but the HAAA server is able to identify the real identity of MN, as it has assigned the Chargeable User-ID. I hope, you can provide me with some information on this matter. Thanks you in advance Rafael _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 16:21:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC913A6890; Wed, 16 Jul 2008 16:21:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6848B3A687D for ; Wed, 16 Jul 2008 16:21:36 -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 XOsSUaMM+6hr for ; Wed, 16 Jul 2008 16:21:35 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by core3.amsl.com (Postfix) with ESMTP id 43CBD3A6863 for ; Wed, 16 Jul 2008 16:21:35 -0700 (PDT) Received: from [88.114.68.141] (a88-114-68-141.elisa-laajakaista.fi [88.114.68.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 80FEA13990D; Thu, 17 Jul 2008 02:22:00 +0300 (EEST) In-Reply-To: <000901c8e77b$ee64b470$cb2e1d50$@de> References: <000901c8e77b$ee64b470$cb2e1d50$@de> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Jouni Korhonen Date: Thu, 17 Jul 2008 02:22:00 +0300 To: Bibi Blocksberg X-Mailer: Apple Mail (2.753.1) Cc: dime@ietf.org Subject: Re: [Dime] Diameter application for PMIP6 (chargeable-User-ID) question X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Rafael, On Jul 16, 2008, at 10:41 PM, Bibi Blocksberg wrote: > Hi all, > > I've one question regarding the draft 'korhonen-dime-pmip6-03.txt' > (http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt). > > > If the MAG performs a user-authentication toward the HAAA > server, it uses the User-Name AVP to identify the MN. After a > successful authentication the HAAA server replies with a > Chargeable-User-Identity. > > My question: Should the MAG use the Chargeable-User-Identity > for the PBU and its MN-ID option, or should the MAG use the > content of the User-Name AVP as MN-ID option in the PBU? If the Chargeable-User-Identity is returned then that identity is to be used. > Section 6.2 on page 14 says that the User-Name > AVP must contain the MN identity if the LMA sends a Diameter > message toward the HAAA server. The value for the User-Name > AVP the LMA has extracted from the received PBU (MN-ID option). > > In my view it isn't clear if the User-Name AVP toward the HAAA > server should contain the Chargeable-User-ID AVP content to > authorize the > PBU, or if the AA-Request and its User-Name AVP contains > the NAI, which was initially used to authenticate the MN by the MAG? The sequence is as follows: MN -> MAG: identity1 = some auth method or link specific identity MAG -> HAAA: User-Name = identity1 MAG <- HAAA: may return a new identity2 in Chargeable-user-Id MAG -> LMA: PBU MN-ID = identity2, if available, otherwise PBU MN-ID = identity1 LMA -> HAAA: User-name = identity from PBU MN-ID i.e. may be identity1 or identity2 Hope this clarifies. > If the User-Name AVP toward the HAA server contains the Chargeable- > User-ID > AVP content, then the real identity of the MN can be concealed > from the > LMA, but > the HAAA server is able to identify the real identity of MN, as it > has > assigned the > Chargeable User-ID. Yes. > I hope, you can provide me with some information on this matter. > > Thanks you in advance > > Rafael Cheers, Jouni > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 16 21:29:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0517D3A6ABD; Wed, 16 Jul 2008 21:29:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84743A6ADF for ; Wed, 16 Jul 2008 21:29:48 -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 tUXDo1mlaNl2 for ; Wed, 16 Jul 2008 21:29:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 3C12C3A6844 for ; Wed, 16 Jul 2008 21:29:46 -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 <0K4400BOSKYFFY@szxga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 08:49:27 +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 <0K4400MY1KYFXQ@szxga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 08:49:27 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4400MF1KYFIE@szxml04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 08:49:27 +0800 (CST) Date: Thu, 17 Jul 2008 08:49:27 +0800 From: Tina TSOU To: Gil Shafran Message-id: <003301c8e7a6$f72a21a0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <009a01c8e6e9$6c3c2ab0$7427460a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] draft-tsou-dime-capabilities-update-problem-statement X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0843117769==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0843117769== Content-type: multipart/alternative; boundary="Boundary_(ID_3/la/7ELiAf+4kMauiguHA)" This is a multi-part message in MIME format. --Boundary_(ID_3/la/7ELiAf+4kMauiguHA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Gil, I think you have got a point. Having 2 ABNFs for CEA in 2 state is indeed a vague implementation (I should have thought of that when I proposed it :-( ). It is acceptable for me (& and I live with the redundant work of having to fill the mandatory AVPs of CEA in update scenario). B. R. Tina ----- Original Message ----- From: Gil Shafran To: Tina TSOU Cc: dime@ietf.org Sent: Wednesday, July 16, 2008 9:09 PM Subject: Re: [Dime] draft-tsou-dime-capabilities-update-problem-statement Hi, I think there is a backward compatibility issue with the 'update' CEA defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains some required AVPs of which the M bit must be set (e.g. Vendor-Id, Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct CEA parsing, based on the peer's state, is abit vague. Specially when peer state machine implementations producing equivalent results are considered compliant. Best regards, Gil On Wed, Jul 16, 2008 at 5:12 AM, Tina TSOU wrote: Comments are welcome:-) It was submitted after -00 deadline, so I am not expected to be discussed in Dublin. However, your comments are very welcome;-) B. R. Tina Filename: draft-tsou-dime-capabilities-update-problem-statement Version: 00 Staging URL: http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt Title: Capabilities Update Problem Statement Creation_date: 2008-07-15 WG ID: Indvidual Submission Number_of_pages: 17 Abstract: This specification clarifies "Capabilities Update" in OPEN state defined in RFC 3588bis. Capabilities update in OPEN state can reuse commands CER/CEA commands for re-negotiation between Diameter peers when one of them changes its capabilities.It is a very important function in Diameter. However, RFC 3588 has defined a mechanism of containing capabilities list both in CER and CEA commands and the peer should update its local database whenever it receives CER/CEA. This makes the process complex and redundant when they are used in OPEN state. So this draft proposes a simpler solution based on CER/CEA commands to deal with this problem. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_3/la/7ELiAf+4kMauiguHA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Gil,
I think you have got a point. Having 2 ABNFs for CEA in 2 state is indeed a vague implementation (I should have thought of that when I proposed it :-( ). It is acceptable for me (& and I live with the redundant work of having to fill the mandatory AVPs of CEA in update scenario).
 
B. R.
Tina
----- Original Message -----
Sent: Wednesday, July 16, 2008 9:09 PM
Subject: Re: [Dime] draft-tsou-dime-capabilities-update-problem-statement

Hi,
 
I think there is a backward compatibility issue with the 'update' CEA defintion. The 'original' ABNF definition of the CEA (rfc3588bis) contains some required AVPs of which the M bit must be set (e.g. Vendor-Id, Host-IP-Addr). These are missing from the 'update' CEA. Choosing the correct CEA parsing, based on the peer's state, is abit vague. Specially when peer state machine implementations producing equivalent results are considered compliant.

Best regards,
Gil

On Wed, Jul 16, 2008 at 5:12 AM, Tina TSOU <tena@huawei.com> wrote:
Comments are welcome:-)
It was submitted after -00 deadline, so I am not expected to be discussed in Dublin.
However, your comments are very welcome;-)
 
B. R.
Tina

Filename:    draft-tsou-dime-capabilities-update-problem-statement
Version:    00
Staging URL:    http://www3.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt
Title:    Capabilities Update Problem Statement
Creation_date:    2008-07-15
WG ID:    Indvidual Submission
Number_of_pages: 17
Abstract:
This specification clarifies "Capabilities Update" in OPEN state
defined in RFC 3588bis.  Capabilities update in OPEN state can reuse
commands CER/CEA commands for re-negotiation between Diameter peers
when one of them changes its capabilities.It is a very important
function in Diameter.

However, RFC 3588 has defined a mechanism of containing capabilities
list both in CER and CEA commands and the peer should update its
local database whenever it receives CER/CEA.  This makes the process
complex and redundant when they are used in OPEN state.  So this
draft proposes a simpler solution based on CER/CEA commands to deal
with this problem.





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


--Boundary_(ID_3/la/7ELiAf+4kMauiguHA)-- --===============0843117769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0843117769==-- From dime-bounces@ietf.org Thu Jul 17 01:20:28 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C9C3A6B2F; Thu, 17 Jul 2008 01:20:28 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794713A6B31 for ; Thu, 17 Jul 2008 01:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 AaC-LY7cfwhh for ; Thu, 17 Jul 2008 01:20:25 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 8795A3A6B2F for ; Thu, 17 Jul 2008 01:20:25 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so351451and.122 for ; Thu, 17 Jul 2008 01:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=s3nIyRFOqwBOPYiMFPQ4pL6NR7f5fxcr4c9lDJ32xu8=; b=VEMAKrg5wxSUJW37CKy2blqhso72xSG8rVpyPcuWAO52RLDzxdw7oW9Si1ADRF214+ QUZCyn8B6Y69hfp3gPMkES1dbQt3kDbFozeZWlyWU000rR29XVysjWXop9qNZS8ODn5n pc2ZxAiyWVJsDWhAdDtWNbwfr8Gl9OVY2PjzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MpMfTpjI+j4ZRu/NAhbbYxeXsOJAUNu0nx9DcpBTYvNDP9+64XpOYNyVJRYzmtts1Q bzXkLXBoVrYMJB0GwuZ5FIfRdk81x+06X3OYpxXzIc92dpkSvoZk7ZwQumjMhmFgA2KP 34ymxmSPsSZYps06hD3Z3GHbbn0jjuEdTpfoM= Received: by 10.100.227.6 with SMTP id z6mr7599ang.133.1216282853924; Thu, 17 Jul 2008 01:20:53 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Thu, 17 Jul 2008 01:20:53 -0700 (PDT) Message-ID: <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> Date: Thu, 17 Jul 2008 10:20:53 +0200 From: "Julien Bournelle" To: "Behcet Sarikaya" In-Reply-To: <447547.52534.qm@web84306.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline References: <447547.52534.qm@web84306.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi behcet, On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya wrote: > Hi Julien, > > ----- Original Message ---- > From: Julien Bournelle > To: Hannes Tschofenig > Cc: dime@ietf.org > Sent: Wednesday, July 16, 2008 3:14:15 AM > Subject: Re: [Dime] Rechartering: > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > Hi, > > On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig > wrote: >> Document: >> >> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> >> * Who is able to be editor of the document? >> >> * Who is interested to help the editor with the work on the draft by >> co-authoring it? >> >> * Who is able to provide reviews? >> >> * Who is unable to actively help with a specific document but supports the >> work? >> >> * Are there concerns regarding this document? > > As I said previously in the ML. I'm not convinced by this I-D. Basically > I don't see the need for a specific Diameter Application for Prefix > Delegation. > > [behcet] The new draft is about Prefix Authorization. Prefix Authorization > is well within AAA domain capabilities. Are you saying no to this? I don't want to reenter in this discussion since we already did it :) I'm not convinced by your Problem Statement. We are already able to deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter Application). And I may be wrong but I don't see the need for a specific application for this. Regards, Julien > > Regards, > > Behcet > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 08:01:56 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CED93A686B; Thu, 17 Jul 2008 08:01:56 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2522B3A6914 for ; Thu, 17 Jul 2008 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGAQNtavEmYZ for ; Thu, 17 Jul 2008 08:01:54 -0700 (PDT) Received: from web84314.mail.re1.yahoo.com (web84314.mail.re1.yahoo.com [69.147.74.193]) by core3.amsl.com (Postfix) with SMTP id C32843A68FF for ; Thu, 17 Jul 2008 08:01:53 -0700 (PDT) Received: (qmail 1529 invoked by uid 60001); 17 Jul 2008 15:02:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PQ2X2hyCTav4kUt9xNy/c7NZiYHrgdYCtoN/EFG5LoJaiiEPLxCgCWH2IDlFy/v8CTPbKwdg1fWBgTLtRFb4/nJXaP16PS75qPX49d0RYyGXfHonhHDPqnW3AN32ObyXEc618VTUNTmuxRb0t3M5lW9dmiKO7y0OtVLTfg3/EgM=; Received: from [72.164.184.70] by web84314.mail.re1.yahoo.com via HTTP; Thu, 17 Jul 2008 08:02:24 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Thu, 17 Jul 2008 08:02:24 -0700 (PDT) From: Behcet Sarikaya To: Julien Bournelle MIME-Version: 1.0 Message-ID: <84211.910.qm@web84314.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0724176829==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0724176829== Content-Type: multipart/alternative; boundary="0-696980072-1216306944=:910" --0-696980072-1216306944=:910 Content-Type: text/plain; charset=us-ascii Hi Julien, The current mechanism was defined with a certain architecture in mind. It simply does not apply to so many new cases that have recently emerged all in mobile networks. We need a new application because of this. I would like to explain this in my presentation if I get a slot in Dublin. Regards, Behcet ----- Original Message ---- From: Julien Bournelle To: Behcet Sarikaya Cc: Hannes Tschofenig ; dime@ietf.org Sent: Thursday, July 17, 2008 3:20:53 AM Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Hi behcet, On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya wrote: > Hi Julien, > > ----- Original Message ---- > From: Julien Bournelle > To: Hannes Tschofenig > Cc: dime@ietf.org > Sent: Wednesday, July 16, 2008 3:14:15 AM > Subject: Re: [Dime] Rechartering: > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > Hi, > > On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig > wrote: >> Document: >> >> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> >> * Who is able to be editor of the document? >> >> * Who is interested to help the editor with the work on the draft by >> co-authoring it? >> >> * Who is able to provide reviews? >> >> * Who is unable to actively help with a specific document but supports the >> work? >> >> * Are there concerns regarding this document? > > As I said previously in the ML. I'm not convinced by this I-D. Basically > I don't see the need for a specific Diameter Application for Prefix > Delegation. > > [behcet] The new draft is about Prefix Authorization. Prefix Authorization > is well within AAA domain capabilities. Are you saying no to this? I don't want to reenter in this discussion since we already did it :) I'm not convinced by your Problem Statement. We are already able to deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter Application). And I may be wrong but I don't see the need for a specific application for this. Regards, Julien > > Regards, > > Behcet > --0-696980072-1216306944=:910 Content-Type: text/html; charset=us-ascii
Hi Julien,
  The current mechanism was defined with a certain architecture in mind. It simply does not apply to so many new cases that have recently emerged all in mobile networks. We need a new application because of this.
  I would like to explain this in my presentation if I get a slot in Dublin.

Regards,

Behcet

----- Original Message ----
From: Julien Bournelle <julien.bournelle@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>; dime@ietf.org
Sent: Thursday, July 17, 2008 3:20:53 AM
Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

Hi behcet,

On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com> wrote:
> Hi Julien,
>
> ----- Original Message ----
> From: Julien Bournelle <julien.bournelle@gmail.com>
> To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> Cc: dime@ietf.org
> Sent: Wednesday, July 16, 2008 3:14:15 AM
> Subject: Re: [Dime] Rechartering:
> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>
> Hi,
>
> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig
> <Hannes.Tschofenig@gmx.net> wrote:
>> Document:
>>
>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>>
>> * Who is able to be editor of the document?
>>
>> * Who is interested to help the editor with the work on the draft by
>> co-authoring it?
>>
>> * Who is able to provide reviews?
>>
>> * Who is unable to actively help with a specific document but supports the
>> work?
>>
>> * Are there concerns regarding this document?
>
> As I said previously in the ML. I'm not convinced by this I-D. Basically
> I don't see the need for a specific Diameter Application for Prefix
> Delegation.
>
> [behcet] The new draft is about Prefix Authorization. Prefix Authorization
> is well within AAA domain capabilities. Are you saying no to this?

I don't want to reenter in this discussion since we already did it :)

I'm not convinced by your Problem Statement. We are already able to
deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter
Application). And I may be wrong but I don't see the need for a specific
application for this.

Regards,

Julien


>
> Regards,
>
> Behcet
>
--0-696980072-1216306944=:910-- --===============0724176829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0724176829==-- From dime-bounces@ietf.org Thu Jul 17 08:45:47 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3373E3A69ED; Thu, 17 Jul 2008 08:45:47 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A129E3A6968 for ; Thu, 17 Jul 2008 08:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or57cb1LFozk for ; Thu, 17 Jul 2008 08:45:45 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 2EEEF3A6951 for ; Thu, 17 Jul 2008 08:45:45 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K45002WUQH2SU@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 10:46:14 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K45005W5QH0YK@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 10:46:14 -0500 (CDT) Date: Thu, 17 Jul 2008 10:45:33 -0500 From: Frank Xia To: Julien Bournelle Message-id: <00de01c8e824$3ddcb400$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien Let talk about a specific issue which is dealt with in the draft. Current prefix definition RFC4005 has no lifetime which is necessary for IPv6 renumbering. There is the same issue with RADIUS (RFC4818). BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Behcet Sarikaya" Cc: Sent: Thursday, July 17, 2008 3:20 AM Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > Hi behcet, > > On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya > wrote: >> Hi Julien, >> >> ----- Original Message ---- >> From: Julien Bournelle >> To: Hannes Tschofenig >> Cc: dime@ietf.org >> Sent: Wednesday, July 16, 2008 3:14:15 AM >> Subject: Re: [Dime] Rechartering: >> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> >> Hi, >> >> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >> wrote: >>> Document: >>> >>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> >>> * Who is able to be editor of the document? >>> >>> * Who is interested to help the editor with the work on the draft by >>> co-authoring it? >>> >>> * Who is able to provide reviews? >>> >>> * Who is unable to actively help with a specific document but supports >>> the >>> work? >>> >>> * Are there concerns regarding this document? >> >> As I said previously in the ML. I'm not convinced by this I-D. Basically >> I don't see the need for a specific Diameter Application for Prefix >> Delegation. >> >> [behcet] The new draft is about Prefix Authorization. Prefix >> Authorization >> is well within AAA domain capabilities. Are you saying no to this? > > I don't want to reenter in this discussion since we already did it :) > > I'm not convinced by your Problem Statement. We are already able to > deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter > Application). And I may be wrong but I don't see the need for a specific > application for this. > > Regards, > > Julien > > >> >> Regards, >> >> Behcet >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 09:27:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191F03A68C8; Thu, 17 Jul 2008 09:27:33 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B6C3A68C8 for ; Thu, 17 Jul 2008 09:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[AWL=-3.020, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MY_CID_AND_ARIAL2=1.46, MY_CID_AND_STYLE=1.54, MY_CID_ARIAL_STYLE=1.58, T_TVD_FW_GRAPHIC_ID1=0.01] 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 neViLRCxSJh0 for ; Thu, 17 Jul 2008 09:27:30 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 63A4C3A68B4 for ; Thu, 17 Jul 2008 09:27:30 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K45008QMSEPQ9@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 11:28:02 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4500HPTSEOA1@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 11:28:01 -0500 (CDT) Date: Thu, 17 Jul 2008 11:27:59 -0500 From: Frank Xia To: Julien Bournelle , Glen Zorn Message-id: <012201c8e82a$1469d610$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026617752==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1026617752== Content-type: multipart/related; boundary="Boundary_(ID_3IVOIuGXwkWHDpRXFf/nxg)"; type="multipart/alternative" This is a multi-part message in MIME format. --Boundary_(ID_3IVOIuGXwkWHDpRXFf/nxg) Content-type: multipart/alternative; boundary="Boundary_(ID_p0h4j6xefaJ6xjh6nhSptA)" --Boundary_(ID_p0h4j6xefaJ6xjh6nhSptA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Julien Julien wrote" We are already able to deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter Application). And I may be wrong but I don't see the need for a specific application for this." The solution you refered to is tied to authentication. In some scenarios, prefix delegation is independent of authentication. The following is a case in in proxy mobile IPv6 1) MN initiates access authentication. MAG (mobile access gateway) is as the authenticator. 2)MAG sends PBU(Proxy Binding Update) to LMA (Local Mobile Anchor). In this message, PBU asks for a prefix for the MN 3)LMA uses Diameter for dynamical prefix requesting 4)LMA sends the prefix to the MAG. BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Behcet Sarikaya" Cc: Sent: Thursday, July 17, 2008 3:20 AM Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > Hi behcet, > > On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya > wrote: >> Hi Julien, >> >> ----- Original Message ---- >> From: Julien Bournelle >> To: Hannes Tschofenig >> Cc: dime@ietf.org >> Sent: Wednesday, July 16, 2008 3:14:15 AM >> Subject: Re: [Dime] Rechartering: >> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> >> Hi, >> >> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >> wrote: >>> Document: >>> >>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> >>> * Who is able to be editor of the document? >>> >>> * Who is interested to help the editor with the work on the draft by >>> co-authoring it? >>> >>> * Who is able to provide reviews? >>> >>> * Who is unable to actively help with a specific document but supports the >>> work? >>> >>> * Are there concerns regarding this document? >> >> As I said previously in the ML. I'm not convinced by this I-D. Basically >> I don't see the need for a specific Diameter Application for Prefix >> Delegation. >> >> [behcet] The new draft is about Prefix Authorization. Prefix Authorization >> is well within AAA domain capabilities. Are you saying no to this? > > I don't want to reenter in this discussion since we already did it :) > > I'm not convinced by your Problem Statement. We are already able to > deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter > Application). And I may be wrong but I don't see the need for a specific > application for this. > > Regards, > > Julien > > >> >> Regards, >> >> Behcet >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --Boundary_(ID_p0h4j6xefaJ6xjh6nhSptA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Julien
 
Julien wrote" We are already able to
 deliver Prefix during network access AAA
(e.g. NASREQ or EAP Diameter
 Application). And I may be wrong
but I don't see the need for a specific
application for this."
 
The solution you refered to is tied to authentication.
In some scenarios, prefix delegation is independent
of  authentication.
 
The following is a case in in proxy mobile IPv6
1) MN initiates access authentication. 
    MAG (mobile access gateway) is as the authenticator.
2)MAG sends PBU(Proxy Binding Update)
   to LMA (Local Mobile Anchor). In this message,
   PBU asks for a prefix for the MN
3)LMA uses Diameter for dynamical prefix requesting
4)LMA sends the prefix to the MAG. 
 
 
BR
Frank
 
----- Original Message -----
From: "Julien Bournelle" <julien.bournelle@gmail.com>
To: "Behcet Sarikaya" <sarikaya@ieee.org>
Sent: Thursday, July 17, 2008 3:20 AM
Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

> Hi behcet,
>
> On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya
> <behcetsarikaya@yahoo.com> wrote:
>> Hi Julien,
>>
>> ----- Original Message ----
>> From: Julien Bournelle <julien.bournelle@gmail.com>
>> To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
>> Cc: dime@ietf.org
>> Sent: Wednesday, July 16, 2008 3:14:15 AM
>> Subject: Re: [Dime] Rechartering:
>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>>
>> Hi,
>>
>> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig
>> <Hannes.Tschofenig@gmx.net> wrote:
>>> Document:
>>>
>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>>>
>>> * Who is able to be editor of the document?
>>>
>>> * Who is interested to help the editor with the work on the draft by
>>> co-authoring it?
>>>
>>> * Who is able to provide reviews?
>>>
>>> * Who is unable to actively help with a specific document but supports the
>>> work?
>>>
>>> * Are there concerns regarding this document?
>>
>> As I said previously in the ML. I'm not convinced by this I-D. Basically
>> I don't see the need for a specific Diameter Application for Prefix
>> Delegation.
>>
>> [behcet] The new draft is about Prefix Authorization. Prefix Authorization
>> is well within AAA domain capabilities. Are you saying no to this?
>
> I don't want to reenter in this discussion since we already did it :)
>
> I'm not convinced by your Problem Statement. We are already able to
> deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter
> Application). And I may be wrong but I don't see the need for a specific
> application for this.
>
> Regards,
>
> Julien
>
>
>>
>> Regards,
>>
>> Behcet
>>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> --Boundary_(ID_p0h4j6xefaJ6xjh6nhSptA)-- --Boundary_(ID_3IVOIuGXwkWHDpRXFf/nxg) Content-id: <011d01c8e82a$142245c0$5c0c7c0a@china.huawei.com> Content-type: image/jpeg; name=clip_image002.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=clip_image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAECAWADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooApQ6vp87Xax3SZsSRcbsr5fGec9sd+lV7TxLo9/NbQ216rvdxmWAFGXzVHUrkc1hPDa6ne X8lvqdoiJcNHqAMgO6Dg44PByCMnjBYVXinsNSl0qC11C1FyllI1sRKp2yh0KjGfYjHpmlF81h21 sdbp2rWWqiU2UrSeS+yTMbJtb0+YCrtYXhS7F9a31wEZC97JuRuqMMAj8CCK3apqwPRhRRRSEFFF FABRRRQAUUUUAFVDqdmNTGmGcC7MfmiIgglemQehq3XM6wEvPEBtrO+tYdUht0e3ErZIbc2QVByQ VPNJvVB0NM+I9JEN1Mt3vjtJfKnaONnCOOo4B6d8dKtWWo2eo2S3tpOsluwJD8gcdc56Vxr6jp1p ptzomn6hZPPcXYgVXuFXcCBvLEZxnDDp1NWElnS51jRZjZxXNwqXUdvbzeZkcCRcEA5IXOMfxUJ3 Vw6nQweIdJubhbeK8BkkbbGGRlEh/wBkkYbp2zWlXOyawt1qtnFp19pl1CZAGgWMvNEMHLZDfLjp yvGa6KmK+oUUUUDCiiigAooooAKz9Q1vT9LljivJnjeX7gWF3z7ZUHn2rQrE8QalY2VzpyXV9b27 faVfbLKqnbhhnk9KFuKTsmzQu9TsrGS3S6nERun8uLcDhm9M9vxpkms6fFfy2DXIN1DD50kSqzMq epwPbp1NYGp61pGs3Mdk99aiEXHlLKtwpDkxZyvuCR+OKgXUrbw3dXcup6lZPqbWpebbIF3yZwig E5HGOtTezs/60uU1/XzOm0zWdP1hZTYXHm+S22QFGUqfcMAavVxenXE2jarpTX8mnRxXtuYPMhui 5mfO9X5UcElumeXFdpVEhRRRQMKKKKACiiigDOuNe0y01GPT7i5MdzKQEVo2wxPo2MfrS6prenaM qNqE5hV+jeU7D8wDiub1S4l1281UafNpssVnB5G+a6KmFwd5fAU8BgvXH3KedfTxDPpUGmzWFxMI /tM9vLc7QGxgL8oYkglj0/hpdAOmu9StLKyF7PKRbkA70Rn4Pf5QTinWF/a6naJd2Uwmhf7rAEfo ea4yPXI18ODQPttgNQFz9iEf2obNgOeuM42fL0zmtfQrt7XxBqGlXjWUM0226jgt59+MjDDkA54D dP4qfUDpaKKKACiiigCNjFGQGKLvO0ZwNx9PenBEByFUY9qo6mgeewz/AA3IYf8AfJrQoF1EpaKK BhRRRQAUUUUAFFFFABRRRQAUxzHGDLIVUKMlm4x+NPqjrSCTR7pD0aMg0AW/LTrsX8qdtXduwM+u KF4UfSloAaEUEkKAT3Ap1FFABRRRQAUUUUAFFFFABTSit95QfqKdRQA3y0/uLx7U1fJmUSJscHow wc/jTz0NUdEQR6RAo6YJ/U0C6l3Ypx8o46cdKdRRQMKKKKACiiigAooooAbsUZ+Uc9eOtNbyoVMj bEVRkscAD8akqjrSCTR7pD0aMg0AXPLTrsX64pdq7t2Bn1xQvCj6UtABRRRQAUUUUAQzW6zvEzEg xPvGO5wR/Wpqoalv86xCOV/0kbsHGRtPFX6BdQooooGFFFFABRRRQAUUVDd7Psk3mSNEgQlnRsFR jkg9qAJqK5Dwlq6PeraHWf7Q+125uUV5xI8JDcoSP9lk69w1ao1XVZ0a6stMimtAxVQ1xtlcA4LA bcY6nk54o6XFc2qiuYFurd4HJCuMEjrVC41DUJLyWDTbOGYW+BK88xjBYjO1cKcnGOuBzVS/8RvZ JaxSpZ2d3PGZHjvbsRpGBxjcAdxyewpMZvDgYpaxYfEAutDlv7WBbiSFzG6wyeYm4dSGUHK854Gc ds8UaNrlxqaXXmWiKbdQR5Tt85OeNrqrA8DqOc0wNqiuf0rxFdX+praS2KRhgzEh3DR47FXRcnt8 pIH5Z6CgAorjfEupJp+tSTJrbWr2luLh7aS4ASbn7oQ/7Kt07kV0f2+V9Qghijie3uLdpUk3ndkY 4xjGMMOc/hSvpcC/RWBd6nqkvh24uIIbeK7hlaNx5zbBhsZB25P5VYulvbjQr5dShgjPksV+zTue i5znCkHPpScrX8gjrY16Kx9P1G+MltBe2aRLcRZhYTb24AJDjHB+hNQQa5qTATXGmwx2yz/Z5HWc lt27buUbRlc464PXiq62FdWub9Fc9qXilLPUJraOXTl+z48wXV6IXYkZwq4PbucDNPvtT1C4XSrn SEt3gumDHz5WQnKkgcKeKV9LjN2o7a3W1t0hQkqnQnrUJbUDp5JhtvtmPuea3l9f723PT2qppd3F a+GYrp0dY4YiWUymVvlzn5jy3TvTFdXsa1FZdveay1xCLnTIEgmPLR3O5ohjI3AqAfTgmqsniMQa ytlJLpzq8wiVIrzM4J6EoQPxwaBm9RWHc3OuLr7QWkNk8H2cMolndT97qQEPNTeIWuBo8hSFJEA3 TgXDxMFHPysoJz+VJO6uD0Naiqd/evawR+RD508zBIoy20E4zknsAASaqHU9QhhuY7i0t1vIoTNG qTMY5FHX5tuQR9PShtIDXorIsNWvZ7i3W8sEto7uMvBiXc4wAcOMAA4PYmtemK9wqK5gW6t3gckK 4wSOtS1S1jf/AGRdeW5R/LOGBwQaBlwcDFLSL90fSloAKKhu1uXt2W0ljhmP3XkjLqPwBGfzqto0 091o0Ek8u+ZlIaTaBkgkZwOO1Ar62L9FZuhX8t9YMLllNzbSvbzlRgFlOM/iMH8a0qBle5t2nkt2 VgBFJvOe4wR/WrFU7+eaGWzWEjEk4V+M/Lg5/lS32pW2nopmZi78RxRqWeQ+gUcn+VAupboqraXM 725mvYUtMt8qGQEgdt3YH2GfrUyzxOCVlRgvJIYHFAySio0nhkbakqMfQMDSfaYN23zo85xjcKAJ aKjeeGNtrzIp9CwFDTxIAWlRQ3IJYDNAElUtW09tU06SyF1LbCXhniCkle4+YEYPSrPnxbN/mpsz jduGKFnicErKjBeSQwOKAM650V7iawmF/LE9kd2Uij/eHGDn5eMjPAx1praAcvFHqd3FZOxZrZCo HJyQHxuAJ7A1ppPDI21JUY+gYGk+0wbtvnR5zjG4UAUbnSJJLl57PUbiyaUASiIIwfAwD8wODjjI 9vSiXRV8iFLW8uLaWFSomyJGYHkht4O7nmnXeqPp9yftlsy2ZxtukJYL/vjGV+vI9cVJqF0yaRPd WjqzCMtGwwwJ7fWgG7EMmjyy2CW76reCVZRL9oQqrZHQYAxt9sc0keinyboXF/cT3FzF5JuPlR0T nG3aAAQWJzirtxdwWdsZ7qVYkUZJb+nqfaoLK+nvC8zWjW9ptzG8x2u/vt/hH159qYXe5DaaNJDc xTXWpXF79nz5AmCDZkYzlQCxxxzWpUaTwyNtSVGPoGBpPtMG7b50ec4xuFIDPtdFkt3v5G1CWZ71 i26SOPMZxgYwvIAwMHPSo4PD8ltp9rbQ6rcrLaApHPsjLbD/AA427ccDtnitV54Y22vMin0LAUNP EgBaVFDcglgM0AZ9voaw6ddWMt5cTpcszF3Kh0LcnBAHfkZpP7HuWs7mCfWLqZ54/L8xkjGxfZQu M9eSK0fPi2b/ADU2Zxu3DFCzxOCVlRgvJIYHFG4LTYoDSJvtNjMdSnP2NCu3y48S5GCT8vHHpioD 4fmOnG0Or3OTcef5nlRbuu7bjbjGeema1knhkbakqMfQMDSfaYN23zo85xjcKOtxWWxRutIlluDP aajNZs4HmhI43DkdDhlOD9PapLvTDc2kMK3k8UsDBo7gEM+QMc5BByCe1W3nhjba8yKfQsBQ08SA FpUUNyCWAzQMpjT7pbAwJqtyJ2fcbhlRm+gBXaB+FRaforWljLZXN/Ne28iFNkqIu0HOeVA65rR8 +LZv81NmcbtwxQs8TglZUYLySGBxQHmZ9vo0sdxG9xqt5cxwHMUTlVA7DcVALfiT61WPhlgEjj1W 6ihilEsMSJGAjZzyduWHJ65rZSeGRtqSox9AwNJ9pg3bfOjznGNwoAqX+mS3VwlzbahPZzKhjZol Rgy5zghgR171HqGkTXtilnHqlzbxhCkhCo7SD1JZTz9K0Hnhjba8yKfQsBQ08SAFpUUNyCWAzQBS OlyyWKwXF/NLNG++O52Iroe2ABj8xzTBo8htp1m1GeW5mjMf2lkQMi+gAG39K0PPi2b/ADU2Zxu3 DFCzxOCVlRgvJIYHFJpMDPTR5VnsJTqU7fYkK7THHiXIxk/LxxjpjpWpUaTwyNtSVGPoGBpPtMG7 b50ec4xuFO4rEtV72BrqylgQhWdcAnpVa71R9PuT9stmWzONt0hLBf8AfGMr9eR64qTULpk0ie6t HVmEZaNhhgT2+tA3oXBwAKWkXJUE9cUtAEN0bkW7GzSJ5v4RM5VfxIBP6VQ0ODUbGx8jUEtQI8lG t5GfOSScgqP61q0UCsr3Mjw5byxWM1zMjRyXtzJcmNxgoGPyj24A/OteiigZUvIpJJbQopISbc3s MGmX+lQXzrNueC6jGI7iE4dfb3HscipLy7Nq9soTd58wj6425BOf0q1QK+pRjsnurM2+sRWt4A3B MeVcDoSpyAfpToNJ021SSO30+1hSYbZFjhVQ49Dgc1cooGUrbRtLs5hNa6baQSjgPFAqsPxApv8A YWj+d539k2Xm7t2/7Om7PXOcdav0UAUrnRtLvJjNdabaTynq8sCsx/Eiln0nTbpI0uNOtZkhG2NZ IVYIPQZHAq5RQBT/ALJ037J9j/s+1+zbt3k+SuzPrtxjNEGk6bapJHb6fawpMNsixwqocehwOauU UAUrbRtLs5hNa6baQSjgPFAqsPxApv8AYWj+d539k2Xm7t2/7Om7PXOcdav0UAZt3YXeoTtHPc+T YjH7uAkPL67m7D2H59qkurJI9HktLOBUUJtSNAAKvVW1C6NlYT3QTeYkLbc4zR0sD7iXmn22oW4i uY923lWBwyN6qRyD7iorWzuo1ktbyaO9tCmFaVf3hHdX4wwx349x3q8DlQfUUtAFK20bS7OYTWum 2kEo4DxQKrD8QKb/AGFo/ned/ZNl5u7dv+zpuz1znHWr9FAFK50bS7yYzXWm2k8p6vLArMfxIpZ9 J026SNLjTrWZIRtjWSFWCD0GRwKuUUAU/wCydN+yfY/7Ptfs27d5Pkrsz67cYzRBpOm2qSR2+n2s KTDbIscKqHHocDmrlFAFK20bS7OYTWum2kEo4DxQKrD8QKb/AGFo/ned/ZNl5u7dv+zpuz1znHWr 9FAFK50bS7yYzXWm2k8p6vLArMfxIpZ9J026SNLjTrWZIRtjWSFWCD0GRwKuUUAU/wCydN+yfY/7 Ptfs27d5Pkrsz67cYzRBpOm2qSR2+n2sKTDbIscKqHHocDmrdV9PuzfWMdyU2F8/LnOMEj+lAr62 I7bRtLs5hNa6baQSjgPFAqsPxApv9haP53nf2TZebu3b/s6bs9c5x1q/RQMpXOjaXeTGa6020nlP V5YFZj+JFLPpOm3SRpcadazJCNsayQqwQegyOBVyigCn/ZOm/ZPsf9n2v2bdu8nyV2Z9duMZog0n TbVJI7fT7WFJhtkWOFVDj0OBzVyigClbaNpdnMJrXTbSCUcB4oFVh+IFN/sLR/O87+ybLzd27f8A Z03Z65zjrV+igDNu7C71Cdo57nybEY/dwEh5fXc3Yew/PtUl1ZJHo8lpZwKihNqRoABV6q2oXRsr Ce6CbzEhbbnGaOlgfcsDoKWkByoPqKWgAooooAKKKKAKV/8A6+y/67j/ANBNXahuLqK2aFZM5mkE a4GecE/0qagXUKKKKBhRRRQAUUUUAFFFFABRRRQAVT1b/kFXH+5Vyobq5js7WS4lz5cSlmwMnFAE q/dH0paQHIBHeloAKKKyl8S6U1w0HnTKyP5bFraVVVvQsVwPzoA1aKy5/EemW91LbSSTiSE/vMWs rBfcsFxj3zUz6zYJfw2Xms086eZGEidlZfXcBjHTv3FAF6iqen6rZ6oJTZu7+S+yTfE6Yb0+YCrl ABRRRQAUUUUAIehqnpH/ACC4Pof5mrlRWt1HeWyXEOdj5xkYPBx/SgXUmooooGFFFFABRRRQAUUU UAFU9W/5BVx/uVcqG6uY7O1kuJc+XEpZsDJxQBKv3R9KWkByAR3paACimSyxwRNLNIscaDLOxwAP Umo7a9tL23+0WtzFPDz+8jcMvHuKAJ6KZFLHNEssTq8bgMrKchge4NPoAo6ioaexyM4uAR/3yavV FN5G6LzigO/93uP8WO3v1qWgXUKKKKBhRRRQAUUUUAFFFFABRRRQAVS1gBtJuVIyChBFXaiuBCYH +0bRFj595wMe9AEi/dH0paQdOKWgArlLeZdX1PUrC31uzEMsxEluibpiu0BsNu49PunFdXSUra3A 5K+vrJdbv4T4nTTdscaNGGi5OD/eBOfpiprG5jsV0m+vgtlbLZyW+6QFVU7l25z93KrkZPt1rp6W nH3V/Xn/AJjuZWgZeG7uBzFc3TyxN/eQ4AP0OK1aKKbdwbu7hRRRSEFFFFACHoapaOoXSoAowMH+ Zq7Udv5HkL9nKGL+HYcigXUlooooGFFFFABRRRQAUUUUAFUtYAbSblSMgoQRV2orgQmB/tG0RY+f ecDHvQBIv3R9KWkHTiloAqakLL7Jv1AK0Mbq+G5BYH5eO5zjA9ag0y3kNxc380Qge62/uR1CjOC3 +0c8+mAO1WNQ02z1S3EF9As0auHAbPDDoRjvTLHSLHSxL9hgELS43NksTjp1PvQBR8LsVtr61H+q tb+aKIei5zj8CxrbqppdgumWCWwkMjAlnkIwXdiSx/Ek1boAoakgeewz/Dcgj/vk1fqKa3Sd4mYk GJ94x64x/WpaBW1uFFFFAwooooAKKKKACiiigAooooAKo6yofR7pD0aMg1eqK5gW5t3gckK4wSOt AEd3Nc29qHtLT7VJwPL8wJx65NQWt5qUsUzXGkmB0XMa/aFbzD6ZHT8avjgYpaAM2zvdUmuFS60c 20RBzJ9pR8fgKZ/aGr/aNn9hny9+PM+1J0z1x/StWigDNvL7VIbhkttHNzEAMSfaUTP4GnXV5qUU ULW+kmdnXMi/aFXyz6ZPWtCigDP+2al/Z/nf2UftO7H2f7QvT13dKLW81KWKZrjSTA6LmNftCt5h 9Mjp+NaFFAGbZ3uqTXCpdaObaIg5k+0o+PwFM/tDV/tGz+wz5e/Hmfak6Z64/pWrRQBm3l9qkNwy W2jm5iAGJPtKJn8DUeprH9jjv7i6fTLiJOHD7gpP8JXo/Pbqe1a1QSWdtLdR3UkKPNECEdhkrnrj 0+tAFbSLu9vLLzL228l84VsFfMH97aeVz6Hml0VBHpECjpg/zNXqjtoFtbdIUJKp0J60Ctrclooo oGFFFFABRRRQAUUUUAFUdZUPo90h6NGQavVFcwLc27wOSFcYJHWgCReFH0paQcDFLQAUUUUAFFFF AFDUg5msAjlf9JBOD1G08Vfqvc27TyW7BgPKk3nPfgj+tWKBW1uFFFFAwooooAKKKKACiiigAooo oAKpazuOj3QRijGMgMDjFXagvYGurOWBWCl1wCe1APUmX7o+lLSAYAFLQAUUUUAFFFFABRRRQAUU UUAFFFFACHpVHRQ40mDe5duSSTn+I1ePSoLK3a1s44GYMUHJH1oFbW5YooooGFFFFABRRRQAUUUU AFUtZ3HR7oIxRjGQGBxirtQXsDXVnLArBS64BPagHqTL90fSlpAMACloAKKKKACiiigCnfzzwy2a wnAknCvx1XBz/KrlVbyKSWW1ZFyI5tzewwatUC6hRRRQMKKKKACiiigAooooAKKKKACqmqTTW+l3 E1ucSpGShxnmrdVdRiefT5oo13Oy4A9aALK5KjPXFLSDoKWgAooooAKKKKACiiigAooooAKKKKAE PSqmlTTXGmxS3BzK2cnGO5x+lWz0qtpsTwafFHIu11ByPxoF1LVczLqmp20l7JLqdgy2spAtvs5V 5BgEAHzDyc4HHJrpqwrHSbpNZnvL6y0tw8hdJkUmZeAAMlfb1pa8yGWLzX7eyv0sZba6M0sZeEIg PnYxlV56jIznA96fNrUccEDpZXk0sylhbpFiRQOpYEgDB46/TNV7+11ptbjvbJbAxRQtGomdwx3F STwCP4f1puuaD/ackN0kNtNPGhQpOzqhB54K8g59jTG7dC4+rIdJlvre3nmaMENAFAkVh1BBI5H1 qj4cub+7hN1ePqHzRKwjuIYUTJ5+TZz7cnvT7bS7yx0KW1tILCK4lYkopcRjPB5OST78VY0uLVrb TfIuls/NijCQmJ3KsQMfNkcdumaO5LvdBo17LefbGmM6lJ8CGeJUaIbQQvyk59c+9Rf8JHDtP+gX 3mC5+z+T5a784zuxu+7jvTdMttbgv7iW8Sw8q4fe3ku5ZSFAA5GO1VjpevF/7Q36f/agl2h8v5fk f3MYzn+vPtR2BXsdHVTVJprfS7ia3OJUjJQ4zzVoZwM9e9VtRiefT5oo13Oy4A9aGMsrkqM9cUtI OgpaACiiigAooooAq3l2bV7ZQm7z5hGefu5BOf0q1VK/BM9lgH/X/wDspq7QLqFFFFAwooooAKKK KACiiigAooooAKrahdGy0+e6VN5iQsFzjNWap6sCdLuABk7O1AMtqcqD6ilpF+6PpS0AFFFFABRR RQAUUUUAFFFFAGJqfiCXTNTjtpdOZ7ZwC1wko+RchdxXrjLAVZvdVXT7+Nbp7eGzeFnMrvtKsCBj 0xz61i3OnXus3Wryz/2lYxtF9njjjSA+dGAehO45JJ/u9qsWD3t1d6RJf6RcpLBA6ySuI9qPgDPD Hrg9PWl0Bm6b21Fn9sNzF9m27/O3jbt9c0y21OxvLV7q2u4ZoEzukRwQuOuaxLeC6ksmkbTJlEF+ 84tpQgMikkgqAxGQTkZI5FXrZ55bubVDYXFuoh2eQ4XzJSDnOASPYZPc0f1+Aky1DrGmXDwpDf28 jXALRKsgJcD09abBqcdxrE1lDLbSLBHmQLNmVXzjBTsMY5zWZ4Yi8qB4J9FuLWRppJ2lmVCGYuSO QxOcH8Ke1/df8JAs39i6h5QiaHzMR4yXBz9/OMD0quo5aXsaF7rmk6dN5N7qNtbybd2ySQKcetPu dX06ztorm5vYIoZsGOR3AV8jPB78VnaxcXJvRbDSr2e0ChpHthH++P8AcOWBAHf16etJqc2qslo1 vDe28Tx5kjtEheVH4wp3/LgDPTPNSBe1HWrHTNM/tGe4j8g42tvGHz0walstUsNRieWyu4bhI+Ha NwQv1rIsLS/PhOezltZI7tWkwkjJ+8O4sMFfl5z6D6VpWuo3NxHLI+lXUCRpkLKU3yN6ABiPxJFC vcBdL1JdTSeWKS2lhSUpG8E3mblwPvccHk8U/wDtbTvt/wBg+3Qfav8Anj5g3flWfpN1cvqV4JdJ vrZLmQOskoj2gBAOcOT1HpUAgufsB0b+zJVkLE/bBs8rdnPmZzu3d+nX86bYk/1NSbW9KtpGjn1G 2jdX8tleUAhsZwam1C6Nlp890qBzEhYLnGayJI5P7R1aU6TcSM9ssaS7UPmgA5Vct6nPOKs/vf8A hFEWWCSKVbdVaN8bgQAOxI7etJbXB9jWU5UH1FLSL90fSlpjIbq5W0t2maOWTb0SJC7MewAH/wCq oLHU0vRKv2a4t5ocb4ZlAcA9CMEgg89DU13dwWVuZrlykQ4Z8Ehfc46D3rH8O/ZzfXz2E8l3ZvsY XMrFyX5BUOfvKAB64JIoQGvY3sOo2Ud3bkmOQcBhggg4II9QQR+FWKxPDG4w6iwz5LahMYeeNuec e27dW3QBBcXUds0KybszSCNcDuQT/Sp6o6ioaexyM4uAR/3yavUC1uFFFFAwooooAKKKKACiiigA ooooAKhurmOztZLmXOyJSzbRk4qaqWsANpNyCMgoQRQDLgOQCO9LSL90fSloAKKKKACiiigAoooo AKKKKACiiigBKitLqO9tkuIs7HzjcMHg4/pUp6Gs2wjmbQUjtJFhlKnY7JuCnJ7ZGaBa3L0lzBDN HDJMiSSkiNC2C2OuBUtYOjiKxvDDf20kWozcG5kfzBcY5+V+3rtwMenFW/smt/aN39rWvlbs7PsR ztz0z5np3xQM06Kzru21eS4LWmp28ERxhHtDIR+O8fyp1zb6q8cIttRghdVxKz2pcOfUDeMfTmgC /RVD7Pqn2Hy/7Rg+1bs+d9lO3Hps3/rmi2t9VSOYXOowTOy4iZLUoEPqRvOfpxQBforOtLbV47gN d6nbzxYOUS0MZP47z/Km/ZNb+0bv7WtfK3Z2fYjnbnpnzPTvigC8lzBJPJAkyNLFjegb5lz0yKS6 uY7O1kuZc7IlLNtGTisfWfKvbkQWNvJLqUPAuI2MYt8/3nx0/wBnnPpVu8jnXw9LHeSpPN5WJHVN oY/SjpcTNIHIBHelpF+6PpS0DCkI3KRzyO1LRQBDaWsNjax2tumyKMYUZz+vc1NRRQBFMYA0XnFA d/7vd/ex29+tS1Q1JA89hnPy3II/75NX6BdQooooGFFFFABRRRQAUUUUAFFFFABUVx5It3NwUEQH zl+mPepao6yofR7pD0aMg0Ay6MY46UtIvCj6UtACdKgjvrOaQRxXcEjnoqyAk/hU5GRg9K4iXTpb WxubxLHTILW2uXlMsSbLgKsmTg4wDxj6cUr+8kHQ7GW+s4HKS3UMbjqryAGnTXVvblRNPFEW6b3A z+dYGqWol15ZYdCtNRaS1BYzFEI+bjkqc1V1Wwj8jStKu9NOqNHukmWKNGKIOiguR8u4gdckLQnd AdbS1keGLmWfRIoriOSOe1Y28iS/eG3gZxkZK7Tx61r02AUUUUAFFFFACVHbmAwL9mKGL+HZ0qQ9 DVHRUEekwKOmD1+poF1L9FFFAwooooAKKKKACiiigAqK48kW7m4KCID5y/THvUtUdZUPo90h6NGQ aAZdGMcdKWkXhR9KWgAoqlq+oppemy3Tbdwwsas20M5OFGe3JrP8MpEtvfQreC7P2gmSQSbtzMoJ 78DOcClfWwG7RWP4Zmc2NxaOzP8AYbqS2V2OSyqcr+QIH4VsUwIprdJniZicxPvXB74x/Wpaoamr NNYBWK4uQTg9RtPFX6BdQooooGFFFFABRRRQAUUUUAFFFFABUVxAlzbvC5IVxg461LVHWQx0e6Cs VYxkBgelAMujgYpaoanqcek2InkjeTOFUKMDJ6bmPCj3NNs2vVikvr+ZWVk3Lb2yb1QdeCBuc/Tj 0FAGgQCCD0NZUPhbQreVZYtMgV1bcDgnn1xU9rrNteTiGOG9ViCcy2Usa/8AfTKBTP7dtfP8n7Pf 7t23P2CbbnOPvbcY9+lAD5dD0yfUBqEtnG10uMSnO7jpT/7KsP7T/tP7LH9s27fOx82PSo7rWbaz nMMkN6zDHMVlLIv/AH0qkU641a3tY4neG8YTLuUR2krkfUKpKn2OKAHWWlWGnSzy2dqkL3DbpWXq 59TVyqP9rW/2L7Z5N55e7bt+yS78/wC5t3Y98UW+rW9zHLIkN4ohXcwktJUJ+gZQWPsM0AXqKoWu s215OIY4b1WIJzLZSxr/AN9MoFM/t218/wAn7Pf7t23P2CbbnOPvbcY9+lAGlRWfdazbWc5hkhvW YY5ispZF/wC+lUinXGrW9rHE7w3jCZdyiO0lcj6hVJU+xxQBdqO3gS2gWGMkqnTPWm2t3He2/nRJ Mi5IxNC0bfkwBqvoqsukQB2LHk5J/wBo0C6l+iiigYUUUUAFFFFABRRRQAVFcQJc27wuSFcYOOtS 1R1kMdHugrFWMZAYHpQDLo4GKWkX7o+lLQBHNBDcxGKeJJUPVXUMD+BqjpejQ6OLk27tIbh/MIZI 0AOMYGxRx9c1pUUAZ2iWEmn2BWcqbmeR55yvQuxyfy4H4Vo0UUAV7m3M8kDBgPKk3nPfgj+tWKpX 808UtmsLYEk4V+ByuDmrtAr6hRRRQMKKKKACiiigAooooAKKKKACoL2A3VnLArBS64BPap6qarLN BpdzLbnEqxkocZ5oAslFZCjgMpGCCMgiqtlpkGnyObVpI4X/AOXcN+7Q+qjt9Bx7VbXJUZ64paAC iiigAooooAKKKKACiiigAooooAQ9Khsrc2tpHAzBig6j61MelVNJmmn02GW4bdK2cnAHc46e1Aup cooooGFFFFABRRRQAUUUUAFQXsBurOWBWCl1wCe1T1U1WWaDS7mW3OJVjJQ4zzQBaAwAKWkXJUZ6 4paACiiigAooooAq3kMkstqyLkRzbm56DBq1RRQAUUUUAFFFFABRRRQAUUUUAFFFFABVbUYnn0+a KNdzsuAM9as0UAIOAKWiigAooooAKKKKACiiigAooooAKKKKAEPSq2nQvBYRRSrtdQcjPvVqigAo oooAKKKKACiiigAooooAKrajE8+nzRRrudlwBnrVmigBBwBS0UUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAH//2Q== --Boundary_(ID_3IVOIuGXwkWHDpRXFf/nxg)-- --===============1026617752== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1026617752==-- From dime-bounces@ietf.org Thu Jul 17 11:07:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B7B3A6AE8; Thu, 17 Jul 2008 11:07:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4605A3A6A4D for ; Thu, 17 Jul 2008 11:07:53 -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 aMvGuLtizytd for ; Thu, 17 Jul 2008 11:07:52 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by core3.amsl.com (Postfix) with ESMTP id 240583A6AE8 for ; Thu, 17 Jul 2008 11:07:51 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so21973wxd.31 for ; Thu, 17 Jul 2008 11:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=NQrVr6dfTeluloVThcRIR/YIbNnreLI9c453Nywt7Ts=; b=vg5+3EwAc3HkZCM8RzDu/NBuPCqkICymwyu8JGQYggSmC7vuO1erWVeR6xfycA8K3r 1wcPsJmBsC4vFHqtAZ3VHmDmoKS9ZEQPPg5OhkMOVtNQ4Wvwf3cwA/zaTUMrkSv77SIU 32clvWGYqgTPbxyI4W169AaJa2DyTWrvHoaPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HA+bScglfQoMtT3TclnIvbI2b20fb18Lez76ODEDH+BfRqo5VDxZ74eQioPkv7ugAN pt/X5ifrwKCFS8pQfBQV+DIg1HO6V1nFWQzVHBErvxvqZCs/6on9rogt/Wc/4QZf3hMi 8GcB3IVgMrsrrbgK+jsHFKyBy5rDC5fkz8Vnw= Received: by 10.100.119.12 with SMTP id r12mr4535572anc.73.1216318103361; Thu, 17 Jul 2008 11:08:23 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Thu, 17 Jul 2008 11:08:23 -0700 (PDT) Message-ID: <5e2406980807171108i5850daadk58f58d406b703176@mail.gmail.com> Date: Thu, 17 Jul 2008 20:08:23 +0200 From: "Julien Bournelle" To: "Frank Xia" In-Reply-To: <00de01c8e824$3ddcb400$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> <00de01c8e824$3ddcb400$5c0c7c0a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Frank, I think we are little bit looping since I have the impression that we already had this discussion. However, see my reply inline. On Thu, Jul 17, 2008 at 5:45 PM, Frank Xia wrote: > Hi Julien > > Let talk about a specific issue which is dealt with in the draft. > > Current prefix definition RFC4005 has no lifetime which > is necessary for IPv6 renumbering. > There is the same issue with RADIUS (RFC4818). Maybe the reason is that the lifetime of the prefix is implicit and is the same as the lifetime of the network access authorization. I may be wrong but I don't see why we would do "hard" renumbering. I mean that if we want to do renumbering there will be a transition period during which the obsolete and the new prefix will be in place. Do you have a specific deployment scenarios in mind ? Regards, Julien > > BR > Frank > > > ----- Original Message ----- From: "Julien Bournelle" > > To: "Behcet Sarikaya" > Cc: > Sent: Thursday, July 17, 2008 3:20 AM > Subject: Re: [Dime] > Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > >> Hi behcet, >> >> On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya >> wrote: >>> >>> Hi Julien, >>> >>> ----- Original Message ---- >>> From: Julien Bournelle >>> To: Hannes Tschofenig >>> Cc: dime@ietf.org >>> Sent: Wednesday, July 16, 2008 3:14:15 AM >>> Subject: Re: [Dime] Rechartering: >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> >>> Hi, >>> >>> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >>> wrote: >>>> >>>> Document: >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> >>>> * Who is able to be editor of the document? >>>> >>>> * Who is interested to help the editor with the work on the draft by >>>> co-authoring it? >>>> >>>> * Who is able to provide reviews? >>>> >>>> * Who is unable to actively help with a specific document but supports >>>> the >>>> work? >>>> >>>> * Are there concerns regarding this document? >>> >>> As I said previously in the ML. I'm not convinced by this I-D. Basically >>> I don't see the need for a specific Diameter Application for Prefix >>> Delegation. >>> >>> [behcet] The new draft is about Prefix Authorization. Prefix >>> Authorization >>> is well within AAA domain capabilities. Are you saying no to this? >> >> I don't want to reenter in this discussion since we already did it :) >> >> I'm not convinced by your Problem Statement. We are already able to >> deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter >> Application). And I may be wrong but I don't see the need for a specific >> application for this. >> >> Regards, >> >> Julien >> >> >>> >>> Regards, >>> >>> Behcet >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 11:12:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CCD3A6998; Thu, 17 Jul 2008 11:12:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE3F3A6998 for ; Thu, 17 Jul 2008 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L44jNFVLKAjD for ; Thu, 17 Jul 2008 11:12:24 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by core3.amsl.com (Postfix) with ESMTP id BFCDA3A6903 for ; Thu, 17 Jul 2008 11:12:23 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so34014wra.17 for ; Thu, 17 Jul 2008 11:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fE0z+NZC3QV32Ach2ryBtW5a4DJYKRszO2vYuRQFj+Q=; b=b8aFsjf5Gjv7lLGAsaoyyrOluDF+O4xLkFL1JdycDgAkzWrCxG1M/kU30Wkklx0Xq7 2DKmMW8I7/9OLHwURDXzaF9josH5373pHTuFqbTpLlEyY/CV6pMB1YU/5gEZp4t6xXUr 8HKxvj86fgFNLFttP0BIIKCvoAQJwec/p+Ss8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cVor5Zm0NweuZId4b81fo/uZwq79FB6SThIzmHvM/m4KmCmoGzZUpMh6sf5ayka+++ fEcF0pix82+zroR7tE1mIJE2VzE1bZy1mSI1Lu9EJqBbSdIikavAJgv432OWRmQWJfAH x4lAeaT+A8XJXqKKREdiCmS2W3iJXPcrBkLUU= Received: by 10.100.197.3 with SMTP id u3mr4538798anf.102.1216318374132; Thu, 17 Jul 2008 11:12:54 -0700 (PDT) Received: by 10.100.211.17 with HTTP; Thu, 17 Jul 2008 11:12:54 -0700 (PDT) Message-ID: <5e2406980807171112h132c1b99od94dce56cfec6c86@mail.gmail.com> Date: Thu, 17 Jul 2008 20:12:54 +0200 From: "Julien Bournelle" To: "Frank Xia" In-Reply-To: <012201c8e82a$1469d610$5c0c7c0a@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> <012201c8e82a$1469d610$5c0c7c0a@china.huawei.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi again, On Thu, Jul 17, 2008 at 6:27 PM, Frank Xia wrote: > Hi Julien > > Julien wrote" We are already able to > deliver Prefix during network access AAA > (e.g. NASREQ or EAP Diameter > Application). And I may be wrong > but I don't see the need for a specific > application for this." > > The solution you refered to is tied to authentication. > In some scenarios, prefix delegation is independent > of authentication. > > The following is a case in in proxy mobile IPv6 > 1) MN initiates access authentication. > MAG (mobile access gateway) is as the authenticator. > 2)MAG sends PBU(Proxy Binding Update) > to LMA (Local Mobile Anchor). In this message, > PBU asks for a prefix for the MN > 3)LMA uses Diameter for dynamical prefix requesting > 4)LMA sends the prefix to the MAG. For the PMIP6 case, we wrote an I-D: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt which hopefully should become a WG item. And as you will see, we have some exchange between LMA and AAA but right before we have some exchanges between MAG and the AAA. So even in this case, I wouldn't say that it is only Prefix Delegation Authorization which is needed but a whole application to do AAA in the PMIPv6 case. Julien > > > BR > Frank > > ----- Original Message ----- > From: "Julien Bournelle" > To: "Behcet Sarikaya" > Cc: > Sent: Thursday, July 17, 2008 3:20 AM > Subject: Re: [Dime] > Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> Hi behcet, >> >> On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya >> wrote: >>> Hi Julien, >>> >>> ----- Original Message ---- >>> From: Julien Bournelle >>> To: Hannes Tschofenig >>> Cc: dime@ietf.org >>> Sent: Wednesday, July 16, 2008 3:14:15 AM >>> Subject: Re: [Dime] Rechartering: >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> >>> Hi, >>> >>> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >>> wrote: >>>> Document: >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> >>>> * Who is able to be editor of the document? >>>> >>>> * Who is interested to help the editor with the work on the draft by >>>> co-authoring it? >>>> >>>> * Who is able to provide reviews? >>>> >>>> * Who is unable to actively help with a specific document but supports >>>> the >>>> work? >>>> >>>> * Are there concerns regarding this document? >>> >>> As I said previously in the ML. I'm not convinced by this I-D. Basically >>> I don't see the need for a specific Diameter Application for Prefix >>> Delegation. >>> >>> [behcet] The new draft is about Prefix Authorization. Prefix >>> Authorization >>> is well within AAA domain capabilities. Are you saying no to this? >> >> I don't want to reenter in this discussion since we already did it :) >> >> I'm not convinced by your Problem Statement. We are already able to >> deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter >> Application). And I may be wrong but I don't see the need for a specific >> application for this. >> >> Regards, >> >> Julien >> >> >>> >>> Regards, >>> >>> Behcet >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 11:23:30 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922BE3A6B30; Thu, 17 Jul 2008 11:23:30 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4813A6B05 for ; Thu, 17 Jul 2008 11:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17pvkI7Gx5JR for ; Thu, 17 Jul 2008 11:23:28 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id B79F83A68C8 for ; Thu, 17 Jul 2008 11:23:28 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K45008SPXS0Q9@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 13:24:00 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4500H92XRZA1@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 13:24:00 -0500 (CDT) Date: Thu, 17 Jul 2008 13:23:59 -0500 From: Frank Xia To: Julien Bournelle Message-id: <001801c8e83a$48499c30$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> <00de01c8e824$3ddcb400$5c0c7c0a@china.huawei.com> <5e2406980807171108i5850daadk58f58d406b703176@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien IMO, If you are arguing the necessity of the IP renumbering, I think we can stop discussing on the topic of lifetime of prefix, because we have fundamental disagreement on this issue. BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Frank Xia" Cc: ; "Behcet Sarikaya" Sent: Thursday, July 17, 2008 1:08 PM Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > Hi Frank, > > I think we are little bit looping since I have the impression that we > already had this discussion. However, see my reply inline. > > On Thu, Jul 17, 2008 at 5:45 PM, Frank Xia wrote: >> Hi Julien >> >> Let talk about a specific issue which is dealt with in the draft. >> >> Current prefix definition RFC4005 has no lifetime which >> is necessary for IPv6 renumbering. >> There is the same issue with RADIUS (RFC4818). > > Maybe the reason is that the lifetime of the prefix is implicit and > is the same as the lifetime of the network access authorization. > I may be wrong but I don't see why we would do "hard" renumbering. > I mean that if we want to do renumbering there will be a transition period > during which the obsolete and the new prefix will be in place. > > Do you have a specific deployment scenarios in mind ? > > Regards, > > Julien > > >> >> BR >> Frank >> >> >> ----- Original Message ----- From: "Julien Bournelle" >> >> To: "Behcet Sarikaya" >> Cc: >> Sent: Thursday, July 17, 2008 3:20 AM >> Subject: Re: [Dime] >> Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> >> >>> Hi behcet, >>> >>> On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya >>> wrote: >>>> >>>> Hi Julien, >>>> >>>> ----- Original Message ---- >>>> From: Julien Bournelle >>>> To: Hannes Tschofenig >>>> Cc: dime@ietf.org >>>> Sent: Wednesday, July 16, 2008 3:14:15 AM >>>> Subject: Re: [Dime] Rechartering: >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> >>>> Hi, >>>> >>>> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >>>> wrote: >>>>> >>>>> Document: >>>>> >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>>> >>>>> * Who is able to be editor of the document? >>>>> >>>>> * Who is interested to help the editor with the work on the draft by >>>>> co-authoring it? >>>>> >>>>> * Who is able to provide reviews? >>>>> >>>>> * Who is unable to actively help with a specific document but supports >>>>> the >>>>> work? >>>>> >>>>> * Are there concerns regarding this document? >>>> >>>> As I said previously in the ML. I'm not convinced by this I-D. >>>> Basically >>>> I don't see the need for a specific Diameter Application for Prefix >>>> Delegation. >>>> >>>> [behcet] The new draft is about Prefix Authorization. Prefix >>>> Authorization >>>> is well within AAA domain capabilities. Are you saying no to this? >>> >>> I don't want to reenter in this discussion since we already did it :) >>> >>> I'm not convinced by your Problem Statement. We are already able to >>> deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter >>> Application). And I may be wrong but I don't see the need for a specific >>> application for this. >>> >>> Regards, >>> >>> Julien >>> >>> >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> >> >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 11:32:05 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101C23A6AE8; Thu, 17 Jul 2008 11:32:05 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE9D3A6AE8 for ; Thu, 17 Jul 2008 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PzT9TNBG4bc for ; Thu, 17 Jul 2008 11:32:03 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DCD243A6954 for ; Thu, 17 Jul 2008 11:32:03 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K45008U0Y6BQ9@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 13:32:35 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4500H0NY6AA1@usaga04-in.huawei.com> for dime@ietf.org; Thu, 17 Jul 2008 13:32:35 -0500 (CDT) Date: Thu, 17 Jul 2008 13:32:34 -0500 From: Frank Xia To: Julien Bournelle Message-id: <001b01c8e83b$7b668550$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <447547.52534.qm@web84306.mail.re1.yahoo.com> <5e2406980807170120m43f3f495veefced2d18df9f84@mail.gmail.com> <012201c8e82a$1469d610$5c0c7c0a@china.huawei.com> <5e2406980807171112h132c1b99od94dce56cfec6c86@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Julien You'd better keep the draft http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt in the current scope, and not mix with prefix delegation. LMA prefix delegation is a separate topic which probably involves DHCP/RADIUS/DIAMETER methods BR Frank ----- Original Message ----- From: "Julien Bournelle" To: "Frank Xia" Cc: "Glen Zorn" ; Sent: Thursday, July 17, 2008 1:12 PM Subject: Re: [Dime] Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > Hi again, > > On Thu, Jul 17, 2008 at 6:27 PM, Frank Xia wrote: >> Hi Julien >> >> Julien wrote" We are already able to >> deliver Prefix during network access AAA >> (e.g. NASREQ or EAP Diameter >> Application). And I may be wrong >> but I don't see the need for a specific >> application for this." >> >> The solution you refered to is tied to authentication. >> In some scenarios, prefix delegation is independent >> of authentication. >> >> The following is a case in in proxy mobile IPv6 >> 1) MN initiates access authentication. >> MAG (mobile access gateway) is as the authenticator. >> 2)MAG sends PBU(Proxy Binding Update) >> to LMA (Local Mobile Anchor). In this message, >> PBU asks for a prefix for the MN >> 3)LMA uses Diameter for dynamical prefix requesting >> 4)LMA sends the prefix to the MAG. > > For the PMIP6 case, we wrote an I-D: > > http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > which hopefully should become a WG item. > > And as you will see, we have some exchange between LMA and AAA but right > before > we have some exchanges between MAG and the AAA. > > So even in this case, I wouldn't say that it is only Prefix > Delegation Authorization which > is needed but a whole application to do AAA in the PMIPv6 case. > > Julien > > >> >> >> BR >> Frank >> >> ----- Original Message ----- >> From: "Julien Bournelle" >> To: "Behcet Sarikaya" >> Cc: >> Sent: Thursday, July 17, 2008 3:20 AM >> Subject: Re: [Dime] >> Rechartering:draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> Hi behcet, >>> >>> On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya >>> wrote: >>>> Hi Julien, >>>> >>>> ----- Original Message ---- >>>> From: Julien Bournelle >>>> To: Hannes Tschofenig >>>> Cc: dime@ietf.org >>>> Sent: Wednesday, July 16, 2008 3:14:15 AM >>>> Subject: Re: [Dime] Rechartering: >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> >>>> Hi, >>>> >>>> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig >>>> wrote: >>>>> Document: >>>>> >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>>> >>>>> * Who is able to be editor of the document? >>>>> >>>>> * Who is interested to help the editor with the work on the draft by >>>>> co-authoring it? >>>>> >>>>> * Who is able to provide reviews? >>>>> >>>>> * Who is unable to actively help with a specific document but supports >>>>> the >>>>> work? >>>>> >>>>> * Are there concerns regarding this document? >>>> >>>> As I said previously in the ML. I'm not convinced by this I-D. >>>> Basically >>>> I don't see the need for a specific Diameter Application for Prefix >>>> Delegation. >>>> >>>> [behcet] The new draft is about Prefix Authorization. Prefix >>>> Authorization >>>> is well within AAA domain capabilities. Are you saying no to this? >>> >>> I don't want to reenter in this discussion since we already did it :) >>> >>> I'm not convinced by your Problem Statement. We are already able to >>> deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter >>> Application). And I may be wrong but I don't see the need for a specific >>> application for this. >>> >>> Regards, >>> >>> Julien >>> >>> >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 17 12:52:04 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4755B3A67F3; Thu, 17 Jul 2008 12:52:04 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AD33A67F3 for ; Thu, 17 Jul 2008 12:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 G7j6TTRIyyEr for ; Thu, 17 Jul 2008 12:52:01 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 681563A63D2 for ; Thu, 17 Jul 2008 12:52:01 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA03.westchester.pa.mail.comcast.net with comcast id r4TS1Z02a1HzFnQ537sYgT; Thu, 17 Jul 2008 19:52:32 +0000 Received: from gwzPC ([72.164.184.70]) by OMTA14.westchester.pa.mail.comcast.net with comcast id r7s61Z00B1XZ4wg3a7sLry; Thu, 17 Jul 2008 19:52:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=MZE0qg0lwuUA:10 a=OIx-b0TaTbIA:10 a=N6sOArNQAAAA:8 a=48vgC7mUAAAA:8 a=Dpy_Ha8PeACjc_dRQ3AA:9 a=vWyAczrWN3HxYoMQ7sYA:9 a=2R2RoJOdpis2GyhmKo3gEFZY8ekA:4 a=MSl-tDqOz04A:10 a=ZrMMMnaxNC4A:10 a=BFDKbZatV3MA:10 a=lZB815dzVvQA:10 a=rC2wZJ5BpNYA:10 a=50e4U0PicR4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=7nbhgd6o4kz9bbjfUkUA:7 a=xcXNVJxsdjBQzbmHpuNz4j3liIAA:4 a=37WNUvjkh6kA:10 From: "Glen Zorn" To: "'Behcet Sarikaya'" , "'Julien Bournelle'" References: <84211.910.qm@web84314.mail.re1.yahoo.com> In-Reply-To: <84211.910.qm@web84314.mail.re1.yahoo.com> Date: Thu, 17 Jul 2008 13:51:59 -0600 Message-ID: <005301c8e846$99733c40$cc59b4c0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjoHiIraT1M41ITTIi6CZrms37qKgAKDEQQ Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661441659==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0661441659== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01C8E814.4ED8CC40" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0054_01C8E814.4ED8CC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Julien, The current mechanism was defined with a certain architecture in mind. It simply does not apply to so many new cases that have recently emerged all in mobile networks. We need a new application because of this. I would like to explain this in my presentation if I get a slot in Dublin. I think that it might be more useful to explain it in the document :-). Regards, Behcet ----- Original Message ---- From: Julien Bournelle To: Behcet Sarikaya Cc: Hannes Tschofenig ; dime@ietf.org Sent: Thursday, July 17, 2008 3:20:53 AM Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Hi behcet, On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya wrote: > Hi Julien, > > ----- Original Message ---- > From: Julien Bournelle > To: Hannes Tschofenig > Cc: dime@ietf.org > Sent: Wednesday, July 16, 2008 3:14:15 AM > Subject: Re: [Dime] Rechartering: > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > Hi, > > On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig > wrote: >> Document: >> >> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps -00.txt >> >> * Who is able to be editor of the document? >> >> * Who is interested to help the editor with the work on the draft by >> co-authoring it? >> >> * Who is able to provide reviews? >> >> * Who is unable to actively help with a specific document but supports the >> work? >> >> * Are there concerns regarding this document? > > As I said previously in the ML. I'm not convinced by this I-D. Basically > I don't see the need for a specific Diameter Application for Prefix > Delegation. > > [behcet] The new draft is about Prefix Authorization. Prefix Authorization > is well within AAA domain capabilities. Are you saying no to this? I don't want to reenter in this discussion since we already did it :) I'm not convinced by your Problem Statement. We are already able to deliver Prefix during network access AAA (e.g. NASREQ or EAP Diameter Application). And I may be wrong but I don't see the need for a specific application for this. Regards, Julien > > Regards, > > Behcet > ------=_NextPart_000_0054_01C8E814.4ED8CC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Julien,
  The current mechanism was defined with a certain architecture in = mind. It simply does not apply to so many new cases that have recently emerged = all in mobile networks. We need a new application because of this.
  I would like to explain this in my presentation if I get a slot = in Dublin.

I think that it = might be more useful to explain it in the document :-).



Regards,

Behcet

----- Original Message ----
From: Julien Bournelle <julien.bournelle@gmail.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>; = dime@ietf.org
Sent: Thursday, July 17, 2008 3:20:53 AM
Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

Hi behcet,

On Wed, Jul 16, 2008 at 5:15 PM, Behcet Sarikaya
<behcetsarikaya@yahoo.com>= wrote:
> Hi Julien,
>
> ----- Original Message ----
> From: Julien Bournelle <julien.bournelle@gmail.com= >
> To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net&g= t;
> Cc: dime@ietf.org
> Sent: Wednesday, July 16, 2008 3:14:15 AM
> Subject: Re: [Dime] Rechartering:
> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>
> Hi,
>
> On Tue, Jul 15, 2008 at 8:29 PM, Hannes Tschofenig
> <Hannes.Tschofenig@gmx.net&g= t; wrote:
>> Document:
>>
>> http://www.ietf.org/internet-drafts/draft-sarikaya-dime= radext-prefix-auth-ps-00.txt
>>
>> * Who is able to be editor of the document?
>>
>> * Who is interested to help the editor with the work on the = draft by
>> co-authoring it?
>>
>> * Who is able to provide reviews?
>>
>> * Who is unable to actively help with a specific document but = supports the
>> work?
>>
>> * Are there concerns regarding this document?
>
> As I said previously in the ML. I'm not convinced by this I-D. = Basically
> I don't see the need for a specific Diameter Application for = Prefix
> Delegation.
>
> [behcet] The new draft is about Prefix Authorization. Prefix = Authorization
> is well within AAA domain capabilities. Are you saying no to = this?

I don't want to reenter in this discussion since we already did it = :)

I'm not convinced by your Problem Statement. We are already able to
deliver Prefix during network access AAA (e.g. NASREQ or EAP = Diameter
Application). And I may be wrong but I don't see the need for a = specific
application for this.

Regards,

Julien


>
> Regards,
>
> Behcet
>

------=_NextPart_000_0054_01C8E814.4ED8CC40-- --===============0661441659== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0661441659==-- From dime-bounces@ietf.org Thu Jul 17 13:16:29 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC57A3A6813; Thu, 17 Jul 2008 13:16:29 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E3D3A6813 for ; Thu, 17 Jul 2008 13:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6FKSJ9r8KzW for ; Thu, 17 Jul 2008 13:16:28 -0700 (PDT) Received: from web84313.mail.re1.yahoo.com (web84313.mail.re1.yahoo.com [69.147.74.192]) by core3.amsl.com (Postfix) with SMTP id 62C323A6812 for ; Thu, 17 Jul 2008 13:16:28 -0700 (PDT) Received: (qmail 15408 invoked by uid 60001); 17 Jul 2008 20:17:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Eofzskwj12etYVSOnbrogOL00WTthViUNjFIBFrVmVzsrfORYM0SsrVA87XU0/YcOFOR5QGLICM7vfHyq/5Sl4DrISJrB5pEdBZoyhW32ksKAS+BiwXe7iSGx2NLINyfj7XzjclGAL9rDGlkrs/1tfUrqan0mQz9q1l5d9DZRDw=; Received: from [72.164.184.70] by web84313.mail.re1.yahoo.com via HTTP; Thu, 17 Jul 2008 13:16:59 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Thu, 17 Jul 2008 13:16:59 -0700 (PDT) From: Behcet Sarikaya To: Glen Zorn MIME-Version: 1.0 Message-ID: <73499.15313.qm@web84313.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0695771143==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0695771143== Content-Type: multipart/alternative; boundary="0-1249930434-1216325819=:15313" --0-1249930434-1216325819=:15313 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Glen Zorn To: Behcet Sarikaya ; Julien Bournelle Cc: dime@ietf.org Sent: Thursday, July 17, 2008 2:51:59 PM Subject: RE: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Hi Julien, The current mechanism was defined with a certain architecture in mind. It simply does not apply to so many new cases that have recently emerged all in mobile networks. We need a new application because of this. I would like to explain this in my presentation if I get a slot in Dublin. I think that it might be more useful to explain it in the document :-). Sure, next version, please Regards, Behcet --0-1249930434-1216325819=:15313 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Glen Zorn <glenzorn@comcast.net>
To: Behcet Sarikaya <sarikaya@ieee.org>; Julien Bournelle <julien.bournelle@gmail.com>
Cc: dime@ietf.org
Sent: Thursday, July 17, 2008 2:51:59 PM
Subject: RE: [Dime] Rechartering: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

Hi Julien,
  The current mechanism was defined with a certain architecture in mind. It simply does not apply to so many new cases that have recently emerged all in mobile networks. We need a new application because of this.
  I would like to explain this in my presentation if I get a slot in Dublin.

I think that it might be more useful to explain it in the document :-).


Sure, next version, please

 
Regards,

Behcet

--0-1249930434-1216325819=:15313-- --===============0695771143== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0695771143==-- From dime-bounces@ietf.org Fri Jul 18 05:58:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B733A681D; Fri, 18 Jul 2008 05:58:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138DB3A681D for ; Fri, 18 Jul 2008 05:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtztNw+bnCHU for ; Fri, 18 Jul 2008 05:58:07 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 224473A67A5 for ; Fri, 18 Jul 2008 05:58:07 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so255272rvf.49 for ; Fri, 18 Jul 2008 05:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=+oOZzInEXzj93zcddJxzYGmoOskHlqU04PiJSdXxIKo=; b=MU0AVelMDhe6z1YVisvCZyceXDXDjoocfQRG928XkV15adDSGUgSqp7DAVw4Dcborr K3hWaGxQi6pT8NFG9ZTYoiRigJQbjI57hgyQFysZhgG+V2G1y2LJEKyYIde7otmfunFV LybCsZfS7wd2+0CiSOjxlzmqgduArg6nhIfR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=MI3XJXjYEqt0GlCyWguwXW7AQYz3yOwNjeCWPjW6h8Qpcj+DNxaZgiW5Sy3hS3smRe vuCWP6hp1sizGlDS5U7gIrUZkMpLtIyCp6ch8wHxlPI5I3zdVR95FJFB/UTQRFwtJDuD 1dyR8XtX/85HExuPCB1Q7NI76Zs936iSo3fCM= Received: by 10.141.74.18 with SMTP id b18mr56555rvl.80.1216385920225; Fri, 18 Jul 2008 05:58:40 -0700 (PDT) Received: by 10.141.35.15 with HTTP; Fri, 18 Jul 2008 05:58:40 -0700 (PDT) Message-ID: <9cf5ced20807180558m5e2eb63t18d203283e764b2b@mail.gmail.com> Date: Fri, 18 Jul 2008 08:58:40 -0400 From: "David Frascone" To: "Gowda, Avinash" In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C05FDC3CA@exchindia3.starentnetworks.com> MIME-Version: 1.0 References: <1216015465.10553.13.camel@INDBNG1172.bng.ind.starentnetworks.com> <69FADB84C90B1248A7DE59422771FA0C05FDC3CA@exchindia3.starentnetworks.com> X-Google-Sender-Auth: 082d9b2ac004c48f Cc: dime@ietf.org Subject: Re: [Dime] DWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1373004998==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1373004998== Content-Type: multipart/alternative; boundary="----=_Part_46252_11108973.1216385920221" ------=_Part_46252_11108973.1216385920221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB0aGluayB0aGUgbmV3IHRleHQgaXMgbW9yZSBjbGVhci4KCi1EYXZlCgpPbiBNb24sIEp1bCAx NCwgMjAwOCBhdCAyOjE5IEFNLCBHb3dkYSwgQXZpbmFzaCA8YWdvd2RhQHN0YXJlbnRuZXR3b3Jr cy5jb20+Cndyb3RlOgoKPiAgSGkgQmlwbGFiLAo+Cj4KPgo+IFlvdXIgcHJvcG9zZWQgY2hhbmdl IGFuZCBleGlzdGluZyBzZW50ZW5jZSBtZWFuIHRoZSBzYW1lLiBFeGNoYW5nZSB3b3JkCj4gbWVh bnMgIlRoZSBhY3Qgb2YgZ2l2aW5nIHNvbWV0aGluZyBpbiByZXR1cm4gZm9yIHNvbWV0aGluZyBy ZWNlaXZlZCIuCj4KPgo+Cj4gSW4gbXkgb3BpbmlvbiB0aGUgZXhpc3Rpbmcgc2VudGVuY2UgYnJp bmdzIG91dCB0aGUgY29ycmVjdCBtZWFuaW5nLgo+Cj4KPgo+IEFueSBjb21tZW50cyBvbiB0aGlz Pwo+Cj4KPgo+IFRoYW5rcywKPgo+IEF2aW5hc2ggR293ZGEKPiAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+Cj4gKkZyb206KiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YKPiAqQmlwbGFiIFNhcmthcgo+ICpT ZW50OiogTW9uZGF5LCBKdWx5IDE0LCAyMDA4IDExOjM0IEFNCj4gKlRvOiogZGltZUBpZXRmLm9y Zwo+ICpTdWJqZWN0OiogW0RpbWVdIERXUgo+Cj4KPgo+IEhpIEFsbCwKPgo+IFdpdGggcmVmZXJl bmNlIHRvIFtSRkMzNTg4LWJpczExXVs1LjUuMV0uCj4KPiBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUtcmZjMzU4OGJpcy0xMS50eHQKPgo+IEkgdGhp bmsgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgbmVlZHMgYmUgY2hhbmdlZCB0by4KPgo+Cj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IDUuNS4xLiAgRGV2aWNlLVdh dGNoZG9nLVJlcXVlc3QKPgo+ICAgIFRoZSBEZXZpY2UtV2F0Y2hkb2ctUmVxdWVzdCAoRFdSKSwg aW5kaWNhdGVkIGJ5IHRoZSBDb21tYW5kLUNvZGUgc2V0Cj4gICAgdG8gMjgwIGFuZCB0aGUgQ29t bWFuZCBGbGFncycgJ1InIGJpdCBzZXQsIGlzIHNlbnQgdG8gYSBwZWVyIHdoZW4gbm8KPiAgICB0 cmFmZmljIGhhcyBiZWVuIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBwZWVycyAoc2VlIFNlY3Rpb24g NS41LjMpCj4gICAg77u/aW5jb21pbmcgdHJhZmZpYyB3YXMgcmVjZWl2ZWQgZnJvbSB0aGUgcGVl ci4KPiAgICBVcG9uIGRldGVjdGlvbiBvZiBhIHRyYW5zcG9ydCBmYWlsdXJlLCB0aGlzIG1lc3Nh Z2UgTVVTVCBOT1QgYmUgc2VudAo+ICAgIHRvIGFuIGFsdGVybmF0ZSBwZWVyLgo+Cj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPgo+IFRoZSBEV1ItdGltZXIgc2hv dWxkIGJlIG1vbml0b3JpbmcgdGhlIGluY29taW5nIHRyYWZmaWMgZnJvbSB0aGUgcGVlciBhbmQK PiBub3QgdGhlCj4gb3V0IGdvaW5nIG9uZS4KPgo+IEFueSBjb21tZW50cz8KPgo+IFRoYW5rcyAm IFJlZ2FyZHMKPiBCaXBsYWIKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gRGlNRSBtYWlsaW5nIGxpc3QKPiBEaU1FQGlldGYub3JnCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCj4KPgo= ------=_Part_46252_11108973.1216385920221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdiBkaXI9Imx0ciI+SSB0aGluayB0aGUgbmV3IHRleHQgaXMgbW9yZSBjbGVhci48YnI+PGJy Pi1EYXZlPGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBKdWwgMTQsIDIw MDggYXQgMjoxOSBBTSwgR293ZGEsIEF2aW5hc2ggJmx0OzxhIGhyZWY9Im1haWx0bzphZ293ZGFA c3RhcmVudG5ldHdvcmtzLmNvbSI+YWdvd2RhQHN0YXJlbnRuZXR3b3Jrcy5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1s ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAu OGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgoKCgoKCgoKCgo8ZGl2IGxpbms9ImJsdWUiIHZsaW5r PSJibHVlIiBsYW5nPSJFTi1VUyI+Cgo8ZGl2PgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9 IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPkhpIEJpcGxhYiw8L3NwYW4+PC9mb250PjwvcD4K CjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij4m bmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJk YW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VmVyZGFuYTsgY29sb3I6IGJsdWU7Ij5Zb3VyIHByb3Bvc2VkIGNoYW5nZSBhbmQgZXhpc3RpbmcK c2VudGVuY2UgbWVhbiB0aGUgc2FtZS4gRXhjaGFuZ2Ugd29yZCBtZWFucyAiVGhlIGFjdCBvZiBn aXZpbmcgc29tZXRoaW5nCmluJm5ic3A7cmV0dXJuIGZvciBzb21ldGhpbmcgcmVjZWl2ZWQiLjwv c3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5h OyBjb2xvcjogYmx1ZTsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9 ImJsdWUiIGZhY2U9IlZlcmRhbmEiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBjb2xvcjogYmx1ZTsiPkluIG15IG9waW5pb24gdGhl IGV4aXN0aW5nIHNlbnRlbmNlCmJyaW5ncyBvdXQgdGhlIGNvcnJlY3QgbWVhbmluZy48L3NwYW4+ PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFuYTsgY29s b3I6IGJsdWU7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVl IiBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogVmVyZGFuYTsgY29sb3I6IGJsdWU7Ij5BbnkgY29tbWVudHMgb24gdGhpcz88 L3NwYW4+PC9mb250PjwvcD4KCjxwPjxmb250IGNvbG9yPSJibHVlIiBmYWNlPSJWZXJkYW5hIiBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVmVyZGFu YTsgY29sb3I6IGJsdWU7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvcD4KCjxkaXY+Cgo8cD48Zm9u dCBjb2xvcj0iYmx1ZSIgZmFjZT0iVmVyZGFuYSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGNvbG9yOiBibHVlOyI+VGhhbmtzLDwv c3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsdWUiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmx1ZTsi Pjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPHA+PGZvbnQgY29sb3I9ImJsdWUiIGZhY2U9IlZlcmRhbmEi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJk YW5hOyBjb2xvcjogYmx1ZTsiPkF2aW5hc2ggR293ZGE8L3NwYW4+PC9mb250PjwvcD4KCjwvZGl2 PgoKPGRpdj4KCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlcjsiIGFsaWduPSJjZW50ZXIi Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsiPgoKPGhyIGFsaWduPSJjZW50ZXIiIHNpemU9IjIiIHdpZHRoPSIxMDAlIj4K Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+Cgo8cD48Yj48Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWE7IGZvbnQt d2VpZ2h0OiBib2xkOyI+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEi IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWE7Ij4gPGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvYT4KW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGlt ZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGltZS1ib3VuY2VzQGlldGYub3Jn PC9hPl0gPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+T24gQmVoYWxmIE9mIDwv c3Bhbj48L2I+QmlwbGFiClNhcmthcjxicj4KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBi b2xkOyI+U2VudDo8L3NwYW4+PC9iPiBNb25kYXksIEp1bHkgMTQsIDIwMDggMTE6MzQKQU08YnI+ CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlRvOjwvc3Bhbj48L2I+IDxhIGhy ZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGltZUBpZXRmLm9yZzwv YT48YnI+CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsiPlN1YmplY3Q6PC9zcGFu PjwvYj4gW0RpbWVdIERXUjwvc3Bhbj48L2ZvbnQ+PC9wPgoKPC9kaXY+PGRpdj48ZGl2PjwvZGl2 PjxkaXYgY2xhc3M9IldqM0M3YyI+Cgo8cD48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvcD4KCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PGZvbnQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPSIzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+SGkgQWxs LDxicj4KPGJyPgpXaXRoIHJlZmVyZW5jZSB0byBbUkZDMzU4OC1iaXMxMV1bNS41LjFdLjxicj4K PGJyPgo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWRpbWUtcmZjMzU4OGJpcy0xMS50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUtcmZjMzU4OGJpcy0xMS50eHQ8 L2E+PGJyPgo8YnI+CkkgdGhpbmsgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgbmVlZHMgYmUgY2hh bmdlZCB0by48YnI+Cjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4KPGEgaHJlZj0iaHR0cDovLzUuNS4xLiIgdGFyZ2V0PSJfYmxhbmsiPjUuNS4xLjwvYT4m bmJzcDsgRGV2aWNlLVdhdGNoZG9nLVJlcXVlc3Q8YnI+Cjxicj4KJm5ic3A7Jm5ic3A7IFRoZSBE ZXZpY2UtV2F0Y2hkb2ctUmVxdWVzdCAoRFdSKSwgaW5kaWNhdGVkIGJ5IHRoZSBDb21tYW5kLUNv ZGUKc2V0PGJyPgombmJzcDsmbmJzcDsgdG8gMjgwIGFuZCB0aGUgQ29tbWFuZCBGbGFncyYjMzk7 ICYjMzk7UiYjMzk7IGJpdCBzZXQsIGlzIHNlbnQgdG8gYSBwZWVyIHdoZW4Kbm88YnI+CiZuYnNw OyZuYnNwOyA8cz48Zm9udCBjb2xvcj0iYmx1ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibHVlOyI+ dHJhZmZpYyBoYXMgYmVlbgpleGNoYW5nZWQgYmV0d2VlbiB0d28gcGVlcnMgKHNlZSBTZWN0aW9u IDUuNS4zKSA8L3NwYW4+PC9mb250Pjwvcz48YnI+CiZuYnNwOyZuYnNwOyA8Zm9udCBjb2xvcj0i cmVkIj48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsiPu+7v2luY29taW5nIHRyYWZmaWMgd2FzCnJl Y2VpdmVkIGZyb20gdGhlIHBlZXIuPC9zcGFuPjwvZm9udD48YnI+CiZuYnNwOyZuYnNwOyBVcG9u IGRldGVjdGlvbiBvZiBhIHRyYW5zcG9ydCBmYWlsdXJlLCB0aGlzIG1lc3NhZ2UgTVVTVCBOT1Qg YmUKc2VudDxicj4KJm5ic3A7Jm5ic3A7IHRvIGFuIGFsdGVybmF0ZSBwZWVyLjxicj4KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPgo8YnI+Cjxicj4KVGhlIERXUi10 aW1lciBzaG91bGQgYmUgbW9uaXRvcmluZyB0aGUgaW5jb21pbmcgdHJhZmZpYyBmcm9tIHRoZSBw ZWVyIGFuZCBub3QKdGhlPGJyPgpvdXQgZ29pbmcgb25lLjxicj4KPGJyPgpBbnkgY29tbWVudHM/ PGJyPgo8YnI+ClRoYW5rcyAmYW1wOyBSZWdhcmRzPGJyPgpCaXBsYWI8L3NwYW4+PC9mb250Pjwv cD4KCjwvZGl2PjwvZGl2PjwvZGl2PgoKPC9kaXY+CgoKPGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpEaU1FIG1haWxpbmcgbGlzdDxicj4KPGEg aHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPkRpTUVAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2E+PGJyPgo8 YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4K ------=_Part_46252_11108973.1216385920221-- --===============1373004998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1373004998==-- From dime-bounces@ietf.org Fri Jul 18 08:18:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7B128C16F; Fri, 18 Jul 2008 08:18:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF5D3A6AD8 for ; Fri, 18 Jul 2008 08:18:51 -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 rGmfwrPOjT7h for ; Fri, 18 Jul 2008 08:18:50 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id EA2193A6AD5 for ; Fri, 18 Jul 2008 08:18:49 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6IFJMWI029441 for ; Fri, 18 Jul 2008 11:19:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 11:19:22 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701205A16@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments for draft-ietf-dime-diameter-qos-06 Thread-Index: Acjo6afVLb+dDOO0SRK2OIBfMdi1Vg== From: "Asveren, Tolga" To: Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org 1- Use of the same Application-Id for push/pull models It sounds reasonable to me to think nodes which support only a single mode. How can we guarantee that messages land to the right server considering that the same Application-Id is used for both of them? 2- 3. Framework "After receiving the authorization request from the AppS or the NE, the AE decides the appropriate mode (i.e. Push or Pull). The usage Push or Pull mode can be determined by the authorizing entity either statically or dynamically." I think I am missing something here. Don't we have always push mode if the authorization request is received from AppS? Or are we talking about a hybrid model where first AppS contacts the Authorizing Entity, receives a token, hands it over to media layer, and this token is used in turn by NE for pull mode? 3- 3. Framework "For Push mode, the authorizing entity needs to identify the appropriate NE(s) to which QoS authorization information needs to be pushed. It might determine this based on information received from the AppS, such as the IP addresses of media flows." It could be a good idea to give a bit more information about this: - This is hard to do as Authorizing Entity would need to have information about routing decisions of NEs for a particular flow - QoS in the core network is usually not scarce - QoS on the access side is scarce - It is not difficult for the Authorizing Entity to determine NEs facing the access side as usually this information is stored somewhere when the endpoint attaches to the network and does not change per IP flow. 4- 3.4 QoS Application Requirements "Identity-based Routing The QoS AAA protocol MUST route AAA requests to the Authorizing Entity, based on the provided identity of the QoS requesting entity or the identity of the AE encoded in the provided authorization token." I think it is responsibility of the QoS application -not QoS AAA protocol- to perform routing decision based on identity. The application decided for the host/realm and the protocol routes the message based on that. I think it could be better to have a global change in this section: QoS AAA protocol ==> QoS AAA application 5- 3.4 QoS Application Requirements "Sending Accounting Records The NE SHOULD be able to send accounting records for a particular QoS reservation state to an accounting entity." Is this a QoS AAA application requirement? It is stated as a requirement on NE. 6- 4.2 Session Establishment "When a QoS-Authz-Request (QAR, see Section 5.1) message with a new session ID is received, the AE operates in the Pull mode; when other triggers are received, the AE operates in the Push mode." Would this shut down the door for certain failure recovery scenarios? For example AE goes down and a backup AE takes over. IMO it is a nice feature if the backup can continue existing sessions without a need to synchronizing state with the failed active AE. This can be achieved by carrying enough information about session state in the message itself (AFAIR, DCCA can do this nicely). The approach I quoted makes this impossible. For certain scenarios backup AE would determine the required mode wrong. I suggest the decision for push/pull is not based on message name but on the message content. 7- There were some proposals about a mode, where NE is notified from AE to reserve resources all the way till the end point. Is this considered out of scope? Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Jul 20 20:23:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5D63A695D; Sun, 20 Jul 2008 20:23:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B3E3A695D for ; Sun, 20 Jul 2008 20:23:40 -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 d1GjxzNZVmNw for ; Sun, 20 Jul 2008 20:23:39 -0700 (PDT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by core3.amsl.com (Postfix) with SMTP id 150263A67EF for ; Sun, 20 Jul 2008 20:23:38 -0700 (PDT) Received: (qmail 24121 invoked from network); 21 Jul 2008 03:24:13 -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=d0f3RHL/tQ5tSNFkcu+6QqjwMLjnEPq8rpnlte82EMWqNAF5JxhWOFpXaZLu9/xyCz41Ci/4OBA4dwfMVBRsmwGmFvc52106AXTyKzOa0Ta+hCq4kJLJEkMaTDRUWjraXoypqM4ZiTmwiciMSb6tBiD6wluF4gsAHXSvOKJwi6U= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 21 Jul 2008 03:24:13 -0000 X-YMail-OSG: 1nZfyTIVM1kVfdU4sfwUYym7xzqBLyy6kYSwd4dfy0B_4hSG2XzhqZGuaPsCtQaVjw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48840163.9040208@rogers.com> Date: Sun, 20 Jul 2008 23:24:19 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: David Frascone References: <1216015465.10553.13.camel@INDBNG1172.bng.ind.starentnetworks.com> <69FADB84C90B1248A7DE59422771FA0C05FDC3CA@exchindia3.starentnetworks.com> <9cf5ced20807180558m5e2eb63t18d203283e764b2b@mail.gmail.com> In-Reply-To: <9cf5ced20807180558m5e2eb63t18d203283e764b2b@mail.gmail.com> Cc: dime@ietf.org Subject: Re: [Dime] DWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org SSBhZ3JlZS4KCkRhdmlkIEZyYXNjb25lIHdyb3RlOgo+IEkgdGhpbmsgdGhlIG5ldyB0ZXh0IGlz IG1vcmUgY2xlYXIuCj4gCj4gLURhdmUKPiAKPiBPbiBNb24sIEp1bCAxNCwgMjAwOCBhdCAyOjE5 IEFNLCBHb3dkYSwgQXZpbmFzaCA8YWdvd2RhQHN0YXJlbnRuZXR3b3Jrcy5jb20+Cj4gd3JvdGU6 Cj4gCj4+ICBIaSBCaXBsYWIsCj4+Cj4+Cj4+Cj4+IFlvdXIgcHJvcG9zZWQgY2hhbmdlIGFuZCBl eGlzdGluZyBzZW50ZW5jZSBtZWFuIHRoZSBzYW1lLiBFeGNoYW5nZSB3b3JkCj4+IG1lYW5zICJU aGUgYWN0IG9mIGdpdmluZyBzb21ldGhpbmcgaW4gcmV0dXJuIGZvciBzb21ldGhpbmcgcmVjZWl2 ZWQiLgo+Pgo+Pgo+Pgo+PiBJbiBteSBvcGluaW9uIHRoZSBleGlzdGluZyBzZW50ZW5jZSBicmlu Z3Mgb3V0IHRoZSBjb3JyZWN0IG1lYW5pbmcuCj4+Cj4+Cj4+Cj4+IEFueSBjb21tZW50cyBvbiB0 aGlzPwo+Pgo+Pgo+Pgo+PiBUaGFua3MsCj4+Cj4+IEF2aW5hc2ggR293ZGEKPj4gICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4KPj4gKkZyb206KiBkaW1lLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YKPj4gKkJpcGxh YiBTYXJrYXIKPj4gKlNlbnQ6KiBNb25kYXksIEp1bHkgMTQsIDIwMDggMTE6MzQgQU0KPj4gKlRv OiogZGltZUBpZXRmLm9yZwo+PiAqU3ViamVjdDoqIFtEaW1lXSBEV1IKPj4KPj4KPj4KPj4gSGkg QWxsLAo+Pgo+PiBXaXRoIHJlZmVyZW5jZSB0byBbUkZDMzU4OC1iaXMxMV1bNS41LjFdLgo+Pgo+ PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUtcmZj MzU4OGJpcy0xMS50eHQKPj4KPj4gSSB0aGluayB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBuZWVk cyBiZSBjaGFuZ2VkIHRvLgo+Pgo+Pgo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4+IDUuNS4xLiAgRGV2aWNlLVdhdGNoZG9nLVJlcXVlc3QKPj4KPj4gICAgVGhl IERldmljZS1XYXRjaGRvZy1SZXF1ZXN0IChEV1IpLCBpbmRpY2F0ZWQgYnkgdGhlIENvbW1hbmQt Q29kZSBzZXQKPj4gICAgdG8gMjgwIGFuZCB0aGUgQ29tbWFuZCBGbGFncycgJ1InIGJpdCBzZXQs IGlzIHNlbnQgdG8gYSBwZWVyIHdoZW4gbm8KPj4gICAgdHJhZmZpYyBoYXMgYmVlbiBleGNoYW5n ZWQgYmV0d2VlbiB0d28gcGVlcnMgKHNlZSBTZWN0aW9uIDUuNS4zKQo+PiAgICDvu79pbmNvbWlu ZyB0cmFmZmljIHdhcyByZWNlaXZlZCBmcm9tIHRoZSBwZWVyLgo+PiAgICBVcG9uIGRldGVjdGlv biBvZiBhIHRyYW5zcG9ydCBmYWlsdXJlLCB0aGlzIG1lc3NhZ2UgTVVTVCBOT1QgYmUgc2VudAo+ PiAgICB0byBhbiBhbHRlcm5hdGUgcGVlci4KPj4KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCj4+Cj4+Cj4+IFRoZSBEV1ItdGltZXIgc2hvdWxkIGJlIG1vbml0b3Jp bmcgdGhlIGluY29taW5nIHRyYWZmaWMgZnJvbSB0aGUgcGVlciBhbmQKPj4gbm90IHRoZQo+PiBv dXQgZ29pbmcgb25lLgo+Pgo+PiBBbnkgY29tbWVudHM/Cj4+Cj4+IFRoYW5rcyAmIFJlZ2FyZHMK Pj4gQmlwbGFiCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4+IERpTUUgbWFpbGluZyBsaXN0Cj4+IERpTUVAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lCj4+Cj4+Cj4+Cj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+PiBEaU1FIG1haWxpbmcgbGlzdAo+PiBEaU1FQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpEaU1FIG1haWxpbmcgbGlzdApEaU1FQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQo= From dime-bounces@ietf.org Mon Jul 21 05:19:22 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CFC3A69D3; Mon, 21 Jul 2008 05:19:22 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495E43A69EA for ; Mon, 21 Jul 2008 05:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 oOcnJYPp+w-H for ; Mon, 21 Jul 2008 05:19: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 545743A69D3 for ; Mon, 21 Jul 2008 05:19: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 m6LBsbK7011113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Jul 2008 13:54:37 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6LBsbRw011499 for ; Mon, 21 Jul 2008 13:54:37 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 13:54:37 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jul 2008 13:54:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 14:54:37 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda Thread-Index: AcjrKIzAc3OS0TSJT6WGCdgT/8KDsw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 21 Jul 2008 11:54:36.0548 (UTC) FILETIME=[8C524440:01C8EB28] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16044.007 X-TM-AS-Result: No--4.845000-8.000000-31 Subject: [Dime] Agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660321674==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0660321674== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB28.8C5056FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EB28.8C5056FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have uploaded a version of the agenda: http://www.ietf.org/proceedings/08jul/agenda/dime.txt ------_=_NextPart_001_01C8EB28.8C5056FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda

I have uploaded a version of the = agenda:
http://www.ietf.org/proceedings/08jul/agenda/dime.txt=

------_=_NextPart_001_01C8EB28.8C5056FA-- --===============0660321674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0660321674==-- From dime-bounces@ietf.org Mon Jul 21 08:49:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04783A692B; Mon, 21 Jul 2008 08:49:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4968A3A689C for ; Mon, 21 Jul 2008 08:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 Wook7DIuFJbK for ; Mon, 21 Jul 2008 08:49:49 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 440D63A6828 for ; Mon, 21 Jul 2008 08:49:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,224,1215403200"; d="scan'208";a="136244999" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 21 Jul 2008 11:50:24 -0400 X-IronPort-AV: E=Sophos;i="4.31,224,1215403200"; d="scan'208";a="239720650" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2008 11:50:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Jul 2008 17:50:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-sun-dime-itu-t-rw (Diameter ITU-T Rw Policy Enforcement Interface Application) to Informational RFC Thread-Index: AcjrR4frb2CXu7qrSvON2jUmcFtJAwAAe31A From: "Romascanu, Dan (Dan)" To: Subject: [Dime] FW: Last Call: draft-sun-dime-itu-t-rw (Diameter ITU-T Rw Policy Enforcement Interface Application) to Informational RFC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, July 21, 2008 6:35 PM To: IETF-Announce Subject: Last Call: draft-sun-dime-itu-t-rw (Diameter ITU-T Rw Policy Enforcement Interface Application) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Diameter ITU-T Rw Policy Enforcement Interface Application ' as an Informational RFC 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 2008-08-18. 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-sun-dime-itu-t-rw-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 17030&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 22 06:05:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A703A68A0; Tue, 22 Jul 2008 06:05:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359543A6822 for ; Tue, 22 Jul 2008 06:05:11 -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 Y9rXMPFowPo4 for ; Tue, 22 Jul 2008 06:05:10 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 9CA9A3A68A0 for ; Tue, 22 Jul 2008 06:05:09 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1255786tib.25 for ; Tue, 22 Jul 2008 06:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=+URatz3zzNpbGMK78+XAUv7AFEpd+t7nCCl9TRazc6A=; b=FHL4WelkAHtyiePQZD+GJBf0rKIHHIVLIG61XdI/hIzhYOZnDkOc+mi2rzdOjGXlQf sUquFUKUy9n+mzttDvgaMYfKfcMNW7ZtvL80GktErvLWFUTFQS4myyKuivY6j+Bi8Bzt Jl+d0gBlob9mHaAor7BeV5eD2bNIp7IoUHbtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=RAKyBtt2Qeefho7PkooMZz+4CGzNvFl+Oc2x4LCf7ubfJc4IR9qASktjii75AYOpF9 MGA0cy71ZAx7sBvLyAaDqIhX8VyDZlv3662Q3UcyQWJUlQvBD9x5Sc6m7J4aYWWw7hFY zxyCjbJmQp/J2kQ8Lgn2W7dJv/o0XCtWX1jf8= Received: by 10.110.68.10 with SMTP id q10mr4532531tia.37.1216731949175; Tue, 22 Jul 2008 06:05:49 -0700 (PDT) Received: by 10.110.28.2 with HTTP; Tue, 22 Jul 2008 06:05:49 -0700 (PDT) Message-ID: Date: Tue, 22 Jul 2008 22:05:49 +0900 From: "Jong-Hyouk Lee" To: "Hannes Tschofenig" In-Reply-To: <487CED0B.90103@gmx.net> MIME-Version: 1.0 References: <487CED0B.90103@gmx.net> Cc: dime@ietf.org, "julien.bournelle@orange-ftgroup.com" Subject: Re: [Dime] Rechartering: draft-korhonen-dime-pmip6 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1910999878==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1910999878== Content-Type: multipart/alternative; boundary="----=_Part_95759_5768772.1216731949150" ------=_Part_95759_5768772.1216731949150 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all. Please, see inline. On Wed, Jul 16, 2008 at 3:31 AM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > [Jong-Hyouk Lee] I can take the reviewer role on this document. > > * Who is unable to actively help but supports it? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By "finished" I > mean "ready for WGLC".) > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > -- Internet Management Technology Lab, Sungkyunkwan University. Jong-Hyouk Lee. #email: jonghyouk (at) gmail (dot) com #webpage: http://cv.hurryon.org ------=_Part_95759_5768772.1216731949150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, all.
 
Please, see inline.

On Wed, Jul 16, 2008 at 3:31 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Document: http://tools.ietf.org/id/draft-korhonen-dime-pmip6-03.txt

* Who is able to be editor of the document?

* Who is interested to help the editor with the work on the draft by co-authoring it?

* Who is able to provide reviews?
 
[Jong-Hyouk Lee]
I can take the reviewer role on this document.
 

* Who is unable to actively help but supports it?

* Are there concerns regarding this document?

* Is there a dependency with another IETF working group or with another SDO?

* How long will it take to finish this document?
(A rough guess based on the current status of the document. By "finished" I mean "ready for WGLC".)


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



--
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://cv.hurryon.org
------=_Part_95759_5768772.1216731949150-- --===============1910999878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1910999878==-- From dime-bounces@ietf.org Tue Jul 22 15:40:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5E13A6A7D; Tue, 22 Jul 2008 15:40:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C716E3A6A59 for ; Tue, 22 Jul 2008 15:40: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=[AWL=-0.001, 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 wjGC+C-VrKiZ for ; Tue, 22 Jul 2008 15:40:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 175A33A6A7D for ; Tue, 22 Jul 2008 15:40:15 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6MMefIk011551; Tue, 22 Jul 2008 17:40:41 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:40:40 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:40:39 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgA References: From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 22 Jul 2008 22:40:40.0775 (UTC) FILETIME=[F803A570:01C8EC4B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2141237298==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2141237298== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC4B.F7D9CCBB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8EC4B.F7D9CCBB Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Tolga, =20 Thanks for review and comments. see my responses inline... copy to all authors in case they have further comments. =20 Rgs, Dong -------- Original Message --------=20 Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 =20 Date: Fri, 18 Jul 2008 11:19:22 -0400=20 From: Asveren, Tolga =20 To: =20 1- Use of the same Application-Id for push/pull models It sounds reasonable to me to think nodes which support only a single mode. How can we guarantee that messages land to the right server considering that the same Application-Id is used for both of them? [Sun, Dong (Dong)] The trigger for initiating the push and pull models is different, for example, when a new request from the PEP is recevied, the Server will start the pull model. In fact, the push and pull are sharing the same state machine per se. the main difference is just how to establish a Diameter session. The enhancement is to allow the Diameter Server to establish a session with a local trigger instead of the trigger from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same application-Id causes any problem, especially for the pull model since push/pull is able use the same server (certainly they can also have separate server according to the configuration). 2- 3. Framework "After receiving the authorization request from the AppS or the NE, the AE decides the appropriate mode (i.e. Push or Pull). The usage Push or Pull mode can be determined by the authorizing entity either statically or dynamically." I think I am missing something here. Don't we have always push mode if the authorization request is received from AppS? Or are we talking about a hybrid model where first AppS contacts the Authorizing Entity, receives a token, hands it over to media layer, and this token is used in turn by NE for pull mode? [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my understanding is that the push and pull models can be decided by AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). If this is correct, the texts may be modified as follows for clarity: "The push and pull models can be decided by the AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). Without any pre-configuration, when receiving a new authorization request from the Apps or a local trigger, the AE starts the Push model; when receiving a new authorization request from the NE, the AE starts the Pull model." [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could you verify my comment or give some further clafication. are you ok with the modified texts?=20 I will update the document accordingly if no objection.=20 3- 3. Framework "For Push mode, the authorizing entity needs to identify the appropriate NE(s) to which QoS authorization information needs to be pushed. It might determine this based on information received from the AppS, such as the IP addresses of media flows." It could be a good idea to give a bit more information about this: - This is hard to do as Authorizing Entity would need to have information about routing decisions of NEs for a particular flow - QoS in the core network is usually not scarce - QoS on the access side is scarce - It is not difficult for the Authorizing Entity to determine NEs facing the access side as usually this information is stored somewhere when the endpoint attaches to the network and does not change per IP flow. [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery of these NEs is not necessarily based on the routing info, instead, it can be preconfigured.=20 In addition, i think this draft mainly focuses on the mechanism and protocol. It can be used for both access and core networks. the QoS status you described looks like well known, not sure how much it may add. 4- 3.4 QoS Application Requirements "Identity-based Routing The QoS AAA protocol MUST route AAA requests to the Authorizing Entity, based on the provided identity of the QoS requesting entity or the identity of the AE encoded in the provided authorization token." I think it is responsibility of the QoS application -not QoS AAA protocol- to perform routing decision based on identity. The application decided for the host/realm and the protocol routes the message based on that. I think it could be better to have a global change in this section: QoS AAA protocol =3D=3D> QoS AAA application [Sun, Dong (Dong)] looks ok to me. 5- 3.4 QoS Application Requirements "Sending Accounting Records The NE SHOULD be able to send accounting records for a particular QoS reservation state to an accounting entity." Is this a QoS AAA application requirement? It is stated as a requirement on NE. [Sun, Dong (Dong)] it is for NE, since we decided to remove the accounting related texts, this one could be gone, IMHO.=20 6- 4.2 Session Establishment "When a QoS-Authz-Request (QAR, see Section 5.1) message with a new session ID is received, the AE operates in the Pull mode; when other triggers are received, the AE operates in the Push mode." Would this shut down the door for certain failure recovery scenarios? For example AE goes down and a backup AE takes over. IMO it is a nice feature if the backup can continue existing sessions without a need to synchronizing state with the failed active AE. This can be achieved by carrying enough information about session state in the message itself (AFAIR, DCCA can do this nicely). The approach I quoted makes this impossible. For certain scenarios backup AE would determine the required mode wrong. I suggest the decision for push/pull is not based on message name but on the message content. [Sun, Dong (Dong)] I think this is the most straightforward and consistent way in terms of state machine to decide the pull/push. and it will work well for the hot standby case, but indeed, it may have some issue with cold standby. In general, the failure handling is not addressed in the draft very much. The question is, do we need to add the failure handling in detail or not for backup server case?=20 7- There were some proposals about a mode, where NE is notified from AE to reserve resources all the way till the end point. Is this considered out of scope? [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but it is not a different mode, just an implementation of resource reservation within the bearer layer. it is mentioned in the section 9 as example. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =20 ------_=_NextPart_001_01C8EC4B.F7D9CCBB Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [Fwd: [Dime] Comments for = draft-ietf-dime-diameter-qos-06]
Hi Tolga,
 
Thanks for review and comments. see = my responses=20 inline...
copy to all authors in case they have further = comments.
 
Rgs,
Dong


-------- Original Message = --------=20
Subject:=20        [Dime] Comments = for=20 draft-ietf-dime-diameter-qos-06     =
Date:   Fri, 18 Jul 2008 = 11:19:22=20 -0400
From:   Asveren, Tolga <tasveren@sonusnet.com> =20
To:     <dime@ietf.org>

1- Use of the same Application-Id = for=20 push/pull models
It sounds reasonable to me to think nodes which = support only=20 a single
mode. How can we guarantee that messages land to the right=20 server
considering that the same Application-Id is used for both of=20 them?
[Sun,=20 Dong (Dong)]  The trigger for initiating the push and pull = models is=20 different, for example, when a new request from the PEP is recevied, the = Server=20 will start the pull model. In fact, the push and pull are sharing the = same state=20 machine per se. the main difference is just how to establish a Diameter = session.=20 The enhancement is to allow the Diameter Server to establish a session = with a=20 local trigger instead of the trigger from the Diameter client (i.e. = NE/PEP).=20 Therefore, I don't think the same application-Id causes any problem, = especially=20 for the pull model since push/pull is able use the same server = (certainly they=20 can also have separate server according to the=20 configuration).

2- 3. Framework
   = "After=20 receiving the
   authorization request from the AppS or the = NE, the=20 AE decides the
   appropriate mode (i.e.  Push or = Pull). =20 The usage Push or Pull mode
   can be determined by the = authorizing=20 entity either statically or
   dynamically."
I think I = am=20 missing something here. Don't we have always push mode if
the = authorization=20 request is received from AppS? Or are we talking about
a hybrid model = where=20 first AppS contacts the Authorizing Entity,
receives a token, hands = it over=20 to media layer, and this token is used
in turn by NE for pull = mode?
[Sun, Dong = (Dong)] I don't think we are talking about a hybrid model. my = understanding=20 is that the push and pull models can be decided by AE on per call = session basis=20 (i.e. dynamically), or can be pre-configured for one of them (i.e.=20 statically). If this is correct, the texts may be modified as = follows for=20 clarity:

 "The push and pull models can be decided by = the AE=20 on per call session basis (i.e. dynamically), or can = be pre-configured for=20 one of them (i.e. statically). Without any pre-configuration, when = receiving a=20 new authorization request from the Apps or a local trigger, the AE = starts the=20 Push model; when receiving a new authorization request from the NE, the = AE=20 starts the Pull model."

[Sun, Dong=20 (Dong)] Tina,  I thought the initial texts come from you. = could=20 you verify my comment or give some further clafication. are you ok with = the=20 modified texts?

I will update the document accordingly if no=20 objection. 


3- 3.=20 Framework
   "For Push mode, the authorizing entity needs = to=20 identify the
   appropriate NE(s) to which QoS = authorization=20 information needs to be
   pushed.  It might determine = this=20 based on information received from
   the AppS, such as the = IP=20 addresses of media flows."
It could be a good idea to give a bit more = information about this:
- This is hard to do as Authorizing Entity = would need=20 to have
information about routing decisions of NEs for a particular=20 flow
-  QoS in the core network is usually not scarce
-  = QoS on=20 the access side is scarce
-  It is not difficult for the = Authorizing=20 Entity to determine NEs
facing the access side as usually this = information is=20 stored somewhere
when the endpoint attaches to the network and does = not=20 change per IP
flow.
[Sun, Dong (Dong)]  my understanding is the = NEs for=20 Policy enforcement are usually some anchoring nodes e.g. DSLAM, Gateway, = LER=20 etc. the discovery of these NEs is not necessarily based on the routing = info,=20 instead, it can be preconfigured.

In=20 addition, i think this draft mainly focuses on the mechanism and = protocol. It=20 can be used for both access and core networks. the QoS status you = described=20 looks like well known, not sure how much it may=20 add.

4- 3.4 QoS Application=20 Requirements

      "Identity-based=20 Routing
      The QoS AAA protocol MUST = route AAA=20 requests to the Authorizing
      Entity, = based on=20 the provided identity of the QoS = requesting
     =20 entity or the identity of the AE encoded in the=20 provided
      authorization = token."

I think=20 it is responsibility of the QoS application -not QoS AAA
protocol- to = perform=20 routing decision based on identity. The application
decided for the=20 host/realm and the protocol routes the message based = on
that.

I think=20 it could be better to have a global change in this section:
QoS AAA = protocol=20 =3D=3D> QoS AAA application

[Sun, Dong (Dong)]  looks ok to=20 me.

5- 3.4 QoS Application=20 Requirements
      "Sending Accounting=20 Records
      The NE SHOULD be able to send=20 accounting records for a particular
      = QoS=20 reservation state to an accounting entity."
Is this a QoS AAA = application=20 requirement? It is stated as a requirement
on NE.

[Sun, Dong (Dong)]  it is for NE, = since we=20 decided to remove the accounting related texts, this one could be gone, = IMHO.=20



6- 4.2 Session Establishment
   = "When a=20 QoS-Authz-Request
   (QAR, see Section 5.1) message with a = new=20 session ID is received, the
   AE operates in the Pull = mode; when=20 other triggers are received, the
   AE operates in the Push = mode."
Would this shut down the door for certain failure recovery=20 scenarios?
For example AE goes down and a backup AE takes over. IMO = it is a=20 nice
feature if the backup can continue existing sessions without a = need=20 to
synchronizing state with the failed active AE. This can be = achieved=20 by
carrying enough information about session state in the message=20 itself
(AFAIR, DCCA can do this nicely). The approach I quoted makes=20 this
impossible. For certain scenarios backup AE would determine the=20 required
mode wrong. I suggest the decision for push/pull is not = based on=20 message
name but on the message content.

[Sun,=20 Dong (Dong)]  I think this is the most straightforward and = consistent=20 way in terms of state machine to decide the pull/push. and it will work = well for=20 the hot standby case, but indeed, it may have some issue with cold = standby. In=20 general, the failure handling is not addressed in the draft very much. = The=20 question is, do we need to add the failure handling in detail or not for = backup=20 server case?

7- There were some = proposals=20 about a mode, where NE is notified from AE
to reserve resources all = the way=20 till the end point. Is this considered
out of scope?

[Sun, Dong (Dong)]  it can be supporoted = implicited by=20 the applicaion, but it is not a different mode, just an implementation = of=20 resource reservation within the bearer layer. it is mentioned in the = section 9=20 as=20 example.


Thanks,
Tolga

_______________= ________________________________
DiME=20 mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime=20

------_=_NextPart_001_01C8EC4B.F7D9CCBB-- --===============2141237298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2141237298==-- From dime-bounces@ietf.org Tue Jul 22 18:16:41 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1693A67EB; Tue, 22 Jul 2008 18:16:41 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94D63A67EB for ; Tue, 22 Jul 2008 18:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 q3SJ8Kj1u8lI for ; Tue, 22 Jul 2008 18:16:40 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 001983A67E2 for ; Tue, 22 Jul 2008 18:16:40 -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 <0K4F00K68Q8VL0@szxga02-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 09:17:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4F0094KQ8VWF@szxga02-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 09:17:19 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4F00AOZQ8VOG@szxml03-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 09:17:19 +0800 (CST) Date: Wed, 23 Jul 2008 09:17:19 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <007a01c8ec61$da366580$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal Subject: [Dime] explicit routing and NAI considered for rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1567624987==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1567624987== Content-type: multipart/alternative; boundary="Boundary_(ID_GF87zKIv2b/nBDwdjoGeFQ)" This is a multi-part message in MIME format. --Boundary_(ID_GF87zKIv2b/nBDwdjoGeFQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi All, Could explicit routing draft be considered together with Jouni's NAI draft? http://www.ietf.org/proceedings/08jul/agenda/dime.txt B. R. Tina --Boundary_(ID_GF87zKIv2b/nBDwdjoGeFQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi All,
Could explicit routing draft be considered together with Jouni's NAI draft?
 
 
B. R.
Tina
--Boundary_(ID_GF87zKIv2b/nBDwdjoGeFQ)-- --===============1567624987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1567624987==-- From dime-bounces@ietf.org Tue Jul 22 19:44:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8B393A692D; Tue, 22 Jul 2008 19:44:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDAA3A692D for ; Tue, 22 Jul 2008 19:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, 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 tB6HACVmArXh for ; Tue, 22 Jul 2008 19:44:47 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C9A103A68D8 for ; Tue, 22 Jul 2008 19:44:46 -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 <0K4F00K1YUBQL0@szxga02-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 10:45:27 +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 <0K4F00D50UBQLE@szxga02-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 10:45:26 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4F00LSEUBPDC@szxml04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 10:45:26 +0800 (CST) Date: Wed, 23 Jul 2008 10:45:25 +0800 From: Tina TSOU To: tasveren@sonusnet.com, "Sun, Dong (Dong)" Message-id: <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0684519151==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0684519151== Content-type: multipart/alternative; boundary="Boundary_(ID_aigIIbZgkhlTxkVqbM4H6g)" This is a multi-part message in MIME format. --Boundary_(ID_aigIIbZgkhlTxkVqbM4H6g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]Hi Tolga, Dong et al, See comments in line beginning with [Tina: ...] Cheers from 30 degree hot Shenzhen, Tina ----- Original Message ----- From: Sun, Dong (Dong) To: tasveren@sonusnet.com Cc: dime@ietf.org ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Tina TSOU ; Glen Zorn Sent: Wednesday, July 23, 2008 6:40 AM Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Tolga, Thanks for review and comments. see my responses inline... copy to all authors in case they have further comments. Rgs, Dong -------- Original Message -------- Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 Date: Fri, 18 Jul 2008 11:19:22 -0400 From: Asveren, Tolga To: 1- Use of the same Application-Id for push/pull models It sounds reasonable to me to think nodes which support only a single mode. How can we guarantee that messages land to the right server considering that the same Application-Id is used for both of them? [Sun, Dong (Dong)] The trigger for initiating the push and pull models is different, for example, when a new request from the PEP is recevied, the Server will start the pull model. In fact, the push and pull are sharing the same state machine per se. the main difference is just how to establish a Diameter session. The enhancement is to allow the Diameter Server to establish a session with a local trigger instead of the trigger from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same application-Id causes any problem, especially for the pull model since push/pull is able use the same server (certainly they can also have separate server according to the configuration). 2- 3. Framework "After receiving the authorization request from the AppS or the NE, the AE decides the appropriate mode (i.e. Push or Pull). The usage Push or Pull mode can be determined by the authorizing entity either statically or dynamically." I think I am missing something here. Don't we have always push mode if the authorization request is received from AppS? Or are we talking about a hybrid model where first AppS contacts the Authorizing Entity, receives a token, hands it over to media layer, and this token is used in turn by NE for pull mode? [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my understanding is that the push and pull models can be decided by AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). If this is correct, the texts may be modified as follows for clarity: "The push and pull models can be decided by the AE on per call session basis (i.e. dynamically), or can be pre-configured for one of them (i.e. statically). Without any pre-configuration, when receiving a new authorization request from the Apps or a local trigger, the AE starts the Push model; when receiving a new authorization request from the NE, the AE starts the Pull model." [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could you verify my comment or give some further clafication. are you ok with the modified texts? I will update the document accordingly if no objection. [Tina: As is specified in the document, "the diversity of QoS capabilities of endpoints and QoS schemes of network technology leads to the distinction on the interaction mode between QoS authorization system and underlying NEs". Therefore, I think the hybrid model should be supported. After receiving a new authorization request from the AppS, the AE can decide which mode should be used based on the information of the request, especially based on the information which indicates QoS capability and the access network type. So I don't see any problem with the original text. However, as is proposed by Hannes, the AVP could be added into the QoS-Request message. Besides, I think the AVP should also be added to indicate the network technology since the network technology is another factor affecting the type of QoS Model being used.] 3- 3. Framework "For Push mode, the authorizing entity needs to identify the appropriate NE(s) to which QoS authorization information needs to be pushed. It might determine this based on information received from the AppS, such as the IP addresses of media flows." It could be a good idea to give a bit more information about this: - This is hard to do as Authorizing Entity would need to have information about routing decisions of NEs for a particular flow - QoS in the core network is usually not scarce - QoS on the access side is scarce - It is not difficult for the Authorizing Entity to determine NEs facing the access side as usually this information is stored somewhere when the endpoint attaches to the network and does not change per IP flow. [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery of these NEs is not necessarily based on the routing info, instead, it can be preconfigured. In addition, i think this draft mainly focuses on the mechanism and protocol. It can be used for both access and core networks. the QoS status you described looks like well known, not sure how much it may add. 4- 3.4 QoS Application Requirements "Identity-based Routing The QoS AAA protocol MUST route AAA requests to the Authorizing Entity, based on the provided identity of the QoS requesting entity or the identity of the AE encoded in the provided authorization token." I think it is responsibility of the QoS application -not QoS AAA protocol- to perform routing decision based on identity. The application decided for the host/realm and the protocol routes the message based on that. I think it could be better to have a global change in this section: QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)] looks ok to me. 5- 3.4 QoS Application Requirements "Sending Accounting Records The NE SHOULD be able to send accounting records for a particular QoS reservation state to an accounting entity." Is this a QoS AAA application requirement? It is stated as a requirement on NE. [Sun, Dong (Dong)] it is for NE, since we decided to remove the accounting related texts, this one could be gone, IMHO. 6- 4.2 Session Establishment "When a QoS-Authz-Request (QAR, see Section 5.1) message with a new session ID is received, the AE operates in the Pull mode; when other triggers are received, the AE operates in the Push mode." Would this shut down the door for certain failure recovery scenarios? For example AE goes down and a backup AE takes over. IMO it is a nice feature if the backup can continue existing sessions without a need to synchronizing state with the failed active AE. This can be achieved by carrying enough information about session state in the message itself (AFAIR, DCCA can do this nicely). The approach I quoted makes this impossible. For certain scenarios backup AE would determine the required mode wrong. I suggest the decision for push/pull is not based on message name but on the message content. [Sun, Dong (Dong)] I think this is the most straightforward and consistent way in terms of state machine to decide the pull/push. and it will work well for the hot standby case, but indeed, it may have some issue with cold standby. In general, the failure handling is not addressed in the draft very much. The question is, do we need to add the failure handling in detail or not for backup server case? 7- There were some proposals about a mode, where NE is notified from AE to reserve resources all the way till the end point. Is this considered out of scope? [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but it is not a different mode, just an implementation of resource reservation within the bearer layer. it is mentioned in the section 9 as example. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_aigIIbZgkhlTxkVqbM4H6g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable [Fwd: [Dime] Comments for = draft-ietf-dime-diameter-qos-06]
Hi Tolga, Dong et al,
See comments in line beginning with = [Tina:=20 ...]
 
Cheers from 30 degree hot Shenzhen,
Tina
----- Original Message -----
From:=20 Sun, Dong (Dong)
Cc: dime@ietf.org ; Tschofenig, Hannes (NSN -=20 FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Tina TSOU = ; Glen=20 Zorn
Sent: Wednesday, July 23, 2008 = 6:40=20 AM
Subject: RE: [Fwd: [Dime] = Comments for=20 draft-ietf-dime-diameter-qos-06]

Hi Tolga,
 
Thanks for review and comments. see=20 my responses inline...
copy to all authors in case they have = further=20 comments.
 
Rgs,
Dong


-------- Original Message = --------=20
Subject:=20        [Dime] = Comments for=20 draft-ietf-dime-diameter-qos-06     =
Date:   Fri, 18 Jul = 2008 11:19:22=20 -0400
From:   Asveren, Tolga <tasveren@sonusnet.com> = =20
To:     = <dime@ietf.org>=20

1- Use of the same = Application-Id for=20 push/pull models
It sounds reasonable to me to think nodes which = support=20 only a single
mode. How can we guarantee that messages land to the = right=20 server
considering that the same Application-Id is used for both of = them?
[Sun,=20 Dong (Dong)]  The trigger for initiating the push and pull = models is=20 different, for example, when a new request from the PEP is recevied, = the=20 Server will start the pull model. In fact, the push and pull are = sharing the=20 same state machine per se. the main difference is just how to = establish a=20 Diameter session. The enhancement is to allow the Diameter Server to = establish=20 a session with a local trigger instead of the trigger from the = Diameter client=20 (i.e. NE/PEP). Therefore, I don't think the same application-Id causes = any=20 problem, especially for the pull model since push/pull is able use the = same=20 server (certainly they can also have separate server according to the=20 configuration).

2- 3. Framework
   = "After=20 receiving the
   authorization request from the AppS or = the NE,=20 the AE decides the
   appropriate mode (i.e.  Push = or=20 Pull).  The usage Push or Pull mode
   can be = determined by=20 the authorizing entity either statically or
   = dynamically."
I=20 think I am missing something here. Don't we have always push mode = if
the=20 authorization request is received from AppS? Or are we talking = about
a=20 hybrid model where first AppS contacts the Authorizing = Entity,
receives a=20 token, hands it over to media layer, and this token is used
in turn = by NE=20 for pull mode?
[Sun, Dong (Dong)] I don't think we are talking = about a=20 hybrid model. my understanding is that the push and pull models can be = decided=20 by AE on per call session basis (i.e. dynamically), or can=20 be pre-configured for one of them (i.e. statically). If this is = correct,=20 the texts may be modified as follows for=20 clarity:

 "The push and pull models can be decided = by=20 the AE on per call session basis (i.e. dynamically), or can=20 be pre-configured for one of them (i.e. statically). Without any=20 pre-configuration, when receiving a new authorization request from the = Apps or=20 a local trigger, the AE starts the Push model; when receiving a new=20 authorization request from the NE, the AE starts the Pull=20 model."

[Sun, Dong=20 (Dong)] Tina,  I thought the initial texts come from = you. could=20 you verify my comment or give some further clafication. are you ok = with the=20 modified texts?

I will update the document accordingly if no=20 objection. 

[Tina: As is specified = in the=20 document, =93the diversity of QoS capabilities
of endpoints and QoS = schemes=20 of network technology leads to the distinction
on the interaction = mode=20 between QoS authorization system and underlying
NEs=94.

Therefore, I think the = hybrid model=20 should be supported. After receiving a
new authorization request = from the=20 AppS, the AE can decide which mode should
be used based on the = information=20 of the request, especially based on the
information which indicates = QoS=20 capability and the access network type. So I
don=92t see any = problem with the=20 original text.

However, as is = proposed by=20 Hannes, the <QoS-Capability> AVP could be added
into the = QoS-Request=20 message. Besides, I think the <Access-Network-Type> = AVP
should also=20 be added to indicate the network technology since the = network
technology is=20 another factor affecting the type of QoS Model being=20 used.]


3- 3. = Framework
   "For=20 Push mode, the authorizing entity needs to identify = the
  =20 appropriate NE(s) to which QoS authorization information needs to=20 be
   pushed.  It might determine this based on = information=20 received from
   the AppS, such as the IP addresses of = media=20 flows."
It could be a good idea to give a bit more information = about=20 this:
- This is hard to do as Authorizing Entity would need to=20 have
information about routing decisions of NEs for a particular=20 flow
-  QoS in the core network is usually not = scarce
-  QoS=20 on the access side is scarce
-  It is not difficult for the=20 Authorizing Entity to determine NEs
facing the access side as = usually this=20 information is stored somewhere
when the endpoint attaches to the = network=20 and does not change per IP
flow.
[Sun, Dong (Dong)]  my = understanding is the=20 NEs for Policy enforcement are usually some anchoring nodes e.g. = DSLAM,=20 Gateway, LER etc. the discovery of these NEs is not necessarily based = on the=20 routing info, instead, it can be preconfigured.=20

In=20 addition, i think this draft mainly focuses on the mechanism and = protocol. It=20 can be used for both access and core networks. the QoS status you = described=20 looks like well known, not sure how much it may=20 add.

4- 3.4 QoS Application=20 Requirements

      "Identity-based=20 Routing
      The QoS AAA protocol MUST = route AAA=20 requests to the Authorizing
      Entity, = based on=20 the provided identity of the QoS = requesting
     =20 entity or the identity of the AE encoded in the=20 provided
      authorization = token."

I=20 think it is responsibility of the QoS application -not QoS = AAA
protocol- to=20 perform routing decision based on identity. The application
decided = for the=20 host/realm and the protocol routes the message based = on
that.

I=20 think it could be better to have a global change in this = section:
QoS AAA=20 protocol =3D=3D> QoS AAA application

[Sun, Dong (Dong)]  looks ok to = me.

5- 3.4 QoS Application=20 Requirements
      "Sending Accounting=20 Records
      The NE SHOULD be able to = send=20 accounting records for a particular
      = QoS=20 reservation state to an accounting entity."
Is this a QoS AAA = application=20 requirement? It is stated as a requirement
on NE.

[Sun, Dong (Dong)]  it is for = NE, since we=20 decided to remove the accounting related texts, this one could be = gone, IMHO.=20



6- 4.2 Session Establishment
   = "When a=20 QoS-Authz-Request
   (QAR, see Section 5.1) message with = a new=20 session ID is received, the
   AE operates in the Pull = mode; when=20 other triggers are received, the
   AE operates in the = Push=20 mode."
Would this shut down the door for certain failure recovery=20 scenarios?
For example AE goes down and a backup AE takes over. IMO = it is a=20 nice
feature if the backup can continue existing sessions without a = need=20 to
synchronizing state with the failed active AE. This can be = achieved=20 by
carrying enough information about session state in the message=20 itself
(AFAIR, DCCA can do this nicely). The approach I quoted = makes=20 this
impossible. For certain scenarios backup AE would determine = the=20 required
mode wrong. I suggest the decision for push/pull is not = based on=20 message
name but on the message content.

[Sun,=20 Dong (Dong)]  I think this is the most straightforward and=20 consistent way in terms of state machine to decide the pull/push. and = it will=20 work well for the hot standby case, but indeed, it may have some issue = with=20 cold standby. In general, the failure handling is not addressed in the = draft=20 very much. The question is, do we need to add the failure handling in = detail=20 or not for backup server case?

7- = There=20 were some proposals about a mode, where NE is notified from AE
to = reserve=20 resources all the way till the end point. Is this considered
out of = scope?

[Sun, Dong (Dong)]  it can be supporoted = implicited by=20 the applicaion, but it is not a different mode, just an implementation = of=20 resource reservation within the bearer layer. it is mentioned in the = section 9=20 as=20 = example.


Thanks,
Tolga

_______________= ________________________________
DiME=20 mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime=20

--Boundary_(ID_aigIIbZgkhlTxkVqbM4H6g)-- --===============0684519151== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0684519151==-- From dime-bounces@ietf.org Wed Jul 23 00:09:33 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41D83A6937; Wed, 23 Jul 2008 00:09:33 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C1A3A6937 for ; Wed, 23 Jul 2008 00:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=-0.943, 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 S7OkMUjXhTKN for ; Wed, 23 Jul 2008 00:09:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4C2253A6824 for ; Wed, 23 Jul 2008 00:09:31 -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 m6N7A1Mp014579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jul 2008 09:10:01 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m6N7A0w4023210; Wed, 23 Jul 2008 09:10:01 +0200 Received: from demuexc025.nsn-intra.net ([10.159.32.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:10:00 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 09:09:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 10:09:57 +0300 Message-ID: In-Reply-To: <007a01c8ec61$da366580$7427460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] explicit routing and NAI considered for rechartering Thread-Index: AcjsYeFg1dhOYHghTqOC1JujvdbTZwAMM9WQ References: <007a01c8ec61$da366580$7427460a@china.huawei.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tina TSOU" , X-OriginalArrivalTime: 23 Jul 2008 07:09:59.0600 (UTC) FILETIME=[1E7E4B00:01C8EC93] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1027-16048.005 X-TM-AS-Result: No--8.002000-8.000000-31 Subject: Re: [Dime] explicit routing and NAI considered for rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tina, I guess you are talking about this document when you speak about explicit routing document: http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 It is expired. Why didn't you submit it for the meeting? Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Tina TSOU Sent: 23 July, 2008 04:17 To: dime@ietf.org Subject: [Dime] explicit routing and NAI considered for rechartering Hi All, Could explicit routing draft be considered together with Jouni's NAI draft? http://www.ietf.org/proceedings/08jul/agenda/dime.txt B. R. Tina _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 04:24:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1999E28C19D; Wed, 23 Jul 2008 04:24:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906AA3A6A4F for ; Wed, 23 Jul 2008 04:24:23 -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 gwYRdrDI4Gjc for ; Wed, 23 Jul 2008 04:24:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 92A153A69C3 for ; Wed, 23 Jul 2008 04:24:22 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 11:25:00 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp009) with SMTP; 23 Jul 2008 13:25:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/WEF5TW9nWaJitjq+4qlyws0H9Lot8RmXIG14Zf7 lNc904lLvjLEuA Message-ID: <4887150C.2000908@gmx.net> Date: Wed, 23 Jul 2008 14:25:00 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Dime] WGLC for draft-ietf-dime-rfc3588bis-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, we would like to start the WGLC for the "Diameter Base Protocol" http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt document. Please have all comments in by August 15, 2008. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 04:59:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EB23A6A2C; Wed, 23 Jul 2008 04:59:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5EC43A6A22 for ; Wed, 23 Jul 2008 04:59:55 -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 Bm6mlwZMGdq3 for ; Wed, 23 Jul 2008 04:59:51 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id F04FE3A68EA for ; Wed, 23 Jul 2008 04:59:50 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 12:00:32 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp067) with SMTP; 23 Jul 2008 14:00:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+y6ZLv2z+f0iwAK2gk68O/f15Pp0A9dY9B8SFGk HXGfCA+wZIwis2 Message-ID: <48871D5F.5010002@gmx.net> Date: Wed, 23 Jul 2008 15:00:31 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Subject: [Dime] DIME Status Update, July 2008 (#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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I wanted to provide another status update during this month to the list based on the recent activities in the group. Here is the copy-and-paste from the webpage: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate -- RFC3588bis A working group last call on the document was started. -- Diameter Application Design Guidelines The document was updated but needs more input from the group, see my mail to the list on the 23rd of July 2008. -- Diameter API Dave has to submit a new version to reflect Dan's feedback. -- draft-ietf-dime-mip6-integrated This document is in Publication Requested state. -- draft-ietf-dime-qos-parameters This document is in Publication Requested state. -- draft-ietf-dime-qos-attributes It would be important to get more feedback on the provided draft update since the document went into WGLC for the first time. -- draft-ietf-dime-mip6-split There are two issues with this document: * I reported about the IPR aspect already some time ago, see http://www.ietf.org/mail-archive/web/dime/current/msg02579.html * The security of some of the authentication mechanisms requires special attention. I will send a mail to the group and to Jari/Pasi/Dan about this issue. -- draft-ietf-dime-diameter-qos Tolga provided a review comments and we will discuss it on the list. Dave is reading the document so that we can soon ship the updated version to the IESG. -- draft-sun-dime-itu-t-rw-00.txt The document entered IETF LC, see http://www.ietf.org/mail-archive/web/dime/current/msg02670.html -- Rechartering We are currently having a rechartering discussion based on the following proposals: * draft-asveren-dime-cong-03.txt * draft-neumann-dime-webauth * draft-stupar-dime-mos-options * draft-dondeti-dime-erp-diameter * draft-korhonen-dime-nai-routing * draft-korhonen-dime-pmip6 * draft-zorn-dime-diameter-base-protocol-mib * draft-zorn-dime-diameter-cc-appl-mib * draft-sarikaya-dimeradext-prefix-auth-ps-00.txt * draft-sarikaya-dime-prefix-delegation-ps I am not sure about draft-tsou-dime-capabilities-update-problem-statement, draft-tsou-dime-base-routing-ext, draft-mccann-dime-rfc4004bis, draft-morariu-dime-grid-accounting, draft-bodin-dime-auditing-reqs, and draft-asveren-dime-state-recovery. The authors of these documents need to tell us what they plan todo with them. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 05:40:37 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB4828C12B; Wed, 23 Jul 2008 05:40:37 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3DA28C12B for ; Wed, 23 Jul 2008 05:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 icj34ztNUFWu for ; Wed, 23 Jul 2008 05:40:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 009693A6817 for ; Wed, 23 Jul 2008 05:40:33 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 12:41:15 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp030) with SMTP; 23 Jul 2008 14:41:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mq51CBkDmr2hOC+yHY2qqm+nz7cN0CwQfiW8yxF x7mStRN9w1My5I Message-ID: <488726EC.6030207@gmx.net> Date: Wed, 23 Jul 2008 15:41:16 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I have sent my rechartering questions around regarding these two documents. I took a brief look at them and I wonder what the relationship between the two documents is. Why are there 2 documents on almost the same subject? When I browse through http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt then I sometimes get the impression that you would like to later standardize a Diameter application. I wasn't sure why additional AVPs aren't sufficient, in case existing AVPs cannot be re-used? Let me also comment on a few selected items: AAA-based prefix authorization (PA) application MUST run between a NAS, located on AR, LMA, MR, etc. and an AAA server. [hannes] This requirement does not say a lot. The AAA protocol is always run between a client and a server. AAA-based PA application MUST support the AAA client to request prefixes from an AAA server. AAA-based PA application MUST support the client to give back the prefixes to the AAA server. [hannes] With the last sentence you mean that you need to have a way to indicate that the AAA session is terminated? If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on the network, the certificate or the information needed to obtain a certificate SHOULD also be sent by the AAA server to NAS. [hannes] What information do you exactly want to carry towards the AAA client? In point-to-point link operation, the NAS MUST identify the interface of MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 to which the AAA server MUST reply with one or more prefixes, e.g. of length /64. [hannes] how would such an interface identifier look like? In point-to-point operation, the AAA server MAY assign the prefix(es) and related parameters such as the lifetime and the certificates to MN from MN's profile. [hannes] I am not sure what this means. You mean that the AAA server should keep state to make sure that it does not forget what it has provided to the MN? For some reason the problem is not well described. In Section 3 of draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 but I do not quite understand what you would like to see happening instead. AAA-based prefix authorization application SHOULD support prefix release procedures. [hannes] isn't this the same as mentioned in the previous requirement "AAA-based PA application MUST support the client to give back the prefixes to the AAA server. " The NAS is responsible for renewing the prefixes when the lifetime expires. The NAS SHOULD be able to extend the lifetime of the prefixes using messages designed for this purpose. [hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime of the AAA session itself? Makes things much easier. The same applies a bit to this requirement: "It SHOULD be possible to renumber the prefixes authorized by AAA server. The AAA server SHOULD initiate prefix renumbering process. " RFC2119 seems to be a bit randomly used in the document. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 06:14:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B3D3A6894; Wed, 23 Jul 2008 06:14:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C603A6894 for ; Wed, 23 Jul 2008 06:14:07 -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 U5Cf7qm0ToG2 for ; Wed, 23 Jul 2008 06:14:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6F37A3A6817 for ; Wed, 23 Jul 2008 06:14:05 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 13:14:45 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp054) with SMTP; 23 Jul 2008 15:14:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ha9AyKOUhi3gBsRPtTLEbGDQt7HMAWnGhh6o9HC dinnI+HGbGWNPI Message-ID: <48872EC6.8090505@gmx.net> Date: Wed, 23 Jul 2008 16:14:46 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Subject: [Dime] Prefix Delegation & IPR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I was made aware of an IPR related to prefix delegation and AAA usage. It is my responsibility as a WG chair to inform the group about it. I suggest that the authors of the IPR (and the draft) make a disclosure. USING DHCPV6 AND AAA FOR MOBILE STATION PREFIX DELEGATION AND ENHANCED NEIGHBOR DISCOVERY Abstract: A network component comprising a processor configured to implement a method comprising promoting transmission of a request for an address prefix to a prefix issuing party, identifying a reply comprising the address prefix from the prefix issuing party, and promoting transmission of a router advertisement comprising the address prefix to a mobile station. Also disclosed is a method comprising receiving a request for an Internet Protocol version 6 (IPv6) prefix, assigning the IPv6 prefix to a mobile station, and sending the IPv6 address to the mobile station, wherein the method is implemented at a Dynamic Host Configuration Protocol (DHCP) server or an Authentication, Authorization and Accounting (AAA) server. http://www.wipo.int/pctdb/en/fetch.jsp?LANG=ENG&DBSELECT=PCT&SERVER_TYPE=19-10&SORT=11243716-KEY&TYPE_FIELD=256&IDB=0&IDOC=86985&C=10&ELEMENT_SET=B&RESULT=1&TOTAL=3&START=1&DISP=25&FORM=SEP-0/HITNUM,B-ENG,DP,MC,AN,PA,ABSUM-ENG&SEARCH_IA=CN2007070031&QUERY=%28FP%2fPrefix+AND+FP%2fdelegation%29+ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 09:46:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56AA53A69A7; Wed, 23 Jul 2008 09:46:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9203A6947 for ; Wed, 23 Jul 2008 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Adr8cr5YNKZL for ; Wed, 23 Jul 2008 09:46:45 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id CA6D63A68BC for ; Wed, 23 Jul 2008 09:46:39 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6NGl9HH024471; Wed, 23 Jul 2008 12:47:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 12:47:08 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, A few comments/questions below. Thanks, Tolga > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 22, 2008 6:41 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > > Thanks for review and comments. see my responses inline... > copy to all authors in case they have further comments. > > Rgs, > Dong > > > -------- Original Message -------- > Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 > Date: Fri, 18 Jul 2008 11:19:22 -0400 > From: Asveren, Tolga > To: > > 1- Use of the same Application-Id for push/pull models > It sounds reasonable to me to think nodes which support only a single > mode. How can we guarantee that messages land to the right server > considering that the same Application-Id is used for both of them? > [Sun, Dong (Dong)] The trigger for initiating the push and pull models is > different, for example, when a new request from the PEP is recevied, the > Server will start the pull model. In fact, the push and pull are sharing > the same state machine per se. the main difference is just how to > establish a Diameter session. The enhancement is to allow the Diameter > Server to establish a session with a local trigger instead of the trigger > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same > application-Id causes any problem, especially for the pull model since > push/pull is able use the same server (certainly they can also have > separate server according to the configuration). [TOLGA]My concern here is about message routing rather than the state machine processing in the server. Let's say a server is capable only to accommodate pull model (it doesn't know what NE to contact if push model is required). How can the network intermediaries, e.g. relay agent, forward the initial request in the session to the right server for push model? How can they be sure that the server supports push model? > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > > > 3- 3. Framework > "For Push mode, the authorizing entity needs to identify the > appropriate NE(s) to which QoS authorization information needs to be > pushed. It might determine this based on information received from > the AppS, such as the IP addresses of media flows." > It could be a good idea to give a bit more information about this: > - This is hard to do as Authorizing Entity would need to have > information about routing decisions of NEs for a particular flow > - QoS in the core network is usually not scarce > - QoS on the access side is scarce > - It is not difficult for the Authorizing Entity to determine NEs > facing the access side as usually this information is stored somewhere > when the endpoint attaches to the network and does not change per IP > flow. > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery > of these NEs is not necessarily based on the routing info, instead, it can > be preconfigured. > In addition, i think this draft mainly focuses on the mechanism and > protocol. It can be used for both access and core networks. the QoS status > you described looks like well known, not sure how much it may add. [TOLGA]Even for some of the nodes you mentioned, I would expect routing to play a role here. For example if there are more than one gateway, AE needs to know which one it should contact for that particular stream. > > 4- 3.4 QoS Application Requirements > > "Identity-based Routing > The QoS AAA protocol MUST route AAA requests to the Authorizing > Entity, based on the provided identity of the QoS requesting > entity or the identity of the AE encoded in the provided > authorization token." > > I think it is responsibility of the QoS application -not QoS AAA > protocol- to perform routing decision based on identity. The application > decided for the host/realm and the protocol routes the message based on > that. > > I think it could be better to have a global change in this section: > QoS AAA protocol ==> QoS AAA application > [Sun, Dong (Dong)] looks ok to me. > > 5- 3.4 QoS Application Requirements > "Sending Accounting Records > The NE SHOULD be able to send accounting records for a particular > QoS reservation state to an accounting entity." > Is this a QoS AAA application requirement? It is stated as a requirement > on NE. > [Sun, Dong (Dong)] it is for NE, since we decided to remove the > accounting related texts, this one could be gone, IMHO. > > > 6- 4.2 Session Establishment > "When a QoS-Authz-Request > (QAR, see Section 5.1) message with a new session ID is received, the > AE operates in the Pull mode; when other triggers are received, the > AE operates in the Push mode." > Would this shut down the door for certain failure recovery scenarios? > For example AE goes down and a backup AE takes over. IMO it is a nice > feature if the backup can continue existing sessions without a need to > synchronizing state with the failed active AE. This can be achieved by > carrying enough information about session state in the message itself > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > impossible. For certain scenarios backup AE would determine the required > mode wrong. I suggest the decision for push/pull is not based on message > name but on the message content. > [Sun, Dong (Dong)] I think this is the most straightforward and > consistent way in terms of state machine to decide the pull/push. and it > will work well for the hot standby case, but indeed, it may have some > issue with cold standby. In general, the failure handling is not addressed > in the draft very much. The question is, do we need to add the failure > handling in detail or not for backup server case? [TOLGA]I agree that details of failure handling may not belong here. OTOH that the QoS application is failover friendly is a parameter to consider IMHO. By carrying enough information in each message so that cold standby elements can be used to take over existing sessions, one trades small amount of bandwidth and limited CPU cycles for complexity in software and probably even more CPU cycles. IMHO this is a bargain. I found this very handy in DCCA. Wouldn't just defining an AVP indicating the type of service requested (push v.s. pull) solve this problem? Actually this issue is also tied to Application-Id problem. If different Application-Ids are used, that implicitly will define the mode required/used. > > 7- There were some proposals about a mode, where NE is notified from AE > to reserve resources all the way till the end point. Is this considered > out of scope? > [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but > it is not a different mode, just an implementation of resource reservation > within the bearer layer. it is mentioned in the section 9 as example. [TOLGA]I think I couldn't explain well what I meant. The model I am talking about is that AE tells NE to reserve resources not only in itself but also through the whole bearer path, e.g. RSVP from edge router to edge router. Is it possible to do this with this version of QoS application draft? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 09:54:25 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346033A6AF6; Wed, 23 Jul 2008 09:54:25 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19B73A6AF0 for ; Wed, 23 Jul 2008 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 SMTt2hltonBY for ; Wed, 23 Jul 2008 09:54:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 7DB743A6AEE for ; Wed, 23 Jul 2008 09:54:22 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4G00L7ZXNSB9@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 11:55:05 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4G002ULXNRQ8@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 11:55:04 -0500 (CDT) Date: Wed, 23 Jul 2008 11:55:03 -0500 From: Frank Xia To: Hannes Tschofenig , dime@ietf.org Message-id: <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <488726EC.6030207@gmx.net> Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes I try to jump ahead of Behcet to answer some of your questions :-) Please check inline comments. BR Frank ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Wednesday, July 23, 2008 7:41 AM Subject: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt >I have sent my rechartering questions around regarding these two documents. >I took a brief look at them and I wonder what the relationship between the >two documents is. Why are there 2 documents on almost the same subject? > Frank=>They have almost the same main idea. You can only refer to the draft http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. > When I browse through > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > then I sometimes get the impression that you would like to later > standardize a Diameter application. I wasn't sure why additional AVPs > aren't sufficient, in case existing AVPs cannot be re-used? Frank=>Prefix delegation is an authorization which may be decoupled from an authentication. RFC4005/4072 only deal with coupled authentication& authorization scenario. > > Let me also comment on a few selected items: > > > AAA-based prefix authorization (PA) application MUST run between a NAS, > located on AR, LMA, MR, etc. and an AAA server. > > [hannes] This requirement does not say a lot. The AAA protocol is always > run between a client and a server. > > > > AAA-based PA application MUST support the AAA client to request prefixes > from an AAA server. AAA-based PA application MUST support the client to > give back the prefixes to the AAA server. > > [hannes] With the last sentence you mean that you need to have a way to > indicate that the AAA session is terminated? Frank=>In IPv6 renumbering scenario, it is necessary > > If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on > the network, the certificate or the information needed to obtain a > certificate SHOULD also be sent by the AAA server to NAS. > > [hannes] What information do you exactly want to carry towards the AAA > client? Frank=>IPv6 address prefix for NAS is authorized to route > > In point-to-point link operation, the NAS MUST identify the interface of > MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 > to which the AAA server MUST reply with one or more prefixes, e.g. of > length /64. > > [hannes] how would such an interface identifier look like? Frank=>Tentatively, it can be the interface identifier part of host's link local address, NAI (RFC4282), or MAC address. > > In point-to-point operation, the AAA server MAY assign the prefix(es) and > related parameters such as the lifetime and the certificates to MN from > MN's profile. > > [hannes] I am not sure what this means. You mean that the AAA server > should keep state to make sure that it does not forget what it has > provided to the MN? Frank=>Probably, the AAA server for prefix delegation is different from the AAA server for authentication. So it is necessary to record the state. > For some reason the problem is not well described. In Section 3 of > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 but > I do not quite understand what you would like to see happening instead. > > AAA-based prefix authorization application SHOULD support prefix release > procedures. > > [hannes] isn't this the same as mentioned in the previous requirement > "AAA-based PA application MUST support the client to give back the > prefixes to the AAA server. " Frank=>It is the same. > > The NAS is responsible for renewing the prefixes when the lifetime > expires. The NAS SHOULD be able to extend the lifetime of the prefixes > using messages designed for this purpose. > > [hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime of > the AAA session itself? Makes things much easier. The same applies a bit > to this requirement: "It SHOULD be possible to renumber the prefixes > authorized by AAA server. The AAA server SHOULD initiate prefix > renumbering process. " Frank=>IPv6 renumbering is a feature of IPv6. If we tie the lifetime of prefix to the lifetime of AAA session, it is certain that we can't suport IPv6 renumbering. Even though IPv6 renumbering probably happen probably infrequently, it is better for us to have such a mechnism to support. For IPv6 renumbering, here are some references RFC 1916/2071/2072/2874/2894/4076/4192. > > RFC2119 seems to be a bit randomly used in the document. Frank=>We will polish the draft, and also welcome more poeple to join us. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 11:22:34 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6B53A6918; Wed, 23 Jul 2008 11:22:34 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9883A67D6 for ; Wed, 23 Jul 2008 11:22:33 -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 WfcuYoVU1irc for ; Wed, 23 Jul 2008 11:22:32 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id E2A4B3A6918 for ; Wed, 23 Jul 2008 11:22:31 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6NIMj0Y002914; Wed, 23 Jul 2008 14:22:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 14:22:44 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701205F12@sonusmail04.sonusnet.com> In-Reply-To: <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjsbjFbI5vql+HjSB+7AesNrMaAEwAgo/7g References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> From: "Asveren, Tolga" To: "Tina TSOU" , "Sun, Dong (Dong)" Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tina, One question below. Thanks, Tolga [.. snip ..] > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > [Tina: As is specified in the document, "the diversity of QoS capabilities > of endpoints and QoS schemes of network technology leads to the > distinction > on the interaction mode between QoS authorization system and underlying > NEs". > Therefore, I think the hybrid model should be supported. After receiving a > new authorization request from the AppS, the AE can decide which mode > should > be used based on the information of the request, especially based on the > information which indicates QoS capability and the access network type. So > I > don't see any problem with the original text. > However, as is proposed by Hannes, the AVP could be added > into the QoS-Request message. Besides, I think the > AVP > should also be added to indicate the network technology since the network > technology is another factor affecting the type of QoS Model being used.] [TOLGA]I just am trying to understand the use case: I understand that endpoints will have different QoS reservation capabilities. i- I have a device, which can't reserve QoS for the media but can indicate its desire to do so in signaling. AppS would determine that push mode is desired. ii- I have a device, which can't reserve QoS for the media and can't indicate its desire to do so in signaling. AppS could determine statically what to do. iii- I have a device, which can reserve QoS for the media. It uses its own capabilities whenever it needs. I guess what I am trying to figure out is, why decision process does not belong to AppS? For , I can see that this type of information could be useful, e.g. a device attached via DOCSIS to IP network v.s. a device attached via a 3GPP technology. OTOH, isn't this information actually necessary in AppS so that it can determine whether it should ask for QoS resources? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 12:18:44 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107BC3A6AFB; Wed, 23 Jul 2008 12:18:44 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E45A3A6AFA for ; Wed, 23 Jul 2008 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 j-g7MuiPoUCW for ; Wed, 23 Jul 2008 12:18:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 158EA3A6AF6 for ; Wed, 23 Jul 2008 12:18:40 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 19:19:22 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp011) with SMTP; 23 Jul 2008 21:19:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19BwJYt4TxBBDN6Nj6GdRFlExELUSunIdkm1ajAD0 MZlBBCZvCA8YvK Message-ID: <48878439.1070701@gmx.net> Date: Wed, 23 Jul 2008 22:19:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapalli References: In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: dime@ietf.org, mipshop@ietf.org Subject: Re: [Dime] [Mipshop] FW: Rechartering: draft-stupar-dime-mos-options X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Your feedback has helped. Thanks a lot! Vijay Devarapalli wrote: > Hi Hannes, > > draft-ietf-mipshop-mstp-solution-05, which is with the IESG currently, > has a dependency on this document. The extensions specified in > draft-stupar-dime-mos-options are required for delivering the MIH server > information to the NAS/access router. > > However, in the AD review, a question was raised on whether we need this > scenario at all. We are currently discussing this. We should be able to > decide on this in the next couple of weeks. I will get back to you. > > If we decide to keep this scenario in > draft-ietf-mipshop-mstp-solution-05, then I would like to see > draft-stupar-dime-mos-options adopted as a DIME WG document. > > Vijay > > >> -----Original Message----- >> From: mipshop-bounces@ietf.org >> [mailto:mipshop-bounces@ietf.org] On Behalf Of Tschofenig, >> Hannes (NSN - FI/Espoo) >> Sent: Tuesday, July 22, 2008 4:24 AM >> To: mipshop@ietf.org >> Cc: ext David Frascone >> Subject: [Mipshop] FW: [Dime] Rechartering: >> draft-stupar-dime-mos-options >> >> Hi all, >> >> In the DIME working group we are currently having a re-chartering >> discussion and one document that has been submitted to DIME relates to >> functionality that was developed in your working group. >> >> We would therefore like to understand whether >> * there is an interest from the MIPSHOP WG to have DIME to >> work on this >> subject >> * there are folks in MIPSHOP willing todo reviews and thereby help to >> finish the work quickly. >> >> We need your feedback! >> >> Ciao >> Hannes & Dave >> DIME Chairs >> >> >>> -----Original Message----- >>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >>> Behalf Of ext Hannes Tschofenig >>> Sent: 15 July, 2008 21:30 >>> To: dime@ietf.org >>> Cc: Patrick Stupar; subir@research.telcordia.com >>> Subject: [Dime] Rechartering: draft-stupar-dime-mos-options >>> >>> Document: >>> >> http://tools.ietf.org/id/draft-stupar-dime-mos-options-00.txt >> >>> * Who is able to be editor of the document? >>> >>> * Who is interested to help the editor with the work on the >>> draft by co-authoring it? >>> >>> * Who is able to provide reviews? >>> >>> * Who is unable to actively help with a specific document but >>> supports the work? >>> >>> * Are there concerns regarding this document? >>> >>> * Is there a dependency with another IETF working group or >>> with another SDO? >>> >>> * How long will it take to finish this document? >>> (A rough guess based on the current status of the document. By >>> "finished" I mean "ready for WGLC".) >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> >> _______________________________________________ >> Mipshop mailing list >> Mipshop@ietf.org >> https://www.ietf.org/mailman/listinfo/mipshop >> >> > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www.ietf.org/mailman/listinfo/mipshop > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 12:30:00 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF393A68E7; Wed, 23 Jul 2008 12:30:00 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA08C3A685E for ; Wed, 23 Jul 2008 12:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 w9vnUV13CboR for ; Wed, 23 Jul 2008 12:29:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DF1483A6AF6 for ; Wed, 23 Jul 2008 12:29:56 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 19:30:39 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp003) with SMTP; 23 Jul 2008 21:30:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/FyGZEikfF0LaOEMAhevAOiKvd9A6fYWDDEooVs0 X8ysgoKRnAM812 Message-ID: <488786DE.6010400@gmx.net> Date: Wed, 23 Jul 2008 22:30:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Frank Xia References: <488726EC.6030207@gmx.net> <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> In-Reply-To: <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 Cc: dime@ietf.org Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Frank, thanks for the quick feedback. I have a few more comments inline Frank Xia wrote: > Hi Hannes > > I try to jump ahead of Behcet to answer > some of your questions :-) > > Please check inline comments. > > BR > Frank > > > ----- Original Message ----- From: "Hannes Tschofenig" > > To: > Sent: Wednesday, July 23, 2008 7:41 AM > Subject: [Dime] Relationship between > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > >> I have sent my rechartering questions around regarding these two >> documents. I took a brief look at them and I wonder what the >> relationship between the two documents is. Why are there 2 documents >> on almost the same subject? >> > Frank=>They have almost the same main idea. > You can only refer to the draft > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. > > Ok. We can essentially forget the other document. Right? >> When I browse through >> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >> then I sometimes get the impression that you would like to later >> standardize a Diameter application. I wasn't sure why additional AVPs >> aren't sufficient, in case existing AVPs cannot be re-used? > Frank=>Prefix delegation is an authorization which may be > decoupled from an authentication. RFC4005/4072 only deal > with coupled authentication& authorization scenario. > It is true that the request for prefix authorization is not run independently from the message exchanges used for authentication. >> >> Let me also comment on a few selected items: >> >> >> AAA-based prefix authorization (PA) application MUST run between a >> NAS, located on AR, LMA, MR, etc. and an AAA server. >> >> [hannes] This requirement does not say a lot. The AAA protocol is >> always run between a client and a server. >> >> >> >> AAA-based PA application MUST support the AAA client to request >> prefixes from an AAA server. AAA-based PA application MUST support >> the client to give back the prefixes to the AAA server. >> >> [hannes] With the last sentence you mean that you need to have a way >> to indicate that the AAA session is terminated? > Frank=>In IPv6 renumbering scenario, it is necessary > >> >> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices >> on the network, the certificate or the information needed to obtain a >> certificate SHOULD also be sent by the AAA server to NAS. >> >> [hannes] What information do you exactly want to carry towards the >> AAA client? > Frank=>IPv6 address prefix for NAS is authorized to route > I mean, you want to provide * prefix * lifetime * certificate from the AAA server to the AAA client. What else? >> >> In point-to-point link operation, the NAS MUST identify the interface >> of MN in its request. The NAS MAY provide a prefix hint, e.g. of >> length /48 to which the AAA server MUST reply with one or more >> prefixes, e.g. of length /64. >> >> [hannes] how would such an interface identifier look like? > Frank=>Tentatively, it can be the interface identifier part of host's > link local > address, NAI (RFC4282), or MAC address. > I would like to better understand what the AAA server should be doing based on this hint. Is the "hint" used to identify the end user and it's host? >> >> In point-to-point operation, the AAA server MAY assign the prefix(es) >> and related parameters such as the lifetime and the certificates to >> MN from MN's profile. >> >> [hannes] I am not sure what this means. You mean that the AAA server >> should keep state to make sure that it does not forget what it has >> provided to the MN? > Frank=>Probably, the AAA server for prefix delegation is different from > the AAA server for authentication. So it is necessary to record the > state. > OK. I don't think that you need to say that since this is already done today. >> For some reason the problem is not well described. In Section 3 of >> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 >> but I do not quite understand what you would like to see happening >> instead. >> >> AAA-based prefix authorization application SHOULD support prefix >> release procedures. >> >> [hannes] isn't this the same as mentioned in the previous requirement >> "AAA-based PA application MUST support the client to give back the >> prefixes to the AAA server. " > Frank=>It is the same. > >> >> The NAS is responsible for renewing the prefixes when the lifetime >> expires. The NAS SHOULD be able to extend the lifetime of the >> prefixes using messages designed for this purpose. >> >> [hannes] Why wouldn't we tie the lifetime of the prefix to the >> lifetime of the AAA session itself? Makes things much easier. The >> same applies a bit to this requirement: "It SHOULD be possible to >> renumber the prefixes authorized by AAA server. The AAA server SHOULD >> initiate prefix renumbering process. " > Frank=>IPv6 renumbering is a feature of IPv6. > If we tie the lifetime of prefix to the lifetime of AAA session, > it is certain that we can't suport IPv6 renumbering. > Even though IPv6 renumbering probably happen probably > infrequently, it is better for us to have such a mechnism to support. > > For IPv6 renumbering, here are some references > RFC 1916/2071/2072/2874/2894/4076/4192. > I know IPv6 renumbering but I was wondering about the following issue. IPv6 renumber should occur less frequently and hence the lifetime is rather long. A AAA session typically isn't very long lived and it is possible to influence the lifetime with various parameters. Now, isn't it possible to re-authenticate and re-authorize the end host in case of network renumbering. Given that you have to re-authenticate quite often for other reasons as well shouldn't cause big problems. I am just trying to figure out how tough the requirements are. >> >> RFC2119 seems to be a bit randomly used in the document. > Frank=>We will polish the draft, > and also welcome more poeple to join us. > Ciao Hannes >> >> Ciao >> Hannes >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 13:00:27 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6703A6A50; Wed, 23 Jul 2008 13:00:27 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9693A68E7 for ; Wed, 23 Jul 2008 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 92KsXCPPAYNv for ; Wed, 23 Jul 2008 13:00:25 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 508573A6A50 for ; Wed, 23 Jul 2008 13:00:25 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4H005A269T58@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 15:01:06 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4H0079569S4N@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 15:01:05 -0500 (CDT) Date: Wed, 23 Jul 2008 15:01:04 -0500 From: Frank Xia To: Hannes Tschofenig Message-id: <02a501c8ecfe$d6d28bb0$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <488726EC.6030207@gmx.net> <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> <488786DE.6010400@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes Please check my reply.. BR Frank ----- Original Message ----- From: "Hannes Tschofenig" To: "Frank Xia" Cc: Sent: Wednesday, July 23, 2008 2:30 PM Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt > Hi Frank, > > thanks for the quick feedback. > > I have a few more comments inline > > Frank Xia wrote: >> Hi Hannes >> >> I try to jump ahead of Behcet to answer >> some of your questions :-) >> >> Please check inline comments. >> >> BR >> Frank >> >> >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: >> Sent: Wednesday, July 23, 2008 7:41 AM >> Subject: [Dime] Relationship between >> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and >> draft-sarikaya-dime-prefix-delegation-ps-01.txt >> >> >>> I have sent my rechartering questions around regarding these two >>> documents. I took a brief look at them and I wonder what the >>> relationship between the two documents is. Why are there 2 documents on >>> almost the same subject? >>> >> Frank=>They have almost the same main idea. >> You can only refer to the draft >> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. >> > Ok. We can essentially forget the other document. Right? Frank=>Yes. > > >>> When I browse through >>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>> then I sometimes get the impression that you would like to later >>> standardize a Diameter application. I wasn't sure why additional AVPs >>> aren't sufficient, in case existing AVPs cannot be re-used? >> Frank=>Prefix delegation is an authorization which may be >> decoupled from an authentication. RFC4005/4072 only deal >> with coupled authentication& authorization scenario. >> > It is true that the request for prefix authorization is not run > independently from the message exchanges used for authentication. Frank=>A little bit confusing. You meant "independently " or not? > >>> >>> Let me also comment on a few selected items: >>> >>> >>> AAA-based prefix authorization (PA) application MUST run between a NAS, >>> located on AR, LMA, MR, etc. and an AAA server. >>> >>> [hannes] This requirement does not say a lot. The AAA protocol is always >>> run between a client and a server. >>> >>> >>> >>> AAA-based PA application MUST support the AAA client to request prefixes >>> from an AAA server. AAA-based PA application MUST support the client to >>> give back the prefixes to the AAA server. >>> >>> [hannes] With the last sentence you mean that you need to have a way to >>> indicate that the AAA session is terminated? >> Frank=>In IPv6 renumbering scenario, it is necessary >> >>> >>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on >>> the network, the certificate or the information needed to obtain a >>> certificate SHOULD also be sent by the AAA server to NAS. >>> >>> [hannes] What information do you exactly want to carry towards the AAA >>> client? >> Frank=>IPv6 address prefix for NAS is authorized to route >> > I mean, you want to provide > * prefix > * lifetime > * certificate > from the AAA server to the AAA client. > What else? Frank=> I can only find these now. > >>> >>> In point-to-point link operation, the NAS MUST identify the interface of >>> MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 >>> to which the AAA server MUST reply with one or more prefixes, e.g. of >>> length /64. >>> >>> [hannes] how would such an interface identifier look like? >> Frank=>Tentatively, it can be the interface identifier part of host's >> link local >> address, NAI (RFC4282), or MAC address. >> > I would like to better understand what the AAA server should be doing > based on this hint. > Is the "hint" used to identify the end user and it's host? Frank=>The hint is only for expressing client's preference. The server may honor this or not based on it's own discretion. > >>> >>> In point-to-point operation, the AAA server MAY assign the prefix(es) >>> and related parameters such as the lifetime and the certificates to MN >>> from MN's profile. >>> >>> [hannes] I am not sure what this means. You mean that the AAA server >>> should keep state to make sure that it does not forget what it has >>> provided to the MN? >> Frank=>Probably, the AAA server for prefix delegation is different from >> the AAA server for authentication. So it is necessary to record the >> state. >> > OK. > > I don't think that you need to say that since this is already done today. > >>> For some reason the problem is not well described. In Section 3 of >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 >>> but I do not quite understand what you would like to see happening >>> instead. >>> >>> AAA-based prefix authorization application SHOULD support prefix release >>> procedures. >>> >>> [hannes] isn't this the same as mentioned in the previous requirement >>> "AAA-based PA application MUST support the client to give back the >>> prefixes to the AAA server. " >> Frank=>It is the same. >> >>> >>> The NAS is responsible for renewing the prefixes when the lifetime >>> expires. The NAS SHOULD be able to extend the lifetime of the prefixes >>> using messages designed for this purpose. >>> >>> [hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime >>> of the AAA session itself? Makes things much easier. The same applies a >>> bit to this requirement: "It SHOULD be possible to renumber the prefixes >>> authorized by AAA server. The AAA server SHOULD initiate prefix >>> renumbering process. " >> Frank=>IPv6 renumbering is a feature of IPv6. >> If we tie the lifetime of prefix to the lifetime of AAA session, >> it is certain that we can't suport IPv6 renumbering. >> Even though IPv6 renumbering probably happen probably >> infrequently, it is better for us to have such a mechnism to support. >> >> For IPv6 renumbering, here are some references >> RFC 1916/2071/2072/2874/2894/4076/4192. >> > I know IPv6 renumbering but I was wondering about the following issue. > > IPv6 renumber should occur less frequently and hence the lifetime is > rather long. > A AAA session typically isn't very long lived and it is possible to > influence the lifetime with various parameters. Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. In fact, many people including me are always online because many operators don't charge based on time. For example, $30 a month is for no limited access. > > Now, isn't it possible to re-authenticate and re-authorize the end host in > case of network renumbering. Given that you have to re-authenticate quite > often for other reasons as well shouldn't cause big problems. Frank=>IMHO, it is not very graceful to kick off all the users when renumbering. > > I am just trying to figure out how tough the requirements are. Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment. However, it is probably too late after large scale deployment. > >>> >>> RFC2119 seems to be a bit randomly used in the document. >> Frank=>We will polish the draft, >> and also welcome more poeple to join us. >> > > Ciao > Hannes >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 13:12:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279023A6ADE; Wed, 23 Jul 2008 13:12:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2F428C131 for ; Wed, 23 Jul 2008 13:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 1-wDjI9zNZp7 for ; Wed, 23 Jul 2008 13:12:40 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1DFE328C1B1 for ; Wed, 23 Jul 2008 13:12:39 -0700 (PDT) Received: (qmail invoked by alias); 23 Jul 2008 20:13:19 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp007) with SMTP; 23 Jul 2008 22:13:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18k6m41ilkkug8yBbLT9KZ5VrUriVGsJ0y6nIAbf1 eon9/eUMK/E90v Message-ID: <488790E1.7060901@gmx.net> Date: Wed, 23 Jul 2008 23:13:21 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Frank Xia References: <488726EC.6030207@gmx.net> <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> <488786DE.6010400@gmx.net> <02a501c8ecfe$d6d28bb0$5c0c7c0a@china.huawei.com> In-Reply-To: <02a501c8ecfe$d6d28bb0$5c0c7c0a@china.huawei.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: dime@ietf.org Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Frank, Frank Xia wrote: > Hi Hannes > > Please check my reply.. > > BR > Frank > ----- Original Message ----- From: "Hannes Tschofenig" > > To: "Frank Xia" > Cc: > Sent: Wednesday, July 23, 2008 2:30 PM > Subject: Re: [Dime] Relationship between > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > >> Hi Frank, >> >> thanks for the quick feedback. >> >> I have a few more comments inline >> >> Frank Xia wrote: >>> Hi Hannes >>> >>> I try to jump ahead of Behcet to answer >>> some of your questions :-) >>> >>> Please check inline comments. >>> >>> BR >>> Frank >>> >>> >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: >>> Sent: Wednesday, July 23, 2008 7:41 AM >>> Subject: [Dime] Relationship between >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and >>> draft-sarikaya-dime-prefix-delegation-ps-01.txt >>> >>> >>>> I have sent my rechartering questions around regarding these two >>>> documents. I took a brief look at them and I wonder what the >>>> relationship between the two documents is. Why are there 2 >>>> documents on almost the same subject? >>>> >>> Frank=>They have almost the same main idea. >>> You can only refer to the draft >>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. >>> >>> >> Ok. We can essentially forget the other document. Right? > Frank=>Yes. > >> >> >>>> When I browse through >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> then I sometimes get the impression that you would like to later >>>> standardize a Diameter application. I wasn't sure why additional >>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used? >>> Frank=>Prefix delegation is an authorization which may be >>> decoupled from an authentication. RFC4005/4072 only deal >>> with coupled authentication& authorization scenario. >>> >> It is true that the request for prefix authorization is not run >> independently from the message exchanges used for authentication. > Frank=>A little bit confusing. You meant "independently " or not? > I agree with you that RFC 4072 combines the prefix authorization protocol run with the EAP protocol run. RFC 4005 is a bit different since it has the RAR and RAA commands that allow you to perform re-authorization.Wouldn't they be a nice fit? >> >>>> >>>> Let me also comment on a few selected items: >>>> >>>> >>>> AAA-based prefix authorization (PA) application MUST run between a >>>> NAS, located on AR, LMA, MR, etc. and an AAA server. >>>> >>>> [hannes] This requirement does not say a lot. The AAA protocol is >>>> always run between a client and a server. >>>> >>>> >>>> >>>> AAA-based PA application MUST support the AAA client to request >>>> prefixes from an AAA server. AAA-based PA application MUST support >>>> the client to give back the prefixes to the AAA server. >>>> >>>> [hannes] With the last sentence you mean that you need to have a >>>> way to indicate that the AAA session is terminated? >>> Frank=>In IPv6 renumbering scenario, it is necessary >>> >>>> >>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the >>>> devices on the network, the certificate or the information needed >>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS. >>>> >>>> [hannes] What information do you exactly want to carry towards the >>>> AAA client? >>> Frank=>IPv6 address prefix for NAS is authorized to route >>> >> I mean, you want to provide >> * prefix >> * lifetime >> * certificate >> from the AAA server to the AAA client. >> What else? > Frank=> I can only find these now. > >> >>>> >>>> In point-to-point link operation, the NAS MUST identify the >>>> interface of MN in its request. The NAS MAY provide a prefix hint, >>>> e.g. of length /48 to which the AAA server MUST reply with one or >>>> more prefixes, e.g. of length /64. >>>> >>>> [hannes] how would such an interface identifier look like? >>> Frank=>Tentatively, it can be the interface identifier part of >>> host's link local >>> address, NAI (RFC4282), or MAC address. >>> >> I would like to better understand what the AAA server should be doing >> based on this hint. >> Is the "hint" used to identify the end user and it's host? > Frank=>The hint is only for expressing client's preference. The > server may honor this or not based on it's own discretion. > I guess you need to describe the details of this hint a bit more. >> >>>> >>>> In point-to-point operation, the AAA server MAY assign the >>>> prefix(es) and related parameters such as the lifetime and the >>>> certificates to MN from MN's profile. >>>> >>>> [hannes] I am not sure what this means. You mean that the AAA >>>> server should keep state to make sure that it does not forget what >>>> it has provided to the MN? >>> Frank=>Probably, the AAA server for prefix delegation is different from >>> the AAA server for authentication. So it is necessary to record the >>> state. >>> >> OK. >> >> I don't think that you need to say that since this is already done >> today. >> >>>> For some reason the problem is not well described. In Section 3 of >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC >>>> 4818 but I do not quite understand what you would like to see >>>> happening instead. >>>> >>>> AAA-based prefix authorization application SHOULD support prefix >>>> release procedures. >>>> >>>> [hannes] isn't this the same as mentioned in the previous >>>> requirement "AAA-based PA application MUST support the client to >>>> give back the prefixes to the AAA server. " >>> Frank=>It is the same. >>> >>>> >>>> The NAS is responsible for renewing the prefixes when the lifetime >>>> expires. The NAS SHOULD be able to extend the lifetime of the >>>> prefixes using messages designed for this purpose. >>>> >>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the >>>> lifetime of the AAA session itself? Makes things much easier. The >>>> same applies a bit to this requirement: "It SHOULD be possible to >>>> renumber the prefixes authorized by AAA server. The AAA server >>>> SHOULD initiate prefix renumbering process. " >>> Frank=>IPv6 renumbering is a feature of IPv6. >>> If we tie the lifetime of prefix to the lifetime of AAA session, >>> it is certain that we can't suport IPv6 renumbering. >>> Even though IPv6 renumbering probably happen probably >>> infrequently, it is better for us to have such a mechnism to support. >>> >>> For IPv6 renumbering, here are some references >>> RFC 1916/2071/2072/2874/2894/4076/4192. >>> >> I know IPv6 renumbering but I was wondering about the following issue. >> >> IPv6 renumber should occur less frequently and hence the lifetime is >> rather long. >> A AAA session typically isn't very long lived and it is possible to >> influence the lifetime with various parameters. > Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. > In fact, many people including me are always online because many > operators > don't charge based on time. For example, $30 a month is for no > limited access. > I don't know your home setup but typically you have a DSL router at home and your PC / laptop may be running all the time. Your DSL router re-connects automatically when re-authentication is needed. >> >> Now, isn't it possible to re-authenticate and re-authorize the end >> host in case of network renumbering. Given that you have to >> re-authenticate quite often for other reasons as well shouldn't cause >> big problems. > Frank=>IMHO, it is not very graceful to kick off all the users > when renumbering. Maybe. When I look at the IT problems I had this year then renumbering is the least thing I worry about. >> >> I am just trying to figure out how tough the requirements are. > Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment. > However, it is probably too late after large scale deployment. > Difficult to know, I agree. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 13:43:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984643A68E4; Wed, 23 Jul 2008 13:43:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181733A68E4 for ; Wed, 23 Jul 2008 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.235, 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 qwiYECdAO2vg for ; Wed, 23 Jul 2008 13:43:12 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id A31833A6887 for ; Wed, 23 Jul 2008 13:43:12 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4H00B4G897UV@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 15:43:55 -0500 (CDT) Received: from X24512z ([10.124.12.92]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4H007FK8954N@usaga04-in.huawei.com> for dime@ietf.org; Wed, 23 Jul 2008 15:43:55 -0500 (CDT) Date: Wed, 23 Jul 2008 15:43:53 -0500 From: Frank Xia To: Hannes Tschofenig Message-id: <02d701c8ed04$d283bc40$5c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <488726EC.6030207@gmx.net> <01f401c8ece4$da93b130$5c0c7c0a@china.huawei.com> <488786DE.6010400@gmx.net> <02a501c8ecfe$d6d28bb0$5c0c7c0a@china.huawei.com> <488790E1.7060901@gmx.net> Cc: dime@ietf.org Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello Hannes Please find my reply... BR Frank ----- Original Message ----- From: "Hannes Tschofenig" To: "Frank Xia" Cc: Sent: Wednesday, July 23, 2008 3:13 PM Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt > Hi Frank, > > Frank Xia wrote: >> Hi Hannes >> >> Please check my reply.. >> >> BR >> Frank >> ----- Original Message ----- From: "Hannes Tschofenig" >> >> To: "Frank Xia" >> Cc: >> Sent: Wednesday, July 23, 2008 2:30 PM >> Subject: Re: [Dime] Relationship between >> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and >> draft-sarikaya-dime-prefix-delegation-ps-01.txt >> >> >>> Hi Frank, >>> >>> thanks for the quick feedback. >>> >>> I have a few more comments inline >>> >>> Frank Xia wrote: >>>> Hi Hannes >>>> >>>> I try to jump ahead of Behcet to answer >>>> some of your questions :-) >>>> >>>> Please check inline comments. >>>> >>>> BR >>>> Frank >>>> >>>> >>>> ----- Original Message ----- From: "Hannes Tschofenig" >>>> >>>> To: >>>> Sent: Wednesday, July 23, 2008 7:41 AM >>>> Subject: [Dime] Relationship between >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and >>>> draft-sarikaya-dime-prefix-delegation-ps-01.txt >>>> >>>> >>>>> I have sent my rechartering questions around regarding these two >>>>> documents. I took a brief look at them and I wonder what the >>>>> relationship between the two documents is. Why are there 2 documents >>>>> on almost the same subject? >>>>> >>>> Frank=>They have almost the same main idea. >>>> You can only refer to the draft >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. >>>> >>> Ok. We can essentially forget the other document. Right? >> Frank=>Yes. >> >>> >>> >>>>> When I browse through >>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>>> then I sometimes get the impression that you would like to later >>>>> standardize a Diameter application. I wasn't sure why additional AVPs >>>>> aren't sufficient, in case existing AVPs cannot be re-used? >>>> Frank=>Prefix delegation is an authorization which may be >>>> decoupled from an authentication. RFC4005/4072 only deal >>>> with coupled authentication& authorization scenario. >>>> >>> It is true that the request for prefix authorization is not run >>> independently from the message exchanges used for authentication. >> Frank=>A little bit confusing. You meant "independently " or not? >> > > I agree with you that RFC 4072 combines the prefix authorization protocol > run with the EAP protocol run. > > RFC 4005 is a bit different since it has the RAR and RAA commands that > allow you to perform re-authorization.Wouldn't they be a nice fit? Frank=>RAR means Reauthentication or Reauthorization request. IMHO, there should be an authentication or authorization before. The message is still coupled with previous authentication. Can we use the PAR/PAA without invloveing previous authentication? I don't think so in RFC4005 context. > >>> >>>>> >>>>> Let me also comment on a few selected items: >>>>> >>>>> >>>>> AAA-based prefix authorization (PA) application MUST run between a >>>>> NAS, located on AR, LMA, MR, etc. and an AAA server. >>>>> >>>>> [hannes] This requirement does not say a lot. The AAA protocol is >>>>> always run between a client and a server. >>>>> >>>>> >>>>> >>>>> AAA-based PA application MUST support the AAA client to request >>>>> prefixes from an AAA server. AAA-based PA application MUST support the >>>>> client to give back the prefixes to the AAA server. >>>>> >>>>> [hannes] With the last sentence you mean that you need to have a way >>>>> to indicate that the AAA session is terminated? >>>> Frank=>In IPv6 renumbering scenario, it is necessary >>>> >>>>> >>>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices >>>>> on the network, the certificate or the information needed to obtain a >>>>> certificate SHOULD also be sent by the AAA server to NAS. >>>>> >>>>> [hannes] What information do you exactly want to carry towards the AAA >>>>> client? >>>> Frank=>IPv6 address prefix for NAS is authorized to route >>>> >>> I mean, you want to provide >>> * prefix >>> * lifetime >>> * certificate >>> from the AAA server to the AAA client. >>> What else? >> Frank=> I can only find these now. >> >>> >>>>> >>>>> In point-to-point link operation, the NAS MUST identify the interface >>>>> of MN in its request. The NAS MAY provide a prefix hint, e.g. of >>>>> length /48 to which the AAA server MUST reply with one or more >>>>> prefixes, e.g. of length /64. >>>>> >>>>> [hannes] how would such an interface identifier look like? >>>> Frank=>Tentatively, it can be the interface identifier part of host's >>>> link local >>>> address, NAI (RFC4282), or MAC address. >>>> >>> I would like to better understand what the AAA server should be doing >>> based on this hint. >>> Is the "hint" used to identify the end user and it's host? >> Frank=>The hint is only for expressing client's preference. The >> server may honor this or not based on it's own discretion. >> > I guess you need to describe the details of this hint a bit more. Frank=>OK. > >>> >>>>> >>>>> In point-to-point operation, the AAA server MAY assign the prefix(es) >>>>> and related parameters such as the lifetime and the certificates to MN >>>>> from MN's profile. >>>>> >>>>> [hannes] I am not sure what this means. You mean that the AAA server >>>>> should keep state to make sure that it does not forget what it has >>>>> provided to the MN? >>>> Frank=>Probably, the AAA server for prefix delegation is different from >>>> the AAA server for authentication. So it is necessary to record the >>>> state. >>>> >>> OK. >>> >>> I don't think that you need to say that since this is already done >>> today. >>> >>>>> For some reason the problem is not well described. In Section 3 of >>>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 >>>>> but I do not quite understand what you would like to see happening >>>>> instead. >>>>> >>>>> AAA-based prefix authorization application SHOULD support prefix >>>>> release procedures. >>>>> >>>>> [hannes] isn't this the same as mentioned in the previous requirement >>>>> "AAA-based PA application MUST support the client to give back the >>>>> prefixes to the AAA server. " >>>> Frank=>It is the same. >>>> >>>>> >>>>> The NAS is responsible for renewing the prefixes when the lifetime >>>>> expires. The NAS SHOULD be able to extend the lifetime of the prefixes >>>>> using messages designed for this purpose. >>>>> >>>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the >>>>> lifetime of the AAA session itself? Makes things much easier. The same >>>>> applies a bit to this requirement: "It SHOULD be possible to renumber >>>>> the prefixes authorized by AAA server. The AAA server SHOULD initiate >>>>> prefix renumbering process. " >>>> Frank=>IPv6 renumbering is a feature of IPv6. >>>> If we tie the lifetime of prefix to the lifetime of AAA session, >>>> it is certain that we can't suport IPv6 renumbering. >>>> Even though IPv6 renumbering probably happen probably >>>> infrequently, it is better for us to have such a mechnism to support. >>>> >>>> For IPv6 renumbering, here are some references >>>> RFC 1916/2071/2072/2874/2894/4076/4192. >>>> >>> I know IPv6 renumbering but I was wondering about the following issue. >>> >>> IPv6 renumber should occur less frequently and hence the lifetime is >>> rather long. >>> A AAA session typically isn't very long lived and it is possible to >>> influence the lifetime with various parameters. >> Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. >> In fact, many people including me are always online because many >> operators >> don't charge based on time. For example, $30 a month is for no limited >> access. >> > I don't know your home setup but typically you have a DSL router at home > and your PC / laptop may be running all the time. Your DSL router > re-connects automatically when re-authentication is needed. Frank=>IMHO,you assume that outgoing traffic trigger DSL router reconnection. It is not true in some scenarios. E.g. if you want to access your home computer which is not connecting to the network, I don't think the DSL router can initiate re-connect. > >>> >>> Now, isn't it possible to re-authenticate and re-authorize the end host >>> in case of network renumbering. Given that you have to re-authenticate >>> quite often for other reasons as well shouldn't cause big problems. >> Frank=>IMHO, it is not very graceful to kick off all the users >> when renumbering. > Maybe. > > When I look at the IT problems I had this year then renumbering is the > least thing I worry about. > >>> >>> I am just trying to figure out how tough the requirements are. >> Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment. >> However, it is probably too late after large scale deployment. >> > Difficult to know, I agree. > > Ciao > Hannes > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 16:15:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8803A6980; Wed, 23 Jul 2008 16:15:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3F03A6980 for ; Wed, 23 Jul 2008 16:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Zc9JUwxAZ5NN for ; Wed, 23 Jul 2008 16:15:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 767A33A6832 for ; Wed, 23 Jul 2008 16:15:45 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6NNGJcP027339; Wed, 23 Jul 2008 18:16:19 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 18:16:18 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 18:16:16 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8A== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 23 Jul 2008 23:16:18.0933 (UTC) FILETIME=[1CDE6A50:01C8ED1A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org My comments inline... Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 23, 2008 12:47 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Dong, A few comments/questions below. Thanks, Tolga > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 22, 2008 6:41 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > > Thanks for review and comments. see my responses inline... > copy to all authors in case they have further comments. > > Rgs, > Dong > > > -------- Original Message -------- > Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 > Date: Fri, 18 Jul 2008 11:19:22 -0400 > From: Asveren, Tolga > To: > > 1- Use of the same Application-Id for push/pull models It sounds > reasonable to me to think nodes which support only a single mode. How > can we guarantee that messages land to the right server considering > that the same Application-Id is used for both of them? > [Sun, Dong (Dong)] The trigger for initiating the push and pull models is > different, for example, when a new request from the PEP is recevied, the > Server will start the pull model. In fact, the push and pull are sharing > the same state machine per se. the main difference is just how to > establish a Diameter session. The enhancement is to allow the Diameter > Server to establish a session with a local trigger instead of the trigger > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same > application-Id causes any problem, especially for the pull model since > push/pull is able use the same server (certainly they can also have > separate server according to the configuration). [TOLGA]My concern here is about message routing rather than the state machine processing in the server. Let's say a server is capable only to accommodate pull model (it doesn't know what NE to contact if push model is required). How can the network intermediaries, e.g. relay agent, forward the initial request in the session to the right server for push model? How can they be sure that the server supports push model? [Dong] The relay agent should route the message according to the destination address/realm that is filled up by the requestor. I don't know how the application id will affect this kind of routing. > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > > > 3- 3. Framework > "For Push mode, the authorizing entity needs to identify the > appropriate NE(s) to which QoS authorization information needs to be > pushed. It might determine this based on information received from > the AppS, such as the IP addresses of media flows." > It could be a good idea to give a bit more information about this: > - This is hard to do as Authorizing Entity would need to have > information about routing decisions of NEs for a particular flow > - QoS in the core network is usually not scarce > - QoS on the access side is scarce > - It is not difficult for the Authorizing Entity to determine NEs > facing the access side as usually this information is stored somewhere > when the endpoint attaches to the network and does not change per IP > flow. > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery > of these NEs is not necessarily based on the routing info, instead, it can > be preconfigured. > In addition, i think this draft mainly focuses on the mechanism and > protocol. It can be used for both access and core networks. the QoS status > you described looks like well known, not sure how much it may add. [TOLGA]Even for some of the nodes you mentioned, I would expect routing to play a role here. For example if there are more than one gateway, AE needs to know which one it should contact for that particular stream. [Dong] in practice a rendezvous AE or hierarchical AEs will derive the address of the right gateway according to preconfigured info in a database or through DNS query. The point is that the NE/PEP is an anchoring point for certain streams per provisioning, not random routing for selecting those PEPs (except load balancing). In other words, not every NE/router is eligible to serve as the PEP in reality. > > 4- 3.4 QoS Application Requirements > > "Identity-based Routing > The QoS AAA protocol MUST route AAA requests to the Authorizing > Entity, based on the provided identity of the QoS requesting > entity or the identity of the AE encoded in the provided > authorization token." > > I think it is responsibility of the QoS application -not QoS AAA > protocol- to perform routing decision based on identity. The application > decided for the host/realm and the protocol routes the message based on > that. > > I think it could be better to have a global change in this section: > QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)] looks ok > to me. > > 5- 3.4 QoS Application Requirements > "Sending Accounting Records > The NE SHOULD be able to send accounting records for a particular > QoS reservation state to an accounting entity." > Is this a QoS AAA application requirement? It is stated as a requirement > on NE. > [Sun, Dong (Dong)] it is for NE, since we decided to remove the > accounting related texts, this one could be gone, IMHO. > > > 6- 4.2 Session Establishment > "When a QoS-Authz-Request > (QAR, see Section 5.1) message with a new session ID is received, the > AE operates in the Pull mode; when other triggers are received, the > AE operates in the Push mode." > Would this shut down the door for certain failure recovery scenarios? > For example AE goes down and a backup AE takes over. IMO it is a nice > feature if the backup can continue existing sessions without a need to > synchronizing state with the failed active AE. This can be achieved by > carrying enough information about session state in the message itself > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > impossible. For certain scenarios backup AE would determine the required > mode wrong. I suggest the decision for push/pull is not based on message > name but on the message content. > [Sun, Dong (Dong)] I think this is the most straightforward and > consistent way in terms of state machine to decide the pull/push. and it > will work well for the hot standby case, but indeed, it may have some > issue with cold standby. In general, the failure handling is not addressed > in the draft very much. The question is, do we need to add the failure > handling in detail or not for backup server case? [TOLGA]I agree that details of failure handling may not belong here. OTOH that the QoS application is failover friendly is a parameter to consider IMHO. By carrying enough information in each message so that cold standby elements can be used to take over existing sessions, one trades small amount of bandwidth and limited CPU cycles for complexity in software and probably even more CPU cycles. IMHO this is a bargain. I found this very handy in DCCA. Wouldn't just defining an AVP indicating the type of service requested (push v.s. pull) solve this problem? Actually this issue is also tied to Application-Id problem. If different Application-Ids are used, that implicitly will define the mode required/used. [Dong] I don't think it makes sense to mandate this kind of parameter for failover since it is more useful for one type of failure handling approach rather than the other. But it is ok to have an optional parameter but it does add significant overhead in the message. In addition, not sure why the application id is tied up with this issue, even in general the routing issue as I explained above. I think the failure handling approach should be consistent for all Diameter applications rather than defining specific one for QoS application. > > 7- There were some proposals about a mode, where NE is notified from AE > to reserve resources all the way till the end point. Is this considered > out of scope? > [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but > it is not a different mode, just an implementation of resource reservation > within the bearer layer. it is mentioned in the section 9 as example. [TOLGA]I think I couldn't explain well what I meant. The model I am talking about is that AE tells NE to reserve resources not only in itself but also through the whole bearer path, e.g. RSVP from edge router to edge router. Is it possible to do this with this version of QoS application draft? [Dong] sure. Absolutely. Current QoS application draft does support it if the NE is able to use the RSVP. However, how to support the RSVP in the NE (procedure, mechanism) is out of scope in this draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 23 16:38:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DD43A6768; Wed, 23 Jul 2008 16:38:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109893A6768 for ; Wed, 23 Jul 2008 16:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2TqwKaTHE-K for ; Wed, 23 Jul 2008 16:38:47 -0700 (PDT) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id B52603A63C9 for ; Wed, 23 Jul 2008 16:38:47 -0700 (PDT) Received: from aruba-mx2.arubanetworks.com ([10.1.1.83]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 16:39:15 -0700 Received: from mail pickup service by aruba-mx2.arubanetworks.com with Microsoft SMTPSVC; Wed, 23 Jul 2008 16:39:04 -0700 Received: from mail.arubanetworks.com ([10.1.1.4]) by aruba-mx2.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 16:25:12 -0700 Received: from ihemail4.lucent.com ([135.245.0.39]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Jul 2008 16:16:25 -0700 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6NNGJcP027339; Wed, 23 Jul 2008 18:16:19 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 18:16:18 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Jul 2008 18:16:16 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8A== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 23 Jul 2008 23:16:18.0933 (UTC) FILETIME=[1CDE6A50:01C8ED1A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Score: -100 X-NAI-Spam-Threshold: 3 X-NAI-Spam-Report: 2 Rules triggered * -100 -- USER_IN_WHITELIST -- From: address is in the user's white-list * 0 -- RV3066 -- Version number X-NAI-Spam-Checker-Version: NAI SpamAssassin 1.2 (2.70 20080723 3066) Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org My comments inline... Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 23, 2008 12:47 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Dong, A few comments/questions below. Thanks, Tolga > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 22, 2008 6:41 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > > Thanks for review and comments. see my responses inline... > copy to all authors in case they have further comments. > > Rgs, > Dong > > > -------- Original Message -------- > Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 > Date: Fri, 18 Jul 2008 11:19:22 -0400 > From: Asveren, Tolga > To: > > 1- Use of the same Application-Id for push/pull models It sounds > reasonable to me to think nodes which support only a single mode. How > can we guarantee that messages land to the right server considering > that the same Application-Id is used for both of them? > [Sun, Dong (Dong)] The trigger for initiating the push and pull models is > different, for example, when a new request from the PEP is recevied, the > Server will start the pull model. In fact, the push and pull are sharing > the same state machine per se. the main difference is just how to > establish a Diameter session. The enhancement is to allow the Diameter > Server to establish a session with a local trigger instead of the trigger > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same > application-Id causes any problem, especially for the pull model since > push/pull is able use the same server (certainly they can also have > separate server according to the configuration). [TOLGA]My concern here is about message routing rather than the state machine processing in the server. Let's say a server is capable only to accommodate pull model (it doesn't know what NE to contact if push model is required). How can the network intermediaries, e.g. relay agent, forward the initial request in the session to the right server for push model? How can they be sure that the server supports push model? [Dong] The relay agent should route the message according to the destination address/realm that is filled up by the requestor. I don't know how the application id will affect this kind of routing. > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > > > 3- 3. Framework > "For Push mode, the authorizing entity needs to identify the > appropriate NE(s) to which QoS authorization information needs to be > pushed. It might determine this based on information received from > the AppS, such as the IP addresses of media flows." > It could be a good idea to give a bit more information about this: > - This is hard to do as Authorizing Entity would need to have > information about routing decisions of NEs for a particular flow > - QoS in the core network is usually not scarce > - QoS on the access side is scarce > - It is not difficult for the Authorizing Entity to determine NEs > facing the access side as usually this information is stored somewhere > when the endpoint attaches to the network and does not change per IP > flow. > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery > of these NEs is not necessarily based on the routing info, instead, it can > be preconfigured. > In addition, i think this draft mainly focuses on the mechanism and > protocol. It can be used for both access and core networks. the QoS status > you described looks like well known, not sure how much it may add. [TOLGA]Even for some of the nodes you mentioned, I would expect routing to play a role here. For example if there are more than one gateway, AE needs to know which one it should contact for that particular stream. [Dong] in practice a rendezvous AE or hierarchical AEs will derive the address of the right gateway according to preconfigured info in a database or through DNS query. The point is that the NE/PEP is an anchoring point for certain streams per provisioning, not random routing for selecting those PEPs (except load balancing). In other words, not every NE/router is eligible to serve as the PEP in reality. > > 4- 3.4 QoS Application Requirements > > "Identity-based Routing > The QoS AAA protocol MUST route AAA requests to the Authorizing > Entity, based on the provided identity of the QoS requesting > entity or the identity of the AE encoded in the provided > authorization token." > > I think it is responsibility of the QoS application -not QoS AAA > protocol- to perform routing decision based on identity. The application > decided for the host/realm and the protocol routes the message based on > that. > > I think it could be better to have a global change in this section: > QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)] looks ok > to me. > > 5- 3.4 QoS Application Requirements > "Sending Accounting Records > The NE SHOULD be able to send accounting records for a particular > QoS reservation state to an accounting entity." > Is this a QoS AAA application requirement? It is stated as a requirement > on NE. > [Sun, Dong (Dong)] it is for NE, since we decided to remove the > accounting related texts, this one could be gone, IMHO. > > > 6- 4.2 Session Establishment > "When a QoS-Authz-Request > (QAR, see Section 5.1) message with a new session ID is received, the > AE operates in the Pull mode; when other triggers are received, the > AE operates in the Push mode." > Would this shut down the door for certain failure recovery scenarios? > For example AE goes down and a backup AE takes over. IMO it is a nice > feature if the backup can continue existing sessions without a need to > synchronizing state with the failed active AE. This can be achieved by > carrying enough information about session state in the message itself > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > impossible. For certain scenarios backup AE would determine the required > mode wrong. I suggest the decision for push/pull is not based on message > name but on the message content. > [Sun, Dong (Dong)] I think this is the most straightforward and > consistent way in terms of state machine to decide the pull/push. and it > will work well for the hot standby case, but indeed, it may have some > issue with cold standby. In general, the failure handling is not addressed > in the draft very much. The question is, do we need to add the failure > handling in detail or not for backup server case? [TOLGA]I agree that details of failure handling may not belong here. OTOH that the QoS application is failover friendly is a parameter to consider IMHO. By carrying enough information in each message so that cold standby elements can be used to take over existing sessions, one trades small amount of bandwidth and limited CPU cycles for complexity in software and probably even more CPU cycles. IMHO this is a bargain. I found this very handy in DCCA. Wouldn't just defining an AVP indicating the type of service requested (push v.s. pull) solve this problem? Actually this issue is also tied to Application-Id problem. If different Application-Ids are used, that implicitly will define the mode required/used. [Dong] I don't think it makes sense to mandate this kind of parameter for failover since it is more useful for one type of failure handling approach rather than the other. But it is ok to have an optional parameter but it does add significant overhead in the message. In addition, not sure why the application id is tied up with this issue, even in general the routing issue as I explained above. I think the failure handling approach should be consistent for all Diameter applications rather than defining specific one for QoS application. > > 7- There were some proposals about a mode, where NE is notified from AE > to reserve resources all the way till the end point. Is this considered > out of scope? > [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but > it is not a different mode, just an implementation of resource reservation > within the bearer layer. it is mentioned in the section 9 as example. [TOLGA]I think I couldn't explain well what I meant. The model I am talking about is that AE tells NE to reserve resources not only in itself but also through the whole bearer path, e.g. RSVP from edge router to edge router. Is it possible to do this with this version of QoS application draft? [Dong] sure. Absolutely. Current QoS application draft does support it if the NE is able to use the RSVP. However, how to support the RSVP in the NE (procedure, mechanism) is out of scope in this draft. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 02:18:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA7328C0D8; Thu, 24 Jul 2008 02:18:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B57828C0D6 for ; Thu, 24 Jul 2008 02:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSo79ZH3HwIB for ; Thu, 24 Jul 2008 02:18:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A880F3A684B for ; Thu, 24 Jul 2008 02:18:13 -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 <0K4I00LDK74LOF@szxga03-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:17:09 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4I00D9J74L56@szxga03-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:17:09 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4I00ARD74KCN@szxml05-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:17:09 +0800 (CST) Date: Thu, 24 Jul 2008 17:17:08 +0800 From: Tina TSOU To: "Asveren, Tolga" , "Sun, Dong (Dong)" Message-id: <018701c8ed6e$0c364d90$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142500290==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1142500290== Content-type: multipart/alternative; boundary="Boundary_(ID_Yd1lxGRQOILrxZSflnbFgw)" This is a multi-part message in MIME format. --Boundary_(ID_Yd1lxGRQOILrxZSflnbFgw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Dong, I agree with you:-) Cheers, Tina ----- Original Message ----- From: Sun, Dong (Dong) To: Asveren, Tolga Cc: dime@ietf.org ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Tina TSOU ; Glen Zorn Sent: Thursday, July 24, 2008 7:16 AM Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] My comments inline... Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Wednesday, July 23, 2008 12:47 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Dong, A few comments/questions below. Thanks, Tolga > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 22, 2008 6:41 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > > Thanks for review and comments. see my responses inline... > copy to all authors in case they have further comments. > > Rgs, > Dong > > > -------- Original Message -------- > Subject: [Dime] Comments for draft-ietf-dime-diameter-qos-06 > Date: Fri, 18 Jul 2008 11:19:22 -0400 > From: Asveren, Tolga > To: > > 1- Use of the same Application-Id for push/pull models It sounds > reasonable to me to think nodes which support only a single mode. How > can we guarantee that messages land to the right server considering > that the same Application-Id is used for both of them? > [Sun, Dong (Dong)] The trigger for initiating the push and pull models is > different, for example, when a new request from the PEP is recevied, the > Server will start the pull model. In fact, the push and pull are sharing > the same state machine per se. the main difference is just how to > establish a Diameter session. The enhancement is to allow the Diameter > Server to establish a session with a local trigger instead of the trigger > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the same > application-Id causes any problem, especially for the pull model since > push/pull is able use the same server (certainly they can also have > separate server according to the configuration). [TOLGA]My concern here is about message routing rather than the state machine processing in the server. Let's say a server is capable only to accommodate pull model (it doesn't know what NE to contact if push model is required). How can the network intermediaries, e.g. relay agent, forward the initial request in the session to the right server for push model? How can they be sure that the server supports push model? [Dong] The relay agent should route the message according to the destination address/realm that is filled up by the requestor. I don't know how the application id will affect this kind of routing. > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > > > 3- 3. Framework > "For Push mode, the authorizing entity needs to identify the > appropriate NE(s) to which QoS authorization information needs to be > pushed. It might determine this based on information received from > the AppS, such as the IP addresses of media flows." > It could be a good idea to give a bit more information about this: > - This is hard to do as Authorizing Entity would need to have > information about routing decisions of NEs for a particular flow > - QoS in the core network is usually not scarce > - QoS on the access side is scarce > - It is not difficult for the Authorizing Entity to determine NEs > facing the access side as usually this information is stored somewhere > when the endpoint attaches to the network and does not change per IP > flow. > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement are > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the discovery > of these NEs is not necessarily based on the routing info, instead, it can > be preconfigured. > In addition, i think this draft mainly focuses on the mechanism and > protocol. It can be used for both access and core networks. the QoS status > you described looks like well known, not sure how much it may add. [TOLGA]Even for some of the nodes you mentioned, I would expect routing to play a role here. For example if there are more than one gateway, AE needs to know which one it should contact for that particular stream. [Dong] in practice a rendezvous AE or hierarchical AEs will derive the address of the right gateway according to preconfigured info in a database or through DNS query. The point is that the NE/PEP is an anchoring point for certain streams per provisioning, not random routing for selecting those PEPs (except load balancing). In other words, not every NE/router is eligible to serve as the PEP in reality. > > 4- 3.4 QoS Application Requirements > > "Identity-based Routing > The QoS AAA protocol MUST route AAA requests to the Authorizing > Entity, based on the provided identity of the QoS requesting > entity or the identity of the AE encoded in the provided > authorization token." > > I think it is responsibility of the QoS application -not QoS AAA > protocol- to perform routing decision based on identity. The application > decided for the host/realm and the protocol routes the message based on > that. > > I think it could be better to have a global change in this section: > QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)] looks ok > to me. > > 5- 3.4 QoS Application Requirements > "Sending Accounting Records > The NE SHOULD be able to send accounting records for a particular > QoS reservation state to an accounting entity." > Is this a QoS AAA application requirement? It is stated as a requirement > on NE. > [Sun, Dong (Dong)] it is for NE, since we decided to remove the > accounting related texts, this one could be gone, IMHO. > > > 6- 4.2 Session Establishment > "When a QoS-Authz-Request > (QAR, see Section 5.1) message with a new session ID is received, the > AE operates in the Pull mode; when other triggers are received, the > AE operates in the Push mode." > Would this shut down the door for certain failure recovery scenarios? > For example AE goes down and a backup AE takes over. IMO it is a nice > feature if the backup can continue existing sessions without a need to > synchronizing state with the failed active AE. This can be achieved by > carrying enough information about session state in the message itself > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > impossible. For certain scenarios backup AE would determine the required > mode wrong. I suggest the decision for push/pull is not based on message > name but on the message content. > [Sun, Dong (Dong)] I think this is the most straightforward and > consistent way in terms of state machine to decide the pull/push. and it > will work well for the hot standby case, but indeed, it may have some > issue with cold standby. In general, the failure handling is not addressed > in the draft very much. The question is, do we need to add the failure > handling in detail or not for backup server case? [TOLGA]I agree that details of failure handling may not belong here. OTOH that the QoS application is failover friendly is a parameter to consider IMHO. By carrying enough information in each message so that cold standby elements can be used to take over existing sessions, one trades small amount of bandwidth and limited CPU cycles for complexity in software and probably even more CPU cycles. IMHO this is a bargain. I found this very handy in DCCA. Wouldn't just defining an AVP indicating the type of service requested (push v.s. pull) solve this problem? Actually this issue is also tied to Application-Id problem. If different Application-Ids are used, that implicitly will define the mode required/used. [Dong] I don't think it makes sense to mandate this kind of parameter for failover since it is more useful for one type of failure handling approach rather than the other. But it is ok to have an optional parameter but it does add significant overhead in the message. In addition, not sure why the application id is tied up with this issue, even in general the routing issue as I explained above. I think the failure handling approach should be consistent for all Diameter applications rather than defining specific one for QoS application. > > 7- There were some proposals about a mode, where NE is notified from AE > to reserve resources all the way till the end point. Is this considered > out of scope? > [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, but > it is not a different mode, just an implementation of resource reservation > within the bearer layer. it is mentioned in the section 9 as example. [TOLGA]I think I couldn't explain well what I meant. The model I am talking about is that AE tells NE to reserve resources not only in itself but also through the whole bearer path, e.g. RSVP from edge router to edge router. Is it possible to do this with this version of QoS application draft? [Dong] sure. Absolutely. Current QoS application draft does support it if the NE is able to use the RSVP. However, how to support the RSVP in the NE (procedure, mechanism) is out of scope in this draft. --Boundary_(ID_Yd1lxGRQOILrxZSflnbFgw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Dong,
I agree with you:-)
 
Cheers,
Tina
----- Original Message -----
Sent: Thursday, July 24, 2008 7:16 AM
Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

My comments inline...
Rgs,
Dong

-----Original Message-----
From: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Wednesday, July 23, 2008 12:47 PM
To: Sun, Dong (Dong)
Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann
Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn
Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06]

Hi Dong,

A few comments/questions below.

Thanks,
Tolga

> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com]
> Sent: Tuesday, July 22, 2008 6:41 PM
> To: Asveren, Tolga
> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-
> A001034; Avri Doria; Tina TSOU; Glen Zorn
> Subject: RE: [Fwd: [Dime] Comments for
draft-ietf-dime-diameter-qos-06]
>
> Hi Tolga,
>
> Thanks for review and comments. see my responses inline...
> copy to all authors in case they have further comments.
>
> Rgs,
> Dong
>
>
> -------- Original Message --------
> Subject:        [Dime] Comments for draft-ietf-dime-diameter-qos-06
> Date:   Fri, 18 Jul 2008 11:19:22 -0400
> From:   Asveren, Tolga <tasveren@sonusnet.com>
> To:     <dime@ietf.org>
>
> 1- Use of the same Application-Id for push/pull models It sounds
> reasonable to me to think nodes which support only a single mode. How
> can we guarantee that messages land to the right server considering
> that the same Application-Id is used for both of them?
> [Sun, Dong (Dong)]  The trigger for initiating the push and pull
models is
> different, for example, when a new request from the PEP is recevied,
the
> Server will start the pull model. In fact, the push and pull are
sharing
> the same state machine per se. the main difference is just how to
> establish a Diameter session. The enhancement is to allow the Diameter

> Server to establish a session with a local trigger instead of the
trigger
> from the Diameter client (i.e. NE/PEP). Therefore, I don't think the
same
> application-Id causes any problem, especially for the pull model since

> push/pull is able use the same server (certainly they can also have
> separate server according to the configuration).
[TOLGA]My concern here is about message routing rather than the state
machine processing in the server. Let's say a server is capable only to
accommodate pull model (it doesn't know what NE to contact if push model
is required). How can the network intermediaries, e.g. relay agent,
forward the initial request in the session to the right server for push
model? How can they be sure that the server supports push model?
[Dong] The relay agent should route the message according to the
destination address/realm that is filled up by the requestor. I don't
know how the application id will affect this kind of routing.
>
> 2- 3. Framework
>    "After receiving the
>    authorization request from the AppS or the NE, the AE decides the
>    appropriate mode (i.e.  Push or Pull).  The usage Push or Pull mode
>    can be determined by the authorizing entity either statically or
>    dynamically."
> I think I am missing something here. Don't we have always push mode if

> the authorization request is received from AppS? Or are we talking
about
> a hybrid model where first AppS contacts the Authorizing Entity,
> receives a token, hands it over to media layer, and this token is used

> in turn by NE for pull mode?
> [Sun, Dong (Dong)] I don't think we are talking about a hybrid model.
my
> understanding is that the push and pull models can be decided by AE on
per
> call session basis (i.e. dynamically), or can be pre-configured for
one of
> them (i.e. statically). If this is correct, the texts may be modified
as
> follows for clarity:
>  "The push and pull models can be decided by the AE on per call
session
> basis (i.e. dynamically), or can be pre-configured for one of them
(i.e.
> statically). Without any pre-configuration, when receiving a new
> authorization request from the Apps or a local trigger, the AE starts
the
> Push model; when receiving a new authorization request from the NE,
the AE
> starts the Pull model."
> [Sun, Dong (Dong)] Tina,  I thought the initial texts come from you.
could
> you verify my comment or give some further clafication. are you ok
with
> the modified texts?
> I will update the document accordingly if no objection.
>
>
> 3- 3. Framework
>    "For Push mode, the authorizing entity needs to identify the
>    appropriate NE(s) to which QoS authorization information needs to
be
>    pushed.  It might determine this based on information received from
>    the AppS, such as the IP addresses of media flows."
> It could be a good idea to give a bit more information about this:
> - This is hard to do as Authorizing Entity would need to have
> information about routing decisions of NEs for a particular flow
> -  QoS in the core network is usually not scarce
> -  QoS on the access side is scarce
> -  It is not difficult for the Authorizing Entity to determine NEs
> facing the access side as usually this information is stored somewhere

> when the endpoint attaches to the network and does not change per IP
> flow.
> [Sun, Dong (Dong)]  my understanding is the NEs for Policy enforcement
are
> usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the
discovery
> of these NEs is not necessarily based on the routing info, instead, it
can
> be preconfigured.
> In addition, i think this draft mainly focuses on the mechanism and
> protocol. It can be used for both access and core networks. the QoS
status
> you described looks like well known, not sure how much it may add.
[TOLGA]Even for some of the nodes you mentioned, I would expect routing
to play a role here. For example if there are more than one gateway, AE
needs to know which one it should contact for that particular stream.
[Dong] in practice a rendezvous AE or hierarchical AEs will derive the
address of the right gateway according to preconfigured info in a
database or through DNS query. The point is that the NE/PEP is an
anchoring point for certain streams per provisioning, not random routing
for selecting those PEPs (except load balancing). In other words, not
every NE/router is eligible to serve as the PEP in reality.
>
> 4- 3.4 QoS Application Requirements
>
>       "Identity-based Routing
>       The QoS AAA protocol MUST route AAA requests to the Authorizing
>       Entity, based on the provided identity of the QoS requesting
>       entity or the identity of the AE encoded in the provided
>       authorization token."
>
> I think it is responsibility of the QoS application -not QoS AAA
> protocol- to perform routing decision based on identity. The
application
> decided for the host/realm and the protocol routes the message based
on
> that.
>
> I think it could be better to have a global change in this section:
> QoS AAA protocol ==> QoS AAA application [Sun, Dong (Dong)]  looks ok
> to me.
>
> 5- 3.4 QoS Application Requirements
>       "Sending Accounting Records
>       The NE SHOULD be able to send accounting records for a
particular
>       QoS reservation state to an accounting entity."
> Is this a QoS AAA application requirement? It is stated as a
requirement
> on NE.
> [Sun, Dong (Dong)]  it is for NE, since we decided to remove the
> accounting related texts, this one could be gone, IMHO.
>
>
> 6- 4.2 Session Establishment
>    "When a QoS-Authz-Request
>    (QAR, see Section 5.1) message with a new session ID is received,
the
>    AE operates in the Pull mode; when other triggers are received, the
>    AE operates in the Push mode."
> Would this shut down the door for certain failure recovery scenarios?
> For example AE goes down and a backup AE takes over. IMO it is a nice
> feature if the backup can continue existing sessions without a need to

> synchronizing state with the failed active AE. This can be achieved by

> carrying enough information about session state in the message itself
> (AFAIR, DCCA can do this nicely). The approach I quoted makes this
> impossible. For certain scenarios backup AE would determine the
required
> mode wrong. I suggest the decision for push/pull is not based on
message
> name but on the message content.
> [Sun, Dong (Dong)]  I think this is the most straightforward and
> consistent way in terms of state machine to decide the pull/push. and
it
> will work well for the hot standby case, but indeed, it may have some
> issue with cold standby. In general, the failure handling is not
addressed
> in the draft very much. The question is, do we need to add the failure

> handling in detail or not for backup server case?
[TOLGA]I agree that details of failure handling may not belong here.
OTOH that the QoS application is failover friendly is a parameter to
consider IMHO. By carrying enough information in each message so that
cold standby elements can be used to take over existing sessions, one
trades small amount of bandwidth and limited CPU cycles for complexity
in software and probably even more CPU cycles. IMHO this is a bargain. I
found this very handy in DCCA. Wouldn't just defining an AVP indicating
the type of service requested (push v.s. pull) solve this problem?
Actually this issue is also tied to Application-Id problem. If different
Application-Ids are used, that implicitly will define the mode
required/used.
[Dong] I don't think it makes sense to mandate this kind of parameter
for failover since it is more useful for one type of failure handling
approach rather than the other. But it is ok to have an optional
parameter but it does add significant overhead in the message. In
addition, not sure why the application id is tied up with this issue,
even in general the routing issue as I explained above.
I think the failure handling approach should be consistent for all
Diameter applications rather than defining specific one for QoS
application.
>
> 7- There were some proposals about a mode, where NE is notified from
AE
> to reserve resources all the way till the end point. Is this
considered
> out of scope?
> [Sun, Dong (Dong)]  it can be supporoted implicited by the applicaion,
but
> it is not a different mode, just an implementation of resource
reservation
> within the bearer layer. it is mentioned in the section 9 as example.
[TOLGA]I think I couldn't explain well what I meant. The model I am
talking about is that AE tells NE to reserve resources not only in
itself but also through the whole bearer path, e.g. RSVP from edge
router to edge router. Is it possible to do this with this version of
QoS application draft?
[Dong] sure. Absolutely. Current QoS application draft does support it
if the NE is able to use the RSVP. However, how to support the RSVP in
the NE (procedure, mechanism) is out of scope in this draft.
--Boundary_(ID_Yd1lxGRQOILrxZSflnbFgw)-- --===============1142500290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1142500290==-- From dime-bounces@ietf.org Thu Jul 24 02:22:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA42C3A684B; Thu, 24 Jul 2008 02:22:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3F13A684B for ; Thu, 24 Jul 2008 02:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.17 X-Spam-Level: X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7f-y-JLag1W for ; Thu, 24 Jul 2008 02:22:01 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 35DD73A682E for ; Thu, 24 Jul 2008 02:22:01 -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 <0K4I00GVM7DHQS@szxga01-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:22:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4I00GU27DHD7@szxga01-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:22:29 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4I0043B7DG0K@szxml04-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:22:29 +0800 (CST) Date: Thu, 24 Jul 2008 17:22:28 +0800 From: Tina TSOU To: "Sun, Dong (Dong)" , "Asveren, Tolga" Message-id: <019301c8ed6e$cb29d140$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E701205F12@sonusmail04.sonusnet.com> Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000437150==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0000437150== Content-type: multipart/alternative; boundary="Boundary_(ID_d0yeUgQa47YhjfHrL88ZQg)" This is a multi-part message in MIME format. --Boundary_(ID_d0yeUgQa47YhjfHrL88ZQg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Tolga, Good question:-) Comments in line beginning with [Tina: ...] Cheers, Tina ----- Original Message ----- From: Asveren, Tolga To: Tina TSOU ; Sun, Dong (Dong) Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes (NSN - FI/Espoo) ; dime@ietf.org Sent: Thursday, July 24, 2008 2:22 AM Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Tina, One question below. Thanks, Tolga [.. snip ..] > > 2- 3. Framework > "After receiving the > authorization request from the AppS or the NE, the AE decides the > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > can be determined by the authorizing entity either statically or > dynamically." > I think I am missing something here. Don't we have always push mode if > the authorization request is received from AppS? Or are we talking about > a hybrid model where first AppS contacts the Authorizing Entity, > receives a token, hands it over to media layer, and this token is used > in turn by NE for pull mode? > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. my > understanding is that the push and pull models can be decided by AE on per > call session basis (i.e. dynamically), or can be pre-configured for one of > them (i.e. statically). If this is correct, the texts may be modified as > follows for clarity: > "The push and pull models can be decided by the AE on per call session > basis (i.e. dynamically), or can be pre-configured for one of them (i.e. > statically). Without any pre-configuration, when receiving a new > authorization request from the Apps or a local trigger, the AE starts the > Push model; when receiving a new authorization request from the NE, the AE > starts the Pull model." > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. could > you verify my comment or give some further clafication. are you ok with > the modified texts? > I will update the document accordingly if no objection. > [Tina: As is specified in the document, "the diversity of QoS capabilities > of endpoints and QoS schemes of network technology leads to the > distinction > on the interaction mode between QoS authorization system and underlying > NEs". > Therefore, I think the hybrid model should be supported. After receiving a > new authorization request from the AppS, the AE can decide which mode > should > be used based on the information of the request, especially based on the > information which indicates QoS capability and the access network type. So > I > don't see any problem with the original text. > However, as is proposed by Hannes, the AVP could be added > into the QoS-Request message. Besides, I think the > AVP > should also be added to indicate the network technology since the network > technology is another factor affecting the type of QoS Model being used.] [TOLGA]I just am trying to understand the use case: I understand that endpoints will have different QoS reservation capabilities. i- I have a device, which can't reserve QoS for the media but can indicate its desire to do so in signaling. AppS would determine that push mode is desired. ii- I have a device, which can't reserve QoS for the media and can't indicate its desire to do so in signaling. AppS could determine statically what to do. iii- I have a device, which can reserve QoS for the media. It uses its own capabilities whenever it needs. I guess what I am trying to figure out is, why decision process does not belong to AppS? For , I can see that this type of information could be useful, e.g. a device attached via DOCSIS to IP network v.s. a device attached via a 3GPP technology. OTOH, isn't this information actually necessary in AppS so that it can determine whether it should ask for QoS resources? [Tina: The AppS belongs to the service layer and in theory it is unaware of the network technology topology and the network technology. The AppS only sends out an authorization request and expects to get a response. It doesn't need to know how the authorization is done, e.g. in Pull mode or Push mode.] --Boundary_(ID_d0yeUgQa47YhjfHrL88ZQg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Hi Tolga,
Good = question:-)
Comments in line = beginning with=20 [Tina: ...]
 
Cheers,
Tina
----- Original Message -----
From:=20 Asveren,=20 Tolga
To: Tina TSOU ; Sun,=20 Dong (Dong)
Sent: Thursday, July 24, 2008 = 2:22=20 AM
Subject: RE: [Fwd: [Dime] = Comments for=20 draft-ietf-dime-diameter-qos-06]

Hi Tina,

One question=20 below.

Thanks,
Tolga



[.. snip ..]
> =
> 2-=20 3. Framework
>    "After receiving=20 the
>    authorization request from the AppS or = the NE,=20 the AE decides the
>    appropriate mode = (i.e.  Push=20 or Pull).  The usage Push or Pull mode
>    = can be=20 determined by the authorizing entity either statically=20 or
>    dynamically."
> I think I am = missing=20 something here. Don't we have always push mode if
> the = authorization=20 request is received from AppS? Or are we talking
about
> a = hybrid=20 model where first AppS contacts the Authorizing Entity,
> = receives a=20 token, hands it over to media layer, and this token is used
> in = turn by=20 NE for pull mode?
> [Sun, Dong (Dong)] I don't think we are = talking=20 about a hybrid model.
my
> understanding is that the push and = pull=20 models can be decided by AE on
per
> call session basis (i.e. = dynamically), or can be pre-configured for
one of
> them = (i.e.=20 statically). If this is correct, the texts may be = modified
as
>=20 follows for clarity:
>  "The push and pull models can be = decided by=20 the AE on per call
session
> basis (i.e. dynamically), or can = be=20 pre-configured for one of them
(i.e.
> statically). Without = any=20 pre-configuration, when receiving a new
> authorization request = from the=20 Apps or a local trigger, the AE starts
the
> Push model; when = receiving a new authorization request from the NE,
the AE
> = starts=20 the Pull model."
> [Sun, Dong (Dong)] Tina,  I thought the = initial=20 texts come from you.
could
> you verify my comment or give = some=20 further clafication. are you ok
with
> the modified = texts?
> I=20 will update the document accordingly if no objection.
> [Tina: = As is=20 specified in the document, "the diversity of = QoS
capabilities
> of=20 endpoints and QoS schemes of network technology leads to the
>=20 distinction
> on the interaction mode between QoS authorization = system=20 and
underlying
> NEs".
> Therefore, I think the hybrid = model=20 should be supported. After
receiving a
> new authorization = request=20 from the AppS, the AE can decide which mode
> should
> be = used=20 based on the information of the request, especially based = on
the
>=20 information which indicates QoS capability and the access = network
type.=20 So
> I
> don't see any problem with the original = text.
>=20 However, as is proposed by Hannes, the <QoS-Capability> AVP = could=20 be
added
> into the QoS-Request message. Besides, I think=20 the
<Access-Network-Type>
> AVP
> should also be = added to=20 indicate the network technology since the
network
> = technology is=20 another factor affecting the type of QoS Model = being
used.]
[TOLGA]I=20 just am trying to understand the use case:
I understand that = endpoints will=20 have different QoS reservation
capabilities.
i- I have a = device, which=20 can't reserve QoS for the media but can
indicate its desire to do = so in=20 signaling. AppS would determine that
push mode is = desired.

ii- I=20 have a device, which can't reserve QoS for the media and = can't
indicate its=20 desire to do so in signaling. AppS could determine
statically what = to=20 do.

iii- I have a device, which can reserve QoS for the media. = It uses=20 its
own capabilities whenever it needs.

I guess what I am = trying to=20 figure out is, why decision process does not
belong to AppS? =

For=20 <Access-Network-Type>, I can see that this type of information=20 could
be useful, e.g. a device attached via DOCSIS to IP network = v.s. a=20 device
attached via a 3GPP technology. OTOH, isn't this information = actually
necessary in AppS so that it can determine whether it = should ask=20 for QoS
resources?

[Tina: The=20 AppS belongs to the service layer and in theory it is unaware of the = network=20 technology topology and the network technology. The AppS only sends = out an=20 authorization request and expects to get a response. It doesn=92t need = to know=20 how the authorization is done, e.g. in Pull mode or Push=20 mode.]

--Boundary_(ID_d0yeUgQa47YhjfHrL88ZQg)-- --===============0000437150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0000437150==-- From dime-bounces@ietf.org Thu Jul 24 02:35:12 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1243A69FD; Thu, 24 Jul 2008 02:35:12 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563DE3A69FD for ; Thu, 24 Jul 2008 02:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.909, 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 mcQrSItrrsQm for ; Thu, 24 Jul 2008 02:35:10 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 435EB3A6943 for ; Thu, 24 Jul 2008 02:35:10 -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 <0K4I002V27ZSRG@szxga04-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:35:52 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4I00HML7ZS0V@szxga04-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:35:52 +0800 (CST) Received: from h36145c ([10.70.39.88]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4I00C677ZSOX@szxml05-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:35:52 +0800 (CST) Date: Thu, 24 Jul 2008 17:35:51 +0800 From: Fortune HUANG To: dime@ietf.org Message-id: <016601c8ed70$aa1d5bf0$1a3afea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjtcKkGEuswOsKcQaqTkyc0zBxi0w== Subject: [Dime] Comment about draft-moncaster-pcn-3-state-encoding-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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi all, The table in section 6 seems to show that if a packet contains the DSCP value DSCP1 or DSCP2 and Not-ECT(00) at the same time, it is a Not-PCN packet. +--------+--------------+-------------+-------------+---------+ | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | +--------+--------------+-------------+-------------+---------+ | DSCP 1 | Not-PCN | NM(Not-ECT) | NM(CE) | ThM | | DSCP 2 | Not-PCN | NM(ECT(0)) | NM(ECT(1)) | ETM | +--------+--------------+-------------+-------------+---------+ In this case, for each incoming packets, the interior node needs to identify whether it is a PCN packet or not by two factors: the DSCP, and the ECN bits. Because as is shown in the table, even if a packet contains the DSCP value DSCP1 or DSCP2, it can also be a Not-PCN packet. However, as is known to us all, one factor (i.e. the DSCP) is enough to identify a PCN packet. And it will improve the performance before putting a packet into the PCN queue by using only one factor to identify a PCN packet. IMO, Not-ECT(00) doesn't need to be used. I wonder if we could put the table in this way: +--------+--------------+-------------+-------------+---------+ | DSCP | Not-ECT (00) | ECT(0) (10) | ECT(1) (01) | CE (11) | +--------+--------------+-------------+-------------+---------+ | DSCP 1 | - | NM(Not-ECT) | NM(CE) | ThM | | DSCP 2 | - | NM(ECT(0)) | NM(ECT(1)) | ETM | | DSCP x | Not-PCN | Not-PCN | Not-PCN | Not-PCN | +--------+--------------+-------------+-------------+---------+ NOTE: DSCPx is a DSCP codepoint other than DSCP1 and DSCP2. Best regards, Fortune **************************************************************************** ************** =A0This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! =A0************************************************************************= *** ************** _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 02:39:43 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224963A69FC; Thu, 24 Jul 2008 02:39:43 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A103A69FC for ; Thu, 24 Jul 2008 02:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.941 X-Spam-Level: X-Spam-Status: No, score=-0.941 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 894-+fhcZu+j for ; Thu, 24 Jul 2008 02:39:40 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 10AFD3A693D for ; Thu, 24 Jul 2008 02:39:40 -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 <0K4I005S9871M6@szxga02-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:40:14 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4I00N658714L@szxga02-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:40:13 +0800 (CST) Received: from h36145c ([10.70.39.88]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4I00C0I871OX@szxml05-in.huawei.com> for dime@ietf.org; Thu, 24 Jul 2008 17:40:13 +0800 (CST) Date: Thu, 24 Jul 2008 17:40:13 +0800 From: Fortune HUANG To: dime@ietf.org Message-id: <016701c8ed71$45a333b0$1a3afea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjtcKkGEuswOsKcQaqTkyc0zBxi0wAAFv8w Subject: [Dime] Sorry, it should have gone to PCN, not DIME.// Comment about draft-moncaster-pcn-3-state-encoding-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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0K5Y+R5Lu25Lq6OiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBGb3J0dW5lIEhVQU5HCuWPkemA geaXtumXtDogMjAwOOW5tDfmnIgyNOaXpSAxNzozNgrmlLbku7bkuro6IGRpbWVAaWV0Zi5vcmcK 5Li76aKYOiBbRGltZV0gQ29tbWVudCBhYm91dCBkcmFmdC1tb25jYXN0ZXItcGNuLTMtc3RhdGUt ZW5jb2RpbmctMDAKCkhpIGFsbCwKClRoZSB0YWJsZSBpbiBzZWN0aW9uIDYgc2VlbXMgdG8gc2hv dyB0aGF0IGlmIGEgcGFja2V0IGNvbnRhaW5zIHRoZSBEU0NQCnZhbHVlIERTQ1AxIG9yIERTQ1Ay IGFuZCBOb3QtRUNUKDAwKSBhdCB0aGUgc2FtZSB0aW1lLCBpdCBpcyBhIE5vdC1QQ04KcGFja2V0 LgogICAgICArLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tLSsKICAgICAgfCAgRFNDUCAgfCBOb3QtRUNUICgwMCkgfCBFQ1QoMCkgKDEw KSB8IEVDVCgxKSAoMDEpIHwgQ0UgKDExKSB8CiAgICAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tKwogICAgICB8IERTQ1AgMSB8 ICAgIE5vdC1QQ04gICB8IE5NKE5vdC1FQ1QpIHwgICAgTk0oQ0UpICAgfCAgIFRoTSAgIHwKICAg ICAgfCBEU0NQIDIgfCAgICBOb3QtUENOICAgfCAgTk0oRUNUKDApKSB8ICBOTShFQ1QoMSkpIHwg ICBFVE0gICB8CiAgICAgICstLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tKwpJbiB0aGlzIGNhc2UsIGZvciBlYWNoIGluY29taW5nIHBh Y2tldHMsIHRoZSBpbnRlcmlvciBub2RlIG5lZWRzIHRvIGlkZW50aWZ5CndoZXRoZXIgaXQgaXMg YSBQQ04gcGFja2V0IG9yIG5vdCBieSB0d28gZmFjdG9yczogdGhlIERTQ1AsIGFuZCB0aGUgRUNO CmJpdHMuIEJlY2F1c2UgYXMgaXMgc2hvd24gaW4gdGhlIHRhYmxlLCBldmVuIGlmIGEgcGFja2V0 IGNvbnRhaW5zIHRoZSBEU0NQCnZhbHVlIERTQ1AxIG9yIERTQ1AyLCBpdCBjYW4gYWxzbyBiZSBh IE5vdC1QQ04gcGFja2V0LgpIb3dldmVyLCBhcyBpcyBrbm93biB0byB1cyBhbGwsIG9uZSBmYWN0 b3IgKGkuZS4gdGhlIERTQ1ApIGlzIGVub3VnaCB0bwppZGVudGlmeSBhIFBDTiBwYWNrZXQuIEFu ZCBpdCB3aWxsIGltcHJvdmUgdGhlIHBlcmZvcm1hbmNlIGJlZm9yZSBwdXR0aW5nIGEKcGFja2V0 IGludG8gdGhlIFBDTiBxdWV1ZSBieSB1c2luZyBvbmx5IG9uZSBmYWN0b3IgdG8gaWRlbnRpZnkg YSBQQ04gcGFja2V0LgpJTU8sIE5vdC1FQ1QoMDApIGRvZXNuJ3QgbmVlZCB0byBiZSB1c2VkLiBJ IHdvbmRlciBpZiB3ZSBjb3VsZCBwdXQgdGhlIHRhYmxlCmluIHRoaXMgd2F5OgorLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsKfCAg RFNDUCAgfCBOb3QtRUNUICgwMCkgfCBFQ1QoMCkgKDEwKSB8IEVDVCgxKSAoMDEpIHwgQ0UgKDEx KSB8CistLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tKwp8IERTQ1AgMSB8ICAgICAgLSAgICAgICB8IE5NKE5vdC1FQ1QpIHwgICAgTk0o Q0UpICAgfCAgIFRoTSAgIHwKfCBEU0NQIDIgfCAgICAgIC0gICAgICAgfCAgTk0oRUNUKDApKSB8 ICBOTShFQ1QoMSkpIHwgICBFVE0gICB8CnwgRFNDUCB4IHwgICAgTm90LVBDTiAgIHwgIE5vdC1Q Q04gICAgfCAgTm90LVBDTiAgICB8IE5vdC1QQ04gfAorLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLSsKTk9URTogRFNDUHggaXMgYSBE U0NQIGNvZGVwb2ludCBvdGhlciB0aGFuIERTQ1AxIGFuZCBEU0NQMi4KCkJlc3QgcmVnYXJkcywK Rm9ydHVuZQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqCioqKioqKioqKioqKioqCiBUaGlzIGVtYWlsIGFu ZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbQpI VUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMKbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGluIGFueSB3YXkKKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRv LCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwKb3IgZGlzc2VtaW5h dGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgaXMK cHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBieQpwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRl IGl0IQogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqCioqKioqKioqKioqKioqCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRGlNRSBtYWlsaW5nIGxpc3QKRGlNRUBp ZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUKCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkRpTUUgbWFpbGluZyBs aXN0CkRpTUVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lCg== From dime-bounces@ietf.org Thu Jul 24 05:02:11 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD05C3A694F; Thu, 24 Jul 2008 05:02:11 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECC93A69CC for ; Thu, 24 Jul 2008 05:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 RUHdYtqSYbhY for ; Thu, 24 Jul 2008 05:02:06 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id 5A7583A683C for ; Thu, 24 Jul 2008 05:01:53 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KLzWl-0001Oo-OD; Thu, 24 Jul 2008 14:02:36 +0200 Message-ID: <48886F5C.7060202@cs.uni-goettingen.de> Date: Thu, 24 Jul 2008 14:02:36 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Hannes Tschofenig References: <487CECC3.2020509@gmx.net> In-Reply-To: <487CECC3.2020509@gmx.net> X-Virus-Scanned: (clean) by exiscan+sophie Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-neumann-dime-webauth X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello Hannes, thank you for asking about the WebAuth status. We are still working on Diameter WebAuth. In fact, we are close to finishing an implementation including a lightweight Diameter WebAuth server and an Apache authentication module that acts as Diameter WebAuth client. I will update the draft shortly with a new version that incorporates the changes we made while working in the implementation. We will also attend the IETF meeting in Dublin. I hope for some discussion and feedback about this work there. Best regards Niklas Hannes Tschofenig wrote: > Document: http://tools.ietf.org/id/draft-neumann-dime-webauth-00.txt > > * Who is able to be editor of the document? > > * Who is interested to help the editor with the work on the draft by > co-authoring it? > > * Who is able to provide reviews? > > * Who is unable to actively help with a specific document but supports > the work? > > * Are there concerns regarding this document? > > * Is there a dependency with another IETF working group or with another > SDO? > > * How long will it take to finish this document? > (A rough guess based on the current status of the document. By > "finished" I mean "ready for WGLC".) > > -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-14419 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 05:06:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACCC3A6919; Thu, 24 Jul 2008 05:06:16 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A763A6806 for ; Thu, 24 Jul 2008 05:06:15 -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 xw-oUgWMf5Nh for ; Thu, 24 Jul 2008 05:06:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 99B193A65A5 for ; Thu, 24 Jul 2008 05:06:14 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2008 12:06:58 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp062) with SMTP; 24 Jul 2008 14:06:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/dxRUiKZXdATWvXpFr6jDhDmCd8oJXin0xCBp4Rw rmLxkMM8q7mEDH Message-ID: <48887060.4060006@gmx.net> Date: Thu, 24 Jul 2008 15:06:56 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Niklas Neumann References: <487CECC3.2020509@gmx.net> <48886F5C.7060202@cs.uni-goettingen.de> In-Reply-To: <48886F5C.7060202@cs.uni-goettingen.de> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-neumann-dime-webauth X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thank you Niklas for the update. Good to hear that the implementation work is ongoing. Do you plan to make it available as open source? Ciao Hannes Niklas Neumann wrote: > Hello Hannes, > > thank you for asking about the WebAuth status. We are still working on > Diameter WebAuth. In fact, we are close to finishing an implementation > including a lightweight Diameter WebAuth server and an Apache > authentication module that acts as Diameter WebAuth client. > > I will update the draft shortly with a new version that incorporates > the changes we made while working in the implementation. We will also > attend the IETF meeting in Dublin. I hope for some discussion and > feedback about this work there. > > > Best regards > Niklas > > > Hannes Tschofenig wrote: >> Document: http://tools.ietf.org/id/draft-neumann-dime-webauth-00.txt >> >> * Who is able to be editor of the document? >> >> * Who is interested to help the editor with the work on the draft by >> co-authoring it? >> >> * Who is able to provide reviews? >> >> * Who is unable to actively help with a specific document but >> supports the work? >> >> * Are there concerns regarding this document? >> >> * Is there a dependency with another IETF working group or with >> another SDO? >> >> * How long will it take to finish this document? >> (A rough guess based on the current status of the document. By >> "finished" I mean "ready for WGLC".) >> >> > > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 05:11:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF683A692C; Thu, 24 Jul 2008 05:11:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805823A692C for ; Thu, 24 Jul 2008 05:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 lItzuDzzkfjG for ; Thu, 24 Jul 2008 05:11:50 -0700 (PDT) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id 856E13A69E7 for ; Thu, 24 Jul 2008 05:11:04 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KLzfY-0000Qe-5B; Thu, 24 Jul 2008 14:11:40 +0200 Message-ID: <4888717C.9020007@cs.uni-goettingen.de> Date: Thu, 24 Jul 2008 14:11:40 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Hannes Tschofenig References: <487CECC3.2020509@gmx.net> <48886F5C.7060202@cs.uni-goettingen.de> <48887060.4060006@gmx.net> In-Reply-To: <48887060.4060006@gmx.net> X-Virus-Scanned: (clean) by exiscan+sophie Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-neumann-dime-webauth X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hannes Tschofenig wrote: > Thank you Niklas for the update. Good to hear that the implementation > work is ongoing. Do you plan to make it available as open source? Yes, both the Apache module and the Diameter WebAuth server will be released under the LGPL. Maybe I can bring a demo to the IETF meeting so people can take a look if they are interested. BR Niklas -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-14419 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 05:15:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6850C3A692C; Thu, 24 Jul 2008 05:15:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9733A67FA for ; Thu, 24 Jul 2008 05:15:09 -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 J+0hvt41GAMK for ; Thu, 24 Jul 2008 05:15:08 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CFC113A692C for ; Thu, 24 Jul 2008 05:15:07 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2008 12:15:51 -0000 Received: from unknown (EHLO [10.183.180.149]) [192.100.124.156] by mail.gmx.net (mp050) with SMTP; 24 Jul 2008 14:15:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+n8zdAAnqnh/8yZtgzqyxVyY+w/p15bvJgv9x6c+ 0uPHS5G0HrWBNL Message-ID: <48887274.6070507@gmx.net> Date: Thu, 24 Jul 2008 15:15:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Niklas Neumann References: <487CECC3.2020509@gmx.net> <48886F5C.7060202@cs.uni-goettingen.de> <48887060.4060006@gmx.net> <4888717C.9020007@cs.uni-goettingen.de> In-Reply-To: <4888717C.9020007@cs.uni-goettingen.de> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.73 Cc: dime@ietf.org Subject: Re: [Dime] Rechartering: draft-neumann-dime-webauth X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Niklas Neumann wrote: > Hannes Tschofenig wrote: >> Thank you Niklas for the update. Good to hear that the implementation >> work is ongoing. Do you plan to make it available as open source? > > Yes, both the Apache module and the Diameter WebAuth server will be > released under the LGPL. Maybe I can bring a demo to the IETF meeting > so people can take a look if they are interested. > We will not have time during the meeting for a demo but showing it after the break would certainly be interesting. Ciao Hannes > > BR > Niklas > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 08:12:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC42828C14A; Thu, 24 Jul 2008 08:12:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C44228C14A for ; Thu, 24 Jul 2008 08:12:45 -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 H7bSZK5vdjoF for ; Thu, 24 Jul 2008 08:12:44 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 9313728C141 for ; Thu, 24 Jul 2008 08:12:43 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6OFD8fT011752; Thu, 24 Jul 2008 11:13:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:13:08 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2g References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org (Continuing in separate threads for each issue for easier tracking.) Hi Dong, One comment below. Thanks, Tolga [.. snip ..] > > > > 1- Use of the same Application-Id for push/pull models It sounds > > reasonable to me to think nodes which support only a single mode. How > > can we guarantee that messages land to the right server considering > > that the same Application-Id is used for both of them? > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > models is > > different, for example, when a new request from the PEP is recevied, > the > > Server will start the pull model. In fact, the push and pull are > sharing > > the same state machine per se. the main difference is just how to > > establish a Diameter session. The enhancement is to allow the Diameter > > > Server to establish a session with a local trigger instead of the > trigger > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the > same > > application-Id causes any problem, especially for the pull model since > > > push/pull is able use the same server (certainly they can also have > > separate server according to the configuration). > [TOLGA]My concern here is about message routing rather than the state > machine processing in the server. Let's say a server is capable only to > accommodate pull model (it doesn't know what NE to contact if push model > is required). How can the network intermediaries, e.g. relay agent, > forward the initial request in the session to the right server for push > model? How can they be sure that the server supports push model? > [Dong] The relay agent should route the message according to the > destination address/realm that is filled up by the requestor. I don't > know how the application id will affect this kind of routing. [TOLGA]The initial message of a session may have only Destination-Realm. In such a case Application-Id is used by intermediaries to select the right server. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 08:25:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AC13A6A6B; Thu, 24 Jul 2008 08:25:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69A83A6A6B for ; Thu, 24 Jul 2008 08:25: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=[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 ThJ7y50GaaQl for ; Thu, 24 Jul 2008 08:25:16 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 869DD3A6A62 for ; Thu, 24 Jul 2008 08:25:16 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6OFPmOc022579; Thu, 24 Jul 2008 11:25:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:25:48 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E70120603A@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAh/pZQ References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, One question below. Thanks, Tolga [.. snip ..] > > 3- 3. Framework > > "For Push mode, the authorizing entity needs to identify the > > appropriate NE(s) to which QoS authorization information needs to > be > > pushed. It might determine this based on information received from > > the AppS, such as the IP addresses of media flows." > > It could be a good idea to give a bit more information about this: > > - This is hard to do as Authorizing Entity would need to have > > information about routing decisions of NEs for a particular flow > > - QoS in the core network is usually not scarce > > - QoS on the access side is scarce > > - It is not difficult for the Authorizing Entity to determine NEs > > facing the access side as usually this information is stored somewhere > > > when the endpoint attaches to the network and does not change per IP > > flow. > > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement > are > > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the > discovery > > of these NEs is not necessarily based on the routing info, instead, it > can > > be preconfigured. > > In addition, i think this draft mainly focuses on the mechanism and > > protocol. It can be used for both access and core networks. the QoS > status > > you described looks like well known, not sure how much it may add. > [TOLGA]Even for some of the nodes you mentioned, I would expect routing > to play a role here. For example if there are more than one gateway, AE > needs to know which one it should contact for that particular stream. > [Dong] in practice a rendezvous AE or hierarchical AEs will derive the > address of the right gateway according to preconfigured info in a > database or through DNS query. The point is that the NE/PEP is an > anchoring point for certain streams per provisioning, not random routing > for selecting those PEPs (except load balancing). In other words, not > every NE/router is eligible to serve as the PEP in reality. [TOLGA] The point I am missing is how does the AE now the NE(s)/PEP(s) to be used for a particular stream? The list of such entities on the path for a stream is obviously determined according to some algorithm/configuration but I am not sure whether AE has the complete information. Let's take an example: +-------+ | | +---| AE |-----------+ | +-------+ | | | | | | | | | | | | | | | | | | +------+ | | .....| | +------+ | . | NE2 | | |........... +------+ | NE1 |........... +------+ | . | . | . +------+ +----.----| | .....| NE3 | +------+ How does the AE know whether NE2 or NE3 will be chosen by NE1 for a particular flow? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 08:43:53 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42063A6957; Thu, 24 Jul 2008 08:43:53 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554593A694F for ; Thu, 24 Jul 2008 08:43: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 h1wU2JHepGGt for ; Thu, 24 Jul 2008 08:43:51 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 3F4523A690D for ; Thu, 24 Jul 2008 08:43:51 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6OFiMqi008910; Thu, 24 Jul 2008 11:44:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:44:20 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbw References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, Comments/questions below. Thanks, Tolga [.. snip ..] > > 6- 4.2 Session Establishment > > "When a QoS-Authz-Request > > (QAR, see Section 5.1) message with a new session ID is received, > the > > AE operates in the Pull mode; when other triggers are received, the > > AE operates in the Push mode." > > Would this shut down the door for certain failure recovery scenarios? > > For example AE goes down and a backup AE takes over. IMO it is a nice > > feature if the backup can continue existing sessions without a need to > > > synchronizing state with the failed active AE. This can be achieved by > > > carrying enough information about session state in the message itself > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > impossible. For certain scenarios backup AE would determine the > required > > mode wrong. I suggest the decision for push/pull is not based on > message > > name but on the message content. > > [Sun, Dong (Dong)] I think this is the most straightforward and > > consistent way in terms of state machine to decide the pull/push. and > it > > will work well for the hot standby case, but indeed, it may have some > > issue with cold standby. In general, the failure handling is not > addressed > > in the draft very much. The question is, do we need to add the failure > > > handling in detail or not for backup server case? > [TOLGA]I agree that details of failure handling may not belong here. > OTOH that the QoS application is failover friendly is a parameter to > consider IMHO. By carrying enough information in each message so that > cold standby elements can be used to take over existing sessions, one > trades small amount of bandwidth and limited CPU cycles for complexity > in software and probably even more CPU cycles. IMHO this is a bargain. I > found this very handy in DCCA. Wouldn't just defining an AVP indicating > the type of service requested (push v.s. pull) solve this problem? > Actually this issue is also tied to Application-Id problem. If different > Application-Ids are used, that implicitly will define the mode > required/used. > [Dong] I don't think it makes sense to mandate this kind of parameter > for failover since it is more useful for one type of failure handling > approach rather than the other. But it is ok to have an optional > parameter but it does add significant overhead in the message. In > addition, not sure why the application id is tied up with this issue, > even in general the routing issue as I explained above. > I think the failure handling approach should be consistent for all > Diameter applications rather than defining specific one for QoS > application. [TOLGA] 1) One can argue the other way around as well: Why exclude some piece of information which is useful for certain type of failover mechanism. IMHO the added overhead is negligible and I am pretty sure much less than the overhead of a hot standby system (let alone the extra complexity it requires) 2) If push/pull modes use different Application-Ids that could be used easily to decide for which mode the message is received. OTOH I agree that this itself wouldn't help for failover friendliness. 3) There are certainly a few things which can be done in base protocol to help failover handling. OTOH base protocol is application state machine agnostic. I don't see how it can help there. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 08:57:14 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF26E3A6932; Thu, 24 Jul 2008 08:57:14 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDDD3A6932 for ; Thu, 24 Jul 2008 08:57:13 -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 jKlpLyccUsjf for ; Thu, 24 Jul 2008 08:57:12 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 9A1BF3A689A for ; Thu, 24 Jul 2008 08:57:12 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6OFvbhH022042; Thu, 24 Jul 2008 11:57:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 11:57:35 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E701206064@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / triggering all-path reservation with push mode Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAjMCTw References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / triggering all-path reservation with push mode X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, One question below. Thanks, Tolga > > 7- There were some proposals about a mode, where NE is notified from > AE > > to reserve resources all the way till the end point. Is this > considered > > out of scope? > > [Sun, Dong (Dong)] it can be supporoted implicited by the applicaion, > but > > it is not a different mode, just an implementation of resource > reservation > > within the bearer layer. it is mentioned in the section 9 as example. > [TOLGA]I think I couldn't explain well what I meant. The model I am > talking about is that AE tells NE to reserve resources not only in > itself but also through the whole bearer path, e.g. RSVP from edge > router to edge router. Is it possible to do this with this version of > QoS application draft? > [Dong] sure. Absolutely. Current QoS application draft does support it > if the NE is able to use the RSVP. However, how to support the RSVP in > the NE (procedure, mechanism) is out of scope in this draft. [TOLGA] How to indicate to NE whether it needs to reserve resources only for itself or also reserve resources through the path (for example with RSVP)? Is there an AVP for this? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 09:14:32 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5953A6975; Thu, 24 Jul 2008 09:14:32 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0D93A6934 for ; Thu, 24 Jul 2008 09:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYKyycLCfDRR for ; Thu, 24 Jul 2008 09:14:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1DB263A67A5 for ; Thu, 24 Jul 2008 09:14:29 -0700 (PDT) Received: (qmail invoked by alias); 24 Jul 2008 16:15:14 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp051) with SMTP; 24 Jul 2008 18:15:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xpltRGfkxlvfCoBclDPDBkKGgbRmN44F9of1wTA GfTbrcqUWEhLKB Message-ID: <4888AA8C.6010803@gmx.net> Date: Thu, 24 Jul 2008 19:15:08 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.8100000000000001 Subject: [Dime] Our DIME Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I had a chat with Dave and we have thought about rechartering discussion at the face-to-face meeting. We came up with the following idea. Dave and I will produce a single slide for each draft under discussion. This should give the group a quick overview. Then, we are going to discuss what we should be doing next in the group. Draft authors are welcome to clarify aspects of their draft and to answer questions during that discussion. Is this a reasonable idea? Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 10:28:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABB528C0F9; Thu, 24 Jul 2008 10:28:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065F828C0F9 for ; Thu, 24 Jul 2008 10:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F6aEvtO-LGo for ; Thu, 24 Jul 2008 10:28:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C684528C0F6 for ; Thu, 24 Jul 2008 10:28:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6OHSvU28545; Thu, 24 Jul 2008 17:28:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 12:28:39 -0500 Message-ID: In-Reply-To: <4888AA8C.6010803@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Our DIME Meeting Thread-Index: AcjtqIoDybo7HVm7RQeUg6xU5oni5wACf4PA References: <4888AA8C.6010803@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , Subject: Re: [Dime] Our DIME Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sure is. Regards, Ahmad > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Thursday, July 24, 2008 11:15 AM > To: dime@ietf.org > Subject: [Dime] Our DIME Meeting > > I had a chat with Dave and we have thought about rechartering > discussion at the face-to-face meeting. > > We came up with the following idea. Dave and I will produce a > single slide for each draft under discussion. This should > give the group a quick overview. Then, we are going to > discuss what we should be doing next in the group. Draft > authors are welcome to clarify aspects of their draft and to > answer questions during that discussion. > > Is this a reasonable idea? > > Ciao > Hannes & Dave > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 11:18:38 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE48B3A6A19; Thu, 24 Jul 2008 11:18:38 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761703A6A19 for ; Thu, 24 Jul 2008 11:18:37 -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 mtTjmD9rMYbD for ; Thu, 24 Jul 2008 11:18:36 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 887B03A69D3 for ; Thu, 24 Jul 2008 11:18:35 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6OIIY5a005050; Thu, 24 Jul 2008 13:18:57 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:18:34 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:18:33 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 24 Jul 2008 18:18:34.0969 (UTC) FILETIME=[AF879490:01C8EDB9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, Comments inline. Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Thursday, July 24, 2008 11:13 AM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id (Continuing in separate threads for each issue for easier tracking.) Hi Dong, One comment below. Thanks, Tolga [.. snip ..] > > > > 1- Use of the same Application-Id for push/pull models It sounds > > reasonable to me to think nodes which support only a single mode. How > > can we guarantee that messages land to the right server considering > > that the same Application-Id is used for both of them? > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > models is > > different, for example, when a new request from the PEP is recevied, > the > > Server will start the pull model. In fact, the push and pull are > sharing > > the same state machine per se. the main difference is just how to > > establish a Diameter session. The enhancement is to allow the Diameter > > > Server to establish a session with a local trigger instead of the > trigger > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the > same > > application-Id causes any problem, especially for the pull model since > > > push/pull is able use the same server (certainly they can also have > > separate server according to the configuration). > [TOLGA]My concern here is about message routing rather than the state > machine processing in the server. Let's say a server is capable only to > accommodate pull model (it doesn't know what NE to contact if push model > is required). How can the network intermediaries, e.g. relay agent, > forward the initial request in the session to the right server for push > model? How can they be sure that the server supports push model? > [Dong] The relay agent should route the message according to the > destination address/realm that is filled up by the requestor. I don't > know how the application id will affect this kind of routing. [TOLGA]The initial message of a session may have only Destination-Realm. In such a case Application-Id is used by intermediaries to select the right server. [Dong] In the context of QoS application, for the pull mode, the NE typically is configured by a default policy server or redirect server. I don't think the scenario you are concerned is a common case in reality although theoretically the base Diameter protocol may allow this kind of behavior, but it is not the case for QoS application, IMHO. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 11:30:21 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EEF3A6A19; Thu, 24 Jul 2008 11:30:21 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD88D3A686A for ; Thu, 24 Jul 2008 11:30:19 -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 Dy3fUNR3dWDW for ; Thu, 24 Jul 2008 11:30:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A150C3A6809 for ; Thu, 24 Jul 2008 11:30:17 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6OIUpv1017878; Thu, 24 Jul 2008 13:30:51 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:30:50 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:30:49 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B91E36@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E70120603A@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAh/pZQAAZ6BtA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120603A@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 24 Jul 2008 18:30:50.0860 (UTC) FILETIME=[6627A2C0:01C8EDBB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Thursday, July 24, 2008 11:26 AM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Hi Dong, One question below. Thanks, Tolga [.. snip ..] > > 3- 3. Framework > > "For Push mode, the authorizing entity needs to identify the > > appropriate NE(s) to which QoS authorization information needs to > be > > pushed. It might determine this based on information received from > > the AppS, such as the IP addresses of media flows." > > It could be a good idea to give a bit more information about this: > > - This is hard to do as Authorizing Entity would need to have > > information about routing decisions of NEs for a particular flow > > - QoS in the core network is usually not scarce > > - QoS on the access side is scarce > > - It is not difficult for the Authorizing Entity to determine NEs > > facing the access side as usually this information is stored somewhere > > > when the endpoint attaches to the network and does not change per IP > > flow. > > [Sun, Dong (Dong)] my understanding is the NEs for Policy enforcement > are > > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the > discovery > > of these NEs is not necessarily based on the routing info, instead, it > can > > be preconfigured. > > In addition, i think this draft mainly focuses on the mechanism and > > protocol. It can be used for both access and core networks. the QoS > status > > you described looks like well known, not sure how much it may add. > [TOLGA]Even for some of the nodes you mentioned, I would expect routing > to play a role here. For example if there are more than one gateway, AE > needs to know which one it should contact for that particular stream. > [Dong] in practice a rendezvous AE or hierarchical AEs will derive the > address of the right gateway according to preconfigured info in a > database or through DNS query. The point is that the NE/PEP is an > anchoring point for certain streams per provisioning, not random routing > for selecting those PEPs (except load balancing). In other words, not > every NE/router is eligible to serve as the PEP in reality. [TOLGA] The point I am missing is how does the AE now the NE(s)/PEP(s) to be used for a particular stream? The list of such entities on the path for a stream is obviously determined according to some algorithm/configuration but I am not sure whether AE has the complete information. Let's take an example: +-------+ | | +---| AE |-----------+ | +-------+ | | | | | | | | | | | | | | | | | | +------+ | | .....| | +------+ | . | NE2 | | |........... +------+ | NE1 |........... +------+ | . | . | . +------+ +----.----| | .....| NE3 | +------+ How does the AE know whether NE2 or NE3 will be chosen by NE1 for a particular flow? [Dong] I assume you knew well how to get it in the access network. You're mainly concerned about the core network case, right? Let's look at this example: in the core network, each edge router is responsible for certain access network domains (or in other words, the BRAS/edge router is configured to route the traffic to a particular edge router in the core, for the simplicity, assuming NE1 is for 10.1.x.x, NE2 for 10.2.x.x, NE3 for 10.3.x.x, when the AE receives a request from AF with the global routable IP address of the end user, it can derive the targeting NE straightforward. Certainly some additional info e.g IP-tuple, subscriber id and traffic classifier might be useful to provide further granularity to allocate the right NE as needed (dependent on the network configuration and Traffic engineering approach). _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 11:48:26 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B68D3A6A1A; Thu, 24 Jul 2008 11:48:26 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F20B3A686A for ; Thu, 24 Jul 2008 11:48:24 -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 cmTEuZOYu0Wf for ; Thu, 24 Jul 2008 11:48:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 5CEAD3A67F5 for ; Thu, 24 Jul 2008 11:48:22 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m6OImrYr029839; Thu, 24 Jul 2008 13:48:53 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Jul 2008 13:48:53 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 13:48:51 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 24 Jul 2008 18:48:53.0660 (UTC) FILETIME=[EB8DCDC0:01C8EDBD] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, Since you agreed that the general failure handling for Diameter is out of scope in the QoS application. In principle, I don't see the necessity to include extra overhead as the mandatory parameters. Frankly, the failure handling of the Diameter Server is a quite comprehensive issue. Sofar, the QoS application should provide some basic failure handling e.g. clean up the expired sessions, but I am not sure if it is appropriate to discuss what you address in the QoS application exclusively. I assume it should be part of base protocol or separate document (I am not sure if it already has) since they are supposed to generic to all applications. See additional comments inline. Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Thursday, July 24, 2008 11:44 AM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Hi Dong, Comments/questions below. Thanks, Tolga [.. snip ..] > > 6- 4.2 Session Establishment > > "When a QoS-Authz-Request > > (QAR, see Section 5.1) message with a new session ID is received, > the > > AE operates in the Pull mode; when other triggers are received, the > > AE operates in the Push mode." > > Would this shut down the door for certain failure recovery scenarios? > > For example AE goes down and a backup AE takes over. IMO it is a nice > > feature if the backup can continue existing sessions without a need to > > > synchronizing state with the failed active AE. This can be achieved by > > > carrying enough information about session state in the message itself > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > impossible. For certain scenarios backup AE would determine the > required > > mode wrong. I suggest the decision for push/pull is not based on > message > > name but on the message content. > > [Sun, Dong (Dong)] I think this is the most straightforward and > > consistent way in terms of state machine to decide the pull/push. and > it > > will work well for the hot standby case, but indeed, it may have some > > issue with cold standby. In general, the failure handling is not > addressed > > in the draft very much. The question is, do we need to add the failure > > > handling in detail or not for backup server case? > [TOLGA]I agree that details of failure handling may not belong here. > OTOH that the QoS application is failover friendly is a parameter to > consider IMHO. By carrying enough information in each message so that > cold standby elements can be used to take over existing sessions, one > trades small amount of bandwidth and limited CPU cycles for complexity > in software and probably even more CPU cycles. IMHO this is a bargain. I > found this very handy in DCCA. Wouldn't just defining an AVP indicating > the type of service requested (push v.s. pull) solve this problem? > Actually this issue is also tied to Application-Id problem. If different > Application-Ids are used, that implicitly will define the mode > required/used. > [Dong] I don't think it makes sense to mandate this kind of parameter > for failover since it is more useful for one type of failure handling > approach rather than the other. But it is ok to have an optional > parameter but it does add significant overhead in the message. In > addition, not sure why the application id is tied up with this issue, > even in general the routing issue as I explained above. > I think the failure handling approach should be consistent for all > Diameter applications rather than defining specific one for QoS > application. [TOLGA] 1) One can argue the other way around as well: Why exclude some piece of information which is useful for certain type of failover mechanism. IMHO the added overhead is negligible and I am pretty sure much less than the overhead of a hot standby system (let alone the extra complexity it requires) [Dong] as indicated, this is not my intention to discuss all possible varieties for failure handover to the standby Diameter server. I assume a generic mechanism should be applied to QoS application. 2) If push/pull modes use different Application-Ids that could be used easily to decide for which mode the message is received. OTOH I agree that this itself wouldn't help for failover friendliness. [Dong] Using different application id for push/pull makes the state mechanism less efficient and does not add too much value for the routing since the scenarios you are concerned are not common (i.e. the message cannot provide a destination address) in reality for QoS application, IMHO. (sorry for saying this). 3) There are certainly a few things which can be done in base protocol to help failover handling. OTOH base protocol is application state machine agnostic. I don't see how it can help there. [Dong] the failover handling you described does not look like a specific case only for QoS application. In fact the failure of the server does not affect too much for ongoing bearer sessions since they will remain anyway. And I am not sure if the NE is the best option to store all session info due to the cost effectiveness and processing capacity issues. Maybe the synchronization between two servers is more efficient, to some extent. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Jul 24 12:10:03 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775A93A6780; Thu, 24 Jul 2008 12:10:03 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914883A67A8 for ; Thu, 24 Jul 2008 12:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8XgSnv1+gTz for ; Thu, 24 Jul 2008 12:10:00 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 65CCA3A6780 for ; Thu, 24 Jul 2008 12:09:57 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6OJ9ZM3004771; Thu, 24 Jul 2008 15:09:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Jul 2008 15:09:34 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012060D3@sonusmail04.sonusnet.com> In-Reply-To: <019301c8ed6e$cb29d140$7427460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjtbxEBhRyYTHgXQEuBr3BoX6byhgAURbqA References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E701205F12@sonusmail04.sonusnet.com> <019301c8ed6e$cb29d140$7427460a@china.huawei.com> From: "Asveren, Tolga" To: "Tina TSOU" , "Sun, Dong (Dong)" Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tina, One more question below. Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Thursday, July 24, 2008 11:58 AM > To: Asveren, Tolga > Subject: FW: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > > > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Thursday, July 24, 2008 5:22 AM > To: Sun, Dong (Dong); Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Glen Zorn > Subject: Re: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > Good question:-) > Comments in line beginning with [Tina: ...] > > Cheers, > Tina > ----- Original Message ----- > From: Asveren, Tolga > To: Tina TSOU ; Sun, Dong (Dong) > Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes > (NSN - FI/Espoo) ; dime@ietf.org > Sent: Thursday, July 24, 2008 2:22 AM > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tina, > > One question below. > > Thanks, > Tolga > > > > [.. snip ..] > > > > 2- 3. Framework > > "After receiving the > > authorization request from the AppS or the NE, the AE decides the > > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > > can be determined by the authorizing entity either statically or > > dynamically." > > I think I am missing something here. Don't we have always push mode if > > the authorization request is received from AppS? Or are we talking > about > > a hybrid model where first AppS contacts the Authorizing Entity, > > receives a token, hands it over to media layer, and this token is used > > in turn by NE for pull mode? > > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. > my > > understanding is that the push and pull models can be decided by AE on > per > > call session basis (i.e. dynamically), or can be pre-configured for > one of > > them (i.e. statically). If this is correct, the texts may be modified > as > > follows for clarity: > > "The push and pull models can be decided by the AE on per call > session > > basis (i.e. dynamically), or can be pre-configured for one of them > (i.e. > > statically). Without any pre-configuration, when receiving a new > > authorization request from the Apps or a local trigger, the AE starts > the > > Push model; when receiving a new authorization request from the NE, > the AE > > starts the Pull model." > > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. > could > > you verify my comment or give some further clafication. are you ok > with > > the modified texts? > > I will update the document accordingly if no objection. > > [Tina: As is specified in the document, "the diversity of QoS > capabilities > > of endpoints and QoS schemes of network technology leads to the > > distinction > > on the interaction mode between QoS authorization system and > underlying > > NEs". > > Therefore, I think the hybrid model should be supported. After > receiving a > > new authorization request from the AppS, the AE can decide which mode > > should > > be used based on the information of the request, especially based on > the > > information which indicates QoS capability and the access network > type. So > > I > > don't see any problem with the original text. > > However, as is proposed by Hannes, the AVP could be > added > > into the QoS-Request message. Besides, I think the > > > AVP > > should also be added to indicate the network technology since the > network > > technology is another factor affecting the type of QoS Model being > used.] > [TOLGA]I just am trying to understand the use case: > I understand that endpoints will have different QoS reservation > capabilities. > i- I have a device, which can't reserve QoS for the media but can > indicate its desire to do so in signaling. AppS would determine that > push mode is desired. > > ii- I have a device, which can't reserve QoS for the media and can't > indicate its desire to do so in signaling. AppS could determine > statically what to do. > > iii- I have a device, which can reserve QoS for the media. It uses its > own capabilities whenever it needs. > > I guess what I am trying to figure out is, why decision process does not > belong to AppS? > > For , I can see that this type of information could > be useful, e.g. a device attached via DOCSIS to IP network v.s. a device > attached via a 3GPP technology. OTOH, isn't this information actually > necessary in AppS so that it can determine whether it should ask for QoS > resources? > [Tina: The AppS belongs to the service layer and in theory it is unaware > of the network technology topology and the network technology. The AppS > only sends out an authorization request and expects to get a response. It > doesn't need to know how the authorization is done, e.g. in Pull mode or > Push mode.] [TOLGA]What you said sounds reasonable but with that model, i.e. AppS completely unaware of networking technology, would AppS need to ask authorization for each and every call? As an example let's consider IMS-mobile. Do we expect AppS to ask for authorization for each call even for IMS-mobile calls, where actually none of them would have required push mode of operation? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Jul 25 00:40:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023553A690E; Fri, 25 Jul 2008 00:40:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35AD3A690E for ; Fri, 25 Jul 2008 00:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw1XRSXYiJuY for ; Fri, 25 Jul 2008 00:40:49 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 89D113A68FA for ; Fri, 25 Jul 2008 00:40:48 -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 <0K4J006KMXBQCX@szxga02-in.huawei.com> for dime@ietf.org; Fri, 25 Jul 2008 15:40:39 +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 <0K4J00DI1XBQVW@szxga02-in.huawei.com> for dime@ietf.org; Fri, 25 Jul 2008 15:40:38 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4J0070XXBQ0P@szxml04-in.huawei.com> for dime@ietf.org; Fri, 25 Jul 2008 15:40:38 +0800 (CST) Date: Fri, 25 Jul 2008 15:40:38 +0800 From: Tina TSOU To: "Sun, Dong (Dong)" , "Asveren, Tolga" Message-id: <00b201c8ee29$bb4e9ba0$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E701205F12@sonusmail04.sonusnet.com> <019301c8ed6e$cb29d140$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E7012060D3@sonusmail04.sonusnet.com> Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424946209==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0424946209== Content-type: multipart/alternative; boundary="Boundary_(ID_H6uhy89QOs/6c29pqU8lBA)" This is a multi-part message in MIME format. --Boundary_(ID_H6uhy89QOs/6c29pqU8lBA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Dear Tolga, Comments in line demarked with [Tina: ...] B. R. Tina ----- Original Message ----- From: Asveren, Tolga To: Tina TSOU ; Sun, Dong (Dong) Cc: dime@ietf.org ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Glen Zorn Sent: Friday, July 25, 2008 3:09 AM Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Hi Tina, One more question below. Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Thursday, July 24, 2008 11:58 AM > To: Asveren, Tolga > Subject: FW: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > > > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Thursday, July 24, 2008 5:22 AM > To: Sun, Dong (Dong); Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Glen Zorn > Subject: Re: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tolga, > Good question:-) > Comments in line beginning with [Tina: ...] > > Cheers, > Tina > ----- Original Message ----- > From: Asveren, Tolga > To: Tina TSOU ; Sun, Dong (Dong) > Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes > (NSN - FI/Espoo) ; dime@ietf.org > Sent: Thursday, July 24, 2008 2:22 AM > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tina, > > One question below. > > Thanks, > Tolga > > > > [.. snip ..] > > > > 2- 3. Framework > > "After receiving the > > authorization request from the AppS or the NE, the AE decides the > > appropriate mode (i.e. Push or Pull). The usage Push or Pull mode > > can be determined by the authorizing entity either statically or > > dynamically." > > I think I am missing something here. Don't we have always push mode if > > the authorization request is received from AppS? Or are we talking > about > > a hybrid model where first AppS contacts the Authorizing Entity, > > receives a token, hands it over to media layer, and this token is used > > in turn by NE for pull mode? > > [Sun, Dong (Dong)] I don't think we are talking about a hybrid model. > my > > understanding is that the push and pull models can be decided by AE on > per > > call session basis (i.e. dynamically), or can be pre-configured for > one of > > them (i.e. statically). If this is correct, the texts may be modified > as > > follows for clarity: > > "The push and pull models can be decided by the AE on per call > session > > basis (i.e. dynamically), or can be pre-configured for one of them > (i.e. > > statically). Without any pre-configuration, when receiving a new > > authorization request from the Apps or a local trigger, the AE starts > the > > Push model; when receiving a new authorization request from the NE, > the AE > > starts the Pull model." > > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. > could > > you verify my comment or give some further clafication. are you ok > with > > the modified texts? > > I will update the document accordingly if no objection. > > [Tina: As is specified in the document, "the diversity of QoS > capabilities > > of endpoints and QoS schemes of network technology leads to the > > distinction > > on the interaction mode between QoS authorization system and > underlying > > NEs". > > Therefore, I think the hybrid model should be supported. After > receiving a > > new authorization request from the AppS, the AE can decide which mode > > should > > be used based on the information of the request, especially based on > the > > information which indicates QoS capability and the access network > type. So > > I > > don't see any problem with the original text. > > However, as is proposed by Hannes, the AVP could be > added > > into the QoS-Request message. Besides, I think the > > > AVP > > should also be added to indicate the network technology since the > network > > technology is another factor affecting the type of QoS Model being > used.] > [TOLGA]I just am trying to understand the use case: > I understand that endpoints will have different QoS reservation > capabilities. > i- I have a device, which can't reserve QoS for the media but can > indicate its desire to do so in signaling. AppS would determine that > push mode is desired. > > ii- I have a device, which can't reserve QoS for the media and can't > indicate its desire to do so in signaling. AppS could determine > statically what to do. > > iii- I have a device, which can reserve QoS for the media. It uses its > own capabilities whenever it needs. > > I guess what I am trying to figure out is, why decision process does not > belong to AppS? > > For , I can see that this type of information could > be useful, e.g. a device attached via DOCSIS to IP network v.s. a device > attached via a 3GPP technology. OTOH, isn't this information actually > necessary in AppS so that it can determine whether it should ask for QoS > resources? > [Tina: The AppS belongs to the service layer and in theory it is unaware > of the network technology topology and the network technology. The AppS > only sends out an authorization request and expects to get a response. It > doesn't need to know how the authorization is done, e.g. in Pull mode or > Push mode.] [TOLGA]What you said sounds reasonable but with that model, i.e. AppS completely unaware of networking technology, would AppS need to ask authorization for each and every call? As an example let's consider IMS-mobile. Do we expect AppS to ask for authorization for each call even for IMS-mobile calls, where actually none of them would have required push mode of operation? [Tina: The AppS is aware of the service provided for each call. If the authorization/QoS is needed for a call, the AppS will send a request to AE and then get a response from AE. If the authorization/QoS is not needed for a call, the AppS will not send a request to AE. This has nothing to do with network topology. Furthermore, this behavior of the AppS has nothing to do with the push or pull mode. To put it in another way, if an authorization/QoS is needed for a call, the AppS just sends a request to the AE, and it doesn't need to predict either the push or pull mode would be used. Even if all the calls would require the pull mode of operation, I see no problem that the AppS sends a request for each call, one by one. I believe you didn't mean there would be a batch request for a group of calls, since different calls normally have different start and termination time.] --Boundary_(ID_H6uhy89QOs/6c29pqU8lBA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear = Tolga,
Comments in line = demarked with [Tina:=20 ...]
 
B. R.
Tina
----- Original Message -----
From:=20 Asveren,=20 Tolga
To: Tina TSOU ; Sun,=20 Dong (Dong)
Cc: dime@ietf.org ; Tschofenig, Hannes (NSN -=20 FI/Espoo) ; McCann Peter-A001034 ; Avri Doria ; Glen=20 Zorn
Sent: Friday, July 25, 2008 = 3:09 AM
Subject: RE: [Fwd: [Dime] = Comments for=20 draft-ietf-dime-diameter-qos-06]

Hi Tina,

One more question=20 below.

Thanks,
Tolga

> -----Original = Message-----
>=20 From: Asveren, Tolga
> Sent: Thursday, July 24, 2008 11:58 = AM
>=20 To: Asveren, Tolga
> Subject: FW: [Fwd: [Dime] Comments=20 for
draft-ietf-dime-diameter-qos-06]
>
>
> =
>=20 ________________________________________
> From: Tina TSOU=20 [mailto:tena@huawei.com]
> Sent: Thursday, July 24, 2008 5:22 = AM
>=20 To: Sun, Dong (Dong); Asveren, Tolga
> Cc: dime@ietf.org; Tschofenig, Hannes = (NSN -=20 FI/Espoo); McCann Peter-
> A001034; Avri Doria; Glen = Zorn
>=20 Subject: Re: [Fwd: [Dime] Comments=20 for
draft-ietf-dime-diameter-qos-06]
>
> Hi = Tolga,
>=20 Good question:-)
> Comments in line beginning with [Tina: = ...]
>=20
> Cheers,
> Tina
> ----- Original Message = -----
>=20 From: Asveren, Tolga
> To: Tina TSOU ; Sun, Dong (Dong)
> = Cc: Glen=20 Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes
> = (NSN -=20 FI/Espoo) ; dime@ietf.org
> = Sent:=20 Thursday, July 24, 2008 2:22 AM
> Subject: RE: [Fwd: [Dime] = Comments=20 for
draft-ietf-dime-diameter-qos-06]
>
> Hi = Tina,
>=20
> One question below.
>
> Thanks,
> = Tolga
>=20
>
>
> [.. snip ..]
> >
> > 2- = 3.=20 Framework
> >    "After receiving the
>=20 >    authorization request from the AppS or the NE, = the AE=20 decides the
> >    appropriate mode = (i.e.  Push=20 or Pull).  The usage Push or Pull
mode
> = >   =20 can be determined by the authorizing entity either statically = or
>=20 >    dynamically."
> > I think I am missing = something here. Don't we have always push mode
if
> > the=20 authorization request is received from AppS? Or are we talking
> = about
> > a hybrid model where first AppS contacts the = Authorizing=20 Entity,
> > receives a token, hands it over to media layer, = and this=20 token is
used
> > in turn by NE for pull mode?
> = > [Sun,=20 Dong (Dong)] I don't think we are talking about a = hybrid
model.
>=20 my
> > understanding is that the push and pull models can be = decided=20 by AE
on
> per
> > call session basis (i.e. = dynamically), or=20 can be pre-configured for
> one of
> > them (i.e. = statically).=20 If this is correct, the texts may be
modified
> as
> = >=20 follows for clarity:
> >  "The push and pull models can = be=20 decided by the AE on per call
> session
> > basis (i.e. = dynamically), or can be pre-configured for one of them
> = (i.e.
>=20 > statically). Without any pre-configuration, when receiving a = new
>=20 > authorization request from the Apps or a local trigger, the=20 AE
starts
> the
> > Push model; when receiving a new = authorization request from the NE,
> the AE
> > starts = the Pull=20 model."
> > [Sun, Dong (Dong)] Tina,  I thought the = initial=20 texts come from you.
> could
> > you verify my comment = or give=20 some further clafication. are you ok
> with
> > the = modified=20 texts?
> > I will update the document accordingly if no=20 objection.
> > [Tina: As is specified in the document, "the = diversity=20 of QoS
> capabilities
> > of endpoints and QoS schemes = of=20 network technology leads to the
> > distinction
> > = on the=20 interaction mode between QoS authorization system and
>=20 underlying
> > NEs".
> > Therefore, I think the = hybrid model=20 should be supported. After
> receiving a
> > new = authorization=20 request from the AppS, the AE can decide which
mode
> >=20 should
> > be used based on the information of the request,=20 especially based on
> the
> > information which = indicates QoS=20 capability and the access network
> type. So
> > = I
> >=20 don't see any problem with the original text.
> > However, as = is=20 proposed by Hannes, the <QoS-Capability> AVP could be
>=20 added
> > into the QoS-Request message. Besides, I think = the
>=20 <Access-Network-Type>
> > AVP
> > should also = be added=20 to indicate the network technology since the
> network
> = >=20 technology is another factor affecting the type of QoS Model = being
>=20 used.]
> [TOLGA]I just am trying to understand the use = case:
> I=20 understand that endpoints will have different QoS reservation
>=20 capabilities.
> i- I have a device, which can't reserve QoS for = the=20 media but can
> indicate its desire to do so in signaling. AppS = would=20 determine that
> push mode is desired.
>
> ii- I = have a=20 device, which can't reserve QoS for the media and can't
> = indicate its=20 desire to do so in signaling. AppS could determine
> statically = what to=20 do.
>
> iii- I have a device, which can reserve QoS for = the=20 media. It uses its
> own capabilities whenever it needs.
> =
> I guess what I am trying to figure out is, why decision = process=20 does
not
> belong to AppS?
>
> For=20 <Access-Network-Type>, I can see that this type of=20 information
could
> be useful, e.g. a device attached via = DOCSIS to=20 IP network v.s. a
device
> attached via a 3GPP technology. = OTOH,=20 isn't this information actually
> necessary in AppS so that it = can=20 determine whether it should ask for
QoS
> resources?
> = [Tina:=20 The AppS belongs to the service layer and in theory it = is
unaware
>=20 of the network technology topology and the network technology.=20 The
AppS
> only sends out an authorization request and = expects to get=20 a response.
It
> doesn't need to know how the authorization = is done,=20 e.g. in Pull mode
or
> Push mode.]
[TOLGA]What you said = sounds=20 reasonable but with that model, i.e. AppS
completely unaware of = networking=20 technology, would AppS need to ask
authorization for each and every = call?=20 As an example let's consider
IMS-mobile. Do we expect AppS to ask = for=20 authorization for each call
even for IMS-mobile calls, where = actually none=20 of them would have
required push mode of operation?

[Tina: The AppS is aware of the=20 service provided for each call. If the authorization/QoS is needed for = a call,=20 the AppS will send a request to AE and then get a response from AE. If = the=20 authorization/QoS is not needed for a call, the AppS will not send a = request=20 to AE. This has nothing to do with network topology. Furthermore, this = behavior of the AppS has nothing to do with the push or pull mode. To = put it=20 in another way, if an authorization/QoS is needed for a call, the AppS = just=20 sends a request to the AE, and it doesn=92t need to = predict either the push or pull=20 mode would be used. Even if all the calls would require the pull mode = of=20 operation, I see no problem that the AppS sends a request for each = call, one=20 by one. I believe you didn=92t mean there = would be a batch request for=20 a group of calls, since different calls normally have different start = and=20 termination time.]

--Boundary_(ID_H6uhy89QOs/6c29pqU8lBA)-- --===============0424946209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0424946209==-- From dime-bounces@ietf.org Mon Jul 28 02:54:17 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7263A69FF; Mon, 28 Jul 2008 02:54:17 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F713A69CE for ; Mon, 28 Jul 2008 02:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OVR4D3xIXSH for ; Mon, 28 Jul 2008 02:54:15 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B4B373A69FF for ; Mon, 28 Jul 2008 02:54:14 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2008 09:54:20 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp013) with SMTP; 28 Jul 2008 11:54:20 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19XKqQSm/BXzoaQ6fMp3eN0xku9i1JToKL+CC2wGF w9EMzOucG9FK25 Message-ID: <488D974B.7030808@gmx.net> Date: Mon, 28 Jul 2008 12:54:19 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.00 Subject: [Dime] Meeting Minute Taker & Jabber Scribe X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org We need a volunteer for today's meeting Please! _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 04:12:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7CF3A6916; Mon, 28 Jul 2008 04:12:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED873A6906 for ; Mon, 28 Jul 2008 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.846 X-Spam-Level: ** X-Spam-Status: No, score=2.846 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 KIAOExeOJhnw for ; Mon, 28 Jul 2008 04:12: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 EEADD3A6916 for ; Mon, 28 Jul 2008 04:12: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 <0K4P00MM2R59K4@szxga01-in.huawei.com> for dime@ietf.org; Mon, 28 Jul 2008 19:12:45 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4P00D62R594J@szxga01-in.huawei.com> for dime@ietf.org; Mon, 28 Jul 2008 19:12:45 +0800 (CST) Received: from jys3105109974f (guestroom-nat.meeting.ietf.org [130.129.64.64]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4P00KJIR4TFK@szxml02-in.huawei.com> for dime@ietf.org; Mon, 28 Jul 2008 19:12:45 +0800 (CST) Date: Mon, 28 Jul 2008 19:12:21 +0800 From: shan To: dime@ietf.org Message-id: <000501c8f0a2$cfc324e0$8b0810ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acjwos3P6i+7rybwTves3tBAoV4u0Q== Subject: [Dime] resubmission draft for capabilities-update-propoblem statment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574427233==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1574427233== Content-type: multipart/alternative; boundary="Boundary_(ID_3fTRFYYe4kYVBRuqMen3HQ)" This is a multi-part message in MIME format. --Boundary_(ID_3fTRFYYe4kYVBRuqMen3HQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all The following is the re-submission of the draft for capabilities update problem! Since there is some problem with the previous submission. The content is same! http://www.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update- problem-statement-00.txt The link in the agenda for the meeting this afternoon hence could be kindly replaced by this one. Your comments welcome! Regards, Mingjun --Boundary_(ID_3fTRFYYe4kYVBRuqMen3HQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all

 

The following is the re-submission of the draft for capabilities update problem! Since there is some problem with the previous submission.

The content is same!

 

http://www.ietf.org/proceedings/staging/draft-tsou-dime-capabilities-update-problem-statement-00.txt

 

The link in the agenda for the meeting this afternoon hence could be kindly replaced by this one.

Your comments welcome!

 

Regards,

Mingjun

--Boundary_(ID_3fTRFYYe4kYVBRuqMen3HQ)-- --===============1574427233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1574427233==-- From dime-bounces@ietf.org Mon Jul 28 04:30:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599853A6808; Mon, 28 Jul 2008 04:30:02 -0700 (PDT) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E092D3A6808; Mon, 28 Jul 2008 04: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: <20080728113001.E092D3A6808@core3.amsl.com> Date: Mon, 28 Jul 2008 04:30:01 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-07.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : The Diameter API Author(s) : P. Calhoun, D. Frascone Filename : draft-ietf-dime-diameter-api-07.txt Pages : 47 Date : 2008-07-28 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes an API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-28042705.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Jul 28 07:55:50 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3C13A6A1D; Mon, 28 Jul 2008 07:55:50 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC103A6AD3 for ; Mon, 28 Jul 2008 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFZCClaCKIun for ; Mon, 28 Jul 2008 07:55:45 -0700 (PDT) Received: from web84306.mail.re1.yahoo.com (web84306.mail.re1.yahoo.com [69.147.74.185]) by core3.amsl.com (Postfix) with SMTP id 949CD3A6ACC for ; Mon, 28 Jul 2008 07:55:45 -0700 (PDT) Received: (qmail 55421 invoked by uid 60001); 28 Jul 2008 14:55:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PSPq41bUQXZrDACif3h2raIfe34e6SGyqYFkiEIFT9V7YFVHkbP6q/uCJSX8IiCfNJMU8T7qSPElXVuBXAphP8okzjACS5a37x7UJlV4DPEJxGnTZnmy57H0Kgkn9oQBna+i8IMF8SF4cGsnvmLF6H/q6trF3puT9YjJf4de/8M=; Received: from [130.129.20.221] by web84306.mail.re1.yahoo.com via HTTP; Mon, 28 Jul 2008 07:55:54 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Mon, 28 Jul 2008 07:55:54 -0700 (PDT) From: Behcet Sarikaya To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <24043.55283.qm@web84306.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: [Dime] draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096999340==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0096999340== Content-Type: multipart/alternative; boundary="0-718023559-1217256954=:55283" --0-718023559-1217256954=:55283 Content-Type: text/plain; charset=us-ascii Hi Hannes, Regarding the issue of SDOs and this draft raised by Avi, I am surprised by the replies from Alper as well as from Avi. The fact is that this problem (AAA based prefix authorization) was not brought to any SDOs by us, at least not yet. I don't know what type of conclusion can be made from this, I leave it up to the working group. I regret the statements made by WiMAX "guru" on this issue during the meeting today. I suggest that people in such positions please make correct (and possibly also objective) statements and refrain from confusing other people in the meeting. Regards, Behcet ----- Original Message ---- From: Hannes Tschofenig To: Frank Xia Cc: dime@ietf.org Sent: Wednesday, July 23, 2008 3:13:21 PM Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt Hi Frank, Frank Xia wrote: > Hi Hannes > > Please check my reply.. > > BR > Frank > ----- Original Message ----- From: "Hannes Tschofenig" > > To: "Frank Xia" > Cc: > Sent: Wednesday, July 23, 2008 2:30 PM > Subject: Re: [Dime] Relationship between > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > >> Hi Frank, >> >> thanks for the quick feedback. >> >> I have a few more comments inline >> >> Frank Xia wrote: >>> Hi Hannes >>> >>> I try to jump ahead of Behcet to answer >>> some of your questions :-) >>> >>> Please check inline comments. >>> >>> BR >>> Frank >>> >>> >>> ----- Original Message ----- From: "Hannes Tschofenig" >>> >>> To: >>> Sent: Wednesday, July 23, 2008 7:41 AM >>> Subject: [Dime] Relationship between >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and >>> draft-sarikaya-dime-prefix-delegation-ps-01.txt >>> >>> >>>> I have sent my rechartering questions around regarding these two >>>> documents. I took a brief look at them and I wonder what the >>>> relationship between the two documents is. Why are there 2 >>>> documents on almost the same subject? >>>> >>> Frank=>They have almost the same main idea. >>> You can only refer to the draft >>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. >>> >>> >> Ok. We can essentially forget the other document. Right? > Frank=>Yes. > >> >> >>>> When I browse through >>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt >>>> then I sometimes get the impression that you would like to later >>>> standardize a Diameter application. I wasn't sure why additional >>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used? >>> Frank=>Prefix delegation is an authorization which may be >>> decoupled from an authentication. RFC4005/4072 only deal >>> with coupled authentication& authorization scenario. >>> >> It is true that the request for prefix authorization is not run >> independently from the message exchanges used for authentication. > Frank=>A little bit confusing. You meant "independently " or not? > I agree with you that RFC 4072 combines the prefix authorization protocol run with the EAP protocol run. RFC 4005 is a bit different since it has the RAR and RAA commands that allow you to perform re-authorization.Wouldn't they be a nice fit? >> >>>> >>>> Let me also comment on a few selected items: >>>> >>>> >>>> AAA-based prefix authorization (PA) application MUST run between a >>>> NAS, located on AR, LMA, MR, etc. and an AAA server. >>>> >>>> [hannes] This requirement does not say a lot. The AAA protocol is >>>> always run between a client and a server. >>>> >>>> >>>> >>>> AAA-based PA application MUST support the AAA client to request >>>> prefixes from an AAA server. AAA-based PA application MUST support >>>> the client to give back the prefixes to the AAA server. >>>> >>>> [hannes] With the last sentence you mean that you need to have a >>>> way to indicate that the AAA session is terminated? >>> Frank=>In IPv6 renumbering scenario, it is necessary >>> >>>> >>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the >>>> devices on the network, the certificate or the information needed >>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS. >>>> >>>> [hannes] What information do you exactly want to carry towards the >>>> AAA client? >>> Frank=>IPv6 address prefix for NAS is authorized to route >>> >> I mean, you want to provide >> * prefix >> * lifetime >> * certificate >> from the AAA server to the AAA client. >> What else? > Frank=> I can only find these now. > >> >>>> >>>> In point-to-point link operation, the NAS MUST identify the >>>> interface of MN in its request. The NAS MAY provide a prefix hint, >>>> e.g. of length /48 to which the AAA server MUST reply with one or >>>> more prefixes, e.g. of length /64. >>>> >>>> [hannes] how would such an interface identifier look like? >>> Frank=>Tentatively, it can be the interface identifier part of >>> host's link local >>> address, NAI (RFC4282), or MAC address. >>> >> I would like to better understand what the AAA server should be doing >> based on this hint. >> Is the "hint" used to identify the end user and it's host? > Frank=>The hint is only for expressing client's preference. The > server may honor this or not based on it's own discretion. > I guess you need to describe the details of this hint a bit more. >> >>>> >>>> In point-to-point operation, the AAA server MAY assign the >>>> prefix(es) and related parameters such as the lifetime and the >>>> certificates to MN from MN's profile. >>>> >>>> [hannes] I am not sure what this means. You mean that the AAA >>>> server should keep state to make sure that it does not forget what >>>> it has provided to the MN? >>> Frank=>Probably, the AAA server for prefix delegation is different from >>> the AAA server for authentication. So it is necessary to record the >>> state. >>> >> OK. >> >> I don't think that you need to say that since this is already done >> today. >> >>>> For some reason the problem is not well described. In Section 3 of >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC >>>> 4818 but I do not quite understand what you would like to see >>>> happening instead. >>>> >>>> AAA-based prefix authorization application SHOULD support prefix >>>> release procedures. >>>> >>>> [hannes] isn't this the same as mentioned in the previous >>>> requirement "AAA-based PA application MUST support the client to >>>> give back the prefixes to the AAA server. " >>> Frank=>It is the same. >>> >>>> >>>> The NAS is responsible for renewing the prefixes when the lifetime >>>> expires. The NAS SHOULD be able to extend the lifetime of the >>>> prefixes using messages designed for this purpose. >>>> >>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the >>>> lifetime of the AAA session itself? Makes things much easier. The >>>> same applies a bit to this requirement: "It SHOULD be possible to >>>> renumber the prefixes authorized by AAA server. The AAA server >>>> SHOULD initiate prefix renumbering process. " >>> Frank=>IPv6 renumbering is a feature of IPv6. >>> If we tie the lifetime of prefix to the lifetime of AAA session, >>> it is certain that we can't suport IPv6 renumbering. >>> Even though IPv6 renumbering probably happen probably >>> infrequently, it is better for us to have such a mechnism to support. >>> >>> For IPv6 renumbering, here are some references >>> RFC 1916/2071/2072/2874/2894/4076/4192. >>> >> I know IPv6 renumbering but I was wondering about the following issue. >> >> IPv6 renumber should occur less frequently and hence the lifetime is >> rather long. >> A AAA session typically isn't very long lived and it is possible to >> influence the lifetime with various parameters. > Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. > In fact, many people including me are always online because many > operators > don't charge based on time. For example, $30 a month is for no > limited access. > I don't know your home setup but typically you have a DSL router at home and your PC / laptop may be running all the time. Your DSL router re-connects automatically when re-authentication is needed. >> >> Now, isn't it possible to re-authenticate and re-authorize the end >> host in case of network renumbering. Given that you have to >> re-authenticate quite often for other reasons as well shouldn't cause >> big problems. > Frank=>IMHO, it is not very graceful to kick off all the users > when renumbering. Maybe. When I look at the IT problems I had this year then renumbering is the least thing I worry about. >> >> I am just trying to figure out how tough the requirements are. > Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment. > However, it is probably too late after large scale deployment. > Difficult to know, I agree. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --0-718023559-1217256954=:55283 Content-Type: text/html; charset=us-ascii
Hi Hannes,
  Regarding the issue of SDOs and this draft raised by Avi, I am surprised by the replies from Alper as well as from Avi.
  The fact is that this problem (AAA based prefix authorization) was not brought to any SDOs by us, at least not yet. I don't know what type of conclusion can be made from this, I leave it up to the working group.
  I regret the statements made by WiMAX "guru" on this issue during the meeting today. I suggest that people in such positions please make correct (and possibly also objective) statements and refrain from confusing other people in the meeting.

Regards,

Behcet

----- Original Message ----
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Frank Xia <xiayangsong@huawei.com>
Cc: dime@ietf.org
Sent: Wednesday, July 23, 2008 3:13:21 PM
Subject: Re: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt

Hi Frank,

Frank Xia wrote:
> Hi Hannes
>
> Please check my reply..
>
> BR
> Frank
> ----- Original Message ----- From: "Hannes Tschofenig"
> <Hannes.Tschofenig@gmx.net>
> To: "Frank Xia" <xiayangsong@huawei.com>
> Cc: <dime@ietf.org>
> Sent: Wednesday, July 23, 2008 2:30 PM
> Subject: Re: [Dime] Relationship between
> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and
> draft-sarikaya-dime-prefix-delegation-ps-01.txt
>
>
>> Hi Frank,
>>
>> thanks for the quick feedback.
>>
>> I have a few more comments inline
>>
>> Frank Xia wrote:
>>> Hi Hannes
>>>
>>> I try to jump ahead of Behcet to  answer
>>> some of your questions :-)
>>>
>>> Please check inline comments.
>>>
>>> BR
>>> Frank
>>>
>>>
>>> ----- Original Message ----- From: "Hannes Tschofenig"
>>> <Hannes.Tschofenig@gmx.net>
>>> To: <dime@ietf.org>
>>> Sent: Wednesday, July 23, 2008 7:41 AM
>>> Subject: [Dime] Relationship between
>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and
>>> draft-sarikaya-dime-prefix-delegation-ps-01.txt
>>>
>>>
>>>> I have sent my rechartering questions around regarding these two
>>>> documents. I took a brief look at them and I wonder what the
>>>> relationship between the two documents is. Why are there 2
>>>> documents on almost the same subject?
>>>>
>>> Frank=>They have almost the same main idea.
>>> You can only refer to the draft
>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt.
>>>
>>>
>> Ok. We can essentially forget the other document. Right?
> Frank=>Yes.
>
>>
>>
>>>> When I browse through
>>>> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>>>> then I sometimes get the impression that you would like to later
>>>> standardize a Diameter application. I wasn't sure why additional
>>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used?
>>> Frank=>Prefix delegation is an authorization which may be
>>> decoupled from an authentication. RFC4005/4072 only deal
>>> with coupled authentication& authorization scenario.
>>>
>> It is true that the request for prefix authorization is not run
>> independently from the message exchanges used for authentication.
> Frank=>A little bit confusing.  You meant "independently " or not?
>

I agree with you that RFC 4072 combines the prefix authorization
protocol run with the EAP protocol run.

RFC 4005 is a bit different since it has the RAR and RAA commands that
allow you to perform re-authorization.Wouldn't they be a nice fit?

>>
>>>>
>>>> Let me also comment on a few selected items:
>>>>
>>>>
>>>> AAA-based prefix authorization (PA) application MUST run between a
>>>> NAS, located on AR, LMA, MR, etc. and an AAA server.
>>>>
>>>> [hannes] This requirement does not say a lot. The AAA protocol is
>>>> always run between a client and a server.
>>>>
>>>>
>>>>
>>>> AAA-based PA application MUST support the AAA client to request
>>>> prefixes from an AAA server. AAA-based PA application MUST support
>>>> the client to give back the prefixes to the AAA server.
>>>>
>>>> [hannes] With the last sentence you mean that you need to have a
>>>> way to indicate that the AAA session is terminated?
>>> Frank=>In IPv6 renumbering scenario, it is necessary
>>>
>>>>
>>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the
>>>> devices on the network, the certificate or the information needed
>>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS.
>>>>
>>>> [hannes] What information do you exactly want to carry towards the
>>>> AAA client?
>>> Frank=>IPv6 address prefix for NAS is authorized to route
>>>
>> I mean, you want to provide
>> * prefix
>> * lifetime
>> * certificate
>> from the AAA server to the AAA client.
>> What else?
> Frank=> I can only find these now.
>
>>
>>>>
>>>> In point-to-point link operation, the NAS MUST identify the
>>>> interface of MN in its request. The NAS MAY provide a prefix hint,
>>>> e.g. of length /48 to which the AAA server MUST reply with one or
>>>> more prefixes, e.g. of length /64.
>>>>
>>>> [hannes] how would such an interface identifier look like?
>>> Frank=>Tentatively, it can be the interface identifier part of
>>> host's link local
>>> address, NAI (RFC4282), or MAC address.
>>>
>> I would like to better understand what the AAA server should be doing
>> based on this hint.
>> Is the "hint" used to identify the end user and it's host?
> Frank=>The hint is only for expressing client's preference.  The
> server may honor this or not based on it's own discretion.
>
I guess you need to describe the details of this hint a bit more.

>>
>>>>
>>>> In point-to-point operation, the AAA server MAY assign the
>>>> prefix(es) and related parameters such as the lifetime and the
>>>> certificates to MN from MN's profile.
>>>>
>>>> [hannes] I am not sure what this means. You mean that the AAA
>>>> server should keep state to make sure that it does not forget what
>>>> it has provided to the MN?
>>> Frank=>Probably, the AAA server for prefix delegation is different from
>>> the AAA server for authentication.  So it is necessary to record the
>>> state.
>>>
>> OK.
>>
>> I don't think that you need to say that since this is already done
>> today.
>>
>>>> For some reason the problem is not well described. In Section 3 of
>>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC
>>>> 4818 but I do not quite understand what you would like to see
>>>> happening instead.
>>>>
>>>> AAA-based prefix authorization application SHOULD support prefix
>>>> release procedures.
>>>>
>>>> [hannes] isn't this the same as mentioned in the previous
>>>> requirement "AAA-based PA application MUST support the client to
>>>> give back the prefixes to the AAA server. "
>>> Frank=>It is the same.
>>>
>>>>
>>>> The NAS is responsible for renewing the prefixes when the lifetime
>>>> expires. The NAS SHOULD be able to extend the lifetime of the
>>>> prefixes using messages designed for this purpose.
>>>>
>>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the
>>>> lifetime of the AAA session itself? Makes things much easier. The
>>>> same applies a bit to this requirement: "It SHOULD be possible to
>>>> renumber the prefixes authorized by AAA server. The AAA server
>>>> SHOULD initiate prefix renumbering process. "
>>> Frank=>IPv6 renumbering is a feature of IPv6.
>>> If we tie the lifetime of prefix to the lifetime of AAA session,
>>> it is certain that we can't suport IPv6 renumbering.
>>> Even though IPv6 renumbering probably happen probably
>>> infrequently, it is better for us to have such a mechnism to support.
>>>
>>> For IPv6 renumbering, here are some references
>>> RFC 1916/2071/2072/2874/2894/4076/4192.
>>>
>> I know IPv6 renumbering but I was wondering about the following issue.
>>
>> IPv6 renumber should occur less frequently and hence the lifetime is
>> rather long.
>> A AAA session typically isn't very long lived and it is possible to
>> influence the lifetime with various parameters.
> Frank=>IMHO, I don't agree with your assumption on AAA session lifetime.
> In fact, many people including me are always online because many
> operators
> don't charge based on time.  For example, $30 a month is for no
> limited access.
>
I don't know your home setup but typically you have a DSL router at home
and your PC / laptop may be running all the time. Your DSL router
re-connects automatically when re-authentication is needed.

>>
>> Now, isn't it possible to re-authenticate and re-authorize the end
>> host in case of network renumbering. Given that you have to
>> re-authenticate quite often for other reasons as well shouldn't cause
>> big problems.
> Frank=>IMHO, it is not very graceful to kick off all the users
> when renumbering.
Maybe.

When I look at the IT problems I had this year then renumbering is the
least thing I worry about.

>>
>> I am just trying to figure out how tough the requirements are.
> Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment.
> However, it is probably too late after large scale deployment.
>
Difficult to know, I agree.

Ciao
Hannes

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--0-718023559-1217256954=:55283-- --===============0096999340== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0096999340==-- From dime-bounces@ietf.org Mon Jul 28 08:12:35 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E2528C138; Mon, 28 Jul 2008 08:12:35 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422623A65A6 for ; Mon, 28 Jul 2008 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 fTwVxuw0-EhK for ; Mon, 28 Jul 2008 08:12:33 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 2A51328C138 for ; Mon, 28 Jul 2008 08:12:31 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SFCQNu012939; Mon, 28 Jul 2008 11:12:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:12:25 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20A== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, Inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:19 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > Application-Id > > Tolga, > Comments inline. > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:13 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / Application-Id > > (Continuing in separate threads for each issue for easier tracking.) > > Hi Dong, > > One comment below. > > Thanks, > Tolga > > [.. snip ..] > > > > > > 1- Use of the same Application-Id for push/pull models It sounds > > > reasonable to me to think nodes which support only a single mode. > How > > > can we guarantee that messages land to the right server considering > > > that the same Application-Id is used for both of them? > > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > > models is > > > different, for example, when a new request from the PEP is recevied, > > the > > > Server will start the pull model. In fact, the push and pull are > > sharing > > > the same state machine per se. the main difference is just how to > > > establish a Diameter session. The enhancement is to allow the > Diameter > > > > > Server to establish a session with a local trigger instead of the > > trigger > > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the > > same > > > application-Id causes any problem, especially for the pull model > since > > > > > push/pull is able use the same server (certainly they can also have > > > separate server according to the configuration). > > [TOLGA]My concern here is about message routing rather than the state > > machine processing in the server. Let's say a server is capable only > to > > accommodate pull model (it doesn't know what NE to contact if push > model > > is required). How can the network intermediaries, e.g. relay agent, > > forward the initial request in the session to the right server for > push > > model? How can they be sure that the server supports push model? > > [Dong] The relay agent should route the message according to the > > destination address/realm that is filled up by the requestor. I don't > > know how the application id will affect this kind of routing. > [TOLGA]The initial message of a session may have only Destination-Realm. > In such a case Application-Id is used by intermediaries to select the > right server. > [Dong] In the context of QoS application, for the pull mode, the NE > typically is configured by a default policy server or redirect server. I > don't think the scenario you are concerned is a common case in reality > although theoretically the base Diameter protocol may allow this kind of > behavior, but it is not the case for QoS application, IMHO. [TOLGA] How can we make sure that a request requiring push mode capabilities is delivered to the right server? That was my initial question. There could be servers which only have authorization capability but do not have any topology information, i.e. not suitable for push mode operation. And what type of problems would be introduced if we used two different Application-Ids? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 08:18:36 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA3028C138; Mon, 28 Jul 2008 08:18:36 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030BF28C16B for ; Mon, 28 Jul 2008 08:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 x0T1D7onCjPK for ; Mon, 28 Jul 2008 08:18:34 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id BE4D428C138 for ; Mon, 28 Jul 2008 08:18:33 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SFII83017751; Mon, 28 Jul 2008 11:18:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:18:17 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D4540@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91E36@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAh/pZQAAZ6BtAAwqpJgA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120603A@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E36@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:31 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > AE topology aware? > > > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:26 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / AE topology aware? > > > Hi Dong, > > One question below. > > Thanks, > Tolga > > [.. snip ..] > > > 3- 3. Framework > > > "For Push mode, the authorizing entity needs to identify the > > > appropriate NE(s) to which QoS authorization information needs to > > be > > > pushed. It might determine this based on information received > from > > > the AppS, such as the IP addresses of media flows." > > > It could be a good idea to give a bit more information about this: > > > - This is hard to do as Authorizing Entity would need to have > > > information about routing decisions of NEs for a particular flow > > > - QoS in the core network is usually not scarce > > > - QoS on the access side is scarce > > > - It is not difficult for the Authorizing Entity to determine NEs > > > facing the access side as usually this information is stored > somewhere > > > > > when the endpoint attaches to the network and does not change per IP > > > > flow. > > > [Sun, Dong (Dong)] my understanding is the NEs for Policy > enforcement > > are > > > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the > > discovery > > > of these NEs is not necessarily based on the routing info, instead, > it > > can > > > be preconfigured. > > > In addition, i think this draft mainly focuses on the mechanism and > > > protocol. It can be used for both access and core networks. the QoS > > status > > > you described looks like well known, not sure how much it may add. > > [TOLGA]Even for some of the nodes you mentioned, I would expect > routing > > to play a role here. For example if there are more than one gateway, > AE > > needs to know which one it should contact for that particular stream. > > [Dong] in practice a rendezvous AE or hierarchical AEs will derive the > > > address of the right gateway according to preconfigured info in a > > database or through DNS query. The point is that the NE/PEP is an > > anchoring point for certain streams per provisioning, not random > routing > > for selecting those PEPs (except load balancing). In other words, not > > every NE/router is eligible to serve as the PEP in reality. > [TOLGA] The point I am missing is how does the AE now the NE(s)/PEP(s) > to be used for a particular stream? The list of such entities on the > path for a stream is obviously determined according to some > algorithm/configuration but I am not sure whether AE has the complete > information. Let's take an example: > > +-------+ > | | > +---| AE |-----------+ > | +-------+ | > | | | > | | | > | | | > | | | > | | | > | | +------+ > | | .....| | > +------+ | . | NE2 | > | |........... +------+ > | NE1 |........... > +------+ | . > | . > | . +------+ > +----.----| | > .....| NE3 | > +------+ > > How does the AE know whether NE2 or NE3 will be chosen by NE1 for a > particular flow? > > [Dong] I assume you knew well how to get it in the access network. > You're mainly concerned about the core network case, right? Let's look > at this example: in the core network, each edge router is responsible > for certain access network domains (or in other words, the BRAS/edge > router is configured to route the traffic to a particular edge router in > the core, for the simplicity, assuming NE1 is for 10.1.x.x, NE2 for > 10.2.x.x, NE3 for 10.3.x.x, when the AE receives a request from AF with > the global routable IP address of the end user, it can derive the > targeting NE straightforward. Certainly some additional info e.g > IP-tuple, subscriber id and traffic classifier might be useful to > provide further granularity to allocate the right NE as needed > (dependent on the network configuration and Traffic engineering > approach). [TOLGA]I don't think we can assume that just by destination IP address the full set of NEs to be traversed can be determined without ambiguity. My comment was about difficulties associated with push model if end-to-end reservation is the goal. Just adding a few sentences to indicate that push model is more suitable for access side reservation would be enough. In any case, this wasn't a comment impacting normative sections of the draft so either way is fine for me. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 08:24:55 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0017228C191; Mon, 28 Jul 2008 08:24:54 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5248228C17C for ; Mon, 28 Jul 2008 08:24:53 -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 Y2+3syI22koh for ; Mon, 28 Jul 2008 08:24:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 523FF28C191 for ; Mon, 28 Jul 2008 08:24:47 -0700 (PDT) Received: (qmail invoked by alias); 28 Jul 2008 15:24:57 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp041) with SMTP; 28 Jul 2008 17:24:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19/hVtJ/IV/XborbX6wJFu6fobIdcXu75XGLTpjpu iVPzupv1FQOUOh Message-ID: <488DE4C8.9070502@gmx.net> Date: Mon, 28 Jul 2008 18:24:56 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Behcet Sarikaya References: <24043.55283.qm@web84306.mail.re1.yahoo.com> In-Reply-To: <24043.55283.qm@web84306.mail.re1.yahoo.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: dime@ietf.org Subject: Re: [Dime] draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Behcet, I cannot comment on Avi's and Alper's feedback. I don't participate in Wimax, 3GPP, and 3GPP2. As you have seen during the meeting there wasn't support for the document in the room. I don't know why this is the case. There could be many reasons, ranging from "insufficient problem description to convince people" to "lack of time to help doing some work on it". This might, however, change as the deployment on IPv6 increases. Hence, I wouldn't be discouraged to continue the work on your document. Ciao Hannes Behcet Sarikaya wrote: > Hi Hannes, > Regarding the issue of SDOs and this draft raised by Avi, I am > surprised by the replies from Alper as well as from Avi. > The fact is that this problem (AAA based prefix authorization) was > not brought to any SDOs by us, at least not yet. I don't know what > type of conclusion can be made from this, I leave it up to the working > group. > I regret the statements made by WiMAX "guru" on this issue during > the meeting today. I suggest that people in such positions please make > correct (and possibly also objective) statements and refrain from > confusing other people in the meeting. > > Regards, > > Behcet > > ----- Original Message ---- > From: Hannes Tschofenig > To: Frank Xia > Cc: dime@ietf.org > Sent: Wednesday, July 23, 2008 3:13:21 PM > Subject: Re: [Dime] Relationship between > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > Hi Frank, > > Frank Xia wrote: > > Hi Hannes > > > > Please check my reply.. > > > > BR > > Frank > > ----- Original Message ----- From: "Hannes Tschofenig" > > > > > To: "Frank Xia" > > > Cc: > > > Sent: Wednesday, July 23, 2008 2:30 PM > > Subject: Re: [Dime] Relationship between > > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > > > > >> Hi Frank, > >> > >> thanks for the quick feedback. > >> > >> I have a few more comments inline > >> > >> Frank Xia wrote: > >>> Hi Hannes > >>> > >>> I try to jump ahead of Behcet to answer > >>> some of your questions :-) > >>> > >>> Please check inline comments. > >>> > >>> BR > >>> Frank > >>> > >>> > >>> ----- Original Message ----- From: "Hannes Tschofenig" > >>> > > >>> To: > > >>> Sent: Wednesday, July 23, 2008 7:41 AM > >>> Subject: [Dime] Relationship between > >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > >>> draft-sarikaya-dime-prefix-delegation-ps-01.txt > >>> > >>> > >>>> I have sent my rechartering questions around regarding these two > >>>> documents. I took a brief look at them and I wonder what the > >>>> relationship between the two documents is. Why are there 2 > >>>> documents on almost the same subject? > >>>> > >>> Frank=>They have almost the same main idea. > >>> You can only refer to the draft > >>> > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. > > >>> > >>> > >> Ok. We can essentially forget the other document. Right? > > Frank=>Yes. > > > >> > >> > >>>> When I browse through > >>>> > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > >>>> then I sometimes get the impression that you would like to later > >>>> standardize a Diameter application. I wasn't sure why additional > >>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used? > >>> Frank=>Prefix delegation is an authorization which may be > >>> decoupled from an authentication. RFC4005/4072 only deal > >>> with coupled authentication& authorization scenario. > >>> > >> It is true that the request for prefix authorization is not run > >> independently from the message exchanges used for authentication. > > Frank=>A little bit confusing. You meant "independently " or not? > > > > I agree with you that RFC 4072 combines the prefix authorization > protocol run with the EAP protocol run. > > RFC 4005 is a bit different since it has the RAR and RAA commands that > allow you to perform re-authorization.Wouldn't they be a nice fit? > > >> > >>>> > >>>> Let me also comment on a few selected items: > >>>> > >>>> > >>>> AAA-based prefix authorization (PA) application MUST run between a > >>>> NAS, located on AR, LMA, MR, etc. and an AAA server. > >>>> > >>>> [hannes] This requirement does not say a lot. The AAA protocol is > >>>> always run between a client and a server. > >>>> > >>>> > >>>> > >>>> AAA-based PA application MUST support the AAA client to request > >>>> prefixes from an AAA server. AAA-based PA application MUST support > >>>> the client to give back the prefixes to the AAA server. > >>>> > >>>> [hannes] With the last sentence you mean that you need to have a > >>>> way to indicate that the AAA session is terminated? > >>> Frank=>In IPv6 renumbering scenario, it is necessary > >>> > >>>> > >>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the > >>>> devices on the network, the certificate or the information needed > >>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS. > >>>> > >>>> [hannes] What information do you exactly want to carry towards the > >>>> AAA client? > >>> Frank=>IPv6 address prefix for NAS is authorized to route > >>> > >> I mean, you want to provide > >> * prefix > >> * lifetime > >> * certificate > >> from the AAA server to the AAA client. > >> What else? > > Frank=> I can only find these now. > > > >> > >>>> > >>>> In point-to-point link operation, the NAS MUST identify the > >>>> interface of MN in its request. The NAS MAY provide a prefix hint, > >>>> e.g. of length /48 to which the AAA server MUST reply with one or > >>>> more prefixes, e.g. of length /64. > >>>> > >>>> [hannes] how would such an interface identifier look like? > >>> Frank=>Tentatively, it can be the interface identifier part of > >>> host's link local > >>> address, NAI (RFC4282), or MAC address. > >>> > >> I would like to better understand what the AAA server should be doing > >> based on this hint. > >> Is the "hint" used to identify the end user and it's host? > > Frank=>The hint is only for expressing client's preference. The > > server may honor this or not based on it's own discretion. > > > I guess you need to describe the details of this hint a bit more. > > >> > >>>> > >>>> In point-to-point operation, the AAA server MAY assign the > >>>> prefix(es) and related parameters such as the lifetime and the > >>>> certificates to MN from MN's profile. > >>>> > >>>> [hannes] I am not sure what this means. You mean that the AAA > >>>> server should keep state to make sure that it does not forget what > >>>> it has provided to the MN? > >>> Frank=>Probably, the AAA server for prefix delegation is different > from > >>> the AAA server for authentication. So it is necessary to record the > >>> state. > >>> > >> OK. > >> > >> I don't think that you need to say that since this is already done > >> today. > >> > >>>> For some reason the problem is not well described. In Section 3 of > >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC > >>>> 4818 but I do not quite understand what you would like to see > >>>> happening instead. > >>>> > >>>> AAA-based prefix authorization application SHOULD support prefix > >>>> release procedures. > >>>> > >>>> [hannes] isn't this the same as mentioned in the previous > >>>> requirement "AAA-based PA application MUST support the client to > >>>> give back the prefixes to the AAA server. " > >>> Frank=>It is the same. > >>> > >>>> > >>>> The NAS is responsible for renewing the prefixes when the lifetime > >>>> expires. The NAS SHOULD be able to extend the lifetime of the > >>>> prefixes using messages designed for this purpose. > >>>> > >>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the > >>>> lifetime of the AAA session itself? Makes things much easier. The > >>>> same applies a bit to this requirement: "It SHOULD be possible to > >>>> renumber the prefixes authorized by AAA server. The AAA server > >>>> SHOULD initiate prefix renumbering process. " > >>> Frank=>IPv6 renumbering is a feature of IPv6. > >>> If we tie the lifetime of prefix to the lifetime of AAA session, > >>> it is certain that we can't suport IPv6 renumbering. > >>> Even though IPv6 renumbering probably happen probably > >>> infrequently, it is better for us to have such a mechnism to support. > >>> > >>> For IPv6 renumbering, here are some references > >>> RFC 1916/2071/2072/2874/2894/4076/4192. > >>> > >> I know IPv6 renumbering but I was wondering about the following issue. > >> > >> IPv6 renumber should occur less frequently and hence the lifetime is > >> rather long. > >> A AAA session typically isn't very long lived and it is possible to > >> influence the lifetime with various parameters. > > Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. > > In fact, many people including me are always online because many > > operators > > don't charge based on time. For example, $30 a month is for no > > limited access. > > > I don't know your home setup but typically you have a DSL router at home > and your PC / laptop may be running all the time. Your DSL router > re-connects automatically when re-authentication is needed. > > >> > >> Now, isn't it possible to re-authenticate and re-authorize the end > >> host in case of network renumbering. Given that you have to > >> re-authenticate quite often for other reasons as well shouldn't cause > >> big problems. > > Frank=>IMHO, it is not very graceful to kick off all the users > > when renumbering. > Maybe. > > When I look at the IT problems I had this year then renumbering is the > least thing I worry about. > > >> > >> I am just trying to figure out how tough the requirements are. > > Frank=>IMHO, it is very hard to figure out before widely IPv6 > deployment. > > However, it is probably too late after large scale deployment. > > > Difficult to know, I agree. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 08:38:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAAA13A6892; Mon, 28 Jul 2008 08:38:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7943A6892 for ; Mon, 28 Jul 2008 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 0ITPd5dAEwsj for ; Mon, 28 Jul 2008 08:38:11 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 5B8D53A6845 for ; Mon, 28 Jul 2008 08:38:11 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SFbmhS001512; Mon, 28 Jul 2008 11:37:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:37:47 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D4549@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAwmyzsA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:49 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > Since you agreed that the general failure handling for Diameter is out > of scope in the QoS application. In principle, I don't see the necessity > to include extra overhead as the mandatory parameters. Frankly, the > failure handling of the Diameter Server is a quite comprehensive issue. > Sofar, the QoS application should provide some basic failure handling > e.g. clean up the expired sessions, but I am not sure if it is > appropriate to discuss what you address in the QoS application > exclusively. I assume it should be part of base protocol or separate > document (I am not sure if it already has) since they are supposed to > generic to all applications. > > See additional comments inline. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:44 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > Comments/questions below. > > Thanks, > Tolga > > > [.. snip ..] > > > 6- 4.2 Session Establishment > > > "When a QoS-Authz-Request > > > (QAR, see Section 5.1) message with a new session ID is received, > > the > > > AE operates in the Pull mode; when other triggers are received, > the > > > AE operates in the Push mode." > > > Would this shut down the door for certain failure recovery > scenarios? > > > For example AE goes down and a backup AE takes over. IMO it is a > nice > > > feature if the backup can continue existing sessions without a need > to > > > > > synchronizing state with the failed active AE. This can be achieved > by > > > > > carrying enough information about session state in the message > itself > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > > impossible. For certain scenarios backup AE would determine the > > required > > > mode wrong. I suggest the decision for push/pull is not based on > > message > > > name but on the message content. > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > consistent way in terms of state machine to decide the pull/push. > and > > it > > > will work well for the hot standby case, but indeed, it may have > some > > > issue with cold standby. In general, the failure handling is not > > addressed > > > in the draft very much. The question is, do we need to add the > failure > > > > > handling in detail or not for backup server case? > > [TOLGA]I agree that details of failure handling may not belong here. > > OTOH that the QoS application is failover friendly is a parameter to > > consider IMHO. By carrying enough information in each message so that > > cold standby elements can be used to take over existing sessions, one > > trades small amount of bandwidth and limited CPU cycles for complexity > > > in software and probably even more CPU cycles. IMHO this is a bargain. > I > > found this very handy in DCCA. Wouldn't just defining an AVP > indicating > > the type of service requested (push v.s. pull) solve this problem? > > Actually this issue is also tied to Application-Id problem. If > different > > Application-Ids are used, that implicitly will define the mode > > required/used. > > [Dong] I don't think it makes sense to mandate this kind of parameter > > for failover since it is more useful for one type of failure handling > > approach rather than the other. But it is ok to have an optional > > parameter but it does add significant overhead in the message. In > > addition, not sure why the application id is tied up with this issue, > > even in general the routing issue as I explained above. > > I think the failure handling approach should be consistent for all > > Diameter applications rather than defining specific one for QoS > > application. > [TOLGA] > 1) One can argue the other way around as well: Why exclude some piece of > information which is useful for certain type of failover mechanism. IMHO > the added overhead is negligible and I am pretty sure much less than the > overhead of a hot standby system (let alone the extra complexity it > requires) > [Dong] as indicated, this is not my intention to discuss all possible > varieties for failure handover to the standby Diameter server. I assume > a generic mechanism should be applied to QoS application. > > 2) If push/pull modes use different Application-Ids that could be used > easily to decide for which mode the message is received. OTOH I agree > that this itself wouldn't help for failover friendliness. > [Dong] Using different application id for push/pull makes the state > mechanism less efficient and does not add too much value for the routing > since the scenarios you are concerned are not common (i.e. the message > cannot provide a destination address) in reality for QoS application, > IMHO. (sorry for saying this). [TOLGA]IMHO you are introducing unnecessary restrictions for no reason. Diameter message routing is making use of Application-Id for initial requests. If you have a problem with this, you should voice your concerns for the 3588-bis document. Otherwise violating base protocol principles on a per application basis doesn't make sense to me. > > 3) There are certainly a few things which can be done in base protocol > to help failover handling. OTOH base protocol is application state > machine agnostic. I don't see how it can help there. > [Dong] the failover handling you described does not look like a specific > case only for QoS application. In fact the failure of the server does > not affect too much for ongoing bearer sessions since they will remain > anyway. And I am not sure if the NE is the best option to store all > session info due to the cost effectiveness and processing capacity > issues. Maybe the synchronization between two servers is more efficient, > to some extent. [TOLGA]I don't think it is ever possible that base protocol can provide redundancy features to cover for all application redundancy needs without any involvement from application itself. If you have any strategy in mind to deal with this problem please tell it. Actually what I am asking for is to remove a failover-unfriendly feature rather than adding new stuff to facilitate redundancy. I really don't understand what is bad about including an AVP indicating the type. I simply don't buy the overhead argument. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 09:16:19 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5240228C1F1; Mon, 28 Jul 2008 09:16:19 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459D028C1ED for ; Mon, 28 Jul 2008 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 iATZn-LZmf9t for ; Mon, 28 Jul 2008 09:16:14 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id E194328C1EA for ; Mon, 28 Jul 2008 09:16:13 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SGGD0P001296; Mon, 28 Jul 2008 12:16:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:16:12 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Resending..... Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:49 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > Since you agreed that the general failure handling for Diameter is out > of scope in the QoS application. In principle, I don't see the necessity > to include extra overhead as the mandatory parameters. Frankly, the > failure handling of the Diameter Server is a quite comprehensive issue. > Sofar, the QoS application should provide some basic failure handling > e.g. clean up the expired sessions, but I am not sure if it is > appropriate to discuss what you address in the QoS application > exclusively. I assume it should be part of base protocol or separate > document (I am not sure if it already has) since they are supposed to > generic to all applications. > > See additional comments inline. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:44 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > Comments/questions below. > > Thanks, > Tolga > > > [.. snip ..] > > > 6- 4.2 Session Establishment > > > "When a QoS-Authz-Request > > > (QAR, see Section 5.1) message with a new session ID is received, > > the > > > AE operates in the Pull mode; when other triggers are received, > the > > > AE operates in the Push mode." > > > Would this shut down the door for certain failure recovery > scenarios? > > > For example AE goes down and a backup AE takes over. IMO it is a > nice > > > feature if the backup can continue existing sessions without a need > to > > > > > synchronizing state with the failed active AE. This can be achieved > by > > > > > carrying enough information about session state in the message > itself > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > > impossible. For certain scenarios backup AE would determine the > > required > > > mode wrong. I suggest the decision for push/pull is not based on > > message > > > name but on the message content. > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > consistent way in terms of state machine to decide the pull/push. > and > > it > > > will work well for the hot standby case, but indeed, it may have > some > > > issue with cold standby. In general, the failure handling is not > > addressed > > > in the draft very much. The question is, do we need to add the > failure > > > > > handling in detail or not for backup server case? > > [TOLGA]I agree that details of failure handling may not belong here. > > OTOH that the QoS application is failover friendly is a parameter to > > consider IMHO. By carrying enough information in each message so that > > cold standby elements can be used to take over existing sessions, one > > trades small amount of bandwidth and limited CPU cycles for complexity > > > in software and probably even more CPU cycles. IMHO this is a bargain. > I > > found this very handy in DCCA. Wouldn't just defining an AVP > indicating > > the type of service requested (push v.s. pull) solve this problem? > > Actually this issue is also tied to Application-Id problem. If > different > > Application-Ids are used, that implicitly will define the mode > > required/used. > > [Dong] I don't think it makes sense to mandate this kind of parameter > > for failover since it is more useful for one type of failure handling > > approach rather than the other. But it is ok to have an optional > > parameter but it does add significant overhead in the message. In > > addition, not sure why the application id is tied up with this issue, > > even in general the routing issue as I explained above. > > I think the failure handling approach should be consistent for all > > Diameter applications rather than defining specific one for QoS > > application. > [TOLGA] > 1) One can argue the other way around as well: Why exclude some piece of > information which is useful for certain type of failover mechanism. IMHO > the added overhead is negligible and I am pretty sure much less than the > overhead of a hot standby system (let alone the extra complexity it > requires) > [Dong] as indicated, this is not my intention to discuss all possible > varieties for failure handover to the standby Diameter server. I assume > a generic mechanism should be applied to QoS application. > > 2) If push/pull modes use different Application-Ids that could be used > easily to decide for which mode the message is received. OTOH I agree > that this itself wouldn't help for failover friendliness. > [Dong] Using different application id for push/pull makes the state > mechanism less efficient and does not add too much value for the routing > since the scenarios you are concerned are not common (i.e. the message > cannot provide a destination address) in reality for QoS application, > IMHO. (sorry for saying this). [TOLGA]IMHO you are introducing unnecessary restrictions for no reason. Diameter message routing is making use of Application-Id for initial requests. If you have a problem with this, you should voice your concerns for the 3588-bis document. Otherwise violating base protocol principles on a per application basis doesn't make sense to me. > > 3) There are certainly a few things which can be done in base protocol > to help failover handling. OTOH base protocol is application state > machine agnostic. I don't see how it can help there. > [Dong] the failover handling you described does not look like a specific > case only for QoS application. In fact the failure of the server does > not affect too much for ongoing bearer sessions since they will remain > anyway. And I am not sure if the NE is the best option to store all > session info due to the cost effectiveness and processing capacity > issues. Maybe the synchronization between two servers is more efficient, > to some extent. [TOLGA]I don't think it is ever possible that base protocol can provide redundancy features to cover for all application redundancy needs without any involvement from application itself. If you have any strategy in mind to deal with this problem please tell it. Actually what I am asking for is to remove a failover-unfriendly feature rather than adding new stuff to facilitate redundancy. I really don't understand what is bad about including an AVP indicating the type. I simply don't buy the overhead argument. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 09:35:09 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7611E28C1F8; Mon, 28 Jul 2008 09:35:09 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57F428C1F7 for ; Mon, 28 Jul 2008 09:35:08 -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 bNrps6etPvb4 for ; Mon, 28 Jul 2008 09:35:07 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id C126328C1F8 for ; Mon, 28 Jul 2008 09:34:42 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SGYeVf016706; Mon, 28 Jul 2008 12:34:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:34:39 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D456B@sonusmail04.sonusnet.com> In-Reply-To: <00b201c8ee29$bb4e9ba0$7427460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] Thread-Index: AcjuKico8Vb2m3faSxmc1KtfJqdy4ACpZT0A References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <012f01c8ec6e$28e89cf0$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E701205F12@sonusmail04.sonusnet.com> <019301c8ed6e$cb29d140$7427460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E7012060D3@sonusmail04.sonusnet.com> <00b201c8ee29$bb4e9ba0$7427460a@china.huawei.com> From: "Asveren, Tolga" To: "Tina TSOU" , "Sun, Dong (Dong)" Cc: Glen Zorn , McCann Peter-A001034 , Avri Doria , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Tina, inline.... Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Monday, July 28, 2008 11:38 AM > To: Asveren, Tolga > Subject: FW: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > > > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Friday, July 25, 2008 3:41 AM > To: Sun, Dong (Dong); Asveren, Tolga > Cc: Glen Zorn; Avri Doria; McCann Peter-A001034; Tschofenig, Hannes (NSN - > FI/Espoo); dime@ietf.org > Subject: Re: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Dear Tolga, > Comments in line demarked with [Tina: ...] > > B. R. > Tina > ----- Original Message ----- > From: Asveren, Tolga > To: Tina TSOU ; Sun, Dong (Dong) > Cc: dime@ietf.org ; Tschofenig, Hannes (NSN - FI/Espoo) ; McCann Peter- > A001034 ; Avri Doria ; Glen Zorn > Sent: Friday, July 25, 2008 3:09 AM > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > > Hi Tina, > > One more question below. > > Thanks, > Tolga > > > -----Original Message----- > > From: Asveren, Tolga > > Sent: Thursday, July 24, 2008 11:58 AM > > To: Asveren, Tolga > > Subject: FW: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > > > > > > > ________________________________________ > > From: Tina TSOU [mailto:tena@huawei.com] > > Sent: Thursday, July 24, 2008 5:22 AM > > To: Sun, Dong (Dong); Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Glen Zorn > > Subject: Re: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > > > Hi Tolga, > > Good question:-) > > Comments in line beginning with [Tina: ...] > > > > Cheers, > > Tina > > ----- Original Message ----- > > From: Asveren, Tolga > > To: Tina TSOU ; Sun, Dong (Dong) > > Cc: Glen Zorn ; Avri Doria ; McCann Peter-A001034 ; Tschofenig, Hannes > > (NSN - FI/Espoo) ; dime@ietf.org > > Sent: Thursday, July 24, 2008 2:22 AM > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > > > Hi Tina, > > > > One question below. > > > > Thanks, > > Tolga > > > > > > > > [.. snip ..] > > > > > > 2- 3. Framework > > > "After receiving the > > > authorization request from the AppS or the NE, the AE decides the > > > appropriate mode (i.e. Push or Pull). The usage Push or Pull > mode > > > can be determined by the authorizing entity either statically or > > > dynamically." > > > I think I am missing something here. Don't we have always push mode > if > > > the authorization request is received from AppS? Or are we talking > > about > > > a hybrid model where first AppS contacts the Authorizing Entity, > > > receives a token, hands it over to media layer, and this token is > used > > > in turn by NE for pull mode? > > > [Sun, Dong (Dong)] I don't think we are talking about a hybrid > model. > > my > > > understanding is that the push and pull models can be decided by AE > on > > per > > > call session basis (i.e. dynamically), or can be pre-configured for > > one of > > > them (i.e. statically). If this is correct, the texts may be > modified > > as > > > follows for clarity: > > > "The push and pull models can be decided by the AE on per call > > session > > > basis (i.e. dynamically), or can be pre-configured for one of them > > (i.e. > > > statically). Without any pre-configuration, when receiving a new > > > authorization request from the Apps or a local trigger, the AE > starts > > the > > > Push model; when receiving a new authorization request from the NE, > > the AE > > > starts the Pull model." > > > [Sun, Dong (Dong)] Tina, I thought the initial texts come from you. > > could > > > you verify my comment or give some further clafication. are you ok > > with > > > the modified texts? > > > I will update the document accordingly if no objection. > > > [Tina: As is specified in the document, "the diversity of QoS > > capabilities > > > of endpoints and QoS schemes of network technology leads to the > > > distinction > > > on the interaction mode between QoS authorization system and > > underlying > > > NEs". > > > Therefore, I think the hybrid model should be supported. After > > receiving a > > > new authorization request from the AppS, the AE can decide which > mode > > > should > > > be used based on the information of the request, especially based on > > the > > > information which indicates QoS capability and the access network > > type. So > > > I > > > don't see any problem with the original text. > > > However, as is proposed by Hannes, the AVP could be > > added > > > into the QoS-Request message. Besides, I think the > > > > > AVP > > > should also be added to indicate the network technology since the > > network > > > technology is another factor affecting the type of QoS Model being > > used.] > > [TOLGA]I just am trying to understand the use case: > > I understand that endpoints will have different QoS reservation > > capabilities. > > i- I have a device, which can't reserve QoS for the media but can > > indicate its desire to do so in signaling. AppS would determine that > > push mode is desired. > > > > ii- I have a device, which can't reserve QoS for the media and can't > > indicate its desire to do so in signaling. AppS could determine > > statically what to do. > > > > iii- I have a device, which can reserve QoS for the media. It uses its > > own capabilities whenever it needs. > > > > I guess what I am trying to figure out is, why decision process does > not > > belong to AppS? > > > > For , I can see that this type of information > could > > be useful, e.g. a device attached via DOCSIS to IP network v.s. a > device > > attached via a 3GPP technology. OTOH, isn't this information actually > > necessary in AppS so that it can determine whether it should ask for > QoS > > resources? > > [Tina: The AppS belongs to the service layer and in theory it is > unaware > > of the network technology topology and the network technology. The > AppS > > only sends out an authorization request and expects to get a response. > It > > doesn't need to know how the authorization is done, e.g. in Pull mode > or > > Push mode.] > [TOLGA]What you said sounds reasonable but with that model, i.e. AppS > completely unaware of networking technology, would AppS need to ask > authorization for each and every call? As an example let's consider > IMS-mobile. Do we expect AppS to ask for authorization for each call > even for IMS-mobile calls, where actually none of them would have > required push mode of operation? > [Tina: The AppS is aware of the service provided for each call. If the > authorization/QoS is needed for a call, the AppS will send a request to AE > and then get a response from AE. If the authorization/QoS is not needed > for a call, the AppS will not send a request to AE. This has nothing to do > with network topology. Furthermore, this behavior of the AppS has nothing > to do with the push or pull mode. To put it in another way, if an > authorization/QoS is needed for a call, the AppS just sends a request to > the AE, and it doesn't need to predict either the push or pull mode would > be used. Even if all the calls would require the pull mode of operation, I > see no problem that the AppS sends a request for each call, one by one. I > believe you didn't mean there would be a batch request for a group of > calls, since different calls normally have different start and termination > time.] [TOLGA]I think we are almost in agreement. So there is still some choice to be made in AppS based on the QoS needs. In an ideal world, I would expect the terminal to signal its QoS needs so that AppS can perform an intelligent decision here. Contacting AE where it actually wasn't necessary needs to be avoided as much as possible. Otherwise we even could end up with double-booking, i.e. both the terminal and AppS reserve resources for the same stream. BTW, can you explain your proposed semantics for ? _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 09:52:49 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EECD28C21E; Mon, 28 Jul 2008 09:52:49 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A03628C21E for ; Mon, 28 Jul 2008 09:52:48 -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 T1npxwA9bbuV for ; Mon, 28 Jul 2008 09:52:47 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2760A28C1FD for ; Mon, 28 Jul 2008 09:52:45 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m6SGqi0n010484; Mon, 28 Jul 2008 11:52:45 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 11:52:44 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 11:52:43 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAA References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 28 Jul 2008 16:52:44.0763 (UTC) FILETIME=[5B6B82B0:01C8F0D2] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Monday, July 28, 2008 11:12 AM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Hi Dong, Inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:19 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > Application-Id > > Tolga, > Comments inline. > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:13 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / Application-Id > > (Continuing in separate threads for each issue for easier tracking.) > > Hi Dong, > > One comment below. > > Thanks, > Tolga > > [.. snip ..] > > > > > > 1- Use of the same Application-Id for push/pull models It sounds > > > reasonable to me to think nodes which support only a single mode. > How > > > can we guarantee that messages land to the right server considering > > > that the same Application-Id is used for both of them? > > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > > models is > > > different, for example, when a new request from the PEP is recevied, > > the > > > Server will start the pull model. In fact, the push and pull are > > sharing > > > the same state machine per se. the main difference is just how to > > > establish a Diameter session. The enhancement is to allow the > Diameter > > > > > Server to establish a session with a local trigger instead of the > > trigger > > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think the > > same > > > application-Id causes any problem, especially for the pull model > since > > > > > push/pull is able use the same server (certainly they can also have > > > separate server according to the configuration). > > [TOLGA]My concern here is about message routing rather than the state > > machine processing in the server. Let's say a server is capable only > to > > accommodate pull model (it doesn't know what NE to contact if push > model > > is required). How can the network intermediaries, e.g. relay agent, > > forward the initial request in the session to the right server for > push > > model? How can they be sure that the server supports push model? > > [Dong] The relay agent should route the message according to the > > destination address/realm that is filled up by the requestor. I don't > > know how the application id will affect this kind of routing. > [TOLGA]The initial message of a session may have only Destination-Realm. > In such a case Application-Id is used by intermediaries to select the > right server. > [Dong] In the context of QoS application, for the pull mode, the NE > typically is configured by a default policy server or redirect server. I > don't think the scenario you are concerned is a common case in reality > although theoretically the base Diameter protocol may allow this kind of > behavior, but it is not the case for QoS application, IMHO. [TOLGA] How can we make sure that a request requiring push mode capabilities is delivered to the right server? That was my initial question. There could be servers which only have authorization capability but do not have any topology information, i.e. not suitable for push mode operation. And what type of problems would be introduced if we used two different Application-Ids? [Dong] Either Application Server or UE or NE needs to perform the selection of AE according to its capabilities. In the case there are different AEs for push or pull respectively, a rendezvous AE will make a selection according to the policy, network technology and/or request attribute. The problem to have two different application id is to mandate the selection of an AE per its capabilities to the AppS (or NE), it is inconsistent with the basic rationale of the QoS application (i.e. maintain the network neutrality). Moreover, it makes the QoS application and implementations more complex since two packages have to be developed... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 10:02:10 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6734128C236; Mon, 28 Jul 2008 10:02:10 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2CA28C228 for ; Mon, 28 Jul 2008 10:02:09 -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 Huhf09LTd2cf for ; Mon, 28 Jul 2008 10:02:07 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A1EDF28C230 for ; Mon, 28 Jul 2008 10:02:07 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6SH1tjh001262; Mon, 28 Jul 2008 12:02:05 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 12:01:52 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:01:50 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEA26@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D4540@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAh/pZQAAZ6BtAAwqpJgAADjx0Q References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120603A@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E36@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4540@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 28 Jul 2008 17:01:52.0463 (UTC) FILETIME=[A1DFE5F0:01C8F0D3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org See inline... Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Monday, July 28, 2008 11:18 AM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / AE topology aware? Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:31 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > AE topology aware? > > > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:26 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / AE topology aware? > > > Hi Dong, > > One question below. > > Thanks, > Tolga > > [.. snip ..] > > > 3- 3. Framework > > > "For Push mode, the authorizing entity needs to identify the > > > appropriate NE(s) to which QoS authorization information needs to > > be > > > pushed. It might determine this based on information received > from > > > the AppS, such as the IP addresses of media flows." > > > It could be a good idea to give a bit more information about this: > > > - This is hard to do as Authorizing Entity would need to have > > > information about routing decisions of NEs for a particular flow > > > - QoS in the core network is usually not scarce > > > - QoS on the access side is scarce > > > - It is not difficult for the Authorizing Entity to determine NEs > > > facing the access side as usually this information is stored > somewhere > > > > > when the endpoint attaches to the network and does not change per IP > > > > flow. > > > [Sun, Dong (Dong)] my understanding is the NEs for Policy > enforcement > > are > > > usually some anchoring nodes e.g. DSLAM, Gateway, LER etc. the > > discovery > > > of these NEs is not necessarily based on the routing info, instead, > it > > can > > > be preconfigured. > > > In addition, i think this draft mainly focuses on the mechanism and > > > protocol. It can be used for both access and core networks. the QoS > > status > > > you described looks like well known, not sure how much it may add. > > [TOLGA]Even for some of the nodes you mentioned, I would expect > routing > > to play a role here. For example if there are more than one gateway, > AE > > needs to know which one it should contact for that particular stream. > > [Dong] in practice a rendezvous AE or hierarchical AEs will derive the > > > address of the right gateway according to preconfigured info in a > > database or through DNS query. The point is that the NE/PEP is an > > anchoring point for certain streams per provisioning, not random > routing > > for selecting those PEPs (except load balancing). In other words, not > > every NE/router is eligible to serve as the PEP in reality. > [TOLGA] The point I am missing is how does the AE now the NE(s)/PEP(s) > to be used for a particular stream? The list of such entities on the > path for a stream is obviously determined according to some > algorithm/configuration but I am not sure whether AE has the complete > information. Let's take an example: > > +-------+ > | | > +---| AE |-----------+ > | +-------+ | > | | | > | | | > | | | > | | | > | | | > | | +------+ > | | .....| | > +------+ | . | NE2 | > | |........... +------+ > | NE1 |........... > +------+ | . > | . > | . +------+ > +----.----| | > .....| NE3 | > +------+ > > How does the AE know whether NE2 or NE3 will be chosen by NE1 for a > particular flow? > > [Dong] I assume you knew well how to get it in the access network. > You're mainly concerned about the core network case, right? Let's look > at this example: in the core network, each edge router is responsible > for certain access network domains (or in other words, the BRAS/edge > router is configured to route the traffic to a particular edge router in > the core, for the simplicity, assuming NE1 is for 10.1.x.x, NE2 for > 10.2.x.x, NE3 for 10.3.x.x, when the AE receives a request from AF with > the global routable IP address of the end user, it can derive the > targeting NE straightforward. Certainly some additional info e.g > IP-tuple, subscriber id and traffic classifier might be useful to > provide further granularity to allocate the right NE as needed > (dependent on the network configuration and Traffic engineering > approach). [TOLGA]I don't think we can assume that just by destination IP address the full set of NEs to be traversed can be determined without ambiguity. My comment was about difficulties associated with push model if end-to-end reservation is the goal. Just adding a few sentences to indicate that push model is more suitable for access side reservation would be enough. In any case, this wasn't a comment impacting normative sections of the draft so either way is fine for me. [Dong] I think we are repeating the same argument here ;-). If you are seeking a theoretical example which the transport network is totally out of scope for the user traffic control (i.e. no TE, no tunneling, no provisioning), the Push model indeed has some issue. However, in that case, I suspect how/why the PEP is needed. The end-to-end reservation, to me, is a requirement, rather than a methodology. We may achieve this objective through a segment by segment reservation, which the push does work well... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 10:07:06 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9926728C203; Mon, 28 Jul 2008 10:07:06 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC94A28C203 for ; Mon, 28 Jul 2008 10:07:05 -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 nromq8r0xp53 for ; Mon, 28 Jul 2008 10:07:04 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 2306E28C210 for ; Mon, 28 Jul 2008 10:07:04 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6SH6hk7006282; Mon, 28 Jul 2008 12:06:48 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 12:06:43 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:06:42 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/w References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 28 Jul 2008 17:06:43.0730 (UTC) FILETIME=[4F7BB720:01C8F0D4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Inline... Rgs, - Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Monday, July 28, 2008 12:16 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Resending..... Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, July 24, 2008 2:49 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > Since you agreed that the general failure handling for Diameter is out > of scope in the QoS application. In principle, I don't see the necessity > to include extra overhead as the mandatory parameters. Frankly, the > failure handling of the Diameter Server is a quite comprehensive issue. > Sofar, the QoS application should provide some basic failure handling > e.g. clean up the expired sessions, but I am not sure if it is > appropriate to discuss what you address in the QoS application > exclusively. I assume it should be part of base protocol or separate > document (I am not sure if it already has) since they are supposed to > generic to all applications. > > See additional comments inline. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, July 24, 2008 11:44 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > Comments/questions below. > > Thanks, > Tolga > > > [.. snip ..] > > > 6- 4.2 Session Establishment > > > "When a QoS-Authz-Request > > > (QAR, see Section 5.1) message with a new session ID is received, > > the > > > AE operates in the Pull mode; when other triggers are received, > the > > > AE operates in the Push mode." > > > Would this shut down the door for certain failure recovery > scenarios? > > > For example AE goes down and a backup AE takes over. IMO it is a > nice > > > feature if the backup can continue existing sessions without a need > to > > > > > synchronizing state with the failed active AE. This can be achieved > by > > > > > carrying enough information about session state in the message > itself > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > > impossible. For certain scenarios backup AE would determine the > > required > > > mode wrong. I suggest the decision for push/pull is not based on > > message > > > name but on the message content. > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > consistent way in terms of state machine to decide the pull/push. > and > > it > > > will work well for the hot standby case, but indeed, it may have > some > > > issue with cold standby. In general, the failure handling is not > > addressed > > > in the draft very much. The question is, do we need to add the > failure > > > > > handling in detail or not for backup server case? > > [TOLGA]I agree that details of failure handling may not belong here. > > OTOH that the QoS application is failover friendly is a parameter to > > consider IMHO. By carrying enough information in each message so that > > cold standby elements can be used to take over existing sessions, one > > trades small amount of bandwidth and limited CPU cycles for complexity > > > in software and probably even more CPU cycles. IMHO this is a bargain. > I > > found this very handy in DCCA. Wouldn't just defining an AVP > indicating > > the type of service requested (push v.s. pull) solve this problem? > > Actually this issue is also tied to Application-Id problem. If > different > > Application-Ids are used, that implicitly will define the mode > > required/used. > > [Dong] I don't think it makes sense to mandate this kind of parameter > > for failover since it is more useful for one type of failure handling > > approach rather than the other. But it is ok to have an optional > > parameter but it does add significant overhead in the message. In > > addition, not sure why the application id is tied up with this issue, > > even in general the routing issue as I explained above. > > I think the failure handling approach should be consistent for all > > Diameter applications rather than defining specific one for QoS > > application. > [TOLGA] > 1) One can argue the other way around as well: Why exclude some piece of > information which is useful for certain type of failover mechanism. IMHO > the added overhead is negligible and I am pretty sure much less than the > overhead of a hot standby system (let alone the extra complexity it > requires) > [Dong] as indicated, this is not my intention to discuss all possible > varieties for failure handover to the standby Diameter server. I assume > a generic mechanism should be applied to QoS application. > > 2) If push/pull modes use different Application-Ids that could be used > easily to decide for which mode the message is received. OTOH I agree > that this itself wouldn't help for failover friendliness. > [Dong] Using different application id for push/pull makes the state > mechanism less efficient and does not add too much value for the routing > since the scenarios you are concerned are not common (i.e. the message > cannot provide a destination address) in reality for QoS application, > IMHO. (sorry for saying this). [TOLGA]IMHO you are introducing unnecessary restrictions for no reason. Diameter message routing is making use of Application-Id for initial requests. If you have a problem with this, you should voice your concerns for the 3588-bis document. Otherwise violating base protocol principles on a per application basis doesn't make sense to me. > > 3) There are certainly a few things which can be done in base protocol > to help failover handling. OTOH base protocol is application state > machine agnostic. I don't see how it can help there. > [Dong] the failover handling you described does not look like a specific > case only for QoS application. In fact the failure of the server does > not affect too much for ongoing bearer sessions since they will remain > anyway. And I am not sure if the NE is the best option to store all > session info due to the cost effectiveness and processing capacity > issues. Maybe the synchronization between two servers is more efficient, > to some extent. [TOLGA]I don't think it is ever possible that base protocol can provide redundancy features to cover for all application redundancy needs without any involvement from application itself. If you have any strategy in mind to deal with this problem please tell it. Actually what I am asking for is to remove a failover-unfriendly feature rather than adding new stuff to facilitate redundancy. I really don't understand what is bad about including an AVP indicating the type. I simply don't buy the overhead argument. [Dong]I don't think the approach you described is a specific requirement only to the QoS application. Then why don't we generalize the issue and method rather than adding something only to the QoS application. In addition, it is obvious an optional approach for failure handling, and I don't think current draft prevents any implementation from adding the optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 12:57:08 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2F23A69FA; Mon, 28 Jul 2008 12:57:08 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2524228C0DF for ; Mon, 28 Jul 2008 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 dOgI+8Im2K7b for ; Mon, 28 Jul 2008 12:57:05 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 8AD6D3A6B13 for ; Mon, 28 Jul 2008 12:57:05 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SJv0s0021597; Mon, 28 Jul 2008 15:57:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 15:56:59 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, Let's talk over an example because I seriously think we are cross talking each other and there probably are a few things I don't understand about QoS application: Org-1 is the service provider Org-2 is the IP access provider App-push is the application-Id for push mode (if different AppIds used) App-pullthe application-Id for pull mode (if different AppIds used) AppQ is the application-Id for QoS application (if a single AppId is used) +-----+ |AppS | (Org1) +-----+ | +-------+ | (Org2) |AE-gw |--------+ +-------+ | | +-------+ (Org2) | AE1 | +-------+ | | +-------+ (Org2) | NE1 | +-------+ A) With different Application-Ids 1- AppS receives a new session request and determines that QoS needs to be reserved on the access side for a particular flow. It determines (by whatever means) that the access side is controlled by Org2. 2- It sends the initial request with Destination-Realm=Org2 and Application-Id=push. This request reaches AE-gw via standard Diameter Base Protocol routing (during capability exchange procedure AE-gw advertised App-push) [Actually here AppS will need to rely on some provisioning as well as capability advertisement is not done per realm, i.e. it won't be clear to AppS that AE-gw supports push-mode for Org2 realm. This IMHO is a missing piece of functionality in Diameter base protocol but can be fixed relativel easily] 3- AE-gw routes the message to AE based on standard Diameter base protocol routing (during capability exchange procedure AE1 advertised App-push). There could be other AEs in the network which are unable to process this request because they do not know the binding between IP addresses and NEs. This is not a problem though as they would advertise only app-pull during capability exchange procedure) What is here that violates network neutrality? B) With a single Application-Id 1- AppS receives a new session request and determines that QoS needs to be reserved on the access side for a particular flow. It determines (by whatever means) that the access side is controlled by Org2. 2- It sends the initial request with Destination-Realm=Org2 and Application-Id=AppQ. This request reaches AE-gw via standard Diameter Base Protocol routing (during capability exchange procedure AE-gw advertised AppQ). 3- AE-gw needs to route the message based on provisioning. Why? Because it needs to find an AE which can handle push mode. It can't rely on capability advertisement because all types of AEs will advertise support for AppQ. Is my understanding for single Application-Id correct? If so, with single Application-Id model there are more steps relying on provisioning rather than on dynamic capability exchange procedures (and for different Application-Id model we can make routing completely dynamic with some minor extensions to the base protocol) I don't believe two Application-Ids add any significant additional complexity. If a node can support Diameter Base Protocol (capability exchange, connection state machine) and QoS application (application state machine, new AVPs) etc... it is hard for me to believe that two Application-Ids makes development of such nodes more complex. It is likely that we will agree to disagree on this one if my understanding of single Application-Id routing is correct. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 12:53 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > Application-Id > > > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 11:12 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / Application-Id > > Hi Dong, > > Inline.... > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, July 24, 2008 2:19 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > Application-Id > > > > Tolga, > > Comments inline. > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Thursday, July 24, 2008 11:13 AM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / Application-Id > > > > (Continuing in separate threads for each issue for easier tracking.) > > > > Hi Dong, > > > > One comment below. > > > > Thanks, > > Tolga > > > > [.. snip ..] > > > > > > > > 1- Use of the same Application-Id for push/pull models It sounds > > > > reasonable to me to think nodes which support only a single mode. > > How > > > > can we guarantee that messages land to the right server > considering > > > > that the same Application-Id is used for both of them? > > > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > > > models is > > > > different, for example, when a new request from the PEP is > recevied, > > > the > > > > Server will start the pull model. In fact, the push and pull are > > > sharing > > > > the same state machine per se. the main difference is just how to > > > > establish a Diameter session. The enhancement is to allow the > > Diameter > > > > > > > Server to establish a session with a local trigger instead of the > > > trigger > > > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think > the > > > same > > > > application-Id causes any problem, especially for the pull model > > since > > > > > > > push/pull is able use the same server (certainly they can also > have > > > > separate server according to the configuration). > > > [TOLGA]My concern here is about message routing rather than the > state > > > machine processing in the server. Let's say a server is capable only > > to > > > accommodate pull model (it doesn't know what NE to contact if push > > model > > > is required). How can the network intermediaries, e.g. relay agent, > > > forward the initial request in the session to the right server for > > push > > > model? How can they be sure that the server supports push model? > > > [Dong] The relay agent should route the message according to the > > > destination address/realm that is filled up by the requestor. I > don't > > > know how the application id will affect this kind of routing. > > [TOLGA]The initial message of a session may have only > Destination-Realm. > > In such a case Application-Id is used by intermediaries to select the > > right server. > > [Dong] In the context of QoS application, for the pull mode, the NE > > typically is configured by a default policy server or redirect server. > I > > don't think the scenario you are concerned is a common case in reality > > > although theoretically the base Diameter protocol may allow this kind > of > > behavior, but it is not the case for QoS application, IMHO. > [TOLGA] How can we make sure that a request requiring push mode > capabilities is delivered to the right server? That was my initial > question. There could be servers which only have authorization > capability but do not have any topology information, i.e. not suitable > for push mode operation. And what type of problems would be introduced > if we used two different Application-Ids? > [Dong] Either Application Server or UE or NE needs to perform the > selection of AE according to its capabilities. In the case there are > different AEs for push or pull respectively, a rendezvous AE will make a > selection according to the policy, network technology and/or request > attribute. > The problem to have two different application id is to mandate the > selection of an AE per its capabilities to the AppS (or NE), it is > inconsistent with the basic rationale of the QoS application (i.e. > maintain the network neutrality). Moreover, it makes the QoS application > and implementations more complex since two packages have to be > developed... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 13:02:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E093A6B17; Mon, 28 Jul 2008 13:02:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6E928C193 for ; Mon, 28 Jul 2008 13:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 Ma235BA3eabt for ; Mon, 28 Jul 2008 13:02:10 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 75B453A6971 for ; Mon, 28 Jul 2008 13:02:10 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SK2CrX025672; Mon, 28 Jul 2008 16:02:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 16:02:11 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, I am not proposing to add anything special to QoS application but just not relying on the type of first command received to determine the QoS model used. IMHO using an AVP for this purpose is a better approach because using command type brings extra complexity from cold-standby system design perspective. Furthermore it is just overloading the meaning of the command code. I just wanted to summarize the issue. My current understanding is that we agree to disagree on this one. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 1:07 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Inline... > Rgs, - Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 12:16 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Resending..... > > > > > Hi Dong, > > inline.... > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, July 24, 2008 2:49 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Tolga, > > Since you agreed that the general failure handling for Diameter is out > > > of scope in the QoS application. In principle, I don't see the > necessity > > to include extra overhead as the mandatory parameters. Frankly, the > > failure handling of the Diameter Server is a quite comprehensive > issue. > > Sofar, the QoS application should provide some basic failure handling > > e.g. clean up the expired sessions, but I am not sure if it is > > appropriate to discuss what you address in the QoS application > > exclusively. I assume it should be part of base protocol or separate > > document (I am not sure if it already has) since they are supposed to > > generic to all applications. > > > > See additional comments inline. > > > > Rgs, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Thursday, July 24, 2008 11:44 AM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Hi Dong, > > > > Comments/questions below. > > > > Thanks, > > Tolga > > > > > > [.. snip ..] > > > > 6- 4.2 Session Establishment > > > > "When a QoS-Authz-Request > > > > (QAR, see Section 5.1) message with a new session ID is > received, > > > the > > > > AE operates in the Pull mode; when other triggers are received, > > the > > > > AE operates in the Push mode." > > > > Would this shut down the door for certain failure recovery > > scenarios? > > > > For example AE goes down and a backup AE takes over. IMO it is a > > nice > > > > feature if the backup can continue existing sessions without a > need > > to > > > > > > > synchronizing state with the failed active AE. This can be > achieved > > by > > > > > > > carrying enough information about session state in the message > > itself > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > > > > impossible. For certain scenarios backup AE would determine the > > > required > > > > mode wrong. I suggest the decision for push/pull is not based on > > > message > > > > name but on the message content. > > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > > consistent way in terms of state machine to decide the pull/push. > > and > > > it > > > > will work well for the hot standby case, but indeed, it may have > > some > > > > issue with cold standby. In general, the failure handling is not > > > addressed > > > > in the draft very much. The question is, do we need to add the > > failure > > > > > > > handling in detail or not for backup server case? > > > [TOLGA]I agree that details of failure handling may not belong here. > > > OTOH that the QoS application is failover friendly is a parameter to > > > > consider IMHO. By carrying enough information in each message so > that > > > cold standby elements can be used to take over existing sessions, > one > > > trades small amount of bandwidth and limited CPU cycles for > complexity > > > > > in software and probably even more CPU cycles. IMHO this is a > bargain. > > I > > > found this very handy in DCCA. Wouldn't just defining an AVP > > indicating > > > the type of service requested (push v.s. pull) solve this problem? > > > Actually this issue is also tied to Application-Id problem. If > > different > > > Application-Ids are used, that implicitly will define the mode > > > required/used. > > > [Dong] I don't think it makes sense to mandate this kind of > parameter > > > for failover since it is more useful for one type of failure > handling > > > approach rather than the other. But it is ok to have an optional > > > parameter but it does add significant overhead in the message. In > > > addition, not sure why the application id is tied up with this > issue, > > > even in general the routing issue as I explained above. > > > I think the failure handling approach should be consistent for all > > > Diameter applications rather than defining specific one for QoS > > > application. > > [TOLGA] > > 1) One can argue the other way around as well: Why exclude some piece > of > > information which is useful for certain type of failover mechanism. > IMHO > > the added overhead is negligible and I am pretty sure much less than > the > > overhead of a hot standby system (let alone the extra complexity it > > requires) > > [Dong] as indicated, this is not my intention to discuss all possible > > varieties for failure handover to the standby Diameter server. I > assume > > a generic mechanism should be applied to QoS application. > > > > 2) If push/pull modes use different Application-Ids that could be used > > > easily to decide for which mode the message is received. OTOH I agree > > that this itself wouldn't help for failover friendliness. > > [Dong] Using different application id for push/pull makes the state > > mechanism less efficient and does not add too much value for the > routing > > since the scenarios you are concerned are not common (i.e. the message > > > cannot provide a destination address) in reality for QoS application, > > IMHO. (sorry for saying this). > [TOLGA]IMHO you are introducing unnecessary restrictions for no reason. > Diameter message routing is making use of Application-Id for initial > requests. If you have a problem with this, you should voice your > concerns for the 3588-bis document. Otherwise violating base protocol > principles on a per application basis doesn't make sense to me. > > > > > > > 3) There are certainly a few things which can be done in base protocol > > > to help failover handling. OTOH base protocol is application state > > machine agnostic. I don't see how it can help there. > > [Dong] the failover handling you described does not look like a > specific > > case only for QoS application. In fact the failure of the server does > > not affect too much for ongoing bearer sessions since they will remain > > > anyway. And I am not sure if the NE is the best option to store all > > session info due to the cost effectiveness and processing capacity > > issues. Maybe the synchronization between two servers is more > efficient, > > to some extent. > [TOLGA]I don't think it is ever possible that base protocol can provide > redundancy features to cover for all application redundancy needs > without any involvement from application itself. If you have any > strategy in mind to deal with this problem please tell it. > Actually what I am asking for is to remove a failover-unfriendly feature > rather than adding new stuff to facilitate redundancy. I really don't > understand what is bad about including an AVP indicating the type. I > simply don't buy the overhead argument. > [Dong]I don't think the approach you described is a specific requirement > only to the QoS application. Then why don't we generalize the issue and > method rather than adding something only to the QoS application. In > addition, it is obvious an optional approach for failure handling, and I > don't think current draft prevents any implementation from adding the > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 13:07:16 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC793A6AF2; Mon, 28 Jul 2008 13:07:15 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 599323A6ADE for ; Mon, 28 Jul 2008 13:07:13 -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 Dz5T-OTC+gDI for ; Mon, 28 Jul 2008 13:07:08 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id C835A28C1A6 for ; Mon, 28 Jul 2008 13:07:07 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6SK7IuU030095 for ; Mon, 28 Jul 2008 16:07:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 16:07:17 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C7@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments for draft-fajardo-dime-app-design-guide-02 Thread-Index: Acjw7YjStKteo9ySRC6BxaiSo240Ig== From: "Asveren, Tolga" To: Subject: [Dime] comments for draft-fajardo-dime-app-design-guide-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org 1) 4.1 "The rules are strict in the case where the AVP(s) to be added is mandatory to be understood and interpreted. This means that the M-bit is set and the AVP(s) is required to exist in command ABNF." I think we finally have a consensus that M-bit and ABNF are two different animals (at least theoretically) and it is M-bit which mandates that receiver has to understand the AVP. So, I would think the last sentence of the quoted text should say "This means that the M-bit is set." 2) 5.1 Split Accounting Model I guess we discussed this but my memory is blur about the outcome: This model seems to have a problem about advertising accounting capability. There is no way that an accounting server can indicate the type of applications for which it can support accounting. So, unless it is known that the accounting server can handle accounting for all types of applications, which use split model, in the network there could be problems with message routing. I guess "The overall system architecture permits the use of centralized accounting for one or more Diameter applications." is added to warn about this but I am not sure whether it is clear enough. 3) There are references to a few expired drafts: [8] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. [9] Asveren, T., "Diameter Duplicate Detection Cons.", draft-asveren-dime-dupcons-00 (work in progress), August 2006. I am not sure whether these will see the daylight again. 4) 5.9 "For general AAA applications, Diameter requires more message exchanges for the same set of services compared to RADIUS. Therefore, application designers should consider scalability issues during the design process." What does this exactly refer to? I will check the extensibility wiki as well and probably have another pass on the design-guidelines draft afterwards. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 17:02:42 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5879B3A6B3F; Mon, 28 Jul 2008 17:02:42 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565213A6B3F for ; Mon, 28 Jul 2008 17:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnYDKqAo6AZv for ; Mon, 28 Jul 2008 17:02:40 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id EE4CF3A688E for ; Mon, 28 Jul 2008 17:02:39 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m6T02YMD007015; Mon, 28 Jul 2008 19:02:36 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 19:02:34 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 19:02:32 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 29 Jul 2008 00:02:34.0320 (UTC) FILETIME=[67319D00:01C8F10E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, The scenario A) mandates the application SP being aware of underlying network technology and operation mode (i.e. push or pull) and making a selection, which is not the intention of QoS application (and net neutrality). And I don't think the content provider (let's say youtube) really cares about which mode is used for the QoS guarantee in the transport network. If you still have question, please give me a call. We can chat about it in detail. Regards, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Monday, July 28, 2008 3:57 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / Application-Id Hi Dong, Let's talk over an example because I seriously think we are cross talking each other and there probably are a few things I don't understand about QoS application: Org-1 is the service provider Org-2 is the IP access provider App-push is the application-Id for push mode (if different AppIds used) App-pullthe application-Id for pull mode (if different AppIds used) AppQ is the application-Id for QoS application (if a single AppId is used) +-----+ |AppS | (Org1) +-----+ | +-------+ | (Org2) |AE-gw |--------+ +-------+ | | +-------+ (Org2) | AE1 | +-------+ | | +-------+ (Org2) | NE1 | +-------+ A) With different Application-Ids 1- AppS receives a new session request and determines that QoS needs to be reserved on the access side for a particular flow. It determines (by whatever means) that the access side is controlled by Org2. 2- It sends the initial request with Destination-Realm=Org2 and Application-Id=push. This request reaches AE-gw via standard Diameter Base Protocol routing (during capability exchange procedure AE-gw advertised App-push) [Actually here AppS will need to rely on some provisioning as well as capability advertisement is not done per realm, i.e. it won't be clear to AppS that AE-gw supports push-mode for Org2 realm. This IMHO is a missing piece of functionality in Diameter base protocol but can be fixed relativel easily] 3- AE-gw routes the message to AE based on standard Diameter base protocol routing (during capability exchange procedure AE1 advertised App-push). There could be other AEs in the network which are unable to process this request because they do not know the binding between IP addresses and NEs. This is not a problem though as they would advertise only app-pull during capability exchange procedure) What is here that violates network neutrality? B) With a single Application-Id 1- AppS receives a new session request and determines that QoS needs to be reserved on the access side for a particular flow. It determines (by whatever means) that the access side is controlled by Org2. 2- It sends the initial request with Destination-Realm=Org2 and Application-Id=AppQ. This request reaches AE-gw via standard Diameter Base Protocol routing (during capability exchange procedure AE-gw advertised AppQ). 3- AE-gw needs to route the message based on provisioning. Why? Because it needs to find an AE which can handle push mode. It can't rely on capability advertisement because all types of AEs will advertise support for AppQ. Is my understanding for single Application-Id correct? If so, with single Application-Id model there are more steps relying on provisioning rather than on dynamic capability exchange procedures (and for different Application-Id model we can make routing completely dynamic with some minor extensions to the base protocol) I don't believe two Application-Ids add any significant additional complexity. If a node can support Diameter Base Protocol (capability exchange, connection state machine) and QoS application (application state machine, new AVPs) etc... it is hard for me to believe that two Application-Ids makes development of such nodes more complex. It is likely that we will agree to disagree on this one if my understanding of single Application-Id routing is correct. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 12:53 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > Application-Id > > > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 11:12 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / Application-Id > > Hi Dong, > > Inline.... > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, July 24, 2008 2:19 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > Application-Id > > > > Tolga, > > Comments inline. > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Thursday, July 24, 2008 11:13 AM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / Application-Id > > > > (Continuing in separate threads for each issue for easier tracking.) > > > > Hi Dong, > > > > One comment below. > > > > Thanks, > > Tolga > > > > [.. snip ..] > > > > > > > > 1- Use of the same Application-Id for push/pull models It sounds > > > > reasonable to me to think nodes which support only a single mode. > > How > > > > can we guarantee that messages land to the right server > considering > > > > that the same Application-Id is used for both of them? > > > > [Sun, Dong (Dong)] The trigger for initiating the push and pull > > > models is > > > > different, for example, when a new request from the PEP is > recevied, > > > the > > > > Server will start the pull model. In fact, the push and pull are > > > sharing > > > > the same state machine per se. the main difference is just how to > > > > establish a Diameter session. The enhancement is to allow the > > Diameter > > > > > > > Server to establish a session with a local trigger instead of the > > > trigger > > > > from the Diameter client (i.e. NE/PEP). Therefore, I don't think > the > > > same > > > > application-Id causes any problem, especially for the pull model > > since > > > > > > > push/pull is able use the same server (certainly they can also > have > > > > separate server according to the configuration). > > > [TOLGA]My concern here is about message routing rather than the > state > > > machine processing in the server. Let's say a server is capable only > > to > > > accommodate pull model (it doesn't know what NE to contact if push > > model > > > is required). How can the network intermediaries, e.g. relay agent, > > > forward the initial request in the session to the right server for > > push > > > model? How can they be sure that the server supports push model? > > > [Dong] The relay agent should route the message according to the > > > destination address/realm that is filled up by the requestor. I > don't > > > know how the application id will affect this kind of routing. > > [TOLGA]The initial message of a session may have only > Destination-Realm. > > In such a case Application-Id is used by intermediaries to select the > > right server. > > [Dong] In the context of QoS application, for the pull mode, the NE > > typically is configured by a default policy server or redirect server. > I > > don't think the scenario you are concerned is a common case in reality > > > although theoretically the base Diameter protocol may allow this kind > of > > behavior, but it is not the case for QoS application, IMHO. > [TOLGA] How can we make sure that a request requiring push mode > capabilities is delivered to the right server? That was my initial > question. There could be servers which only have authorization > capability but do not have any topology information, i.e. not suitable > for push mode operation. And what type of problems would be introduced > if we used two different Application-Ids? > [Dong] Either Application Server or UE or NE needs to perform the > selection of AE according to its capabilities. In the case there are > different AEs for push or pull respectively, a rendezvous AE will make a > selection according to the policy, network technology and/or request > attribute. > The problem to have two different application id is to mandate the > selection of an AE per its capabilities to the AppS (or NE), it is > inconsistent with the basic rationale of the QoS application (i.e. > maintain the network neutrality). Moreover, it makes the QoS application > and implementations more complex since two packages have to be > developed... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Jul 28 17:46:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E4A3A6AFC; Mon, 28 Jul 2008 17:46:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5054728C13B for ; Mon, 28 Jul 2008 17:46: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 X3XK+qJMEfEg for ; Mon, 28 Jul 2008 17:45:48 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 6088C3A6AFC for ; Mon, 28 Jul 2008 17:45:41 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m6T0jhi7014613; Mon, 28 Jul 2008 19:45:44 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Jul 2008 19:45:43 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 19:45:41 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SAACJCP4A== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 29 Jul 2008 00:45:43.0504 (UTC) FILETIME=[6E77BD00:01C8F114] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, Before we move further on the failure handover issue, I'd like to clarify a basic question (I need some education from the Diameter experts): in 3588 and 4005, how a new session is recogizied by the Diameter Server? It seems no one uses the explicit indicator for identifying a new session, if my understanding is correct. Furthermore, if we rely on the Diameter client for the indication of new session, it may cause the problem when the client recovers from the failure, e.g. it may think the recovered session as a new session. As I indicated, the QoS application is intended to keep consistent with the base protocol and the "mom" protocol 4005. In fact, besides the session-id, the QoS application also looks at the QoS resources and other AVPs to decide the transition of the session state. I just like to highligh my point: how to handle failover is a general issue, I don't think the QoS application requires any extra mechanism compared to any other applications. So I'd like to adapt a generic mechanism already used by other applications if possible, rather than creating an "unique" mechanism here. Regards, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Monday, July 28, 2008 4:02 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Hi Dong, I am not proposing to add anything special to QoS application but just not relying on the type of first command received to determine the QoS model used. IMHO using an AVP for this purpose is a better approach because using command type brings extra complexity from cold-standby system design perspective. Furthermore it is just overloading the meaning of the command code. I just wanted to summarize the issue. My current understanding is that we agree to disagree on this one. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 1:07 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Inline... > Rgs, - Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 12:16 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Resending..... > > > > > Hi Dong, > > inline.... > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, July 24, 2008 2:49 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Tolga, > > Since you agreed that the general failure handling for Diameter is out > > > of scope in the QoS application. In principle, I don't see the > necessity > > to include extra overhead as the mandatory parameters. Frankly, the > > failure handling of the Diameter Server is a quite comprehensive > issue. > > Sofar, the QoS application should provide some basic failure handling > > e.g. clean up the expired sessions, but I am not sure if it is > > appropriate to discuss what you address in the QoS application > > exclusively. I assume it should be part of base protocol or separate > > document (I am not sure if it already has) since they are supposed to > > generic to all applications. > > > > See additional comments inline. > > > > Rgs, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Thursday, July 24, 2008 11:44 AM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Hi Dong, > > > > Comments/questions below. > > > > Thanks, > > Tolga > > > > > > [.. snip ..] > > > > 6- 4.2 Session Establishment > > > > "When a QoS-Authz-Request > > > > (QAR, see Section 5.1) message with a new session ID is > received, > > > the > > > > AE operates in the Pull mode; when other triggers are received, > > the > > > > AE operates in the Push mode." > > > > Would this shut down the door for certain failure recovery > > scenarios? > > > > For example AE goes down and a backup AE takes over. IMO it is a > > nice > > > > feature if the backup can continue existing sessions without a > need > > to > > > > > > > synchronizing state with the failed active AE. This can be > achieved > > by > > > > > > > carrying enough information about session state in the message > > itself > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes this > > > > > impossible. For certain scenarios backup AE would determine the > > > required > > > > mode wrong. I suggest the decision for push/pull is not based on > > > message > > > > name but on the message content. > > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > > consistent way in terms of state machine to decide the pull/push. > > and > > > it > > > > will work well for the hot standby case, but indeed, it may have > > some > > > > issue with cold standby. In general, the failure handling is not > > > addressed > > > > in the draft very much. The question is, do we need to add the > > failure > > > > > > > handling in detail or not for backup server case? > > > [TOLGA]I agree that details of failure handling may not belong here. > > > OTOH that the QoS application is failover friendly is a parameter to > > > > consider IMHO. By carrying enough information in each message so > that > > > cold standby elements can be used to take over existing sessions, > one > > > trades small amount of bandwidth and limited CPU cycles for > complexity > > > > > in software and probably even more CPU cycles. IMHO this is a > bargain. > > I > > > found this very handy in DCCA. Wouldn't just defining an AVP > > indicating > > > the type of service requested (push v.s. pull) solve this problem? > > > Actually this issue is also tied to Application-Id problem. If > > different > > > Application-Ids are used, that implicitly will define the mode > > > required/used. > > > [Dong] I don't think it makes sense to mandate this kind of > parameter > > > for failover since it is more useful for one type of failure > handling > > > approach rather than the other. But it is ok to have an optional > > > parameter but it does add significant overhead in the message. In > > > addition, not sure why the application id is tied up with this > issue, > > > even in general the routing issue as I explained above. > > > I think the failure handling approach should be consistent for all > > > Diameter applications rather than defining specific one for QoS > > > application. > > [TOLGA] > > 1) One can argue the other way around as well: Why exclude some piece > of > > information which is useful for certain type of failover mechanism. > IMHO > > the added overhead is negligible and I am pretty sure much less than > the > > overhead of a hot standby system (let alone the extra complexity it > > requires) > > [Dong] as indicated, this is not my intention to discuss all possible > > varieties for failure handover to the standby Diameter server. I > assume > > a generic mechanism should be applied to QoS application. > > > > 2) If push/pull modes use different Application-Ids that could be used > > > easily to decide for which mode the message is received. OTOH I agree > > that this itself wouldn't help for failover friendliness. > > [Dong] Using different application id for push/pull makes the state > > mechanism less efficient and does not add too much value for the > routing > > since the scenarios you are concerned are not common (i.e. the message > > > cannot provide a destination address) in reality for QoS application, > > IMHO. (sorry for saying this). > [TOLGA]IMHO you are introducing unnecessary restrictions for no reason. > Diameter message routing is making use of Application-Id for initial > requests. If you have a problem with this, you should voice your > concerns for the 3588-bis document. Otherwise violating base protocol > principles on a per application basis doesn't make sense to me. > > > > > > > 3) There are certainly a few things which can be done in base protocol > > > to help failover handling. OTOH base protocol is application state > > machine agnostic. I don't see how it can help there. > > [Dong] the failover handling you described does not look like a > specific > > case only for QoS application. In fact the failure of the server does > > not affect too much for ongoing bearer sessions since they will remain > > > anyway. And I am not sure if the NE is the best option to store all > > session info due to the cost effectiveness and processing capacity > > issues. Maybe the synchronization between two servers is more > efficient, > > to some extent. > [TOLGA]I don't think it is ever possible that base protocol can provide > redundancy features to cover for all application redundancy needs > without any involvement from application itself. If you have any > strategy in mind to deal with this problem please tell it. > Actually what I am asking for is to remove a failover-unfriendly feature > rather than adding new stuff to facilitate redundancy. I really don't > understand what is bad about including an AVP indicating the type. I > simply don't buy the overhead argument. > [Dong]I don't think the approach you described is a specific requirement > only to the QoS application. Then why don't we generalize the issue and > method rather than adding something only to the QoS application. In > addition, it is obvious an optional approach for failure handling, and I > don't think current draft prevents any implementation from adding the > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 00:53:51 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14B53A6AB3; Tue, 29 Jul 2008 00:53:51 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E293A6AB3 for ; Tue, 29 Jul 2008 00:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[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 y3l6ljuk1U2s for ; Tue, 29 Jul 2008 00:53:49 -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 CA6A83A692C for ; Tue, 29 Jul 2008 00:53:48 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id m6T7rwaw025079 for ; Tue, 29 Jul 2008 16:53:58 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m6T7rwI6023903 for ; Tue, 29 Jul 2008 16:53:58 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m6T7rwKW023898 for ; Tue, 29 Jul 2008 16:53:58 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 2412E4418 for ; Tue, 29 Jul 2008 16:53:58 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail1.nict.go.jp (Postfix) with ESMTP id 04279440E for ; Tue, 29 Jul 2008 16:53:57 +0900 (JST) Message-ID: <488ECC7B.8090203@nict.go.jp> Date: Tue, 29 Jul 2008 16:53:31 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.95.6 OpenPGP: id=33D9F61D Subject: [Dime] Security mechanism in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello, I have a question regarding the Inband-Security-Id AVP in the CER/CEA exchange. I think draft-ietf-dime-rfc3588bis-11 is lacking information on the meaning of this AVP when several instances are found in a CER or CEA message, as allowed by the ABNF. For example, if peer A is connecting to peer B, and is able use IPsec and TLS to protect the connection to this peer, should it send a CER with two Inband-Security-Id AVPs, one with value 0 and one with value 1? In that case, if peer B is also able to support both mechanism, what should happen? Thank you for any clarification... 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 dime-bounces@ietf.org Tue Jul 29 01:36:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0063A697F; Tue, 29 Jul 2008 01:36:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300DB28C1A9 for ; Tue, 29 Jul 2008 01:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP9kyroHBrPj for ; Tue, 29 Jul 2008 01:32:30 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by core3.amsl.com (Postfix) with ESMTP id 74DFD28C1B7 for ; Tue, 29 Jul 2008 01:32:30 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so5275139wra.17 for ; Tue, 29 Jul 2008 01:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=sxQhHUexvRZwn2hzb3JXtp1ADTan9Tn/XbCKfVqc7js=; b=ph2e+qCt1gROQ9JO41140Wdd4wvtE1qlQEjx0PNjgUc9AyKjzJrdlZWxFE4R9VpSnq +UQlI/fzFsz6vla5SAz1h+gbDbHmiTN18gwov2uN+35NsU7PKP9mhqw0GnE2J+WMvO8y i69V7Is+5SzOGEARYc8YEFD1Pf8z0Piu4+RvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=LdZnyhcGzbVOYfjxzRPb49PXdXKvI8Kul9wCr8I3folC3o1+ya/MGxXj5c/uDHSbKB ATMJdDrLnzDPFv8PhlBmyAl3s2Zox4Wcs3ySYkhepPwAyYjfA2fNL+8CxmiqxWPQG0md gQNGxMXfwhaq+EcQJuDkTwR2iLem7vNrf/Oig= Received: by 10.90.55.9 with SMTP id d9mr8401258aga.40.1217320360721; Tue, 29 Jul 2008 01:32:40 -0700 (PDT) Received: by 10.90.65.17 with HTTP; Tue, 29 Jul 2008 01:32:40 -0700 (PDT) Message-ID: <9cf5ced20807290132x250654c4k3c1e6e1cd1f25541@mail.gmail.com> Date: Tue, 29 Jul 2008 04:32:40 -0400 From: "David Frascone" To: dime@ietf.org In-Reply-To: <488D8BEB.4010604@gmx.net> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E701205FEB@sonusmail04.sonusnet.com> <488CEE37.3050705@tari.toshiba.com> <488D8BEB.4010604@gmx.net> X-Google-Sender-Auth: 2e4248490f5abb1d Subject: [Dime] Fwd: Please take a look at the Diameter Guidelines draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1492040113==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============1492040113== Content-Type: multipart/alternative; boundary="----=_Part_41243_16540540.1217320360704" ------=_Part_41243_16540540.1217320360704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Some discussion has gone on editing / reviewing the diameter guidelines draft. Please review the following thread. -Dave Forwarded conversation Subject: Please take a look at the Diameter Guidelines draft ------------------------ From: *Tschofenig, Hannes (NSN - FI/Espoo)* Date: Mon, Jul 21, 2008 at 7:14 AM To: diameter-extensibility@googlegroups.com http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-07. txt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Diameter Extensibility Design Team" group. To post to this group, send email to diameter-extensibility@googlegroups.com To unsubscribe from this group, send email to diameter-extensibility-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/diameter-extensibility?hl=en -~----------~----~----~----~------~----~------~--~--- ---------- From: *David Frascone* Date: Mon, Jul 21, 2008 at 5:18 PM To: diameter-extensibility@googlegroups.com Some nits: In the abstract, "a guidelines" should be "a guideline" Introduction, 2nd paragraph, Decisions are "made", not "done". Section 4, 2nd sentence, There is a 1 or an l after the period. Section 4, last sentence: The meaning is clear, but the sentence is a bad run on. I suggest something like the following to replace it: Thelatter case would result in a new application but it has a more subtle issues, like deciding whether importing of commands and functionality is really better than simply using the existing application. Section 5, paragraph 1, two sentences start with "In general," The second should be removed. Section 6.1, the text for the Optional AVP's bullet is not in the bullet. Also, in the new bullet list under the paragraph, one of the bullets is missing a newline. Section 6.1, I'd replace "When one of the above questions can be answered with 'yes' then the M-bit has to be set." with "If any of the above questions can be answered 'yes', then the M-bit must be set" Section 6.1 The bullets under the above mentioned sentence change do not have a clear meaning. I think this might be due to poor indenting. I think the intent might have been two nesting levels, but that is not shown in the text. Because of that, the bullets are very out of place, and I'm not sure what they are referring to. Section 6.1: Last sentence, remove "as much as possible" That is in indication that it is ok to break the rules. I think the "should be avoided" is enough. It's a should, not a must. Section 6.2: 1st sentence: "Is significant" -- I'm not sure what this sentence is trying to say. What is significant? Section 6.2: bad line formatting in all of the cases. Section 7: Mandatory characteristics "are tied", not "is tied" Section 8, first sentence: How do you maintain an AVP value? Section 8.2: statemachine is two words, no? Also, statemachines *are* not intended for, (not is) Also, the last sentence isn't really clear. It uses the word "example" twice, which is confusing. Section 9, last sentance needs a newline before it. Section 11: Don't use contractions ;) -- get rid of the 'it's' (it is) Seciton 11: Same paragraph, "it is should be suficient" does not pass my parser. ---------- From: *Asveren, Tolga* Date: Thu, Jul 24, 2008 at 9:35 AM To: diameter-extensibility@googlegroups.com 1) 4.1 "The rules are strict in the case where the AVP(s) to be added is mandatory to be understood and interpreted. This means that the M-bit is set and the AVP(s) is required to exist in command ABNF." I think we finally have a consensus that M-bit and ABNF are two different animals (at least theoretically) and it is M-bit which mandates that receiver has to understand the AVP. So, I would think the last sentence of the quoted text should say "This means that the M-bit is set." 2) 5.1 Split Accounting Model I guess we discussed this but my memory is blur about the outcome: This model seems to have a problem about advertising accounting capability. There is no way that an accounting server can indicate the type of applications for which it can support accounting. So, unless it is known that the accounting server can handle accounting for all types of applications, which use split model, in the network there could be problems with message routing. I guess "The overall system architecture permits the use of centralized accounting for one or more Diameter applications." is added to warn about this but I am not sure whether it is clear enough. 3) There are references to a few expired drafts: [8] Calhoun, P., "Diameter Resource Management Extensions", draft-calhoun-diameter-res-mgmt-08.txt (work in progress), March 2001. [9] Asveren, T., "Diameter Duplicate Detection Cons.", draft-asveren-dime-dupcons-00 (work in progress), August 2006. I am not sure whether these will see the daylight again. 4) 5.9 "For general AAA applications, Diameter requires more message exchanges for the same set of services compared to RADIUS. Therefore, application designers should consider scalability issues during the design process." What does this exactly refer to? I will check the extensibility wiki as well and probably have another pass on the design-guidelines draft afterwards. Thanks, Tolga ---------- From: *Victor Fajardo* Date: Sun, Jul 27, 2008 at 5:52 PM To: diameter-extensibility@googlegroups.com Hi Tolga, Ok. This should be cleaned up. I agree that the sentence is too vague. Since the bis describes these models a little clearer, do you think we should trim down this section in the app guide simply enumerate possible problems for each one ? Ok. I can't remember exactly but it may have to do with capabilities exchanges. This maybe another text we can trim down. -- victor ---------- From: *Hannes Tschofenig* Date: Mon, Jul 28, 2008 at 5:05 AM To: diameter-extensibility@googlegroups.com Can you guys replay these mails to the DIME mailing list? We need to have a discussion on the list. ------=_Part_41243_16540540.1217320360704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Some discussion has gone on editing / reviewing the diameter guidelines draft.  Please review the following thread.

-Dave

Forwarded conversation
Subject: Please take a look at the Diameter Guidelines draft
------------------------

From: Tschofenig, Hannes (NSN - FI/Espoo) <hannes.tschofenig@nsn.com>
Date: Mon, Jul 21, 2008 at 7:14 AM
To: diameter-extensibility@googlegroups.com



http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-07.
txt

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Diameter Extensibility Design Team" group.
To post to this group, send email to diameter-extensibility@googlegroups.com
To unsubscribe from this group, send email to diameter-extensibility-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/diameter-extensibility?hl=en
-~----------~----~----~----~------~----~------~--~---


----------
From: David Frascone <dave@frascone.com>
Date: Mon, Jul 21, 2008 at 5:18 PM
To: diameter-extensibility@googlegroups.com


Some nits:

In the abstract, "a guidelines" should be "a guideline"

Introduction, 2nd paragraph, Decisions are "made", not "done".

Section 4, 2nd sentence, There is a 1 or an l after the period.

Section 4, last sentence:  The meaning is clear, but the sentence is a bad run on.  I suggest something like the following to replace it: 
   Thelatter case would result in a new application but it has a more



   subtle issues, like deciding whether importing of commands and
   functionality is really better than simply using the existing
   application.
Section 5, paragraph 1, two sentences start with "In general,"  The second should be removed.

Section 6.1, the text for the Optional AVP's bullet is not in the bullet.  Also, in the new bullet list under the paragraph,  one of the bullets is missing a newline.

Section 6.1, I'd replace "When one of the above questions can be answered with 'yes' then the M-bit has to be set." with "If any of the above questions can be answered 'yes', then the M-bit must be set"

Section 6.1 The bullets under the above mentioned sentence change do not have a clear meaning.  I think this might be due to poor indenting.  I think the intent might have been two nesting levels, but that is not shown in the text.  Because of that, the bullets are very out of place, and I'm not sure what they are referring to.

Section 6.1: Last sentence, remove "as much as possible"  That is in indication that it is ok to break the rules.  I think the "should be avoided" is enough.  It's a should, not a must.

Section 6.2: 1st sentence:  "Is significant" -- I'm not sure what this sentence is trying to say.  What is significant?

Section 6.2: bad line formatting in all of the cases.

Section 7: Mandatory characteristics "are tied", not "is tied"

Section 8, first sentence:  How do you maintain an AVP value?

Section 8.2: statemachine is two words, no?  Also, statemachines *are* not intended for, (not is)  Also, the last sentence isn't really clear.  It uses the word "example" twice, which is confusing.

Section 9, last sentance needs a newline before it.

Section 11:  Don't use contractions ;) -- get rid of the 'it's' (it is)
Seciton 11: Same paragraph, "it is should be suficient" does not pass my parser.

----------
From: Asveren, Tolga <tasveren@sonusnet.com>
Date: Thu, Jul 24, 2008 at 9:35 AM
To: diameter-extensibility@googlegroups.com



1) 4.1
"The rules are strict in the case where the AVP(s) to be added is
 mandatory to be understood and interpreted.  This means that the
 M-bit is set and the AVP(s) is required to exist in command ABNF."

I think we finally have a consensus that M-bit and ABNF are two
different animals (at least theoretically) and it is M-bit which
mandates that receiver has to understand the AVP. So, I would think the
last sentence of the quoted text should say "This means that the M-bit
is set."

2) 5.1
Split Accounting Model

I guess we discussed this but my memory is blur about the outcome:
This model seems to have a problem about advertising accounting
capability. There is no way that an accounting server can indicate the
type of applications for which it can support accounting. So, unless it
is known that the accounting server can handle accounting for all types
of applications, which use split model, in the network there could be
problems with message routing. I guess
"The overall system architecture permits the use of centralized
 accounting for one or more Diameter applications."
is added to warn about this but I am not sure whether it is clear
enough.

3) There are references to a few expired drafts:
[8]  Calhoun, P., "Diameter Resource Management Extensions",
       draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
       March 2001.

  [9]  Asveren, T., "Diameter Duplicate Detection Cons.",
       draft-asveren-dime-dupcons-00 (work in progress), August 2006.

I am not sure whether these will see the daylight again.



4) 5.9
"For general AAA applications, Diameter requires more message
 exchanges for the same set of services compared to RADIUS.
 Therefore, application designers should consider scalability
 issues during the design process."
What does this exactly refer to?



I will check the extensibility wiki as well and probably have another
pass on the design-guidelines draft afterwards.


Thanks,
Tolga

----------
From: Victor Fajardo <vfajardo@tari.toshiba.com>
Date: Sun, Jul 27, 2008 at 5:52 PM
To: diameter-extensibility@googlegroups.com



Hi Tolga,
Ok. This should be cleaned up.
I agree that the sentence is too vague. Since the bis describes these
models a little clearer, do you think we should trim down this section
in the app guide simply enumerate possible problems for each one ?
Ok.
I can't remember exactly but it may have to do with capabilities
exchanges. This maybe another text we can trim down.

-- victor

----------
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Date: Mon, Jul 28, 2008 at 5:05 AM
To: diameter-extensibility@googlegroups.com



Can you guys replay these mails to the DIME mailing list?
We need to have a discussion on the list.


------=_Part_41243_16540540.1217320360704-- --===============1492040113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============1492040113==-- From dime-bounces@ietf.org Tue Jul 29 04:42:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA2528C112; Tue, 29 Jul 2008 04:42:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5EC28C116 for ; Tue, 29 Jul 2008 04:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuPdqhF4otRO for ; Tue, 29 Jul 2008 04:42:43 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id ED9A53A6A6D for ; Tue, 29 Jul 2008 04:42:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1217331770!2869759!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 21105 invoked from network); 29 Jul 2008 11:42:50 -0000 Received: from unknown (HELO motgate5.mot.com) (136.182.1.15) by server-11.tower-128.messagelabs.com with SMTP; 29 Jul 2008 11:42:50 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m6TBgijO014697 for ; Tue, 29 Jul 2008 04:42:49 -0700 (MST) Received: from az10vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id m6TBgiXF006650 for ; Tue, 29 Jul 2008 06:42:44 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id m6TBgh05006643 for ; Tue, 29 Jul 2008 06:42:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 07:42:39 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id thread-index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzyw References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , "Asveren, Tolga" X-CFilter-Loop: Reflected Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org One of the motivations for introducing a Diameter QoS protocol was indeed to provide an interface between applications (such as a streaming video server) and network elements that need to enforce QoS. I think net neutrality means documenting this interface and opening it up to anyone that has a connection to the "Diameter Cloud". That being said, I don't have a strong opinion on whether we should use 1 or 2 Application IDs; personally I think it is easier for the application endpoint in a user terminal to provide an authentication token that points to an application server domain than it is to have the application server figure out the access network to which the user is attached based only on its IP address. This is why the original document had pull-only. If the AppS can figure out the Destination-Realm of the enforcing NE(s) then we should use standard Diameter routing based on Destination-Realm. Having a separate application ID for each mode of operation might lead us down the path of having some nodes implement only one half of the protocol which could lead to interoperability problems. -Pete Sun, Dong (Dong) wrote: > Tolga, > > The scenario A) mandates the application SP being aware of underlying > network technology and operation mode (i.e. push or pull) and making > a selection, which is not the intention of QoS application (and net > neutrality). And I don't think the content provider (let's say > youtube) really cares about which mode is used for the QoS guarantee > in the transport network. > > If you still have question, please give me a call. We can chat about > it in detail. > > Regards, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 3:57 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / Application-Id > > Hi Dong, > > Let's talk over an example because I seriously think we are cross > talking each other and there probably are a few things I don't > understand about QoS application: > > Org-1 is the service provider > Org-2 is the IP access provider > > App-push is the application-Id for push mode (if different AppIds > used) App-pullthe application-Id for pull mode (if different AppIds > used) > > AppQ is the application-Id for QoS application (if a single AppId is > used) > > > +-----+ > |AppS | (Org1) > +-----+ > | > +-------+ | > (Org2) |AE-gw |--------+ > +-------+ > | > | > +-------+ > (Org2) | AE1 | > +-------+ > | > | > +-------+ > (Org2) | NE1 | > +-------+ > A) With different Application-Ids > 1- AppS receives a new session request and determines that QoS needs > to be reserved on the access side for a particular flow. It > determines (by whatever means) that the access side is controlled by > Org2. > > 2- It sends the initial request with Destination-Realm=Org2 and > Application-Id=push. This request reaches AE-gw via standard Diameter > Base Protocol routing (during capability exchange procedure AE-gw > advertised App-push) [Actually here AppS will need to rely on some > provisioning as well as capability advertisement is not done per > realm, i.e. it won't be clear to AppS that AE-gw supports push-mode > for Org2 realm. This IMHO is a missing piece of functionality in > Diameter base protocol but can be fixed relativel easily] > > 3- AE-gw routes the message to AE based on standard Diameter base > protocol routing (during capability exchange procedure AE1 advertised > App-push). There could be other AEs in the network which are unable > to process this request because they do not know the binding between > IP addresses and NEs. This is not a problem though as they would > advertise only app-pull during capability exchange procedure) > > What is here that violates network neutrality? > > > B) With a single Application-Id > 1- AppS receives a new session request and determines that QoS needs > to be reserved on the access side for a particular flow. It > determines (by whatever means) that the access side is controlled by > Org2. > > 2- It sends the initial request with Destination-Realm=Org2 and > Application-Id=AppQ. This request reaches AE-gw via standard Diameter > Base Protocol routing (during capability exchange procedure AE-gw > advertised AppQ). > > 3- AE-gw needs to route the message based on provisioning. Why? > Because it needs to find an AE which can handle push mode. It can't > rely on capability advertisement because all types of AEs will > advertise support for AppQ. > > Is my understanding for single Application-Id correct? If so, with > single Application-Id model there are more steps relying on > provisioning rather than on dynamic capability exchange procedures > (and for different Application-Id model we can make routing > completely dynamic with some minor extensions to the base protocol) > > > I don't believe two Application-Ids add any significant additional > complexity. If a node can support Diameter Base Protocol (capability > exchange, connection state machine) and QoS application (application > state machine, new AVPs) etc... it is hard for me to believe that two > Application-Ids makes development of such nodes more complex. > > > It is likely that we will agree to disagree on this one if my > understanding of single Application-Id routing is correct. > > Thanks, > Tolga > >> -----Original Message----- >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] >> Sent: Monday, July 28, 2008 12:53 PM >> To: Asveren, Tolga >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- >> A001034; Avri Doria; Tina TSOU; Glen Zorn >> Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / >> Application-Id >> >> >> >> -----Original Message----- >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] >> Sent: Monday, July 28, 2008 11:12 AM >> To: Sun, Dong (Dong) >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn >> Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] >> / Application-Id >> >> Hi Dong, >> >> Inline.... >> >> Thanks, >> Tolga >> >>> -----Original Message----- >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] >>> Sent: Thursday, July 24, 2008 2:19 PM >>> To: Asveren, Tolga >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn >>> Subject: RE: [Fwd: [Dime] Comments for >> draft-ietf-dime-diameter-qos-06] / >>> Application-Id >>> >>> Tolga, >>> Comments inline. >>> Dong >>> >>> -----Original Message----- >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] >>> Sent: Thursday, July 24, 2008 11:13 AM >>> To: Sun, Dong (Dong) >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn >>> Subject: RE: [Fwd: [Dime] Comments for >> draft-ietf-dime-diameter-qos-06] >>> / Application-Id >>> >>> (Continuing in separate threads for each issue for easier tracking.) >>> >>> Hi Dong, >>> >>> One comment below. >>> >>> Thanks, >>> Tolga >>> >>> [.. snip ..] >>>>> >>>>> 1- Use of the same Application-Id for push/pull models It sounds > >>>>> reasonable to me to think nodes which support only a single mode. >>>>> How can we guarantee that messages land to the right server >>>>> considering that the same Application-Id is used for both of them? >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and pull >>>>> models is different, for example, when a new request from the PEP >>>>> is recevied, the Server will start the pull model. In fact, the >>>>> push and pull are sharing the same state machine per se. the main >>>>> difference is just how to establish a Diameter session. The >>>>> enhancement is to allow the Diameter >>>> >>>>> Server to establish a session with a local trigger instead of the >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I >>>>> don't think the same application-Id causes any problem, >>>>> especially for the pull model since >>>> >>>>> push/pull is able use the same server (certainly they can also >>>>> have separate server according to the configuration). >>>> [TOLGA]My concern here is about message routing rather than the >>>> state machine processing in the server. Let's say a server is >>>> capable only to accommodate pull model (it doesn't know what NE to >>>> contact if push model is required). How can the network >>>> intermediaries, e.g. relay agent, forward the initial request in >>>> the session to the right server for push model? How can they be >>>> sure that the server supports push model? [Dong] The relay agent >>>> should route the message according to the destination >>>> address/realm that is filled up by the requestor. I don't know how >>>> the application id will affect this kind of routing. >>> [TOLGA]The initial message of a session may have only >>> Destination-Realm. In such a case Application-Id is used by >>> intermediaries to select the right server. [Dong] In the context of >>> QoS application, for the pull mode, the NE typically is configured >>> by a default policy server or redirect server. I don't think the >>> scenario you are concerned is a common case in reality >> >>> although theoretically the base Diameter protocol may allow this >>> kind of behavior, but it is not the case for QoS application, IMHO. >> [TOLGA] How can we make sure that a request requiring push mode >> capabilities is delivered to the right server? That was my initial >> question. There could be servers which only have authorization >> capability but do not have any topology information, i.e. not >> suitable > >> for push mode operation. And what type of problems would be >> introduced > >> if we used two different Application-Ids? >> [Dong] Either Application Server or UE or NE needs to perform the >> selection of AE according to its capabilities. In the case there are >> different AEs for push or pull respectively, a rendezvous AE will >> make a selection according to the policy, network technology and/or >> request attribute. The problem to have two different application id >> is to mandate the selection of an AE per its capabilities to the >> AppS (or NE), it is inconsistent with the basic rationale of the QoS >> application (i.e. maintain the network neutrality). Moreover, it >> makes the QoS application and implementations more complex since two >> packages have to be developed... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 07:51:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C77C3A6B69; Tue, 29 Jul 2008 07:51:46 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 904383A6B69 for ; Tue, 29 Jul 2008 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L5IpsCveZh0 for ; Tue, 29 Jul 2008 07:51:43 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by core3.amsl.com (Postfix) with ESMTP id 35C863A6927 for ; Tue, 29 Jul 2008 07:51:43 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so5418105wra.17 for ; Tue, 29 Jul 2008 07:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=ZPd9RW2/naBnBOkaO2E0oJZd/bYwmhghw9n1erNlze4=; b=IMUkOihUGcUS6aTFI3mKeFXZDByJCNC3pXFTR9kLBfrklvslt9kQyTj6z7HfDbbfsa F9+RjSJ4cHQSLTx2TXccbx/7Bmo3E2Ibz+PsMTNaMG/lw8xfBFaEpWj9BlUwohJZGKf9 z98M1IvJIYwrLASSgvg8QZeX16EsW4F+3P9js= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=C4/WNjEW2fjnsUkA1G018a4GrXflBD/HULX4YQvEj5yspYW7dqNKSUEAgnOkaEyCk1 72jQj0ITrdu8MSR5GeCCZLCE3MdsUozFUEwnr5Vl/t/N70RyCa6CFZtKBLCbOG4uSNm+ 7jauUvlbsQCNrIX90HTKFNqjl3fwnPEkvu36U= Received: by 10.90.94.2 with SMTP id r2mr4631767agb.29.1217343114456; Tue, 29 Jul 2008 07:51:54 -0700 (PDT) Received: by 10.90.65.17 with HTTP; Tue, 29 Jul 2008 07:51:54 -0700 (PDT) Message-ID: <9cf5ced20807290751mdbb45deidca3e2dc3274c4e5@mail.gmail.com> Date: Tue, 29 Jul 2008 10:51:54 -0400 From: "David Frascone" To: dime@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: d691d851245bae4e Subject: [Dime] Rechartering Work Items X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2111304253==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============2111304253== Content-Type: multipart/alternative; boundary="----=_Part_44747_11456088.1217343114506" ------=_Part_44747_11456088.1217343114506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dime Rechartering In the interest of rechartering, we spent a good deal of the meeting yesterday discussing new work. Based on in-room feedback we have come up with some suggestions. But, this is just a starting point. We still need responses from people on the list, in order to ratify a new agenda. The following drafts were briefly presented by the chairs: - draft-asveren-dime-cong-03.txt - draft-zorn-dime-diameter-base-protocol-mib - draft-zorn-dime-diameter-cc-appl-mib - draft-tsou-dime-capabilities-update-problem-statement - draft-morariu-dime-grid-accounting - draft-bodin-dime-auditing-reqs - draft-asveren-dime-state-recovery - draft-tsou-dime-base-routing-ext - draft-mccann-dime-rfc4004bis - draft-sarikaya-dimeradext-prefix-auth-ps-00.txt - draft-neumann-dime-webauth - draft-stupar-dime-mos-options - draft-dondeti-dime-erp-diameter - draft-korhonen-dime-nai-routing - draft-korhonen-dime-pmip6 Based on in-room volunteers / interest, we have tentatively come up with the following list of work items: - We will ask operators, other working groups, and SDO's for input on the MIBs defined in : - draft-zorn-dime-diameter-base-protocol-mib - draft-zorn-dime-diameter-cc-appl-mib - Hopefully with some real-world implementers input, our MIBs will be more useful. - The problem described in draft-tsou-dime-capabilities-update-problem-statement should be covered by 3588bis. We need people to carefully review the CER/CEA section and make sure that there are no technical difficulties with regard to updating capabilities. If there are, then we need to fix it. Even if there are no technical issues, given the level of confusion in the room, the text needs to be edited / rewritten to more clearly explain how to update capabilities. - There were editors, reviewers, and interest in the following documents; we feel that they should be made a new WG items: - draft-dondeti-dime-erp-diameter - draft-korhonen-dime-nai-routing - draft-korhonen-dime-pmip6 - The other drafts seemed to have no interest, editors, or reviewers. If you feel that your draft does have those items, please bring it up on the list. Again -- this list of work is not complete -- please feel free to suggest new items, or revise this list. We will make the decision here, on the list. -Dave ------=_Part_44747_11456088.1217343114506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


Dime Rechartering

In the interest of rechartering, we spent a good deal of the meeting yesterday discussing new work.  Based on in-room feedback we have come up with some suggestions.  But, this is just a starting point.  We still need responses from people on the list, in order to ratify a new agenda.


The following drafts were briefly presented by the chairs:

  •    draft-asveren-dime-cong-03.txt
  •    draft-zorn-dime-diameter-base-protocol-mib
  •    draft-zorn-dime-diameter-cc-appl-mib
  •    draft-tsou-dime-capabilities-update-problem-statement
  •    draft-morariu-dime-grid-accounting
  •    draft-bodin-dime-auditing-reqs
  •    draft-asveren-dime-state-recovery
  •    draft-tsou-dime-base-routing-ext
  •    draft-mccann-dime-rfc4004bis
  •    draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
  •    draft-neumann-dime-webauth
  •    draft-stupar-dime-mos-options
  •    draft-dondeti-dime-erp-diameter
  •    draft-korhonen-dime-nai-routing
  •    draft-korhonen-dime-pmip6

Based on in-room volunteers / interest, we have tentatively come up with the following list of work items:

  • We will ask operators, other working groups, and SDO's for input on the MIBs defined in :
      • draft-zorn-dime-diameter-base-protocol-mib
      • draft-zorn-dime-diameter-cc-appl-mib
    • Hopefully with some real-world implementers input, our MIBs will be more useful.
  • The problem described in draft-tsou-dime-capabilities-update-problem-statement should be covered by 3588bis.  We need people to carefully review the CER/CEA section and make sure that there are no technical difficulties with regard to updating capabilities.  If there are, then we need to fix it.  Even if there are no technical issues, given the level of confusion in the room, the text needs to be edited / rewritten to more clearly explain how to update capabilities.
  • There were editors, reviewers, and interest in the following documents; we feel that they should be made a new WG items:
    • draft-dondeti-dime-erp-diameter
    • draft-korhonen-dime-nai-routing
    • draft-korhonen-dime-pmip6
  • The other drafts seemed to have no interest, editors, or reviewers.  If you feel that your draft does have those items, please bring it up on the list.

Again -- this list of work is not complete -- please feel free to suggest new items, or revise this list.  We will make the decision here, on the list.

-Dave
------=_Part_44747_11456088.1217343114506-- --===============2111304253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2111304253==-- From dime-bounces@ietf.org Tue Jul 29 08:48:18 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310643A6A5A; Tue, 29 Jul 2008 08:48:18 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9243A6853 for ; Tue, 29 Jul 2008 08:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 tOJZhrCzhMBY for ; Tue, 29 Jul 2008 08:48:13 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 60CA93A6A5A for ; Tue, 29 Jul 2008 08:48:12 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6TFmGfe021393; Tue, 29 Jul 2008 11:48:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:48:15 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzywAAXRb8A= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "McCann Peter-A001034" , "Sun, Dong (Dong)" Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org (Reply for both Pete's and Dong's explanations) The origin of my question was the doubt whether all nodes would implement both push and pull modes. I see that this is expected so there won't be a problem of finding the right server. This makes it unnecessary to use different Application-Ids from routing perspective (I am still not sure whether support for both modes will be universal but it seems I am in minority on this one). I need clarification on one point though: Both of you stated AppS knowing that push mode is necessary requires that it is aware of access network type used the terminal. IMHO it is more than that: access network type, terminal capabilities, whether QoS reservation is requested for the session by the enduser all play a role in this decision AFAICS. Even for access provider it may not be possible to know the answer for all these questions. For example: 1) AppS receives the session request and decides that this type of session requires QoS reservation 2) It sends a request to the AE 3) How does the AE determine whether a push mode reservation is really necessary? There seem to be only a single entity with perfect information: the terminal/enduser. I would expect the endpoint to signal its request for the AppS to reserve QoS resources as part of the session signaling. Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, July 29, 2008 7:43 AM > To: Sun, Dong (Dong); Asveren, Tolga > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > One of the motivations for introducing a Diameter QoS protocol > was indeed to provide an interface between applications (such > as a streaming video server) and network elements that need > to enforce QoS. I think net neutrality means documenting this > interface and opening it up to anyone that has a connection > to the "Diameter Cloud". > > That being said, I don't have a strong opinion on whether we > should use 1 or 2 Application IDs; personally I think it is > easier for the application endpoint in a user terminal to > provide an authentication token that points to an application > server domain than it is to have the application server figure > out the access network to which the user is attached based only > on its IP address. This is why the original document had pull-only. > If the AppS can figure out the Destination-Realm of the enforcing > NE(s) then we should use standard Diameter routing based on > Destination-Realm. Having a separate application ID for each > mode of operation might lead us down the path of having some > nodes implement only one half of the protocol which could lead > to interoperability problems. > > -Pete > > Sun, Dong (Dong) wrote: > > Tolga, > > > > The scenario A) mandates the application SP being aware of underlying > > network technology and operation mode (i.e. push or pull) and making > > a selection, which is not the intention of QoS application (and net > > neutrality). And I don't think the content provider (let's say > > youtube) really cares about which mode is used for the QoS guarantee > > in the transport network. > > > > If you still have question, please give me a call. We can chat about > > it in detail. > > > > Regards, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 3:57 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / Application-Id > > > > Hi Dong, > > > > Let's talk over an example because I seriously think we are cross > > talking each other and there probably are a few things I don't > > understand about QoS application: > > > > Org-1 is the service provider > > Org-2 is the IP access provider > > > > App-push is the application-Id for push mode (if different AppIds > > used) App-pullthe application-Id for pull mode (if different AppIds > > used) > > > > AppQ is the application-Id for QoS application (if a single AppId is > > used) > > > > > > +-----+ > > |AppS | (Org1) > > +-----+ > > | > > +-------+ | > > (Org2) |AE-gw |--------+ > > +-------+ > > | > > | > > +-------+ > > (Org2) | AE1 | > > +-------+ > > | > > | > > +-------+ > > (Org2) | NE1 | > > +-------+ > > A) With different Application-Ids > > 1- AppS receives a new session request and determines that QoS needs > > to be reserved on the access side for a particular flow. It > > determines (by whatever means) that the access side is controlled by > > Org2. > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > Application-Id=push. This request reaches AE-gw via standard Diameter > > Base Protocol routing (during capability exchange procedure AE-gw > > advertised App-push) [Actually here AppS will need to rely on some > > provisioning as well as capability advertisement is not done per > > realm, i.e. it won't be clear to AppS that AE-gw supports push-mode > > for Org2 realm. This IMHO is a missing piece of functionality in > > Diameter base protocol but can be fixed relativel easily] > > > > 3- AE-gw routes the message to AE based on standard Diameter base > > protocol routing (during capability exchange procedure AE1 advertised > > App-push). There could be other AEs in the network which are unable > > to process this request because they do not know the binding between > > IP addresses and NEs. This is not a problem though as they would > > advertise only app-pull during capability exchange procedure) > > > > What is here that violates network neutrality? > > > > > > B) With a single Application-Id > > 1- AppS receives a new session request and determines that QoS needs > > to be reserved on the access side for a particular flow. It > > determines (by whatever means) that the access side is controlled by > > Org2. > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > Application-Id=AppQ. This request reaches AE-gw via standard Diameter > > Base Protocol routing (during capability exchange procedure AE-gw > > advertised AppQ). > > > > 3- AE-gw needs to route the message based on provisioning. Why? > > Because it needs to find an AE which can handle push mode. It can't > > rely on capability advertisement because all types of AEs will > > advertise support for AppQ. > > > > Is my understanding for single Application-Id correct? If so, with > > single Application-Id model there are more steps relying on > > provisioning rather than on dynamic capability exchange procedures > > (and for different Application-Id model we can make routing > > completely dynamic with some minor extensions to the base protocol) > > > > > > I don't believe two Application-Ids add any significant additional > > complexity. If a node can support Diameter Base Protocol (capability > > exchange, connection state machine) and QoS application (application > > state machine, new AVPs) etc... it is hard for me to believe that two > > Application-Ids makes development of such nodes more complex. > > > > > > It is likely that we will agree to disagree on this one if my > > understanding of single Application-Id routing is correct. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > >> Sent: Monday, July 28, 2008 12:53 PM > >> To: Asveren, Tolga > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > >> A001034; Avri Doria; Tina TSOU; Glen Zorn > >> Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > >> Application-Id > >> > >> > >> > >> -----Original Message----- > >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > >> Sent: Monday, July 28, 2008 11:12 AM > >> To: Sun, Dong (Dong) > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > >> Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > >> / Application-Id > >> > >> Hi Dong, > >> > >> Inline.... > >> > >> Thanks, > >> Tolga > >> > >>> -----Original Message----- > >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > >>> Sent: Thursday, July 24, 2008 2:19 PM > >>> To: Asveren, Tolga > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn > >>> Subject: RE: [Fwd: [Dime] Comments for > >> draft-ietf-dime-diameter-qos-06] / > >>> Application-Id > >>> > >>> Tolga, > >>> Comments inline. > >>> Dong > >>> > >>> -----Original Message----- > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > >>> Sent: Thursday, July 24, 2008 11:13 AM > >>> To: Sun, Dong (Dong) > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > >>> Subject: RE: [Fwd: [Dime] Comments for > >> draft-ietf-dime-diameter-qos-06] > >>> / Application-Id > >>> > >>> (Continuing in separate threads for each issue for easier tracking.) > >>> > >>> Hi Dong, > >>> > >>> One comment below. > >>> > >>> Thanks, > >>> Tolga > >>> > >>> [.. snip ..] > >>>>> > >>>>> 1- Use of the same Application-Id for push/pull models It sounds > > > >>>>> reasonable to me to think nodes which support only a single mode. > >>>>> How can we guarantee that messages land to the right server > >>>>> considering that the same Application-Id is used for both of them? > >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and pull > >>>>> models is different, for example, when a new request from the PEP > >>>>> is recevied, the Server will start the pull model. In fact, the > >>>>> push and pull are sharing the same state machine per se. the main > >>>>> difference is just how to establish a Diameter session. The > >>>>> enhancement is to allow the Diameter > >>>> > >>>>> Server to establish a session with a local trigger instead of the > >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I > >>>>> don't think the same application-Id causes any problem, > >>>>> especially for the pull model since > >>>> > >>>>> push/pull is able use the same server (certainly they can also > >>>>> have separate server according to the configuration). > >>>> [TOLGA]My concern here is about message routing rather than the > >>>> state machine processing in the server. Let's say a server is > >>>> capable only to accommodate pull model (it doesn't know what NE to > >>>> contact if push model is required). How can the network > >>>> intermediaries, e.g. relay agent, forward the initial request in > >>>> the session to the right server for push model? How can they be > >>>> sure that the server supports push model? [Dong] The relay agent > >>>> should route the message according to the destination > >>>> address/realm that is filled up by the requestor. I don't know how > >>>> the application id will affect this kind of routing. > >>> [TOLGA]The initial message of a session may have only > >>> Destination-Realm. In such a case Application-Id is used by > >>> intermediaries to select the right server. [Dong] In the context of > >>> QoS application, for the pull mode, the NE typically is configured > >>> by a default policy server or redirect server. I don't think the > >>> scenario you are concerned is a common case in reality > >> > >>> although theoretically the base Diameter protocol may allow this > >>> kind of behavior, but it is not the case for QoS application, IMHO. > >> [TOLGA] How can we make sure that a request requiring push mode > >> capabilities is delivered to the right server? That was my initial > >> question. There could be servers which only have authorization > >> capability but do not have any topology information, i.e. not > >> suitable > > > >> for push mode operation. And what type of problems would be > >> introduced > > > >> if we used two different Application-Ids? > >> [Dong] Either Application Server or UE or NE needs to perform the > >> selection of AE according to its capabilities. In the case there are > >> different AEs for push or pull respectively, a rendezvous AE will > >> make a selection according to the policy, network technology and/or > >> request attribute. The problem to have two different application id > >> is to mandate the selection of an AE per its capabilities to the > >> AppS (or NE), it is inconsistent with the basic rationale of the QoS > >> application (i.e. maintain the network neutrality). Moreover, it > >> makes the QoS application and implementations more complex since two > >> packages have to be developed... > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 09:21:13 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3AE3A6875; Tue, 29 Jul 2008 09:21:13 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0EE3A68C6 for ; Tue, 29 Jul 2008 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 cRa0IE95cqnT for ; Tue, 29 Jul 2008 09:21:10 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 5FC233A6875 for ; Tue, 29 Jul 2008 09:21:10 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6TGKvLs014984; Tue, 29 Jul 2008 12:20:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:20:54 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D46C5@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SAACJCP4AAhFUtg References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, It is a great help for developers if a message contains information to reconstruct a session after a failover. If you don't think that this is a good idea/necessary or creates too much overhead then fine. And actually this probably would require more than the change I asked. I don't think there could be a general mechanism to provide all the support needed for failover friendliness; it is not just about deciding whether a request is for an existing session but also reconstructing existing state (which is different for each application). IMHO DCCA(RFC4006) is a good example. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 8:46 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > > Before we move further on the failure handover issue, I'd like to > clarify a basic question (I need some education from the Diameter > experts): in 3588 and 4005, how a new session is recogizied by the > Diameter Server? It seems no one uses the explicit indicator for > identifying a new session, if my understanding is correct. Furthermore, > if we rely on the Diameter client for the indication of new session, it > may cause the problem when the client recovers from the failure, e.g. it > may think the recovered session as a new session. > > As I indicated, the QoS application is intended to keep consistent with > the base protocol and the "mom" protocol 4005. In fact, besides the > session-id, the QoS application also looks at the QoS resources and > other AVPs to decide the transition of the session state. > > I just like to highligh my point: how to handle failover is a general > issue, I don't think the QoS application requires any extra mechanism > compared to any other applications. So I'd like to adapt a generic > mechanism already used by other applications if possible, rather than > creating an "unique" mechanism here. > > Regards, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 4:02 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > I am not proposing to add anything special to QoS application but just > not relying on the type of first command received to determine the QoS > model used. IMHO using an AVP for this purpose is a better approach > because using command type brings extra complexity from cold-standby > system design perspective. Furthermore it is just overloading the > meaning of the command code. > > I just wanted to summarize the issue. My current understanding is that > we agree to disagree on this one. > > Thanks, > Tolga > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Monday, July 28, 2008 1:07 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Inline... > > Rgs, - Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 12:16 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Resending..... > > > > > > > > > > Hi Dong, > > > > inline.... > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > Sent: Thursday, July 24, 2008 2:49 PM > > > To: Asveren, Tolga > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > > > failover friendliness > > > > > > Tolga, > > > Since you agreed that the general failure handling for Diameter is > out > > > > > of scope in the QoS application. In principle, I don't see the > > necessity > > > to include extra overhead as the mandatory parameters. Frankly, the > > > failure handling of the Diameter Server is a quite comprehensive > > issue. > > > Sofar, the QoS application should provide some basic failure > handling > > > e.g. clean up the expired sessions, but I am not sure if it is > > > appropriate to discuss what you address in the QoS application > > > exclusively. I assume it should be part of base protocol or separate > > > > document (I am not sure if it already has) since they are supposed > to > > > generic to all applications. > > > > > > See additional comments inline. > > > > > > Rgs, > > > Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Thursday, July 24, 2008 11:44 AM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > > > / failover friendliness > > > > > > Hi Dong, > > > > > > Comments/questions below. > > > > > > Thanks, > > > Tolga > > > > > > > > > [.. snip ..] > > > > > 6- 4.2 Session Establishment > > > > > "When a QoS-Authz-Request > > > > > (QAR, see Section 5.1) message with a new session ID is > > received, > > > > the > > > > > AE operates in the Pull mode; when other triggers are > received, > > > the > > > > > AE operates in the Push mode." > > > > > Would this shut down the door for certain failure recovery > > > scenarios? > > > > > For example AE goes down and a backup AE takes over. IMO it is a > > > nice > > > > > feature if the backup can continue existing sessions without a > > need > > > to > > > > > > > > > synchronizing state with the failed active AE. This can be > > achieved > > > by > > > > > > > > > carrying enough information about session state in the message > > > itself > > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes > this > > > > > > > impossible. For certain scenarios backup AE would determine the > > > > required > > > > > mode wrong. I suggest the decision for push/pull is not based on > > > > message > > > > > name but on the message content. > > > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > > > > consistent way in terms of state machine to decide the > pull/push. > > > and > > > > it > > > > > will work well for the hot standby case, but indeed, it may have > > > some > > > > > issue with cold standby. In general, the failure handling is not > > > > addressed > > > > > in the draft very much. The question is, do we need to add the > > > failure > > > > > > > > > handling in detail or not for backup server case? > > > > [TOLGA]I agree that details of failure handling may not belong > here. > > > > OTOH that the QoS application is failover friendly is a parameter > to > > > > > > consider IMHO. By carrying enough information in each message so > > that > > > > cold standby elements can be used to take over existing sessions, > > one > > > > trades small amount of bandwidth and limited CPU cycles for > > complexity > > > > > > > in software and probably even more CPU cycles. IMHO this is a > > bargain. > > > I > > > > found this very handy in DCCA. Wouldn't just defining an AVP > > > indicating > > > > the type of service requested (push v.s. pull) solve this problem? > > > > Actually this issue is also tied to Application-Id problem. If > > > different > > > > Application-Ids are used, that implicitly will define the mode > > > > required/used. > > > > [Dong] I don't think it makes sense to mandate this kind of > > parameter > > > > for failover since it is more useful for one type of failure > > handling > > > > approach rather than the other. But it is ok to have an optional > > > > parameter but it does add significant overhead in the message. In > > > > addition, not sure why the application id is tied up with this > > issue, > > > > even in general the routing issue as I explained above. > > > > I think the failure handling approach should be consistent for all > > > > > Diameter applications rather than defining specific one for QoS > > > > application. > > > [TOLGA] > > > 1) One can argue the other way around as well: Why exclude some > piece > > of > > > information which is useful for certain type of failover mechanism. > > IMHO > > > the added overhead is negligible and I am pretty sure much less than > > the > > > overhead of a hot standby system (let alone the extra complexity it > > > requires) > > > [Dong] as indicated, this is not my intention to discuss all > possible > > > varieties for failure handover to the standby Diameter server. I > > assume > > > a generic mechanism should be applied to QoS application. > > > > > > 2) If push/pull modes use different Application-Ids that could be > used > > > > > easily to decide for which mode the message is received. OTOH I > agree > > > that this itself wouldn't help for failover friendliness. > > > [Dong] Using different application id for push/pull makes the state > > > mechanism less efficient and does not add too much value for the > > routing > > > since the scenarios you are concerned are not common (i.e. the > message > > > > > cannot provide a destination address) in reality for QoS > application, > > > IMHO. (sorry for saying this). > > [TOLGA]IMHO you are introducing unnecessary restrictions for no > reason. > > Diameter message routing is making use of Application-Id for initial > > requests. If you have a problem with this, you should voice your > > concerns for the 3588-bis document. Otherwise violating base protocol > > principles on a per application basis doesn't make sense to me. > > > > > > > > > > > > 3) There are certainly a few things which can be done in base > protocol > > > > > to help failover handling. OTOH base protocol is application state > > > machine agnostic. I don't see how it can help there. > > > [Dong] the failover handling you described does not look like a > > specific > > > case only for QoS application. In fact the failure of the server > does > > > not affect too much for ongoing bearer sessions since they will > remain > > > > > anyway. And I am not sure if the NE is the best option to store all > > > session info due to the cost effectiveness and processing capacity > > > issues. Maybe the synchronization between two servers is more > > efficient, > > > to some extent. > > [TOLGA]I don't think it is ever possible that base protocol can > provide > > redundancy features to cover for all application redundancy needs > > without any involvement from application itself. If you have any > > strategy in mind to deal with this problem please tell it. > > Actually what I am asking for is to remove a failover-unfriendly > feature > > rather than adding new stuff to facilitate redundancy. I really don't > > understand what is bad about including an AVP indicating the type. I > > simply don't buy the overhead argument. > > [Dong]I don't think the approach you described is a specific > requirement > > only to the QoS application. Then why don't we generalize the issue > and > > method rather than adding something only to the QoS application. In > > addition, it is obvious an optional approach for failure handling, and > I > > don't think current draft prevents any implementation from adding the > > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 09:23:45 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E873A692E; Tue, 29 Jul 2008 09:23:45 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676853A692E for ; Tue, 29 Jul 2008 09:23:44 -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 DUcv38CrNMwh for ; Tue, 29 Jul 2008 09:23:42 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AB4B03A6875 for ; Tue, 29 Jul 2008 09:23:42 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6TGNcqQ019252; Tue, 29 Jul 2008 11:23:50 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 11:23:45 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:23:44 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEE5F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzywAAXRb8AABCLmMA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" , "McCann Peter-A001034" X-OriginalArrivalTime: 29 Jul 2008 16:23:45.0840 (UTC) FILETIME=[795AAB00:01C8F197] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, The AE controlling the access network resources should be able to know the access technology and decide the push or pull mode. In certain circumstance, the endpoint may know some info of access network, but I suspect it might not be a general case, for example, for the femto network, the cellular UE does not really know/care about the broadband access. It is the access networks (including the AE in the access network) that know it. Moreover, there are many different kinds of endpoints, according the QoS draft, certain types i.e. Category 1, does not have the capability to decide the QoS attributes. I believe the draft should and has been able to support all variants. Not see any issue sofar. Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Tuesday, July 29, 2008 11:48 AM To: McCann Peter-A001034; Sun, Dong (Dong) Cc: Glen Zorn; Avri Doria; dime@ietf.org Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id (Reply for both Pete's and Dong's explanations) The origin of my question was the doubt whether all nodes would implement both push and pull modes. I see that this is expected so there won't be a problem of finding the right server. This makes it unnecessary to use different Application-Ids from routing perspective (I am still not sure whether support for both modes will be universal but it seems I am in minority on this one). I need clarification on one point though: Both of you stated AppS knowing that push mode is necessary requires that it is aware of access network type used the terminal. IMHO it is more than that: access network type, terminal capabilities, whether QoS reservation is requested for the session by the enduser all play a role in this decision AFAICS. Even for access provider it may not be possible to know the answer for all these questions. For example: 1) AppS receives the session request and decides that this type of session requires QoS reservation 2) It sends a request to the AE 3) How does the AE determine whether a push mode reservation is really necessary? There seem to be only a single entity with perfect information: the terminal/enduser. I would expect the endpoint to signal its request for the AppS to reserve QoS resources as part of the session signaling. Thanks, Tolga > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, July 29, 2008 7:43 AM > To: Sun, Dong (Dong); Asveren, Tolga > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > One of the motivations for introducing a Diameter QoS protocol was > indeed to provide an interface between applications (such as a > streaming video server) and network elements that need to enforce QoS. > I think net neutrality means documenting this interface and opening it > up to anyone that has a connection to the "Diameter Cloud". > > That being said, I don't have a strong opinion on whether we should > use 1 or 2 Application IDs; personally I think it is easier for the > application endpoint in a user terminal to provide an authentication > token that points to an application server domain than it is to have > the application server figure out the access network to which the user > is attached based only on its IP address. This is why the original > document had pull-only. > If the AppS can figure out the Destination-Realm of the enforcing > NE(s) then we should use standard Diameter routing based on > Destination-Realm. Having a separate application ID for each mode of > operation might lead us down the path of having some nodes implement > only one half of the protocol which could lead to interoperability > problems. > > -Pete > > Sun, Dong (Dong) wrote: > > Tolga, > > > > The scenario A) mandates the application SP being aware of underlying > > network technology and operation mode (i.e. push or pull) and making > > a selection, which is not the intention of QoS application (and net > > neutrality). And I don't think the content provider (let's say > > youtube) really cares about which mode is used for the QoS guarantee > > in the transport network. > > > > If you still have question, please give me a call. We can chat about > > it in detail. > > > > Regards, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 3:57 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / Application-Id > > > > Hi Dong, > > > > Let's talk over an example because I seriously think we are cross > > talking each other and there probably are a few things I don't > > understand about QoS application: > > > > Org-1 is the service provider > > Org-2 is the IP access provider > > > > App-push is the application-Id for push mode (if different AppIds > > used) App-pullthe application-Id for pull mode (if different AppIds > > used) > > > > AppQ is the application-Id for QoS application (if a single AppId is > > used) > > > > > > +-----+ > > |AppS | (Org1) > > +-----+ > > | > > +-------+ | > > (Org2) |AE-gw |--------+ > > +-------+ > > | > > | > > +-------+ > > (Org2) | AE1 | > > +-------+ > > | > > | > > +-------+ > > (Org2) | NE1 | > > +-------+ > > A) With different Application-Ids > > 1- AppS receives a new session request and determines that QoS needs > > to be reserved on the access side for a particular flow. It > > determines (by whatever means) that the access side is controlled by > > Org2. > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > Application-Id=push. This request reaches AE-gw via standard Diameter > > Base Protocol routing (during capability exchange procedure AE-gw > > advertised App-push) [Actually here AppS will need to rely on some > > provisioning as well as capability advertisement is not done per > > realm, i.e. it won't be clear to AppS that AE-gw supports push-mode > > for Org2 realm. This IMHO is a missing piece of functionality in > > Diameter base protocol but can be fixed relativel easily] > > > > 3- AE-gw routes the message to AE based on standard Diameter base > > protocol routing (during capability exchange procedure AE1 advertised > > App-push). There could be other AEs in the network which are unable > > to process this request because they do not know the binding between > > IP addresses and NEs. This is not a problem though as they would > > advertise only app-pull during capability exchange procedure) > > > > What is here that violates network neutrality? > > > > > > B) With a single Application-Id > > 1- AppS receives a new session request and determines that QoS needs > > to be reserved on the access side for a particular flow. It > > determines (by whatever means) that the access side is controlled by > > Org2. > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > Application-Id=AppQ. This request reaches AE-gw via standard Diameter > > Base Protocol routing (during capability exchange procedure AE-gw > > advertised AppQ). > > > > 3- AE-gw needs to route the message based on provisioning. Why? > > Because it needs to find an AE which can handle push mode. It can't > > rely on capability advertisement because all types of AEs will > > advertise support for AppQ. > > > > Is my understanding for single Application-Id correct? If so, with > > single Application-Id model there are more steps relying on > > provisioning rather than on dynamic capability exchange procedures > > (and for different Application-Id model we can make routing > > completely dynamic with some minor extensions to the base protocol) > > > > > > I don't believe two Application-Ids add any significant additional > > complexity. If a node can support Diameter Base Protocol (capability > > exchange, connection state machine) and QoS application (application > > state machine, new AVPs) etc... it is hard for me to believe that two > > Application-Ids makes development of such nodes more complex. > > > > > > It is likely that we will agree to disagree on this one if my > > understanding of single Application-Id routing is correct. > > > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > >> Sent: Monday, July 28, 2008 12:53 PM > >> To: Asveren, Tolga > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > >> A001034; Avri Doria; Tina TSOU; Glen Zorn > >> Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > >> Application-Id > >> > >> > >> > >> -----Original Message----- > >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > >> Sent: Monday, July 28, 2008 11:12 AM > >> To: Sun, Dong (Dong) > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > >> Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > >> / Application-Id > >> > >> Hi Dong, > >> > >> Inline.... > >> > >> Thanks, > >> Tolga > >> > >>> -----Original Message----- > >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > >>> Sent: Thursday, July 24, 2008 2:19 PM > >>> To: Asveren, Tolga > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn > >>> Subject: RE: [Fwd: [Dime] Comments for > >> draft-ietf-dime-diameter-qos-06] / > >>> Application-Id > >>> > >>> Tolga, > >>> Comments inline. > >>> Dong > >>> > >>> -----Original Message----- > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > >>> Sent: Thursday, July 24, 2008 11:13 AM > >>> To: Sun, Dong (Dong) > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > >>> Subject: RE: [Fwd: [Dime] Comments for > >> draft-ietf-dime-diameter-qos-06] > >>> / Application-Id > >>> > >>> (Continuing in separate threads for each issue for easier tracking.) > >>> > >>> Hi Dong, > >>> > >>> One comment below. > >>> > >>> Thanks, > >>> Tolga > >>> > >>> [.. snip ..] > >>>>> > >>>>> 1- Use of the same Application-Id for push/pull models It sounds > > > >>>>> reasonable to me to think nodes which support only a single mode. > >>>>> How can we guarantee that messages land to the right server > >>>>> considering that the same Application-Id is used for both of them? > >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and pull > >>>>> models is different, for example, when a new request from the PEP > >>>>> is recevied, the Server will start the pull model. In fact, the > >>>>> push and pull are sharing the same state machine per se. the main > >>>>> difference is just how to establish a Diameter session. The > >>>>> enhancement is to allow the Diameter > >>>> > >>>>> Server to establish a session with a local trigger instead of the > >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I > >>>>> don't think the same application-Id causes any problem, > >>>>> especially for the pull model since > >>>> > >>>>> push/pull is able use the same server (certainly they can also > >>>>> have separate server according to the configuration). > >>>> [TOLGA]My concern here is about message routing rather than the > >>>> state machine processing in the server. Let's say a server is > >>>> capable only to accommodate pull model (it doesn't know what NE to > >>>> contact if push model is required). How can the network > >>>> intermediaries, e.g. relay agent, forward the initial request in > >>>> the session to the right server for push model? How can they be > >>>> sure that the server supports push model? [Dong] The relay agent > >>>> should route the message according to the destination > >>>> address/realm that is filled up by the requestor. I don't know how > >>>> the application id will affect this kind of routing. > >>> [TOLGA]The initial message of a session may have only > >>> Destination-Realm. In such a case Application-Id is used by > >>> intermediaries to select the right server. [Dong] In the context of > >>> QoS application, for the pull mode, the NE typically is configured > >>> by a default policy server or redirect server. I don't think the > >>> scenario you are concerned is a common case in reality > >> > >>> although theoretically the base Diameter protocol may allow this > >>> kind of behavior, but it is not the case for QoS application, IMHO. > >> [TOLGA] How can we make sure that a request requiring push mode > >> capabilities is delivered to the right server? That was my initial > >> question. There could be servers which only have authorization > >> capability but do not have any topology information, i.e. not > >> suitable > > > >> for push mode operation. And what type of problems would be > >> introduced > > > >> if we used two different Application-Ids? > >> [Dong] Either Application Server or UE or NE needs to perform the > >> selection of AE according to its capabilities. In the case there are > >> different AEs for push or pull respectively, a rendezvous AE will > >> make a selection according to the policy, network technology and/or > >> request attribute. The problem to have two different application id > >> is to mandate the selection of an AE per its capabilities to the > >> AppS (or NE), it is inconsistent with the basic rationale of the QoS > >> application (i.e. maintain the network neutrality). Moreover, it > >> makes the QoS application and implementations more complex since two > >> packages have to be developed... > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 09:38:24 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1181A3A67A3; Tue, 29 Jul 2008 09:38:24 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23183A6891 for ; Tue, 29 Jul 2008 09:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 vLAjDqT3-Ff1 for ; Tue, 29 Jul 2008 09:38:21 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id C8ACD3A6890 for ; Tue, 29 Jul 2008 09:38:20 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6TGcRqC028685; Tue, 29 Jul 2008 12:38:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 12:38:21 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D46CC@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEE5F@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzywAAXRb8AABCLmMAAAgyKg References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE5F@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" , "McCann Peter-A001034" Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, That the endpoint is able to reserve QoS resources is one thing, that it knows a particular session requires QoS reservation (not necessarily the attributes just the need) is another one. I expect the endpoint to know the latter for sure. I don't know what would happen for the following case: 1) The terminal is capable of reserving QoS 2) A softclient is running on the terminal which is not making use of QoS reservation capabilities of the terminal (it is a generic softclient) but it signals it desire for QoS as part of the session signaling Who will initiate the QoS reservation? My understanding of your explanation is that if an access network allows pull model then it won't allow push model as you seem tying the decision for push/pull model to the access network type (?). Is this always the case and are we sure that this always will be the case? Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 29, 2008 12:24 PM > To: Asveren, Tolga; McCann Peter-A001034 > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > Tolga, > > The AE controlling the access network resources should be able to know > the access technology and decide the push or pull mode. In certain > circumstance, the endpoint may know some info of access network, but I > suspect it might not be a general case, for example, for the femto > network, the cellular UE does not really know/care about the broadband > access. It is the access networks (including the AE in the access > network) that know it. > > Moreover, there are many different kinds of endpoints, according the QoS > draft, certain types i.e. Category 1, does not have the capability to > decide the QoS attributes. I believe the draft should and has been able > to support all variants. Not see any issue sofar. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 29, 2008 11:48 AM > To: McCann Peter-A001034; Sun, Dong (Dong) > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > (Reply for both Pete's and Dong's explanations) > > The origin of my question was the doubt whether all nodes would > implement both push and pull modes. I see that this is expected so there > won't be a problem of finding the right server. This makes it > unnecessary to use different Application-Ids from routing perspective (I > am still not sure whether support for both modes will be universal but > it seems I am in minority on this one). > > > I need clarification on one point though: > Both of you stated AppS knowing that push mode is necessary requires > that it is aware of access network type used the terminal. IMHO it is > more than that: access network type, terminal capabilities, whether QoS > reservation is requested for the session by the enduser all play a role > in this decision AFAICS. Even for access provider it may not be possible > to know the answer for all these questions. > > For example: > 1) AppS receives the session request and decides that this type of > session requires QoS reservation > 2) It sends a request to the AE > 3) How does the AE determine whether a push mode reservation is really > necessary? > > There seem to be only a single entity with perfect information: the > terminal/enduser. I would expect the endpoint to signal its request for > the AppS to reserve QoS resources as part of the session signaling. > > Thanks, > Tolga > > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Tuesday, July 29, 2008 7:43 AM > > To: Sun, Dong (Dong); Asveren, Tolga > > Cc: Glen Zorn; Avri Doria; dime@ietf.org > > Subject: RE: [Dime] [Fwd: Comments for > draft-ietf-dime-diameter-qos-06] > > /Application-Id > > > > One of the motivations for introducing a Diameter QoS protocol was > > indeed to provide an interface between applications (such as a > > streaming video server) and network elements that need to enforce QoS. > > > I think net neutrality means documenting this interface and opening it > > > up to anyone that has a connection to the "Diameter Cloud". > > > > That being said, I don't have a strong opinion on whether we should > > use 1 or 2 Application IDs; personally I think it is easier for the > > application endpoint in a user terminal to provide an authentication > > token that points to an application server domain than it is to have > > the application server figure out the access network to which the user > > > is attached based only on its IP address. This is why the original > > document had pull-only. > > If the AppS can figure out the Destination-Realm of the enforcing > > NE(s) then we should use standard Diameter routing based on > > Destination-Realm. Having a separate application ID for each mode of > > operation might lead us down the path of having some nodes implement > > only one half of the protocol which could lead to interoperability > > problems. > > > > -Pete > > > > Sun, Dong (Dong) wrote: > > > Tolga, > > > > > > The scenario A) mandates the application SP being aware of > underlying > > > network technology and operation mode (i.e. push or pull) and making > > > > a selection, which is not the intention of QoS application (and net > > > neutrality). And I don't think the content provider (let's say > > > youtube) really cares about which mode is used for the QoS guarantee > > > > in the transport network. > > > > > > If you still have question, please give me a call. We can chat about > > > > it in detail. > > > > > > Regards, > > > Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Monday, July 28, 2008 3:57 PM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / Application-Id > > > > > > Hi Dong, > > > > > > Let's talk over an example because I seriously think we are cross > > > talking each other and there probably are a few things I don't > > > understand about QoS application: > > > > > > Org-1 is the service provider > > > Org-2 is the IP access provider > > > > > > App-push is the application-Id for push mode (if different AppIds > > > used) App-pullthe application-Id for pull mode (if different AppIds > > > used) > > > > > > AppQ is the application-Id for QoS application (if a single AppId is > > > used) > > > > > > > > > +-----+ > > > |AppS | (Org1) > > > +-----+ > > > | > > > +-------+ | > > > (Org2) |AE-gw |--------+ > > > +-------+ > > > | > > > | > > > +-------+ > > > (Org2) | AE1 | > > > +-------+ > > > | > > > | > > > +-------+ > > > (Org2) | NE1 | > > > +-------+ > > > A) With different Application-Ids > > > 1- AppS receives a new session request and determines that QoS needs > > > > to be reserved on the access side for a particular flow. It > > > determines (by whatever means) that the access side is controlled by > > > > Org2. > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > Application-Id=push. This request reaches AE-gw via standard > Diameter > > > Base Protocol routing (during capability exchange procedure AE-gw > > > advertised App-push) [Actually here AppS will need to rely on some > > > provisioning as well as capability advertisement is not done per > > > realm, i.e. it won't be clear to AppS that AE-gw supports push-mode > > > for Org2 realm. This IMHO is a missing piece of functionality in > > > Diameter base protocol but can be fixed relativel easily] > > > > > > 3- AE-gw routes the message to AE based on standard Diameter base > > > protocol routing (during capability exchange procedure AE1 > advertised > > > App-push). There could be other AEs in the network which are unable > > > to process this request because they do not know the binding between > > > > IP addresses and NEs. This is not a problem though as they would > > > advertise only app-pull during capability exchange procedure) > > > > > > What is here that violates network neutrality? > > > > > > > > > B) With a single Application-Id > > > 1- AppS receives a new session request and determines that QoS needs > > > > to be reserved on the access side for a particular flow. It > > > determines (by whatever means) that the access side is controlled by > > > > Org2. > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > Application-Id=AppQ. This request reaches AE-gw via standard > Diameter > > > Base Protocol routing (during capability exchange procedure AE-gw > > > advertised AppQ). > > > > > > 3- AE-gw needs to route the message based on provisioning. Why? > > > Because it needs to find an AE which can handle push mode. It can't > > > rely on capability advertisement because all types of AEs will > > > advertise support for AppQ. > > > > > > Is my understanding for single Application-Id correct? If so, with > > > single Application-Id model there are more steps relying on > > > provisioning rather than on dynamic capability exchange procedures > > > (and for different Application-Id model we can make routing > > > completely dynamic with some minor extensions to the base protocol) > > > > > > > > > I don't believe two Application-Ids add any significant additional > > > complexity. If a node can support Diameter Base Protocol (capability > > > > exchange, connection state machine) and QoS application (application > > > > state machine, new AVPs) etc... it is hard for me to believe that > two > > > Application-Ids makes development of such nodes more complex. > > > > > > > > > It is likely that we will agree to disagree on this one if my > > > understanding of single Application-Id routing is correct. > > > > > > Thanks, > > > Tolga > > > > > >> -----Original Message----- > > >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > >> Sent: Monday, July 28, 2008 12:53 PM > > >> To: Asveren, Tolga > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > >> A001034; Avri Doria; Tina TSOU; Glen Zorn > > >> Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / > > >> Application-Id > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > >> Sent: Monday, July 28, 2008 11:12 AM > > >> To: Sun, Dong (Dong) > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > >> Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] > > >> / Application-Id > > >> > > >> Hi Dong, > > >> > > >> Inline.... > > >> > > >> Thanks, > > >> Tolga > > >> > > >>> -----Original Message----- > > >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > >>> Sent: Thursday, July 24, 2008 2:19 PM > > >>> To: Asveren, Tolga > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn > > >>> Subject: RE: [Fwd: [Dime] Comments for > > >> draft-ietf-dime-diameter-qos-06] / > > >>> Application-Id > > >>> > > >>> Tolga, > > >>> Comments inline. > > >>> Dong > > >>> > > >>> -----Original Message----- > > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > >>> Sent: Thursday, July 24, 2008 11:13 AM > > >>> To: Sun, Dong (Dong) > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > >>> Subject: RE: [Fwd: [Dime] Comments for > > >> draft-ietf-dime-diameter-qos-06] > > >>> / Application-Id > > >>> > > >>> (Continuing in separate threads for each issue for easier > tracking.) > > >>> > > >>> Hi Dong, > > >>> > > >>> One comment below. > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> [.. snip ..] > > >>>>> > > >>>>> 1- Use of the same Application-Id for push/pull models It sounds > > > > > >>>>> reasonable to me to think nodes which support only a single > mode. > > >>>>> How can we guarantee that messages land to the right server > > >>>>> considering that the same Application-Id is used for both of > them? > > >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and pull > > > >>>>> models is different, for example, when a new request from the > PEP > > >>>>> is recevied, the Server will start the pull model. In fact, the > > >>>>> push and pull are sharing the same state machine per se. the > main > > >>>>> difference is just how to establish a Diameter session. The > > >>>>> enhancement is to allow the Diameter > > >>>> > > >>>>> Server to establish a session with a local trigger instead of > the > > >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I > > >>>>> don't think the same application-Id causes any problem, > > >>>>> especially for the pull model since > > >>>> > > >>>>> push/pull is able use the same server (certainly they can also > > >>>>> have separate server according to the configuration). > > >>>> [TOLGA]My concern here is about message routing rather than the > > >>>> state machine processing in the server. Let's say a server is > > >>>> capable only to accommodate pull model (it doesn't know what NE > to > > >>>> contact if push model is required). How can the network > > >>>> intermediaries, e.g. relay agent, forward the initial request in > > >>>> the session to the right server for push model? How can they be > > >>>> sure that the server supports push model? [Dong] The relay agent > > >>>> should route the message according to the destination > > >>>> address/realm that is filled up by the requestor. I don't know > how > > >>>> the application id will affect this kind of routing. > > >>> [TOLGA]The initial message of a session may have only > > >>> Destination-Realm. In such a case Application-Id is used by > > >>> intermediaries to select the right server. [Dong] In the context > of > > >>> QoS application, for the pull mode, the NE typically is configured > > > >>> by a default policy server or redirect server. I don't think the > > >>> scenario you are concerned is a common case in reality > > >> > > >>> although theoretically the base Diameter protocol may allow this > > >>> kind of behavior, but it is not the case for QoS application, > IMHO. > > >> [TOLGA] How can we make sure that a request requiring push mode > > >> capabilities is delivered to the right server? That was my initial > > >> question. There could be servers which only have authorization > > >> capability but do not have any topology information, i.e. not > > >> suitable > > > > > >> for push mode operation. And what type of problems would be > > >> introduced > > > > > >> if we used two different Application-Ids? > > >> [Dong] Either Application Server or UE or NE needs to perform the > > >> selection of AE according to its capabilities. In the case there > are > > >> different AEs for push or pull respectively, a rendezvous AE will > > >> make a selection according to the policy, network technology and/or > > > >> request attribute. The problem to have two different application id > > > >> is to mandate the selection of an AE per its capabilities to the > > >> AppS (or NE), it is inconsistent with the basic rationale of the > QoS > > >> application (i.e. maintain the network neutrality). Moreover, it > > >> makes the QoS application and implementations more complex since > two > > >> packages have to be developed... > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 09:45:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C342B3A691E; Tue, 29 Jul 2008 09:45:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410173A691E for ; Tue, 29 Jul 2008 09:45:50 -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 rSoPWl2RBEyE for ; Tue, 29 Jul 2008 09:45:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B75233A6922 for ; Tue, 29 Jul 2008 09:45:44 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6TGiqCT010179; Tue, 29 Jul 2008 11:45:38 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 11:45:37 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:45:35 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEE86@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D46C5@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SAACJCP4AAhFUtgAAEvGuA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46C5@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 29 Jul 2008 16:45:37.0314 (UTC) FILETIME=[870DB820:01C8F19A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Tolga, I am opposing any great idea to support the failover. Meanwhile, as far as I can see, the approach you proposed is just one option. BTW, I am not saying it does not work. The bottom line, again, I do seek a common mechanism/framework for the failover. Sure, in your approach, the detailed application state related info may vary, but I am not sure if it will make any essential difference for the mechanism. This is a sophiscated and general issue. I don't want to jump into a special solution for the QoS application since I believe a generic mechanism (i.e. the common state machine) can help minimize the development effort as a whole for the Diameter protocol stack. As far as I know, it seems the failure approach defined in 4006 (i.e. "Credit-Control-Failure-Handling" if it is what you refer to) is not yet widely used by the industry and other SDOs for the time being (due to the complexity, I guess). Please correct me if I am wrong about this point. Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Tuesday, July 29, 2008 12:21 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Hi Dong, It is a great help for developers if a message contains information to reconstruct a session after a failover. If you don't think that this is a good idea/necessary or creates too much overhead then fine. And actually this probably would require more than the change I asked. I don't think there could be a general mechanism to provide all the support needed for failover friendliness; it is not just about deciding whether a request is for an existing session but also reconstructing existing state (which is different for each application). IMHO DCCA(RFC4006) is a good example. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Monday, July 28, 2008 8:46 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > > Before we move further on the failure handover issue, I'd like to > clarify a basic question (I need some education from the Diameter > experts): in 3588 and 4005, how a new session is recogizied by the > Diameter Server? It seems no one uses the explicit indicator for > identifying a new session, if my understanding is correct. Furthermore, > if we rely on the Diameter client for the indication of new session, it > may cause the problem when the client recovers from the failure, e.g. it > may think the recovered session as a new session. > > As I indicated, the QoS application is intended to keep consistent with > the base protocol and the "mom" protocol 4005. In fact, besides the > session-id, the QoS application also looks at the QoS resources and > other AVPs to decide the transition of the session state. > > I just like to highligh my point: how to handle failover is a general > issue, I don't think the QoS application requires any extra mechanism > compared to any other applications. So I'd like to adapt a generic > mechanism already used by other applications if possible, rather than > creating an "unique" mechanism here. > > Regards, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Monday, July 28, 2008 4:02 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > I am not proposing to add anything special to QoS application but just > not relying on the type of first command received to determine the QoS > model used. IMHO using an AVP for this purpose is a better approach > because using command type brings extra complexity from cold-standby > system design perspective. Furthermore it is just overloading the > meaning of the command code. > > I just wanted to summarize the issue. My current understanding is that > we agree to disagree on this one. > > Thanks, > Tolga > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Monday, July 28, 2008 1:07 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Inline... > > Rgs, - Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 12:16 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Resending..... > > > > > > > > > > Hi Dong, > > > > inline.... > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > Sent: Thursday, July 24, 2008 2:49 PM > > > To: Asveren, Tolga > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > > > failover friendliness > > > > > > Tolga, > > > Since you agreed that the general failure handling for Diameter is > out > > > > > of scope in the QoS application. In principle, I don't see the > > necessity > > > to include extra overhead as the mandatory parameters. Frankly, the > > > failure handling of the Diameter Server is a quite comprehensive > > issue. > > > Sofar, the QoS application should provide some basic failure > handling > > > e.g. clean up the expired sessions, but I am not sure if it is > > > appropriate to discuss what you address in the QoS application > > > exclusively. I assume it should be part of base protocol or separate > > > > document (I am not sure if it already has) since they are supposed > to > > > generic to all applications. > > > > > > See additional comments inline. > > > > > > Rgs, > > > Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Thursday, July 24, 2008 11:44 AM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > > > / failover friendliness > > > > > > Hi Dong, > > > > > > Comments/questions below. > > > > > > Thanks, > > > Tolga > > > > > > > > > [.. snip ..] > > > > > 6- 4.2 Session Establishment > > > > > "When a QoS-Authz-Request > > > > > (QAR, see Section 5.1) message with a new session ID is > > received, > > > > the > > > > > AE operates in the Pull mode; when other triggers are > received, > > > the > > > > > AE operates in the Push mode." > > > > > Would this shut down the door for certain failure recovery > > > scenarios? > > > > > For example AE goes down and a backup AE takes over. IMO it is a > > > nice > > > > > feature if the backup can continue existing sessions without a > > need > > > to > > > > > > > > > synchronizing state with the failed active AE. This can be > > achieved > > > by > > > > > > > > > carrying enough information about session state in the message > > > itself > > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes > this > > > > > > > impossible. For certain scenarios backup AE would determine the > > > > required > > > > > mode wrong. I suggest the decision for push/pull is not based on > > > > message > > > > > name but on the message content. > > > > > [Sun, Dong (Dong)] I think this is the most straightforward and > > > > > > consistent way in terms of state machine to decide the > pull/push. > > > and > > > > it > > > > > will work well for the hot standby case, but indeed, it may have > > > some > > > > > issue with cold standby. In general, the failure handling is not > > > > addressed > > > > > in the draft very much. The question is, do we need to add the > > > failure > > > > > > > > > handling in detail or not for backup server case? > > > > [TOLGA]I agree that details of failure handling may not belong > here. > > > > OTOH that the QoS application is failover friendly is a parameter > to > > > > > > consider IMHO. By carrying enough information in each message so > > that > > > > cold standby elements can be used to take over existing sessions, > > one > > > > trades small amount of bandwidth and limited CPU cycles for > > complexity > > > > > > > in software and probably even more CPU cycles. IMHO this is a > > bargain. > > > I > > > > found this very handy in DCCA. Wouldn't just defining an AVP > > > indicating > > > > the type of service requested (push v.s. pull) solve this problem? > > > > Actually this issue is also tied to Application-Id problem. If > > > different > > > > Application-Ids are used, that implicitly will define the mode > > > > required/used. > > > > [Dong] I don't think it makes sense to mandate this kind of > > parameter > > > > for failover since it is more useful for one type of failure > > handling > > > > approach rather than the other. But it is ok to have an optional > > > > parameter but it does add significant overhead in the message. In > > > > addition, not sure why the application id is tied up with this > > issue, > > > > even in general the routing issue as I explained above. > > > > I think the failure handling approach should be consistent for all > > > > > Diameter applications rather than defining specific one for QoS > > > > application. > > > [TOLGA] > > > 1) One can argue the other way around as well: Why exclude some > piece > > of > > > information which is useful for certain type of failover mechanism. > > IMHO > > > the added overhead is negligible and I am pretty sure much less than > > the > > > overhead of a hot standby system (let alone the extra complexity it > > > requires) > > > [Dong] as indicated, this is not my intention to discuss all > possible > > > varieties for failure handover to the standby Diameter server. I > > assume > > > a generic mechanism should be applied to QoS application. > > > > > > 2) If push/pull modes use different Application-Ids that could be > used > > > > > easily to decide for which mode the message is received. OTOH I > agree > > > that this itself wouldn't help for failover friendliness. > > > [Dong] Using different application id for push/pull makes the state > > > mechanism less efficient and does not add too much value for the > > routing > > > since the scenarios you are concerned are not common (i.e. the > message > > > > > cannot provide a destination address) in reality for QoS > application, > > > IMHO. (sorry for saying this). > > [TOLGA]IMHO you are introducing unnecessary restrictions for no > reason. > > Diameter message routing is making use of Application-Id for initial > > requests. If you have a problem with this, you should voice your > > concerns for the 3588-bis document. Otherwise violating base protocol > > principles on a per application basis doesn't make sense to me. > > > > > > > > > > > > 3) There are certainly a few things which can be done in base > protocol > > > > > to help failover handling. OTOH base protocol is application state > > > machine agnostic. I don't see how it can help there. > > > [Dong] the failover handling you described does not look like a > > specific > > > case only for QoS application. In fact the failure of the server > does > > > not affect too much for ongoing bearer sessions since they will > remain > > > > > anyway. And I am not sure if the NE is the best option to store all > > > session info due to the cost effectiveness and processing capacity > > > issues. Maybe the synchronization between two servers is more > > efficient, > > > to some extent. > > [TOLGA]I don't think it is ever possible that base protocol can > provide > > redundancy features to cover for all application redundancy needs > > without any involvement from application itself. If you have any > > strategy in mind to deal with this problem please tell it. > > Actually what I am asking for is to remove a failover-unfriendly > feature > > rather than adding new stuff to facilitate redundancy. I really don't > > understand what is bad about including an AVP indicating the type. I > > simply don't buy the overhead argument. > > [Dong]I don't think the approach you described is a specific > requirement > > only to the QoS application. Then why don't we generalize the issue > and > > method rather than adding something only to the QoS application. In > > addition, it is obvious an optional approach for failure handling, and > I > > don't think current draft prevents any implementation from adding the > > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 09:52:02 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC363A6942; Tue, 29 Jul 2008 09:52:02 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C16E3A692E for ; Tue, 29 Jul 2008 09:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3KXQY2Lt-haO for ; Tue, 29 Jul 2008 09:51:59 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id AA17E3A6910 for ; Tue, 29 Jul 2008 09:51:59 -0700 (PDT) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m6TGpreq017178; Tue, 29 Jul 2008 11:52:07 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 11:52:04 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:52:03 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEE92@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D46CC@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzywAAXRb8AABCLmMAAAgyKgAACjneA= References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE5F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46CC@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" , "McCann Peter-A001034" X-OriginalArrivalTime: 29 Jul 2008 16:52:04.0968 (UTC) FILETIME=[6E1D0680:01C8F19B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org For some dumb endpoints, the AppS can decide whether the QoS reservation is required or not according to the service attribute and agreement and initiate the QoS reservation. It is not really sth new. The selection of push or pull is related to both access network capability and endpoint capability. However the relationship is pretty much static for a combination of one type endpoint and access network. The network can figure out based on the registration and configuration. Of course, if the endpoint can provide additional info, it also helps, but all the info from the endpoint should be authorized, which means the network makes final decision. Rgs, Dong -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Tuesday, July 29, 2008 12:38 PM To: Sun, Dong (Dong); McCann Peter-A001034 Cc: Glen Zorn; Avri Doria; dime@ietf.org Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Hi Dong, That the endpoint is able to reserve QoS resources is one thing, that it knows a particular session requires QoS reservation (not necessarily the attributes just the need) is another one. I expect the endpoint to know the latter for sure. I don't know what would happen for the following case: 1) The terminal is capable of reserving QoS 2) A softclient is running on the terminal which is not making use of QoS reservation capabilities of the terminal (it is a generic softclient) but it signals it desire for QoS as part of the session signaling Who will initiate the QoS reservation? My understanding of your explanation is that if an access network allows pull model then it won't allow push model as you seem tying the decision for push/pull model to the access network type (?). Is this always the case and are we sure that this always will be the case? Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 29, 2008 12:24 PM > To: Asveren, Tolga; McCann Peter-A001034 > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > Tolga, > > The AE controlling the access network resources should be able to know > the access technology and decide the push or pull mode. In certain > circumstance, the endpoint may know some info of access network, but I > suspect it might not be a general case, for example, for the femto > network, the cellular UE does not really know/care about the broadband > access. It is the access networks (including the AE in the access > network) that know it. > > Moreover, there are many different kinds of endpoints, according the QoS > draft, certain types i.e. Category 1, does not have the capability to > decide the QoS attributes. I believe the draft should and has been able > to support all variants. Not see any issue sofar. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 29, 2008 11:48 AM > To: McCann Peter-A001034; Sun, Dong (Dong) > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > (Reply for both Pete's and Dong's explanations) > > The origin of my question was the doubt whether all nodes would > implement both push and pull modes. I see that this is expected so there > won't be a problem of finding the right server. This makes it > unnecessary to use different Application-Ids from routing perspective (I > am still not sure whether support for both modes will be universal but > it seems I am in minority on this one). > > > I need clarification on one point though: > Both of you stated AppS knowing that push mode is necessary requires > that it is aware of access network type used the terminal. IMHO it is > more than that: access network type, terminal capabilities, whether QoS > reservation is requested for the session by the enduser all play a role > in this decision AFAICS. Even for access provider it may not be possible > to know the answer for all these questions. > > For example: > 1) AppS receives the session request and decides that this type of > session requires QoS reservation > 2) It sends a request to the AE > 3) How does the AE determine whether a push mode reservation is really > necessary? > > There seem to be only a single entity with perfect information: the > terminal/enduser. I would expect the endpoint to signal its request for > the AppS to reserve QoS resources as part of the session signaling. > > Thanks, > Tolga > > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Tuesday, July 29, 2008 7:43 AM > > To: Sun, Dong (Dong); Asveren, Tolga > > Cc: Glen Zorn; Avri Doria; dime@ietf.org > > Subject: RE: [Dime] [Fwd: Comments for > draft-ietf-dime-diameter-qos-06] > > /Application-Id > > > > One of the motivations for introducing a Diameter QoS protocol was > > indeed to provide an interface between applications (such as a > > streaming video server) and network elements that need to enforce QoS. > > > I think net neutrality means documenting this interface and opening it > > > up to anyone that has a connection to the "Diameter Cloud". > > > > That being said, I don't have a strong opinion on whether we should > > use 1 or 2 Application IDs; personally I think it is easier for the > > application endpoint in a user terminal to provide an authentication > > token that points to an application server domain than it is to have > > the application server figure out the access network to which the user > > > is attached based only on its IP address. This is why the original > > document had pull-only. > > If the AppS can figure out the Destination-Realm of the enforcing > > NE(s) then we should use standard Diameter routing based on > > Destination-Realm. Having a separate application ID for each mode of > > operation might lead us down the path of having some nodes implement > > only one half of the protocol which could lead to interoperability > > problems. > > > > -Pete > > > > Sun, Dong (Dong) wrote: > > > Tolga, > > > > > > The scenario A) mandates the application SP being aware of > underlying > > > network technology and operation mode (i.e. push or pull) and making > > > > a selection, which is not the intention of QoS application (and net > > > neutrality). And I don't think the content provider (let's say > > > youtube) really cares about which mode is used for the QoS guarantee > > > > in the transport network. > > > > > > If you still have question, please give me a call. We can chat about > > > > it in detail. > > > > > > Regards, > > > Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Monday, July 28, 2008 3:57 PM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / Application-Id > > > > > > Hi Dong, > > > > > > Let's talk over an example because I seriously think we are cross > > > talking each other and there probably are a few things I don't > > > understand about QoS application: > > > > > > Org-1 is the service provider > > > Org-2 is the IP access provider > > > > > > App-push is the application-Id for push mode (if different AppIds > > > used) App-pullthe application-Id for pull mode (if different AppIds > > > used) > > > > > > AppQ is the application-Id for QoS application (if a single AppId is > > > used) > > > > > > > > > +-----+ > > > |AppS | (Org1) > > > +-----+ > > > | > > > +-------+ | > > > (Org2) |AE-gw |--------+ > > > +-------+ > > > | > > > | > > > +-------+ > > > (Org2) | AE1 | > > > +-------+ > > > | > > > | > > > +-------+ > > > (Org2) | NE1 | > > > +-------+ > > > A) With different Application-Ids > > > 1- AppS receives a new session request and determines that QoS needs > > > > to be reserved on the access side for a particular flow. It > > > determines (by whatever means) that the access side is controlled by > > > > Org2. > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > Application-Id=push. This request reaches AE-gw via standard > Diameter > > > Base Protocol routing (during capability exchange procedure AE-gw > > > advertised App-push) [Actually here AppS will need to rely on some > > > provisioning as well as capability advertisement is not done per > > > realm, i.e. it won't be clear to AppS that AE-gw supports push-mode > > > for Org2 realm. This IMHO is a missing piece of functionality in > > > Diameter base protocol but can be fixed relativel easily] > > > > > > 3- AE-gw routes the message to AE based on standard Diameter base > > > protocol routing (during capability exchange procedure AE1 > advertised > > > App-push). There could be other AEs in the network which are unable > > > to process this request because they do not know the binding between > > > > IP addresses and NEs. This is not a problem though as they would > > > advertise only app-pull during capability exchange procedure) > > > > > > What is here that violates network neutrality? > > > > > > > > > B) With a single Application-Id > > > 1- AppS receives a new session request and determines that QoS needs > > > > to be reserved on the access side for a particular flow. It > > > determines (by whatever means) that the access side is controlled by > > > > Org2. > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > Application-Id=AppQ. This request reaches AE-gw via standard > Diameter > > > Base Protocol routing (during capability exchange procedure AE-gw > > > advertised AppQ). > > > > > > 3- AE-gw needs to route the message based on provisioning. Why? > > > Because it needs to find an AE which can handle push mode. It can't > > > rely on capability advertisement because all types of AEs will > > > advertise support for AppQ. > > > > > > Is my understanding for single Application-Id correct? If so, with > > > single Application-Id model there are more steps relying on > > > provisioning rather than on dynamic capability exchange procedures > > > (and for different Application-Id model we can make routing > > > completely dynamic with some minor extensions to the base protocol) > > > > > > > > > I don't believe two Application-Ids add any significant additional > > > complexity. If a node can support Diameter Base Protocol (capability > > > > exchange, connection state machine) and QoS application (application > > > > state machine, new AVPs) etc... it is hard for me to believe that > two > > > Application-Ids makes development of such nodes more complex. > > > > > > > > > It is likely that we will agree to disagree on this one if my > > > understanding of single Application-Id routing is correct. > > > > > > Thanks, > > > Tolga > > > > > >> -----Original Message----- > > >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > >> Sent: Monday, July 28, 2008 12:53 PM > > >> To: Asveren, Tolga > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > >> A001034; Avri Doria; Tina TSOU; Glen Zorn > > >> Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / > > >> Application-Id > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > >> Sent: Monday, July 28, 2008 11:12 AM > > >> To: Sun, Dong (Dong) > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > >> Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] > > >> / Application-Id > > >> > > >> Hi Dong, > > >> > > >> Inline.... > > >> > > >> Thanks, > > >> Tolga > > >> > > >>> -----Original Message----- > > >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > >>> Sent: Thursday, July 24, 2008 2:19 PM > > >>> To: Asveren, Tolga > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn > > >>> Subject: RE: [Fwd: [Dime] Comments for > > >> draft-ietf-dime-diameter-qos-06] / > > >>> Application-Id > > >>> > > >>> Tolga, > > >>> Comments inline. > > >>> Dong > > >>> > > >>> -----Original Message----- > > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > >>> Sent: Thursday, July 24, 2008 11:13 AM > > >>> To: Sun, Dong (Dong) > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > >>> Subject: RE: [Fwd: [Dime] Comments for > > >> draft-ietf-dime-diameter-qos-06] > > >>> / Application-Id > > >>> > > >>> (Continuing in separate threads for each issue for easier > tracking.) > > >>> > > >>> Hi Dong, > > >>> > > >>> One comment below. > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> [.. snip ..] > > >>>>> > > >>>>> 1- Use of the same Application-Id for push/pull models It sounds > > > > > >>>>> reasonable to me to think nodes which support only a single > mode. > > >>>>> How can we guarantee that messages land to the right server > > >>>>> considering that the same Application-Id is used for both of > them? > > >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and pull > > > >>>>> models is different, for example, when a new request from the > PEP > > >>>>> is recevied, the Server will start the pull model. In fact, the > > >>>>> push and pull are sharing the same state machine per se. the > main > > >>>>> difference is just how to establish a Diameter session. The > > >>>>> enhancement is to allow the Diameter > > >>>> > > >>>>> Server to establish a session with a local trigger instead of > the > > >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I > > >>>>> don't think the same application-Id causes any problem, > > >>>>> especially for the pull model since > > >>>> > > >>>>> push/pull is able use the same server (certainly they can also > > >>>>> have separate server according to the configuration). > > >>>> [TOLGA]My concern here is about message routing rather than the > > >>>> state machine processing in the server. Let's say a server is > > >>>> capable only to accommodate pull model (it doesn't know what NE > to > > >>>> contact if push model is required). How can the network > > >>>> intermediaries, e.g. relay agent, forward the initial request in > > >>>> the session to the right server for push model? How can they be > > >>>> sure that the server supports push model? [Dong] The relay agent > > >>>> should route the message according to the destination > > >>>> address/realm that is filled up by the requestor. I don't know > how > > >>>> the application id will affect this kind of routing. > > >>> [TOLGA]The initial message of a session may have only > > >>> Destination-Realm. In such a case Application-Id is used by > > >>> intermediaries to select the right server. [Dong] In the context > of > > >>> QoS application, for the pull mode, the NE typically is configured > > > >>> by a default policy server or redirect server. I don't think the > > >>> scenario you are concerned is a common case in reality > > >> > > >>> although theoretically the base Diameter protocol may allow this > > >>> kind of behavior, but it is not the case for QoS application, > IMHO. > > >> [TOLGA] How can we make sure that a request requiring push mode > > >> capabilities is delivered to the right server? That was my initial > > >> question. There could be servers which only have authorization > > >> capability but do not have any topology information, i.e. not > > >> suitable > > > > > >> for push mode operation. And what type of problems would be > > >> introduced > > > > > >> if we used two different Application-Ids? > > >> [Dong] Either Application Server or UE or NE needs to perform the > > >> selection of AE according to its capabilities. In the case there > are > > >> different AEs for push or pull respectively, a rendezvous AE will > > >> make a selection according to the policy, network technology and/or > > > >> request attribute. The problem to have two different application id > > > >> is to mandate the selection of an AE per its capabilities to the > > >> AppS (or NE), it is inconsistent with the basic rationale of the > QoS > > >> application (i.e. maintain the network neutrality). Moreover, it > > >> makes the QoS application and implementations more complex since > two > > >> packages have to be developed... > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 10:15:48 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E413A69C4; Tue, 29 Jul 2008 10:15:48 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569093A69C4 for ; Tue, 29 Jul 2008 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 vRUC5Y9vTtyt for ; Tue, 29 Jul 2008 10:15:45 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id D87F93A69DC for ; Tue, 29 Jul 2008 10:15:42 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6THFXFU025291; Tue, 29 Jul 2008 13:15:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:15:30 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D46DB@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEE86@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SAACJCP4AAhFUtgAAEvGuAAAOm4QA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE86@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, O.K. fair enough. P.S.: It wasn't just Credit-Control-Failure-Handling AVP I was referring to but also inclusion of CC-Request-Type, CC-Request-Number etc... in every message. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 29, 2008 12:46 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > I am opposing any great idea to support the failover. Meanwhile, as far > as I can see, the approach you proposed is just one option. BTW, I am > not saying it does not work. > > The bottom line, again, I do seek a common mechanism/framework for the > failover. Sure, in your approach, the detailed application state related > info may vary, but I am not sure if it will make any essential > difference for the mechanism. > > This is a sophiscated and general issue. I don't want to jump into a > special solution for the QoS application since I believe a generic > mechanism (i.e. the common state machine) can help minimize the > development effort as a whole for the Diameter protocol stack. > > As far as I know, it seems the failure approach defined in 4006 (i.e. > "Credit-Control-Failure-Handling" if it is what you refer to) is not yet > widely used by the industry and other SDOs for the time being (due to > the complexity, I guess). Please correct me if I am wrong about this > point. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 29, 2008 12:21 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > It is a great help for developers if a message contains information to > reconstruct a session after a failover. If you don't think that this is > a good idea/necessary or creates too much overhead then fine. And > actually this probably would require more than the change I asked. > > I don't think there could be a general mechanism to provide all the > support needed for failover friendliness; it is not just about deciding > whether a request is for an existing session but also reconstructing > existing state (which is different for each application). IMHO > DCCA(RFC4006) is a good example. > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Monday, July 28, 2008 8:46 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Tolga, > > > > Before we move further on the failure handover issue, I'd like to > > clarify a basic question (I need some education from the Diameter > > experts): in 3588 and 4005, how a new session is recogizied by the > > Diameter Server? It seems no one uses the explicit indicator for > > identifying a new session, if my understanding is correct. > Furthermore, > > if we rely on the Diameter client for the indication of new session, > it > > may cause the problem when the client recovers from the failure, e.g. > it > > may think the recovered session as a new session. > > > > As I indicated, the QoS application is intended to keep consistent > with > > the base protocol and the "mom" protocol 4005. In fact, besides the > > session-id, the QoS application also looks at the QoS resources and > > other AVPs to decide the transition of the session state. > > > > I just like to highligh my point: how to handle failover is a general > > issue, I don't think the QoS application requires any extra mechanism > > compared to any other applications. So I'd like to adapt a generic > > mechanism already used by other applications if possible, rather than > > creating an "unique" mechanism here. > > > > Regards, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 4:02 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Hi Dong, > > > > I am not proposing to add anything special to QoS application but just > > > not relying on the type of first command received to determine the QoS > > > model used. IMHO using an AVP for this purpose is a better approach > > because using command type brings extra complexity from cold-standby > > system design perspective. Furthermore it is just overloading the > > meaning of the command code. > > > > I just wanted to summarize the issue. My current understanding is that > > > we agree to disagree on this one. > > > > Thanks, > > Tolga > > > -----Original Message----- > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > Sent: Monday, July 28, 2008 1:07 PM > > > To: Asveren, Tolga > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > > > failover friendliness > > > > > > Inline... > > > Rgs, - Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Monday, July 28, 2008 12:16 PM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > > > / failover friendliness > > > > > > Resending..... > > > > > > > > > > > > > > > Hi Dong, > > > > > > inline.... > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > > Sent: Thursday, July 24, 2008 2:49 PM > > > > To: Asveren, Tolga > > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter- > > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / > > > > failover friendliness > > > > > > > > Tolga, > > > > Since you agreed that the general failure handling for Diameter is > > out > > > > > > > of scope in the QoS application. In principle, I don't see the > > > necessity > > > > to include extra overhead as the mandatory parameters. Frankly, > the > > > > failure handling of the Diameter Server is a quite comprehensive > > > issue. > > > > Sofar, the QoS application should provide some basic failure > > handling > > > > e.g. clean up the expired sessions, but I am not sure if it is > > > > appropriate to discuss what you address in the QoS application > > > > exclusively. I assume it should be part of base protocol or > separate > > > > > > document (I am not sure if it already has) since they are supposed > > to > > > > generic to all applications. > > > > > > > > See additional comments inline. > > > > > > > > Rgs, > > > > Dong > > > > > > > > -----Original Message----- > > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > > Sent: Thursday, July 24, 2008 11:44 AM > > > > To: Sun, Dong (Dong) > > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] > > > > / failover friendliness > > > > > > > > Hi Dong, > > > > > > > > Comments/questions below. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > > [.. snip ..] > > > > > > 6- 4.2 Session Establishment > > > > > > "When a QoS-Authz-Request > > > > > > (QAR, see Section 5.1) message with a new session ID is > > > received, > > > > > the > > > > > > AE operates in the Pull mode; when other triggers are > > received, > > > > the > > > > > > AE operates in the Push mode." > > > > > > Would this shut down the door for certain failure recovery > > > > scenarios? > > > > > > For example AE goes down and a backup AE takes over. IMO it is > a > > > > nice > > > > > > feature if the backup can continue existing sessions without a > > > need > > > > to > > > > > > > > > > > synchronizing state with the failed active AE. This can be > > > achieved > > > > by > > > > > > > > > > > carrying enough information about session state in the message > > > > itself > > > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes > > this > > > > > > > > > impossible. For certain scenarios backup AE would determine > the > > > > > required > > > > > > mode wrong. I suggest the decision for push/pull is not based > on > > > > > message > > > > > > name but on the message content. > > > > > > [Sun, Dong (Dong)] I think this is the most straightforward > and > > > > > > > > consistent way in terms of state machine to decide the > > pull/push. > > > > and > > > > > it > > > > > > will work well for the hot standby case, but indeed, it may > have > > > > some > > > > > > issue with cold standby. In general, the failure handling is > not > > > > > addressed > > > > > > in the draft very much. The question is, do we need to add the > > > > failure > > > > > > > > > > > handling in detail or not for backup server case? > > > > > [TOLGA]I agree that details of failure handling may not belong > > here. > > > > > OTOH that the QoS application is failover friendly is a > parameter > > to > > > > > > > > consider IMHO. By carrying enough information in each message so > > > that > > > > > cold standby elements can be used to take over existing > sessions, > > > one > > > > > trades small amount of bandwidth and limited CPU cycles for > > > complexity > > > > > > > > > in software and probably even more CPU cycles. IMHO this is a > > > bargain. > > > > I > > > > > found this very handy in DCCA. Wouldn't just defining an AVP > > > > indicating > > > > > the type of service requested (push v.s. pull) solve this > problem? > > > > > Actually this issue is also tied to Application-Id problem. If > > > > different > > > > > Application-Ids are used, that implicitly will define the mode > > > > > required/used. > > > > > [Dong] I don't think it makes sense to mandate this kind of > > > parameter > > > > > for failover since it is more useful for one type of failure > > > handling > > > > > approach rather than the other. But it is ok to have an optional > > > > > > parameter but it does add significant overhead in the message. > In > > > > > addition, not sure why the application id is tied up with this > > > issue, > > > > > even in general the routing issue as I explained above. > > > > > I think the failure handling approach should be consistent for > all > > > > > > > Diameter applications rather than defining specific one for QoS > > > > > application. > > > > [TOLGA] > > > > 1) One can argue the other way around as well: Why exclude some > > piece > > > of > > > > information which is useful for certain type of failover > mechanism. > > > IMHO > > > > the added overhead is negligible and I am pretty sure much less > than > > > the > > > > overhead of a hot standby system (let alone the extra complexity > it > > > > requires) > > > > [Dong] as indicated, this is not my intention to discuss all > > possible > > > > varieties for failure handover to the standby Diameter server. I > > > assume > > > > a generic mechanism should be applied to QoS application. > > > > > > > > 2) If push/pull modes use different Application-Ids that could be > > used > > > > > > > easily to decide for which mode the message is received. OTOH I > > agree > > > > that this itself wouldn't help for failover friendliness. > > > > [Dong] Using different application id for push/pull makes the > state > > > > mechanism less efficient and does not add too much value for the > > > routing > > > > since the scenarios you are concerned are not common (i.e. the > > message > > > > > > > cannot provide a destination address) in reality for QoS > > application, > > > > IMHO. (sorry for saying this). > > > [TOLGA]IMHO you are introducing unnecessary restrictions for no > > reason. > > > Diameter message routing is making use of Application-Id for initial > > > > requests. If you have a problem with this, you should voice your > > > concerns for the 3588-bis document. Otherwise violating base > protocol > > > principles on a per application basis doesn't make sense to me. > > > > > > > > > > > > > > > > > 3) There are certainly a few things which can be done in base > > protocol > > > > > > > to help failover handling. OTOH base protocol is application state > > > > > machine agnostic. I don't see how it can help there. > > > > [Dong] the failover handling you described does not look like a > > > specific > > > > case only for QoS application. In fact the failure of the server > > does > > > > not affect too much for ongoing bearer sessions since they will > > remain > > > > > > > anyway. And I am not sure if the NE is the best option to store > all > > > > session info due to the cost effectiveness and processing capacity > > > > > issues. Maybe the synchronization between two servers is more > > > efficient, > > > > to some extent. > > > [TOLGA]I don't think it is ever possible that base protocol can > > provide > > > redundancy features to cover for all application redundancy needs > > > without any involvement from application itself. If you have any > > > strategy in mind to deal with this problem please tell it. > > > Actually what I am asking for is to remove a failover-unfriendly > > feature > > > rather than adding new stuff to facilitate redundancy. I really > don't > > > understand what is bad about including an AVP indicating the type. I > > > > simply don't buy the overhead argument. > > > [Dong]I don't think the approach you described is a specific > > requirement > > > only to the QoS application. Then why don't we generalize the issue > > and > > > method rather than adding something only to the QoS application. In > > > addition, it is obvious an optional approach for failure handling, > and > > I > > > don't think current draft prevents any implementation from adding > the > > > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 10:16:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C353A69C4; Tue, 29 Jul 2008 10:16:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D253A69C4 for ; Tue, 29 Jul 2008 10:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msNgiHUo4-37 for ; Tue, 29 Jul 2008 10:16:49 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id 4555C3A69B9 for ; Tue, 29 Jul 2008 10:16:43 -0700 (PDT) Received: (qmail 13231 invoked by uid 60001); 29 Jul 2008 17:16:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PGMzaIwYZd3rYLuQR3iQpRQeFx8791h+AR0+lV9mv6WwX/bcKpr+UNRfovEEYMo2nsPq4I8bNHMIcXIPT6JJ+E/74w/PHK7i3tIJWXJweYFLe58qn0EYYxttoJ7ZEB6wEghKsM8DhJnu3DmLnsHVq5c/vd6jRDa8geFNB2u+7is=; Received: from [130.129.20.221] by web84308.mail.re1.yahoo.com via HTTP; Tue, 29 Jul 2008 10:16:55 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Tue, 29 Jul 2008 10:16:55 -0700 (PDT) From: Behcet Sarikaya To: Hannes Tschofenig MIME-Version: 1.0 Message-ID: <772476.11729.qm@web84308.mail.re1.yahoo.com> Cc: dime@ietf.org Subject: Re: [Dime] draft-sarikaya-dimeradext-prefix-auth-ps-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0190333869==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --===============0190333869== Content-Type: multipart/alternative; boundary="0-785883996-1217351815=:11729" --0-785883996-1217351815=:11729 Content-Type: text/plain; charset=us-ascii Hi Hannes, It seems like you understood the problem. So in that sense draft-sarikaya-dimeradext-prefix-auth-ps achieved something . One clarification: the solution application for this PS will be of type RFC 4005, 4072 so it is not appropriate for SDOs to develop such an application as opposed to MIP6 bootstrapping type of applications, but instead the SDOs would be able to standardize the uses of such an application. Hope this clarifies. Regards, Behcet ----- Original Message ---- From: Hannes Tschofenig To: Behcet Sarikaya Cc: dime@ietf.org Sent: Monday, July 28, 2008 10:24:56 AM Subject: Re: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt Hi Behcet, I cannot comment on Avi's and Alper's feedback. I don't participate in Wimax, 3GPP, and 3GPP2. As you have seen during the meeting there wasn't support for the document in the room. I don't know why this is the case. There could be many reasons, ranging from "insufficient problem description to convince people" to "lack of time to help doing some work on it". This might, however, change as the deployment on IPv6 increases. Hence, I wouldn't be discouraged to continue the work on your document. Ciao Hannes Behcet Sarikaya wrote: > Hi Hannes, > Regarding the issue of SDOs and this draft raised by Avi, I am > surprised by the replies from Alper as well as from Avi. > The fact is that this problem (AAA based prefix authorization) was > not brought to any SDOs by us, at least not yet. I don't know what > type of conclusion can be made from this, I leave it up to the working > group. > I regret the statements made by WiMAX "guru" on this issue during > the meeting today. I suggest that people in such positions please make > correct (and possibly also objective) statements and refrain from > confusing other people in the meeting. > > Regards, > > Behcet > > ----- Original Message ---- > From: Hannes Tschofenig > To: Frank Xia > Cc: dime@ietf.org > Sent: Wednesday, July 23, 2008 3:13:21 PM > Subject: Re: [Dime] Relationship between > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > Hi Frank, > > Frank Xia wrote: > > Hi Hannes > > > > Please check my reply.. > > > > BR > > Frank > > ----- Original Message ----- From: "Hannes Tschofenig" > > > > > To: "Frank Xia" > > > Cc: > > > Sent: Wednesday, July 23, 2008 2:30 PM > > Subject: Re: [Dime] Relationship between > > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > > draft-sarikaya-dime-prefix-delegation-ps-01.txt > > > > > >> Hi Frank, > >> > >> thanks for the quick feedback. > >> > >> I have a few more comments inline > >> > >> Frank Xia wrote: > >>> Hi Hannes > >>> > >>> I try to jump ahead of Behcet to answer > >>> some of your questions :-) > >>> > >>> Please check inline comments. > >>> > >>> BR > >>> Frank > >>> > >>> > >>> ----- Original Message ----- From: "Hannes Tschofenig" > >>> > > >>> To: > > >>> Sent: Wednesday, July 23, 2008 7:41 AM > >>> Subject: [Dime] Relationship between > >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and > >>> draft-sarikaya-dime-prefix-delegation-ps-01.txt > >>> > >>> > >>>> I have sent my rechartering questions around regarding these two > >>>> documents. I took a brief look at them and I wonder what the > >>>> relationship between the two documents is. Why are there 2 > >>>> documents on almost the same subject? > >>>> > >>> Frank=>They have almost the same main idea. > >>> You can only refer to the draft > >>> > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt. > > >>> > >>> > >> Ok. We can essentially forget the other document. Right? > > Frank=>Yes. > > > >> > >> > >>>> When I browse through > >>>> > http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt > > >>>> then I sometimes get the impression that you would like to later > >>>> standardize a Diameter application. I wasn't sure why additional > >>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used? > >>> Frank=>Prefix delegation is an authorization which may be > >>> decoupled from an authentication. RFC4005/4072 only deal > >>> with coupled authentication& authorization scenario. > >>> > >> It is true that the request for prefix authorization is not run > >> independently from the message exchanges used for authentication. > > Frank=>A little bit confusing. You meant "independently " or not? > > > > I agree with you that RFC 4072 combines the prefix authorization > protocol run with the EAP protocol run. > > RFC 4005 is a bit different since it has the RAR and RAA commands that > allow you to perform re-authorization.Wouldn't they be a nice fit? > > >> > >>>> > >>>> Let me also comment on a few selected items: > >>>> > >>>> > >>>> AAA-based prefix authorization (PA) application MUST run between a > >>>> NAS, located on AR, LMA, MR, etc. and an AAA server. > >>>> > >>>> [hannes] This requirement does not say a lot. The AAA protocol is > >>>> always run between a client and a server. > >>>> > >>>> > >>>> > >>>> AAA-based PA application MUST support the AAA client to request > >>>> prefixes from an AAA server. AAA-based PA application MUST support > >>>> the client to give back the prefixes to the AAA server. > >>>> > >>>> [hannes] With the last sentence you mean that you need to have a > >>>> way to indicate that the AAA session is terminated? > >>> Frank=>In IPv6 renumbering scenario, it is necessary > >>> > >>>> > >>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the > >>>> devices on the network, the certificate or the information needed > >>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS. > >>>> > >>>> [hannes] What information do you exactly want to carry towards the > >>>> AAA client? > >>> Frank=>IPv6 address prefix for NAS is authorized to route > >>> > >> I mean, you want to provide > >> * prefix > >> * lifetime > >> * certificate > >> from the AAA server to the AAA client. > >> What else? > > Frank=> I can only find these now. > > > >> > >>>> > >>>> In point-to-point link operation, the NAS MUST identify the > >>>> interface of MN in its request. The NAS MAY provide a prefix hint, > >>>> e.g. of length /48 to which the AAA server MUST reply with one or > >>>> more prefixes, e.g. of length /64. > >>>> > >>>> [hannes] how would such an interface identifier look like? > >>> Frank=>Tentatively, it can be the interface identifier part of > >>> host's link local > >>> address, NAI (RFC4282), or MAC address. > >>> > >> I would like to better understand what the AAA server should be doing > >> based on this hint. > >> Is the "hint" used to identify the end user and it's host? > > Frank=>The hint is only for expressing client's preference. The > > server may honor this or not based on it's own discretion. > > > I guess you need to describe the details of this hint a bit more. > > >> > >>>> > >>>> In point-to-point operation, the AAA server MAY assign the > >>>> prefix(es) and related parameters such as the lifetime and the > >>>> certificates to MN from MN's profile. > >>>> > >>>> [hannes] I am not sure what this means. You mean that the AAA > >>>> server should keep state to make sure that it does not forget what > >>>> it has provided to the MN? > >>> Frank=>Probably, the AAA server for prefix delegation is different > from > >>> the AAA server for authentication. So it is necessary to record the > >>> state. > >>> > >> OK. > >> > >> I don't think that you need to say that since this is already done > >> today. > >> > >>>> For some reason the problem is not well described. In Section 3 of > >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC > >>>> 4818 but I do not quite understand what you would like to see > >>>> happening instead. > >>>> > >>>> AAA-based prefix authorization application SHOULD support prefix > >>>> release procedures. > >>>> > >>>> [hannes] isn't this the same as mentioned in the previous > >>>> requirement "AAA-based PA application MUST support the client to > >>>> give back the prefixes to the AAA server. " > >>> Frank=>It is the same. > >>> > >>>> > >>>> The NAS is responsible for renewing the prefixes when the lifetime > >>>> expires. The NAS SHOULD be able to extend the lifetime of the > >>>> prefixes using messages designed for this purpose. > >>>> > >>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the > >>>> lifetime of the AAA session itself? Makes things much easier. The > >>>> same applies a bit to this requirement: "It SHOULD be possible to > >>>> renumber the prefixes authorized by AAA server. The AAA server > >>>> SHOULD initiate prefix renumbering process. " > >>> Frank=>IPv6 renumbering is a feature of IPv6. > >>> If we tie the lifetime of prefix to the lifetime of AAA session, > >>> it is certain that we can't suport IPv6 renumbering. > >>> Even though IPv6 renumbering probably happen probably > >>> infrequently, it is better for us to have such a mechnism to support. > >>> > >>> For IPv6 renumbering, here are some references > >>> RFC 1916/2071/2072/2874/2894/4076/4192. > >>> > >> I know IPv6 renumbering but I was wondering about the following issue. > >> > >> IPv6 renumber should occur less frequently and hence the lifetime is > >> rather long. > >> A AAA session typically isn't very long lived and it is possible to > >> influence the lifetime with various parameters. > > Frank=>IMHO, I don't agree with your assumption on AAA session lifetime. > > In fact, many people including me are always online because many > > operators > > don't charge based on time. For example, $30 a month is for no > > limited access. > > > I don't know your home setup but typically you have a DSL router at home > and your PC / laptop may be running all the time. Your DSL router > re-connects automatically when re-authentication is needed. > > >> > >> Now, isn't it possible to re-authenticate and re-authorize the end > >> host in case of network renumbering. Given that you have to > >> re-authenticate quite often for other reasons as well shouldn't cause > >> big problems. > > Frank=>IMHO, it is not very graceful to kick off all the users > > when renumbering. > Maybe. > > When I look at the IT problems I had this year then renumbering is the > least thing I worry about. > > >> > >> I am just trying to figure out how tough the requirements are. > > Frank=>IMHO, it is very hard to figure out before widely IPv6 > deployment. > > However, it is probably too late after large scale deployment. > > > Difficult to know, I agree. > > Ciao > Hannes > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --0-785883996-1217351815=:11729 Content-Type: text/html; charset=us-ascii
Hi Hannes,
  It seems like you understood the problem.  So in that sense  draft-sarikaya-dimeradext-prefix-auth-ps achieved something .
One clarification: the solution application for this PS will be of type RFC 4005, 4072 so it is not appropriate for SDOs to develop such an application as opposed to MIP6 bootstrapping type of applications, but instead the SDOs would be able to standardize the uses of such an application. Hope this clarifies.

Regards,

Behcet

----- Original Message ----
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: dime@ietf.org
Sent: Monday, July 28, 2008 10:24:56 AM
Subject: Re: draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

Hi Behcet,

I cannot comment on Avi's and Alper's feedback. I don't participate in
Wimax, 3GPP, and 3GPP2.

As you have seen during the meeting there wasn't support for the
document in the room. I don't know why this is the case. There could be
many reasons, ranging from "insufficient problem description to convince
people" to "lack of time to help doing some work on it". This might,
however, change as the deployment on IPv6 increases.
Hence, I wouldn't be discouraged to continue the work on your document.

Ciao
Hannes

Behcet Sarikaya wrote:
> Hi Hannes,
>  Regarding the issue of SDOs and this draft raised by Avi, I am
> surprised by the replies from Alper as well as from Avi.
>  The fact is that this problem (AAA based prefix authorization) was
> not brought to any SDOs by us, at least not yet. I don't know what
> type of conclusion can be made from this, I leave it up to the working
> group.
>  I regret the statements made by WiMAX "guru" on this issue during
> the meeting today. I suggest that people in such positions please make
> correct (and possibly also objective) statements and refrain from
> confusing other people in the meeting.
>
> Regards,
>
> Behcet
>
> ----- Original Message ----
> From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> To: Frank Xia <xiayangsong@huawei.com>
> Cc: dime@ietf.org
> Sent: Wednesday, July 23, 2008 3:13:21 PM
> Subject: Re: [Dime] Relationship between
> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and
> draft-sarikaya-dime-prefix-delegation-ps-01.txt
>
> Hi Frank,
>
> Frank Xia wrote:
> > Hi Hannes
> >
> > Please check my reply..
> >
> > BR
> > Frank
> > ----- Original Message ----- From: "Hannes Tschofenig"
> > <Hannes.Tschofenig@gmx.net <mailto:Hannes.Tschofenig@gmx.net>>
> > To: "Frank Xia" <xiayangsong@huawei.com <mailto:xiayangsong@huawei.com>>
> > Cc: <dime@ietf.org <mailto:dime@ietf.org>>
> > Sent: Wednesday, July 23, 2008 2:30 PM
> > Subject: Re: [Dime] Relationship between
> > draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and
> > draft-sarikaya-dime-prefix-delegation-ps-01.txt
> >
> >
> >> Hi Frank,
> >>
> >> thanks for the quick feedback.
> >>
> >> I have a few more comments inline
> >>
> >> Frank Xia wrote:
> >>> Hi Hannes
> >>>
> >>> I try to jump ahead of Behcet to  answer
> >>> some of your questions :-)
> >>>
> >>> Please check inline comments.
> >>>
> >>> BR
> >>> Frank
> >>>
> >>>
> >>> ----- Original Message ----- From: "Hannes Tschofenig"
> >>> <Hannes.Tschofenig@gmx.net <mailto:Hannes.Tschofenig@gmx.net>>
> >>> To: <dime@ietf.org <mailto:dime@ietf.org>>
> >>> Sent: Wednesday, July 23, 2008 7:41 AM
> >>> Subject: [Dime] Relationship between
> >>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and
> >>> draft-sarikaya-dime-prefix-delegation-ps-01.txt
> >>>
> >>>
> >>>> I have sent my rechartering questions around regarding these two
> >>>> documents. I took a brief look at them and I wonder what the
> >>>> relationship between the two documents is. Why are there 2
> >>>> documents on almost the same subject?
> >>>>
> >>> Frank=>They have almost the same main idea.
> >>> You can only refer to the draft
> >>>
> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt.
>
> >>>
> >>>
> >> Ok. We can essentially forget the other document. Right?
> > Frank=>Yes.
> >
> >>
> >>
> >>>> When I browse through
> >>>>
> http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt
>
> >>>> then I sometimes get the impression that you would like to later
> >>>> standardize a Diameter application. I wasn't sure why additional
> >>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used?
> >>> Frank=>Prefix delegation is an authorization which may be
> >>> decoupled from an authentication. RFC4005/4072 only deal
> >>> with coupled authentication& authorization scenario.
> >>>
> >> It is true that the request for prefix authorization is not run
> >> independently from the message exchanges used for authentication.
> > Frank=>A little bit confusing.  You meant "independently " or not?
> >
>
> I agree with you that RFC 4072 combines the prefix authorization
> protocol run with the EAP protocol run.
>
> RFC 4005 is a bit different since it has the RAR and RAA commands that
> allow you to perform re-authorization.Wouldn't they be a nice fit?
>
> >>
> >>>>
> >>>> Let me also comment on a few selected items:
> >>>>
> >>>>
> >>>> AAA-based prefix authorization (PA) application MUST run between a
> >>>> NAS, located on AR, LMA, MR, etc. and an AAA server.
> >>>>
> >>>> [hannes] This requirement does not say a lot. The AAA protocol is
> >>>> always run between a client and a server.
> >>>>
> >>>>
> >>>>
> >>>> AAA-based PA application MUST support the AAA client to request
> >>>> prefixes from an AAA server. AAA-based PA application MUST support
> >>>> the client to give back the prefixes to the AAA server.
> >>>>
> >>>> [hannes] With the last sentence you mean that you need to have a
> >>>> way to indicate that the AAA session is terminated?
> >>> Frank=>In IPv6 renumbering scenario, it is necessary
> >>>
> >>>>
> >>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the
> >>>> devices on the network, the certificate or the information needed
> >>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS.
> >>>>
> >>>> [hannes] What information do you exactly want to carry towards the
> >>>> AAA client?
> >>> Frank=>IPv6 address prefix for NAS is authorized to route
> >>>
> >> I mean, you want to provide
> >> * prefix
> >> * lifetime
> >> * certificate
> >> from the AAA server to the AAA client.
> >> What else?
> > Frank=> I can only find these now.
> >
> >>
> >>>>
> >>>> In point-to-point link operation, the NAS MUST identify the
> >>>> interface of MN in its request. The NAS MAY provide a prefix hint,
> >>>> e.g. of length /48 to which the AAA server MUST reply with one or
> >>>> more prefixes, e.g. of length /64.
> >>>>
> >>>> [hannes] how would such an interface identifier look like?
> >>> Frank=>Tentatively, it can be the interface identifier part of
> >>> host's link local
> >>> address, NAI (RFC4282), or MAC address.
> >>>
> >> I would like to better understand what the AAA server should be doing
> >> based on this hint.
> >> Is the "hint" used to identify the end user and it's host?
> > Frank=>The hint is only for expressing client's preference.  The
> > server may honor this or not based on it's own discretion.
> >
> I guess you need to describe the details of this hint a bit more.
>
> >>
> >>>>
> >>>> In point-to-point operation, the AAA server MAY assign the
> >>>> prefix(es) and related parameters such as the lifetime and the
> >>>> certificates to MN from MN's profile.
> >>>>
> >>>> [hannes] I am not sure what this means. You mean that the AAA
> >>>> server should keep state to make sure that it does not forget what
> >>>> it has provided to the MN?
> >>> Frank=>Probably, the AAA server for prefix delegation is different
> from
> >>> the AAA server for authentication.  So it is necessary to record the
> >>> state.
> >>>
> >> OK.
> >>
> >> I don't think that you need to say that since this is already done
> >> today.
> >>
> >>>> For some reason the problem is not well described. In Section 3 of
> >>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC
> >>>> 4818 but I do not quite understand what you would like to see
> >>>> happening instead.
> >>>>
> >>>> AAA-based prefix authorization application SHOULD support prefix
> >>>> release procedures.
> >>>>
> >>>> [hannes] isn't this the same as mentioned in the previous
> >>>> requirement "AAA-based PA application MUST support the client to
> >>>> give back the prefixes to the AAA server. "
> >>> Frank=>It is the same.
> >>>
> >>>>
> >>>> The NAS is responsible for renewing the prefixes when the lifetime
> >>>> expires. The NAS SHOULD be able to extend the lifetime of the
> >>>> prefixes using messages designed for this purpose.
> >>>>
> >>>> [hannes] Why wouldn't we tie the lifetime of the prefix to the
> >>>> lifetime of the AAA session itself? Makes things much easier. The
> >>>> same applies a bit to this requirement: "It SHOULD be possible to
> >>>> renumber the prefixes authorized by AAA server. The AAA server
> >>>> SHOULD initiate prefix renumbering process. "
> >>> Frank=>IPv6 renumbering is a feature of IPv6.
> >>> If we tie the lifetime of prefix to the lifetime of AAA session,
> >>> it is certain that we can't suport IPv6 renumbering.
> >>> Even though IPv6 renumbering probably happen probably
> >>> infrequently, it is better for us to have such a mechnism to support.
> >>>
> >>> For IPv6 renumbering, here are some references
> >>> RFC 1916/2071/2072/2874/2894/4076/4192.
> >>>
> >> I know IPv6 renumbering but I was wondering about the following issue.
> >>
> >> IPv6 renumber should occur less frequently and hence the lifetime is
> >> rather long.
> >> A AAA session typically isn't very long lived and it is possible to
> >> influence the lifetime with various parameters.
> > Frank=>IMHO, I don't agree with your assumption on AAA session lifetime.
> > In fact, many people including me are always online because many
> > operators
> > don't charge based on time.  For example, $30 a month is for no
> > limited access.
> >
> I don't know your home setup but typically you have a DSL router at home
> and your PC / laptop may be running all the time. Your DSL router
> re-connects automatically when re-authentication is needed.
>
> >>
> >> Now, isn't it possible to re-authenticate and re-authorize the end
> >> host in case of network renumbering. Given that you have to
> >> re-authenticate quite often for other reasons as well shouldn't cause
> >> big problems.
> > Frank=>IMHO, it is not very graceful to kick off all the users
> > when renumbering.
> Maybe.
>
> When I look at the IT problems I had this year then renumbering is the
> least thing I worry about.
>
> >>
> >> I am just trying to figure out how tough the requirements are.
> > Frank=>IMHO, it is very hard to figure out before widely IPv6
> deployment.
> > However, it is probably too late after large scale deployment.
> >
> Difficult to know, I agree.
>
> Ciao
> Hannes
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org <mailto:DiME@ietf.org>
> https://www.ietf.org/mailman/listinfo/dime

--0-785883996-1217351815=:11729-- --===============0190333869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============0190333869==-- From dime-bounces@ietf.org Tue Jul 29 10:20:57 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA733A6A4F; Tue, 29 Jul 2008 10:20:57 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801D33A6A09 for ; Tue, 29 Jul 2008 10:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 RRCeS7GTptzB for ; Tue, 29 Jul 2008 10:20:53 -0700 (PDT) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 3992A3A6A4D for ; Tue, 29 Jul 2008 10:20:53 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonussf2.sonusnet.com (8.13.7/8.13.7) with ESMTP id m6THKu1w029533; Tue, 29 Jul 2008 13:20:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:20:52 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7012D46DD@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D01BCEE92@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAhzt2gAAaGnqAAwqs20AADVEAAAAECXiAADgv3gAAYMzywAAXRb8AABCLmMAAAgyKgAACjneAAAQrDsA== References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E701206031@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01B91E18@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D453B@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D01BCEA16@ILEXC2U01.ndc.lucent.com><033458F56EC2A64E8D2D7B759FA3E7E7012D45C3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC0F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46AC@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE5F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46CC@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE92@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" , "McCann Peter-A001034" Cc: Glen Zorn , dime@ietf.org, Avri Doria Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] /Application-Id X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Dong, inline.... Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 29, 2008 12:52 PM > To: Asveren, Tolga; McCann Peter-A001034 > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > For some dumb endpoints, the AppS can decide whether the QoS reservation > is required or not according to the service attribute and agreement and > initiate the QoS reservation. It is not really sth new. [TOLGA]Yes agreed. > > The selection of push or pull is related to both access network > capability and endpoint capability. However the relationship is pretty > much static for a combination of one type endpoint and access network. > The network can figure out based on the registration and configuration. > Of course, if the endpoint can provide additional info, it also helps, > but all the info from the endpoint should be authorized, which means the > network makes final decision. [TOLGA]The network can determine certain information when the endpoint is attaching but this may not be all what is necessary. For example in the example I provided there is a softclient and access network knows nothing about it. Who will reserve the QoS in that case? Is it the AppS? > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 29, 2008 12:38 PM > To: Sun, Dong (Dong); McCann Peter-A001034 > Cc: Glen Zorn; Avri Doria; dime@ietf.org > Subject: RE: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] > /Application-Id > > Hi Dong, > > That the endpoint is able to reserve QoS resources is one thing, that it > knows a particular session requires QoS reservation (not necessarily the > attributes just the need) is another one. I expect the endpoint to know > the latter for sure. > > I don't know what would happen for the following case: > 1) The terminal is capable of reserving QoS > 2) A softclient is running on the terminal which is not making use of > QoS reservation capabilities of the terminal (it is a generic > softclient) but it signals it desire for QoS as part of the session > signaling > > Who will initiate the QoS reservation? > > My understanding of your explanation is that if an access network allows > pull model then it won't allow push model as you seem tying the decision > for push/pull model to the access network type (?). Is this always the > case and are we sure that this always will be the case? > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Tuesday, July 29, 2008 12:24 PM > > To: Asveren, Tolga; McCann Peter-A001034 > > Cc: Glen Zorn; Avri Doria; dime@ietf.org > > Subject: RE: [Dime] [Fwd: Comments for > draft-ietf-dime-diameter-qos-06] > > /Application-Id > > > > Tolga, > > > > The AE controlling the access network resources should be able to know > > > the access technology and decide the push or pull mode. In certain > > circumstance, the endpoint may know some info of access network, but I > > > suspect it might not be a general case, for example, for the femto > > network, the cellular UE does not really know/care about the broadband > > > access. It is the access networks (including the AE in the access > > network) that know it. > > > > Moreover, there are many different kinds of endpoints, according the > QoS > > draft, certain types i.e. Category 1, does not have the capability to > > decide the QoS attributes. I believe the draft should and has been > able > > to support all variants. Not see any issue sofar. > > > > Rgs, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Tuesday, July 29, 2008 11:48 AM > > To: McCann Peter-A001034; Sun, Dong (Dong) > > Cc: Glen Zorn; Avri Doria; dime@ietf.org > > Subject: RE: [Dime] [Fwd: Comments for > draft-ietf-dime-diameter-qos-06] > > /Application-Id > > > > (Reply for both Pete's and Dong's explanations) > > > > The origin of my question was the doubt whether all nodes would > > implement both push and pull modes. I see that this is expected so > there > > won't be a problem of finding the right server. This makes it > > unnecessary to use different Application-Ids from routing perspective > (I > > am still not sure whether support for both modes will be universal but > > > it seems I am in minority on this one). > > > > > > I need clarification on one point though: > > Both of you stated AppS knowing that push mode is necessary requires > > that it is aware of access network type used the terminal. IMHO it is > > more than that: access network type, terminal capabilities, whether > QoS > > reservation is requested for the session by the enduser all play a > role > > in this decision AFAICS. Even for access provider it may not be > possible > > to know the answer for all these questions. > > > > For example: > > 1) AppS receives the session request and decides that this type of > > session requires QoS reservation > > 2) It sends a request to the AE > > 3) How does the AE determine whether a push mode reservation is really > > > necessary? > > > > There seem to be only a single entity with perfect information: the > > terminal/enduser. I would expect the endpoint to signal its request > for > > the AppS to reserve QoS resources as part of the session signaling. > > > > Thanks, > > Tolga > > > > > > > > > -----Original Message----- > > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > > Sent: Tuesday, July 29, 2008 7:43 AM > > > To: Sun, Dong (Dong); Asveren, Tolga > > > Cc: Glen Zorn; Avri Doria; dime@ietf.org > > > Subject: RE: [Dime] [Fwd: Comments for > > draft-ietf-dime-diameter-qos-06] > > > /Application-Id > > > > > > One of the motivations for introducing a Diameter QoS protocol was > > > indeed to provide an interface between applications (such as a > > > streaming video server) and network elements that need to enforce > QoS. > > > > > I think net neutrality means documenting this interface and opening > it > > > > > up to anyone that has a connection to the "Diameter Cloud". > > > > > > That being said, I don't have a strong opinion on whether we should > > > use 1 or 2 Application IDs; personally I think it is easier for the > > > application endpoint in a user terminal to provide an authentication > > > > token that points to an application server domain than it is to have > > > > the application server figure out the access network to which the > user > > > > > is attached based only on its IP address. This is why the original > > > document had pull-only. > > > If the AppS can figure out the Destination-Realm of the enforcing > > > NE(s) then we should use standard Diameter routing based on > > > Destination-Realm. Having a separate application ID for each mode > of > > > operation might lead us down the path of having some nodes implement > > > > only one half of the protocol which could lead to interoperability > > > problems. > > > > > > -Pete > > > > > > Sun, Dong (Dong) wrote: > > > > Tolga, > > > > > > > > The scenario A) mandates the application SP being aware of > > underlying > > > > network technology and operation mode (i.e. push or pull) and > making > > > > > > a selection, which is not the intention of QoS application (and > net > > > > neutrality). And I don't think the content provider (let's say > > > > youtube) really cares about which mode is used for the QoS > guarantee > > > > > > in the transport network. > > > > > > > > If you still have question, please give me a call. We can chat > about > > > > > > it in detail. > > > > > > > > Regards, > > > > Dong > > > > > > > > -----Original Message----- > > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > > Sent: Monday, July 28, 2008 3:57 PM > > > > To: Sun, Dong (Dong) > > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > > Subject: RE: [Fwd: [Dime] Comments for > > > > draft-ietf-dime-diameter-qos-06] / Application-Id > > > > > > > > Hi Dong, > > > > > > > > Let's talk over an example because I seriously think we are cross > > > > talking each other and there probably are a few things I don't > > > > understand about QoS application: > > > > > > > > Org-1 is the service provider > > > > Org-2 is the IP access provider > > > > > > > > App-push is the application-Id for push mode (if different AppIds > > > > used) App-pullthe application-Id for pull mode (if different > AppIds > > > > used) > > > > > > > > AppQ is the application-Id for QoS application (if a single AppId > is > > > > used) > > > > > > > > > > > > +-----+ > > > > |AppS | (Org1) > > > > +-----+ > > > > | > > > > +-------+ | > > > > (Org2) |AE-gw |--------+ > > > > +-------+ > > > > | > > > > | > > > > +-------+ > > > > (Org2) | AE1 | > > > > +-------+ > > > > | > > > > | > > > > +-------+ > > > > (Org2) | NE1 | > > > > +-------+ > > > > A) With different Application-Ids > > > > 1- AppS receives a new session request and determines that QoS > needs > > > > > > to be reserved on the access side for a particular flow. It > > > > determines (by whatever means) that the access side is controlled > by > > > > > > Org2. > > > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > > Application-Id=push. This request reaches AE-gw via standard > > Diameter > > > > Base Protocol routing (during capability exchange procedure AE-gw > > > > advertised App-push) [Actually here AppS will need to rely on some > > > > > provisioning as well as capability advertisement is not done per > > > > realm, i.e. it won't be clear to AppS that AE-gw supports > push-mode > > > > for Org2 realm. This IMHO is a missing piece of functionality in > > > > Diameter base protocol but can be fixed relativel easily] > > > > > > > > 3- AE-gw routes the message to AE based on standard Diameter base > > > > protocol routing (during capability exchange procedure AE1 > > advertised > > > > App-push). There could be other AEs in the network which are > unable > > > > to process this request because they do not know the binding > between > > > > > > IP addresses and NEs. This is not a problem though as they would > > > > advertise only app-pull during capability exchange procedure) > > > > > > > > What is here that violates network neutrality? > > > > > > > > > > > > B) With a single Application-Id > > > > 1- AppS receives a new session request and determines that QoS > needs > > > > > > to be reserved on the access side for a particular flow. It > > > > determines (by whatever means) that the access side is controlled > by > > > > > > Org2. > > > > > > > > 2- It sends the initial request with Destination-Realm=Org2 and > > > > Application-Id=AppQ. This request reaches AE-gw via standard > > Diameter > > > > Base Protocol routing (during capability exchange procedure AE-gw > > > > advertised AppQ). > > > > > > > > 3- AE-gw needs to route the message based on provisioning. Why? > > > > Because it needs to find an AE which can handle push mode. It > can't > > > > rely on capability advertisement because all types of AEs will > > > > advertise support for AppQ. > > > > > > > > Is my understanding for single Application-Id correct? If so, with > > > > > single Application-Id model there are more steps relying on > > > > provisioning rather than on dynamic capability exchange procedures > > > > > (and for different Application-Id model we can make routing > > > > completely dynamic with some minor extensions to the base > protocol) > > > > > > > > > > > > I don't believe two Application-Ids add any significant additional > > > > > complexity. If a node can support Diameter Base Protocol > (capability > > > > > > exchange, connection state machine) and QoS application > (application > > > > > > state machine, new AVPs) etc... it is hard for me to believe that > > two > > > > Application-Ids makes development of such nodes more complex. > > > > > > > > > > > > It is likely that we will agree to disagree on this one if my > > > > understanding of single Application-Id routing is correct. > > > > > > > > Thanks, > > > > Tolga > > > > > > > >> -----Original Message----- > > > >> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > >> Sent: Monday, July 28, 2008 12:53 PM > > > >> To: Asveren, Tolga > > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter- > > > >> A001034; Avri Doria; Tina TSOU; Glen Zorn > > > >> Subject: RE: [Fwd: [Dime] Comments for > > > > draft-ietf-dime-diameter-qos-06] / > > > >> Application-Id > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > >> Sent: Monday, July 28, 2008 11:12 AM > > > >> To: Sun, Dong (Dong) > > > >> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > >> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > >> Subject: RE: [Fwd: [Dime] Comments for > > > > draft-ietf-dime-diameter-qos-06] > > > >> / Application-Id > > > >> > > > >> Hi Dong, > > > >> > > > >> Inline.... > > > >> > > > >> Thanks, > > > >> Tolga > > > >> > > > >>> -----Original Message----- > > > >>> From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > >>> Sent: Thursday, July 24, 2008 2:19 PM > > > >>> To: Asveren, Tolga > > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > >>> Peter- A001034; Avri Doria; Tina TSOU; Glen Zorn > > > >>> Subject: RE: [Fwd: [Dime] Comments for > > > >> draft-ietf-dime-diameter-qos-06] / > > > >>> Application-Id > > > >>> > > > >>> Tolga, > > > >>> Comments inline. > > > >>> Dong > > > >>> > > > >>> -----Original Message----- > > > >>> From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > >>> Sent: Thursday, July 24, 2008 11:13 AM > > > >>> To: Sun, Dong (Dong) > > > >>> Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > >>> Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > >>> Subject: RE: [Fwd: [Dime] Comments for > > > >> draft-ietf-dime-diameter-qos-06] > > > >>> / Application-Id > > > >>> > > > >>> (Continuing in separate threads for each issue for easier > > tracking.) > > > >>> > > > >>> Hi Dong, > > > >>> > > > >>> One comment below. > > > >>> > > > >>> Thanks, > > > >>> Tolga > > > >>> > > > >>> [.. snip ..] > > > >>>>> > > > >>>>> 1- Use of the same Application-Id for push/pull models It > sounds > > > > > > > >>>>> reasonable to me to think nodes which support only a single > > mode. > > > >>>>> How can we guarantee that messages land to the right server > > > >>>>> considering that the same Application-Id is used for both of > > them? > > > >>>>> [Sun, Dong (Dong)] The trigger for initiating the push and > pull > > > > > >>>>> models is different, for example, when a new request from the > > PEP > > > >>>>> is recevied, the Server will start the pull model. In fact, > the > > > >>>>> push and pull are sharing the same state machine per se. the > > main > > > >>>>> difference is just how to establish a Diameter session. The > > > >>>>> enhancement is to allow the Diameter > > > >>>> > > > >>>>> Server to establish a session with a local trigger instead of > > the > > > >>>>> trigger from the Diameter client (i.e. NE/PEP). Therefore, I > > > >>>>> don't think the same application-Id causes any problem, > > > >>>>> especially for the pull model since > > > >>>> > > > >>>>> push/pull is able use the same server (certainly they can also > > > > >>>>> have separate server according to the configuration). > > > >>>> [TOLGA]My concern here is about message routing rather than the > > > > >>>> state machine processing in the server. Let's say a server is > > > >>>> capable only to accommodate pull model (it doesn't know what NE > > to > > > >>>> contact if push model is required). How can the network > > > >>>> intermediaries, e.g. relay agent, forward the initial request > in > > > >>>> the session to the right server for push model? How can they be > > > > >>>> sure that the server supports push model? [Dong] The relay > agent > > > >>>> should route the message according to the destination > > > >>>> address/realm that is filled up by the requestor. I don't know > > how > > > >>>> the application id will affect this kind of routing. > > > >>> [TOLGA]The initial message of a session may have only > > > >>> Destination-Realm. In such a case Application-Id is used by > > > >>> intermediaries to select the right server. [Dong] In the context > > of > > > >>> QoS application, for the pull mode, the NE typically is > configured > > > > > >>> by a default policy server or redirect server. I don't think the > > > > >>> scenario you are concerned is a common case in reality > > > >> > > > >>> although theoretically the base Diameter protocol may allow this > > > > >>> kind of behavior, but it is not the case for QoS application, > > IMHO. > > > >> [TOLGA] How can we make sure that a request requiring push mode > > > >> capabilities is delivered to the right server? That was my > initial > > > >> question. There could be servers which only have authorization > > > >> capability but do not have any topology information, i.e. not > > > >> suitable > > > > > > > >> for push mode operation. And what type of problems would be > > > >> introduced > > > > > > > >> if we used two different Application-Ids? > > > >> [Dong] Either Application Server or UE or NE needs to perform the > > > > >> selection of AE according to its capabilities. In the case there > > are > > > >> different AEs for push or pull respectively, a rendezvous AE will > > > > >> make a selection according to the policy, network technology > and/or > > > > > >> request attribute. The problem to have two different application > id > > > > > >> is to mandate the selection of an AE per its capabilities to the > > > >> AppS (or NE), it is inconsistent with the basic rationale of the > > QoS > > > >> application (i.e. maintain the network neutrality). Moreover, it > > > >> makes the QoS application and implementations more complex since > > two > > > >> packages have to be developed... > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Jul 29 11:05:46 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AB13A6A5A; Tue, 29 Jul 2008 11:05:46 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C541C3A6926 for ; Tue, 29 Jul 2008 11:05:44 -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 z4FP2H7zJw9b for ; Tue, 29 Jul 2008 11:05:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F088C3A6A5A for ; Tue, 29 Jul 2008 11:05:42 -0700 (PDT) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id m6TI5i1T027615; Tue, 29 Jul 2008 13:05:45 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 13:05:44 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 13:05:42 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D01BCEF27@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7012D46DB@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Thread-Index: AcjrIfqbkC5HFev9T/m0SK8z8JZVtwA7FzgAADUpzsAADTSC8AAicVbwAAZ5WrAAxGr5kAABps/wAAYY7SAACJCP4AAhFUtgAAEvGuAAAOm4QAACmZ/w References: <09C9068466B79E4C938DC7737562404D01B9162D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E701205ECB@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91AEF@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E70120604D@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01B91E56@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D4565@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEA2F@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D45C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEC12@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46C5@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D01BCEE86@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E7012D46DB@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" X-OriginalArrivalTime: 29 Jul 2008 18:05:44.0426 (UTC) FILETIME=[B850CCA0:01C8F1A5] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Glen Zorn , Avri Doria , McCann Peter-A001034 , dime@ietf.org Subject: Re: [Dime] [Fwd: Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Sorry. Found a typo. " I am opposing any great idea to support the failover." What I mean, "I am NOT opposing ..." -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Tuesday, July 29, 2008 1:16 PM To: Sun, Dong (Dong) Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / failover friendliness Hi Dong, O.K. fair enough. P.S.: It wasn't just Credit-Control-Failure-Handling AVP I was referring to but also inclusion of CC-Request-Type, CC-Request-Number etc... in every message. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Tuesday, July 29, 2008 12:46 PM > To: Asveren, Tolga > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] / > failover friendliness > > Tolga, > I am opposing any great idea to support the failover. Meanwhile, as far > as I can see, the approach you proposed is just one option. BTW, I am > not saying it does not work. > > The bottom line, again, I do seek a common mechanism/framework for the > failover. Sure, in your approach, the detailed application state related > info may vary, but I am not sure if it will make any essential > difference for the mechanism. > > This is a sophiscated and general issue. I don't want to jump into a > special solution for the QoS application since I believe a generic > mechanism (i.e. the common state machine) can help minimize the > development effort as a whole for the Diameter protocol stack. > > As far as I know, it seems the failure approach defined in 4006 (i.e. > "Credit-Control-Failure-Handling" if it is what you refer to) is not yet > widely used by the industry and other SDOs for the time being (due to > the complexity, I guess). Please correct me if I am wrong about this > point. > > Rgs, > Dong > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Tuesday, July 29, 2008 12:21 PM > To: Sun, Dong (Dong) > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > Subject: RE: [Fwd: [Dime] Comments for draft-ietf-dime-diameter-qos-06] > / failover friendliness > > Hi Dong, > > It is a great help for developers if a message contains information to > reconstruct a session after a failover. If you don't think that this is > a good idea/necessary or creates too much overhead then fine. And > actually this probably would require more than the change I asked. > > I don't think there could be a general mechanism to provide all the > support needed for failover friendliness; it is not just about deciding > whether a request is for an existing session but also reconstructing > existing state (which is different for each application). IMHO > DCCA(RFC4006) is a good example. > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Monday, July 28, 2008 8:46 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann Peter- > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] / > > failover friendliness > > > > Tolga, > > > > Before we move further on the failure handover issue, I'd like to > > clarify a basic question (I need some education from the Diameter > > experts): in 3588 and 4005, how a new session is recogizied by the > > Diameter Server? It seems no one uses the explicit indicator for > > identifying a new session, if my understanding is correct. > Furthermore, > > if we rely on the Diameter client for the indication of new session, > it > > may cause the problem when the client recovers from the failure, e.g. > it > > may think the recovered session as a new session. > > > > As I indicated, the QoS application is intended to keep consistent > with > > the base protocol and the "mom" protocol 4005. In fact, besides the > > session-id, the QoS application also looks at the QoS resources and > > other AVPs to decide the transition of the session state. > > > > I just like to highligh my point: how to handle failover is a general > > issue, I don't think the QoS application requires any extra mechanism > > compared to any other applications. So I'd like to adapt a generic > > mechanism already used by other applications if possible, rather than > > creating an "unique" mechanism here. > > > > Regards, > > Dong > > > > -----Original Message----- > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > Sent: Monday, July 28, 2008 4:02 PM > > To: Sun, Dong (Dong) > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > Subject: RE: [Fwd: [Dime] Comments for > draft-ietf-dime-diameter-qos-06] > > / failover friendliness > > > > Hi Dong, > > > > I am not proposing to add anything special to QoS application but just > > > not relying on the type of first command received to determine the QoS > > > model used. IMHO using an AVP for this purpose is a better approach > > because using command type brings extra complexity from cold-standby > > system design perspective. Furthermore it is just overloading the > > meaning of the command code. > > > > I just wanted to summarize the issue. My current understanding is that > > > we agree to disagree on this one. > > > > Thanks, > > Tolga > > > -----Original Message----- > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > Sent: Monday, July 28, 2008 1:07 PM > > > To: Asveren, Tolga > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > Peter- > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] / > > > failover friendliness > > > > > > Inline... > > > Rgs, - Dong > > > > > > -----Original Message----- > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > Sent: Monday, July 28, 2008 12:16 PM > > > To: Sun, Dong (Dong) > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > Subject: RE: [Fwd: [Dime] Comments for > > draft-ietf-dime-diameter-qos-06] > > > / failover friendliness > > > > > > Resending..... > > > > > > > > > > > > > > > Hi Dong, > > > > > > inline.... > > > > > > Thanks, > > > Tolga > > > > > > > -----Original Message----- > > > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > > > Sent: Thursday, July 24, 2008 2:49 PM > > > > To: Asveren, Tolga > > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > Peter- > > > > A001034; Avri Doria; Tina TSOU; Glen Zorn > > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] / > > > > failover friendliness > > > > > > > > Tolga, > > > > Since you agreed that the general failure handling for Diameter is > > out > > > > > > > of scope in the QoS application. In principle, I don't see the > > > necessity > > > > to include extra overhead as the mandatory parameters. Frankly, > the > > > > failure handling of the Diameter Server is a quite comprehensive > > > issue. > > > > Sofar, the QoS application should provide some basic failure > > handling > > > > e.g. clean up the expired sessions, but I am not sure if it is > > > > appropriate to discuss what you address in the QoS application > > > > exclusively. I assume it should be part of base protocol or > separate > > > > > > document (I am not sure if it already has) since they are supposed > > to > > > > generic to all applications. > > > > > > > > See additional comments inline. > > > > > > > > Rgs, > > > > Dong > > > > > > > > -----Original Message----- > > > > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > > > > Sent: Thursday, July 24, 2008 11:44 AM > > > > To: Sun, Dong (Dong) > > > > Cc: dime@ietf.org; Tschofenig, Hannes (NSN - FI/Espoo); McCann > > > > Peter-A001034; Avri Doria; Tina TSOU; Glen Zorn > > > > Subject: RE: [Fwd: [Dime] Comments for > > > draft-ietf-dime-diameter-qos-06] > > > > / failover friendliness > > > > > > > > Hi Dong, > > > > > > > > Comments/questions below. > > > > > > > > Thanks, > > > > Tolga > > > > > > > > > > > > [.. snip ..] > > > > > > 6- 4.2 Session Establishment > > > > > > "When a QoS-Authz-Request > > > > > > (QAR, see Section 5.1) message with a new session ID is > > > received, > > > > > the > > > > > > AE operates in the Pull mode; when other triggers are > > received, > > > > the > > > > > > AE operates in the Push mode." > > > > > > Would this shut down the door for certain failure recovery > > > > scenarios? > > > > > > For example AE goes down and a backup AE takes over. IMO it is > a > > > > nice > > > > > > feature if the backup can continue existing sessions without a > > > need > > > > to > > > > > > > > > > > synchronizing state with the failed active AE. This can be > > > achieved > > > > by > > > > > > > > > > > carrying enough information about session state in the message > > > > itself > > > > > > (AFAIR, DCCA can do this nicely). The approach I quoted makes > > this > > > > > > > > > impossible. For certain scenarios backup AE would determine > the > > > > > required > > > > > > mode wrong. I suggest the decision for push/pull is not based > on > > > > > message > > > > > > name but on the message content. > > > > > > [Sun, Dong (Dong)] I think this is the most straightforward > and > > > > > > > > consistent way in terms of state machine to decide the > > pull/push. > > > > and > > > > > it > > > > > > will work well for the hot standby case, but indeed, it may > have > > > > some > > > > > > issue with cold standby. In general, the failure handling is > not > > > > > addressed > > > > > > in the draft very much. The question is, do we need to add the > > > > failure > > > > > > > > > > > handling in detail or not for backup server case? > > > > > [TOLGA]I agree that details of failure handling may not belong > > here. > > > > > OTOH that the QoS application is failover friendly is a > parameter > > to > > > > > > > > consider IMHO. By carrying enough information in each message so > > > that > > > > > cold standby elements can be used to take over existing > sessions, > > > one > > > > > trades small amount of bandwidth and limited CPU cycles for > > > complexity > > > > > > > > > in software and probably even more CPU cycles. IMHO this is a > > > bargain. > > > > I > > > > > found this very handy in DCCA. Wouldn't just defining an AVP > > > > indicating > > > > > the type of service requested (push v.s. pull) solve this > problem? > > > > > Actually this issue is also tied to Application-Id problem. If > > > > different > > > > > Application-Ids are used, that implicitly will define the mode > > > > > required/used. > > > > > [Dong] I don't think it makes sense to mandate this kind of > > > parameter > > > > > for failover since it is more useful for one type of failure > > > handling > > > > > approach rather than the other. But it is ok to have an optional > > > > > > parameter but it does add significant overhead in the message. > In > > > > > addition, not sure why the application id is tied up with this > > > issue, > > > > > even in general the routing issue as I explained above. > > > > > I think the failure handling approach should be consistent for > all > > > > > > > Diameter applications rather than defining specific one for QoS > > > > > application. > > > > [TOLGA] > > > > 1) One can argue the other way around as well: Why exclude some > > piece > > > of > > > > information which is useful for certain type of failover > mechanism. > > > IMHO > > > > the added overhead is negligible and I am pretty sure much less > than > > > the > > > > overhead of a hot standby system (let alone the extra complexity > it > > > > requires) > > > > [Dong] as indicated, this is not my intention to discuss all > > possible > > > > varieties for failure handover to the standby Diameter server. I > > > assume > > > > a generic mechanism should be applied to QoS application. > > > > > > > > 2) If push/pull modes use different Application-Ids that could be > > used > > > > > > > easily to decide for which mode the message is received. OTOH I > > agree > > > > that this itself wouldn't help for failover friendliness. > > > > [Dong] Using different application id for push/pull makes the > state > > > > mechanism less efficient and does not add too much value for the > > > routing > > > > since the scenarios you are concerned are not common (i.e. the > > message > > > > > > > cannot provide a destination address) in reality for QoS > > application, > > > > IMHO. (sorry for saying this). > > > [TOLGA]IMHO you are introducing unnecessary restrictions for no > > reason. > > > Diameter message routing is making use of Application-Id for initial > > > > requests. If you have a problem with this, you should voice your > > > concerns for the 3588-bis document. Otherwise violating base > protocol > > > principles on a per application basis doesn't make sense to me. > > > > > > > > > > > > > > > > > 3) There are certainly a few things which can be done in base > > protocol > > > > > > > to help failover handling. OTOH base protocol is application state > > > > > machine agnostic. I don't see how it can help there. > > > > [Dong] the failover handling you described does not look like a > > > specific > > > > case only for QoS application. In fact the failure of the server > > does > > > > not affect too much for ongoing bearer sessions since they will > > remain > > > > > > > anyway. And I am not sure if the NE is the best option to store > all > > > > session info due to the cost effectiveness and processing capacity > > > > > issues. Maybe the synchronization between two servers is more > > > efficient, > > > > to some extent. > > > [TOLGA]I don't think it is ever possible that base protocol can > > provide > > > redundancy features to cover for all application redundancy needs > > > without any involvement from application itself. If you have any > > > strategy in mind to deal with this problem please tell it. > > > Actually what I am asking for is to remove a failover-unfriendly > > feature > > > rather than adding new stuff to facilitate redundancy. I really > don't > > > understand what is bad about including an AVP indicating the type. I > > > > simply don't buy the overhead argument. > > > [Dong]I don't think the approach you described is a specific > > requirement > > > only to the QoS application. Then why don't we generalize the issue > > and > > > method rather than adding something only to the QoS application. In > > > addition, it is obvious an optional approach for failure handling, > and > > I > > > don't think current draft prevents any implementation from adding > the > > > optional parameters as needed. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Jul 30 01:03:23 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329B928C118; Wed, 30 Jul 2008 01:03:23 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A94728C118 for ; Wed, 30 Jul 2008 01:03:22 -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=1.494, 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 Jcb4U-ewpVQg for ; Wed, 30 Jul 2008 01:03:21 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C81C928C111 for ; Wed, 30 Jul 2008 01:03:20 -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 <0K4T00II67PWM7@szxga02-in.huawei.com> for dime@ietf.org; Wed, 30 Jul 2008 16:03:33 +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 <0K4T005SC7PWZ9@szxga02-in.huawei.com> for dime@ietf.org; Wed, 30 Jul 2008 16:03:32 +0800 (CST) Received: from z24109b ([10.70.39.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4T0046V7PW0Q@szxml04-in.huawei.com> for dime@ietf.org; Wed, 30 Jul 2008 16:03:32 +0800 (CST) Date: Wed, 30 Jul 2008 16:03:32 +0800 From: Tina TSOU To: dime@ietf.org, "Tschofenig, Hannes (NSN - FI/Espoo)" Message-id: <029701c8f21a$c2583010$7427460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <007a01c8ec61$da366580$7427460a@china.huawei.com> Subject: Re: [Dime] explicit routing and NAI considered for rechartering X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2024392903==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2024392903== Content-type: multipart/alternative; boundary="Boundary_(ID_fwniVPerGoPAf3sF/n0KoQ)" This is a multi-part message in MIME format. --Boundary_(ID_fwniVPerGoPAf3sF/n0KoQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi Hannes et al, We resubmitted it. Since DIME WG has considered draft-korhonen-dime-nai-routing for rechartering, will our extended routing draft be considered also? A new version of I-D, draft-tsou-dime-base-routing-ext-04.txt has been successfuly submitted. Filename: draft-tsou-dime-base-routing-ext Revision: 04 Title: Diameter Routing Extensions Creation_date: 2008-07-29 WG ID: Independent Submission Number_of_pages: 28 Abstract: This document describes two(2) extensions to the current diameter routing scheme. The first extension describes an explicit routing mechanism that MAY be employed by Diameter nodes to allow specific stateful Diameter proxies to remain in the path of all messages exchanges constituting a Diameter session. The second extension describes a realm based redirection scheme as an alternative to host based redirection described in [RFC3588]. B. R. Tina ----- Original Message ----- From: Tschofenig, Hannes (NSN - FI/Espoo) To: ext Tina TSOU ; dime@ietf.org Sent: Wednesday, July 23, 2008 3:09 PM Subject: RE: [Dime] explicit routing and NAI considered for rechartering Hi Tina, I guess you are talking about this document when you speak about explicit routing document: http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03 It is expired. Why didn't you submit it for the meeting? Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of ext Tina TSOU Sent: 23 July, 2008 04:17 To: dime@ietf.org Subject: [Dime] explicit routing and NAI considered for rechartering Hi All, Could explicit routing draft be considered together with Jouni's NAI draft? http://www.ietf.org/proceedings/08jul/agenda/dime.txt B. R. Tina --Boundary_(ID_fwniVPerGoPAf3sF/n0KoQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi Hannes et al,
We resubmitted it.
Since DIME WG has considered draft-korhonen-dime-nai-routing for rechartering, will our extended routing draft be considered also?
 
A new version of I-D, draft-tsou-dime-base-routing-ext-04.txt has been successfuly submitted.

Filename: draft-tsou-dime-base-routing-ext
Revision: 04
Title: Diameter Routing Extensions
Creation_date: 2008-07-29
WG ID: Independent Submission
Number_of_pages: 28

Abstract:
This document describes two(2) extensions to the current diameter
routing scheme.  The first extension describes an explicit routing
mechanism that MAY be employed by Diameter nodes to allow specific
stateful Diameter proxies to remain in the path of all messages
exchanges constituting a Diameter session.  The second extension
describes a realm based redirection scheme as an alternative to host
based redirection described in [RFC3588].
                                                                                 
 
 
B. R.
Tina
----- Original Message -----
Sent: Wednesday, July 23, 2008 3:09 PM
Subject: RE: [Dime] explicit routing and NAI considered for rechartering

Hi Tina,
 
I guess you are talking about this document when you speak about
explicit routing document:
http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03

It is expired. Why didn't you submit it for the meeting?
 
Ciao
Hannes

________________________________

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On
Behalf Of ext Tina TSOU
Sent: 23 July, 2008 04:17
To: dime@ietf.org
Subject: [Dime] explicit routing and NAI considered for
rechartering


Hi All,
Could explicit routing draft be considered together with Jouni's
NAI draft?

http://www.ietf.org/proceedings/08jul/agenda/dime.txt

B. R.
Tina
--Boundary_(ID_fwniVPerGoPAf3sF/n0KoQ)-- --===============2024392903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --===============2024392903==-- From dime-bounces@ietf.org Thu Jul 31 11:41:52 2008 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA4B3A6D20; Thu, 31 Jul 2008 11:41:52 -0700 (PDT) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10ED43A68E1 for ; Thu, 31 Jul 2008 11:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 79pl1uy0OGgt for ; Thu, 31 Jul 2008 11:41:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 21BF23A6C4E for ; Thu, 31 Jul 2008 11:41:49 -0700 (PDT) Received: (qmail invoked by alias); 31 Jul 2008 18:15:10 -0000 Received: from unknown (EHLO [130.129.20.103]) [130.129.20.103] by mail.gmx.net (mp021) with SMTP; 31 Jul 2008 20:15:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+SQq4hZcWSwr5N3NW3Zr58J8bJ4jW9WBFQyQZCxH JErQvbfsBemZAX Message-ID: <48920132.9080108@gmx.net> Date: Thu, 31 Jul 2008 21:15:14 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: GEOPRIV , dime@ietf.org, 'ECRIT' , keyprov@ietf.org X-Y-GMX-Trusted: 0 X-FuHaFi: 0.84 Subject: [Dime] Chillout, IETF#72 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org In case you are still in Dublin on Friday evening and if you are interested to hang around with other IETF folks please drop me a note. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime