From mailman-bounces@core3.amsl.com Fri Feb 1 06:16:31 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A73828D3FE for ; Fri, 1 Feb 2008 06:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtrhxFyaoNes for ; Fri, 1 Feb 2008 06:08:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C63293709 for ; Fri, 1 Feb 2008 05:44:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dime-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:03 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/dime/dime-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:19:16 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAE9293BD0 for ; Fri, 1 Feb 2008 06:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKYhXcatttob for ; Fri, 1 Feb 2008 06:11:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A1D28D8EF for ; Fri, 1 Feb 2008 05:44:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dime-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:06:03 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/dime/dime-archive%40megatron.ietf.org From dime-bounces@ietf.org Fri Feb 1 06:39:00 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0512933D3; Fri, 1 Feb 2008 06:39:00 -0800 (PST) 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_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYCK-6cjpL6c; Fri, 1 Feb 2008 06:39:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90382A2B2F; Fri, 1 Feb 2008 06:15:33 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E26D28D2E6 for ; Fri, 1 Feb 2008 05:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs0sfdDHDUiN for ; Fri, 1 Feb 2008 05:55:56 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by core3.amsl.com (Postfix) with ESMTP id 1B0B929460E for ; Fri, 1 Feb 2008 05:31:35 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m11DVmpC019028; Fri, 1 Feb 2008 08:31:49 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47A31F3F.7050308@tari.toshiba.com> Date: Fri, 01 Feb 2008 08:31:43 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: "Satendra Gera (satgera)" References: <8EB00AB9BCE95E4DBADDDB25EBCBF95D04F7F652@xmb-blr-418.apac.cisco.com> In-Reply-To: <8EB00AB9BCE95E4DBADDDB25EBCBF95D04F7F652@xmb-blr-418.apac.cisco.com> Cc: dime@ietf.org Subject: Re: [Dime] Section 4.5: Relevance of "SHLD NOT" column X-BeenThere: dime@ietf.org X-Mailman-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 Comments inline: > > There have been changes in section 4.5: Diameter Base Protocol AVPs > between bis3-bis6 document. > Can you please explain > > a) the rational behind retaining "SHLD NOT" column in the table. > Probably to cover rfc2119 conventions ... though it may not make sense to have it there > b) use case where marking a AVP bit to "SHLD NOT" will help. AFAIR > haven't seen an application marking an AVP bit as "SHLD NOT". > have'nt seen any as well and i don't think there's any use case for it. regards, victor > c) what should be the behavior incase a message is received with an AVP, > where a "SHLD NOT" bit is set in the header. > > Regards, > Satendra > > _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 1 07:40:02 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA6F3A694A; Fri, 1 Feb 2008 07:40:02 -0800 (PST) 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 core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScbgjD1WRm3V; Fri, 1 Feb 2008 07:40:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350923A699D; Fri, 1 Feb 2008 07:38:37 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738733A6950 for ; Fri, 1 Feb 2008 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycFkVWiQ0KZl for ; Fri, 1 Feb 2008 07:38:35 -0800 (PST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by core3.amsl.com (Postfix) with ESMTP id DF0CA3A69C4 for ; Fri, 1 Feb 2008 07:36:24 -0800 (PST) Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m11Fbx89025783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Feb 2008 07:37:59 -0800 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m11FbwZ3000042; Fri, 1 Feb 2008 07:37:58 -0800 (PST) Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Feb 2008 07:37:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Feb 2008 07:37:57 -0800 Message-ID: In-Reply-To: <5FB585F183235B42A9E70095055136FB709A52@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3GPP Thread-Index: AchjWsQu1p3qYyEvQLmvyiN2/uPGqwAF8syAACz7+NAAHjZpYAASN9Bw From: "Giaretta, Gerardo" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , X-OriginalArrivalTime: 01 Feb 2008 15:37:58.0445 (UTC) FILETIME=[6BD635D0:01C864E8] Subject: Re: [Dime] 3GPP X-BeenThere: dime@ietf.org X-Mailman-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 think draft-ietf-dime-mip6-split is also a normative reference for EPS, at least for 3GPP CT4 work. Jouni can be more precise on this as he attends CT4 meetings. Thanks Gerardo > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Thursday, January 31, 2008 10:56 PM > To: dime@ietf.org > Subject: [Dime] 3GPP > > I also learned that the latest 3GPP SA2 TS23.402 v8.0.0+ (intermediate > draft) for EPS lists the > following docs also worked in Dime. > > [40] IETF Internet-Draft, draft-korhonen-dime-pmip6-02.txt, "Diameter > Proxy Mobile IPv6: Support for Mobility Access Gateway and Local > Mobility Anchor to Diameter Server Interaction", work in progress. > > [41] IETF Internet-Draft, draft-ietf-dime-mip6-integrated-07.txt, > "Diameter Mobile IPv6: Support for Network Access Server to Diameter > Server Interaction", work in progress. > > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > http://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Feb 2 00:39:04 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB6528C45C; Sat, 2 Feb 2008 00:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O7a09AYnyoQ; Sat, 2 Feb 2008 00:39:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A733A682A; Sat, 2 Feb 2008 00:39:03 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7277328C44B for ; Sat, 2 Feb 2008 00:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl37q37JVZoR for ; Sat, 2 Feb 2008 00:39:01 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id DAB803A6884 for ; Sat, 2 Feb 2008 00:38:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,294,1199644200"; d="scan'208";a="96724975" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 02 Feb 2008 14:10:20 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m128eJCc026489; Sat, 2 Feb 2008 14:10:19 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m128eG1D008531; Sat, 2 Feb 2008 08:40:16 GMT Received: from xfe-blr-411.apac.cisco.com ([64.104.140.151]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Feb 2008 14:10:15 +0530 Received: from satgerawxp02 ([10.76.141.75]) by xfe-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Feb 2008 14:10:14 +0530 From: "Satendra Gera" To: "'Victor Fajardo'" References: <8EB00AB9BCE95E4DBADDDB25EBCBF95D04F7F652@xmb-blr-418.apac.cisco.com> <47A31F3F.7050308@tari.toshiba.com> Date: Sat, 2 Feb 2008 14:09:15 +0530 Message-ID: <008401c86577$188174f0$4b8d4c0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Achk1tcclD2AWke8TRCHUQGpuKGuogAn5H5g In-Reply-To: <47A31F3F.7050308@tari.toshiba.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 02 Feb 2008 08:40:14.0718 (UTC) FILETIME=[3B1AB9E0:01C86577] Authentication-Results: ind-dkim-1; header.From=satgera@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: dime@ietf.org Subject: Re: [Dime] Section 4.5: Relevance of "SHLD NOT" column X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Thanks Victor for the prompt reply. In that case, I suggest we remove the column to avoid confusion and temptation for applications to mark a bit as "SHLD NOT" assuming some behavior. Regards, Satendra -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] Sent: Friday, February 01, 2008 7:02 PM To: Satendra Gera (satgera) Cc: dime@ietf.org; Shwetha Bhandari (shwethab); liyaqatali@motorola.com Subject: Re: Section 4.5: Relevance of "SHLD NOT" column Comments inline: > > There have been changes in section 4.5: Diameter Base Protocol AVPs > between bis3-bis6 document. > Can you please explain > > a) the rational behind retaining "SHLD NOT" column in the table. > Probably to cover rfc2119 conventions ... though it may not make sense to have it there > b) use case where marking a AVP bit to "SHLD NOT" will help. AFAIR > haven't seen an application marking an AVP bit as "SHLD NOT". > have'nt seen any as well and i don't think there's any use case for it. regards, victor > c) what should be the behavior incase a message is received with an > AVP, where a "SHLD NOT" bit is set in the header. > > Regards, > Satendra > > _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Feb 10 20:40:51 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C002C3A699B; Sun, 10 Feb 2008 20:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 hZ6xMF1PpMEA; Sun, 10 Feb 2008 20:40:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F0C3A697E; Sun, 10 Feb 2008 20:40:51 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115773A697E for ; Sun, 10 Feb 2008 20:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoXQw7JRsHpQ for ; Sun, 10 Feb 2008 20:40:49 -0800 (PST) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id 657353A6838 for ; Sun, 10 Feb 2008 20:40:49 -0800 (PST) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 20:42:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 20:42:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: New Version Notification for draft-zorn-dime-diameter-cc-appl-mib-03 Thread-Index: AchsZ/geMPNzlstxSwSypTnC/XjefgAAEndg From: "Glen Zorn" To: X-OriginalArrivalTime: 11 Feb 2008 04:42:15.0339 (UTC) FILETIME=[79A627B0:01C86C68] Subject: [Dime] FYI: New Version Notification for draft-zorn-dime-diameter-cc-appl-mib-03 X-BeenThere: dime@ietf.org X-Mailman-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 IETF I-D Submission Tool scribbled on Monday, February 11, 2008 11:36 AM: > A new version of I-D, draft-zorn-dime-diameter-cc-appl-mib-03.txt has > been successfuly submitted by Glen Zorn and posted to the IETF > repository. > > Filename: draft-zorn-dime-diameter-cc-appl-mib > Revision: 03 > Title: Diameter Credit Control Application MIB > Creation_date: 2008-02-10 > WG ID: Independent Submission > Number_of_pages: 21 > > Abstract: > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter base protocol is > intended to provide a framework for AAA applications. > > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter Credit Control application. > > > > The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Feb 10 20:44:03 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5892E3A6A02; Sun, 10 Feb 2008 20:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 9xF5n82ykLBq; Sun, 10 Feb 2008 20:44:02 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988AE3A698D; Sun, 10 Feb 2008 20:44:02 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD773A68EB for ; Sun, 10 Feb 2008 20:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKDgCXGtCTTP for ; Sun, 10 Feb 2008 20:44:01 -0800 (PST) Received: from mail.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by core3.amsl.com (Postfix) with SMTP id B9DF93A69C7 for ; Sun, 10 Feb 2008 20:44:01 -0800 (PST) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by mail.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Feb 2008 20:45:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Feb 2008 20:45:24 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: New Version Notification for draft-zorn-dime-diameter-base-protocol-mib-03 Thread-Index: AchsaL2bnpv3uBqOTiOS413/Zf08EwAABaQQ From: "Glen Zorn" To: X-OriginalArrivalTime: 11 Feb 2008 04:45:27.0942 (UTC) FILETIME=[EC730A60:01C86C68] Subject: [Dime] FYI: New Version Notification for draft-zorn-dime-diameter-base-protocol-mib-03 X-BeenThere: dime@ietf.org X-Mailman-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 IETF I-D Submission Tool scribbled on Monday, February 11, 2008 11:43 AM: > A new version of I-D, > draft-zorn-dime-diameter-base-protocol-mib-03.txt has been > successfuly submitted by Glen Zorn and posted to the IETF repository. > > Filename: draft-zorn-dime-diameter-base-protocol-mib > Revision: 03 > Title: Diameter Base Protocol MIB > Creation_date: 2008-02-10 > WG ID: Independent Submission > Number_of_pages: 53 > > Abstract: > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter protocol is > designed to provide a framework for AAA applications. > > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter protocol. > > > > The IETF Secretariat. _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 11 07:07:07 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9963A6C75; Mon, 11 Feb 2008 07:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 vp13FSmjSLy5; Mon, 11 Feb 2008 07:07:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7923A6C81; Mon, 11 Feb 2008 07:07:01 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91EE53A6C73 for ; Mon, 11 Feb 2008 07:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpFdxZ-711yc for ; Mon, 11 Feb 2008 07:06:58 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D39013A6C5C for ; Mon, 11 Feb 2008 07:06:56 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m1BF7kBI026035 for ; Mon, 11 Feb 2008 17:08:17 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 17:07:40 +0200 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Feb 2008 17:07:40 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Feb 2008 17:07:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter Extensibility & M-Bit Usage Thread-Index: Achsv9nUtUuoRK5MQHWd3+rbroD5/Q== From: To: X-OriginalArrivalTime: 11 Feb 2008 15:07:40.0472 (UTC) FILETIME=[D85F0B80:01C86CBF] X-Nokia-AV: Clean Subject: [Dime] Diameter Extensibility & M-Bit Usage X-BeenThere: dime@ietf.org X-Mailman-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, as part of finishing the Diameter Base protocol-bis document we ran into the M-bit issue. Victor, the RFC3588bis draft editor, incorporated a discussion about the M bit into the latest version of the Diameter Design Guidelines document that lead me to believe that there is a problem. So, here is the text from Section 4.1 of RFC 3588: " The 'M' Bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the 'M' bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message MUST be rejected. " Also note the extensibility rules; by adding an AVP with the M bit set to an existing application requires a new application id to be allocated. Let us, for the moment, focus only on the usage of the M bit for the AVP (rather than the values carried within an AVP). There is no direct dependency between the ABNF and the usage of the M bit but one can certainly say that a specification indicating within the ABNF that a certain AVP must at least occur 1 (or multiple) times requires the implementation to understand it. Hence, in this case the usage of the M bit is redundant. For the same application a couple of AVPs might be optional in the ABNF but the definition of the AVP flag table may allow the M bit to be set. This allows certain deployments to have a dynamic "capability indication" via probing. Having the AVP optional in the ABNF and at the same time require the M bit to be set just implies that the AVP has to be understood (= implemented) but not necessarily used. This implements the classical: mandatory to implement - optional to use behavior. Hence, for a newly defined Diameter application it is fine to indicate all AVPs as mandatory to implement (if this is the intention of the authors). An author of a specification would therefore have to think of what the minimum to implement functionality of a given specification has to be. For certain use cases, the M bit merely serves the purpose of determining the support for certain features. When optional AVPs are available then there are essentially two points in time when to agree on a specific functionality: A) At Configuration Time: Two operators get together and agree to support a specific functionality. Based on the configuration of the stack certain AVPs are sent whereas others' aren't. We have seen this approach happening a lot (also at the interop). It is obviously more time consuming. B) At Run Time: This is the sort of zero-configuration approach where both figure out what they support during the protocol run. With the deployments we see today we are largely talking about (A) rather than (B). Nevertheless, Diameter provides functionality for (B) in the Diameter Base protocol and it is certainly useful and powerful. Unfortunately, this functionality is provided only in a very basic form since there is little feedback from the receiving end (and intermediary) when certain functionality is not supported (unless one incrementially probes to determine what went wrong). More important is the usage of the M bit when it comes to the extensibility story. When a new application is extended by new AVPs then one could require support of the new functionality from the other end during run-time. When the ABNF is changed substantially then there is clearly a need for defining a new Diameter application, like it is necessary to register a new XML schema when you change it (rather than extending it). When you, however, only make use of the extension points to add new functionality then there is also with XML no need to change the parent schema(s). It seems to be interesting to re-use the same concepts in Diameter as well. Other protocols have similar concepts. For example, consider SIP that defines the supported / required feature. See Section 8.1.1.9 and Section 8.2.2.3 of RFC 3261. In some sense this refers to the "end-to-end capability" mechanism used in some of our documents and that is being used also in RADIUS in some places. Unfortunately, there has never been an attempt to define such a feature consistently so that it could be used by many Diameter extensions in a generic way. Note that the concept in SIP refers to "features" (an abstract functionality) rather than a specific header field or even a specific value in a header field. Corresponding error codes are defined in the SIP specification as well along with this mechanism. Example: SIP Location Conveyance -- http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-09 -- specifies an option tag "geolocation" for usage with the Require, Supported and Unsupported headers. The document defines how to carry location information. Obviously, with the processing of location information many things can go wrong and could be misinterpreted by the receiving party. Hence, there are a large number of specific error codes that can be used. I am not sure what todo about the extensiblity rule regarding an AVP with the M bit set being added to an existing application that requires a new Diameter application to be defined. When comparing this to SIP one could argue that the application ID corresponds to the option tag. Unfortunately, it is not quite the same since the application ID is used in Diameter also for routing (but not in SIP) and hence it would correspond better to a Require header combined with a Proxy-Require header. Comparing this approach with XML and Relax NG schemas one could also say that defining new AVPs in a specification is like defining a new XML / Relax NG schema and these schemas are typically registered as well. The comparison is, however, also not fully correct since most of the XML usage I have been using in the IETF was an end-to-end matter and hence the problem with intermediaries did not appear. Furthermore, XML schemas do not allow individual attributes or elements to be registered unless they appear in separate schemas. AVPs are, however, registered separately. Merging of several applications in a single Diameter message is, however, not possible. This has often been the concern when new Diameter applications are defined since new Diameter applications lead to additional message exchanges and cannot be piggy-backed on top of other applications without making a design decision to incorporate the functionality of another Diameter application. When you want to develop them independently then you might encounter an interesting extensibility story since you have very monolithic applications. Regarding the end-to-end capability negotation there is room to learn something from work done in other areas on extensiblity and maybe we don't need to re-invent the wheel every time we define another extension. Currently, capabilities are described using different levels of granularity. For example: In http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.t xt we use the MIP6-Feature-Vector that is used to convey information from the NAS to the AAAH server. It is a bit map, as shown in Section 4.7.5. The same AVP is used in the reverse direction by the AAAH to indicate the authorization decision (e.g., whether the local domain is authorized to allocate a HA or not) in addition to implemented functionality that could be used for a specific protocol run. As such, this functionality is more than the functionality used in SIP with the Require, Supported etc. headers. One problem I see is that the initial goal of routing with the help of Diameter application was to simplify progressing at Diameter proxies. Instead of having to parse through the entire message in order to figure out whether there is something interesting in there for them to process they just had to inspect the Diameter application. Unforuntely, this hasn't really worked too well since there is no such functionality as the SIP Proxy Require that would delegate the decision to set a certain mode from the specification designer to the person that deploys it. The same problem already appeared with the usage of the application ID and the way of doing accounting. Hence, many decisions should be really configuration time or design time decisions rather than design time decision. It is kind of difficult to make a good decision on the M-bit and on the larger extensibility story given that * Diameter routing depends also on the Application ID * the M-bit indicates that intermediaries and other end points have to support a certain functionality Hence, the M-bit has various functionality mixed into a single piece of information. * the usage of "MAY/SHOULD use the M-bit" in the AVP flag table isn't really considered in the extensibility story for Diameter * adding functionality to resolve some of these problems isn't so easy given that these are pretty core protocol features (hint: backward compatibility). I don't see an easy way to solve some of these issues. I wonder whether anyone of you has an opinion about this rather complicated subject. Ciao Hannes PS: It might be good to start with a list of things we want and do not want: * We clearly don't want to define new applications with every tiny extension. Consider the following example. Think about the Diameter QoS attribute draft. Imagine that we would have to define an application. This would mean to define it to run it in the following environments: - Diameter EAP + Diameter QoS attributes - Diameter NASREQ + Diameter QoS attributes - Diameter CC + Diameter QoS attributes - Diameter Mobile IP + Diameter QoS attributes - etc. * We don't want to decide during design time whether intermediaries should be involved. The previous bullet shows the dilemma. The application ID is used to tell intermediate nodes to participate in a particular exchange. On the other hand we would like to have an easy way for network operators to configure their nodes to process certain extensions. One way is obviously to have these intermediaries to look through the entire Diameter message for the presence (or absence) of certain AVPs. * It would help protocol designers to have an e2e capability indication mechanism. With the way how people extend Diameter applications already today I don't see a way to avoid having such a capability. The question is only whether we want to define a generic mechanism (even though it is a bit late). _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 11 10:36:34 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63B53A6D6A; Mon, 11 Feb 2008 10:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_73=0.6, 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 hN7BRHnD7LHk; Mon, 11 Feb 2008 10:36:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC9F3A6D59; Mon, 11 Feb 2008 10:36:32 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427363A6D48 for ; Mon, 11 Feb 2008 10:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML5XSiZIWliz for ; Mon, 11 Feb 2008 10:36:29 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 886CF3A6D8C for ; Mon, 11 Feb 2008 10:35:54 -0800 (PST) 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 m1BIbKi3020042; Mon, 11 Feb 2008 13:37:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Feb 2008 13:37:19 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E75097B0@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter Extensibility & M-Bit Usage thread-index: Achsv9nUtUuoRK5MQHWd3+rbroD5/QAE9uAA References: From: "Asveren, Tolga" To: , Subject: Re: [Dime] Diameter Extensibility & M-Bit Usage X-BeenThere: dime@ietf.org X-Mailman-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 below for comments/questions. Thanks, Tolga > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > hannes.tschofenig@nsn.com > Sent: Monday, February 11, 2008 10:08 AM > To: dime@ietf.org > Subject: [Dime] Diameter Extensibility & M-Bit Usage > > Hi all, > > as part of finishing the Diameter Base protocol-bis document we ran into > the M-bit issue. Victor, the RFC3588bis draft editor, incorporated a > discussion about the M bit into the latest version of the Diameter > Design Guidelines document that lead me to believe that there is a > problem. > > So, here is the text from Section 4.1 of RFC 3588: > " > The 'M' Bit, known as the Mandatory bit, indicates whether support of > the AVP is required. If an AVP with the 'M' bit set is received by a > Diameter client, server, proxy, or translation agent and either the AVP > or its value is unrecognized, the message MUST be rejected. > " > > Also note the extensibility rules; by adding an AVP with the M bit set > to an existing application requires a new application id to be > allocated. > > Let us, for the moment, focus only on the usage of the M bit for the AVP > (rather than the values carried within an AVP). > > There is no direct dependency between the ABNF and the usage of the M > bit but one can certainly say that a specification indicating within the > ABNF that a certain AVP must at least occur 1 (or multiple) times > requires the implementation to understand it. Hence, in this case the > usage of the M bit is redundant. > > For the same application a couple of AVPs might be optional in the ABNF > but the definition of the AVP flag table may allow the M bit to be set. > This allows certain deployments to have a dynamic "capability > indication" via probing. Having the AVP optional in the ABNF and at the > same time require the M bit to be set just implies that the AVP has to > be understood (= implemented) but not necessarily used. This implements > the classical: mandatory to implement - optional to use behavior. Hence, > for a newly defined Diameter application it is fine to indicate all AVPs > as mandatory to implement (if this is the intention of the authors). An > author of a specification would therefore have to think of what the > minimum to implement functionality of a given specification has to be. [TOLGA]IMHO whether the AVP is actually used in the messages at all is orthogonal to whether support for it needs to be present (and whether it would force a new applicationId to be defined). The latter is determined whether the M-bit is set for the new AVP. > > For certain use cases, the M bit merely serves the purpose of > determining the support for certain features. When optional AVPs are > available then there are essentially two points in time when to agree on > a specific functionality: > > A) At Configuration Time: > > Two operators get together and agree to support a specific > functionality. Based on the configuration of the stack certain AVPs are > sent whereas others' aren't. We have seen this approach happening a lot > (also at the interop). It is obviously more time consuming. > > B) At Run Time: > > This is the sort of zero-configuration approach where both figure out > what they support during the protocol run. > > With the deployments we see today we are largely talking about (A) > rather than (B). Nevertheless, Diameter provides functionality for (B) > in the Diameter Base protocol and it is certainly useful and powerful. > Unfortunately, this functionality is provided only in a very basic form > since there is little feedback from the receiving end (and intermediary) > when certain functionality is not supported (unless one incrementially > probes to determine what went wrong). [TOLGA]Are we talking about "Capability Exchange" when we refer to "Diameter Base protocol mechanism to determine support"? If so, it is only a hop-by-hop mechanism. I think it could be used to propagate information about supported applications end-to-end if the intermediaries are intelligent enough to update what they support(but then there are relay agents which advertise support for all applications) (and the mechanism lack the capability to signal support for specific application per realm). > > More important is the usage of the M bit when it comes to the > extensibility story. When a new application is extended by new AVPs then > one could require support of the new functionality from the other end > during run-time. When the ABNF is changed substantially then there is > clearly a need for defining a new Diameter application, like it is > necessary to register a new XML schema when you change it (rather than > extending it). When you, however, only make use of the extension points > to add new functionality then there is also with XML no need to change > the parent schema(s). It seems to be interesting to re-use the same > concepts in Diameter as well. > > Other protocols have similar concepts. For example, consider SIP that > defines the supported / required feature. See Section 8.1.1.9 and > Section 8.2.2.3 of RFC 3261. In some sense this refers to the > "end-to-end capability" mechanism used in some of our documents and that > is being used also in RADIUS in some places. Unfortunately, there has > never been an attempt to define such a feature consistently so that it > could be used by many Diameter extensions in a generic way. Note that > the concept in SIP refers to "features" (an abstract functionality) > rather than a specific header field or even a specific value in a header > field. Corresponding error codes are defined in the SIP specification as > well along with this mechanism. [TOLGA]I guess your worry is whether combinations of supported extensions should be enumerated in advance by a standards organization (defining a new ApplicationId for each of them) or should be signaled as listed exclusively by endpoints (maybe via an AVP). > > Example: SIP Location Conveyance -- > http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-09 -- > specifies an option tag "geolocation" for usage with the Require, > Supported and Unsupported headers. The document defines how to carry > location information. Obviously, with the processing of location > information many things can go wrong and could be misinterpreted by the > receiving party. Hence, there are a large number of specific error codes > that can be used. > > I am not sure what todo about the extensiblity rule regarding an AVP > with the M bit set being added to an existing application that requires > a new Diameter application to be defined. When comparing this to SIP one > could argue that the application ID corresponds to the option tag. > Unfortunately, it is not quite the same since the application ID is used > in Diameter also for routing (but not in SIP) and hence it would > correspond better to a Require header combined with a Proxy-Require > header. Comparing this approach with XML and Relax NG schemas one could [TOLGA]I am not sure whether it would really correspond to Require/Require-Proxy header. The field containing the information used for routing is ApplicationId, just the content of the field changes. Being able to route based on this information is part of the base protocol. > also say that defining new AVPs in a specification is like defining a > new XML / Relax NG schema and these schemas are typically registered as > well. The comparison is, however, also not fully correct since most of > the XML usage I have been using in the IETF was an end-to-end matter and > hence the problem with intermediaries did not appear. Furthermore, XML > schemas do not allow individual attributes or elements to be registered > unless they appear in separate schemas. AVPs are, however, registered > separately. Merging of several applications in a single Diameter message > is, however, not possible. This has often been the concern when new > Diameter applications are defined since new Diameter applications lead > to additional message exchanges and cannot be piggy-backed on top of > other applications without making a design decision to incorporate the > functionality of another Diameter application. When you want to develop > them independently then you might encounter an interesting extensibility > story since you have very monolithic applications. > > Regarding the end-to-end capability negotation there is room to learn > something from work done in other areas on extensiblity and maybe we > don't need to re-invent the wheel every time we define another > extension. Currently, capabilities are described using different levels > of granularity. For example: > > In > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.t > xt we use the MIP6-Feature-Vector that is used to convey information > from the NAS to the AAAH server. It is a bit map, as shown in Section > 4.7.5. The same AVP is used in the reverse direction by the AAAH to > indicate the authorization decision (e.g., whether the local domain is > authorized to allocate a HA or not) in addition to implemented > functionality that could be used for a specific protocol run. [TOLGA]I think, the way Diameter base protocol stands right now, there is little room to negotiate capabilities outside of as indicated by ApplicationId. Anything other than that (e.g. with an AVP) would be negotiating optional capabilities, whose lack of support shouldn't cause the session to be terminated (because routing logic is unaware of these optional capabilities and could route initial messages always to a non-supporting endpoint) > > As such, this functionality is more than the functionality used in SIP > with the Require, Supported etc. headers. > > One problem I see is that the initial goal of routing with the help of > Diameter application was to simplify progressing at Diameter proxies. [TOLGA]Not only simplification. Routing based only on ApplicationId does not require software updates on intermediaries as well. > Instead of having to parse through the entire message in order to figure > out whether there is something interesting in there for them to process > they just had to inspect the Diameter application. Unforuntely, this > hasn't really worked too well since there is no such functionality as > the SIP Proxy Require that would delegate the decision to set a certain > mode from the specification designer to the person that deploys it. The > same problem already appeared with the usage of the application ID and > the way of doing accounting. Hence, many decisions should be really > configuration time or design time decisions rather than design time > decision. [TOLGA]Again, I think your real worry is whether combination of capabilities should be enumerated in advance by SDOs; and I share your concern. > > It is kind of difficult to make a good decision on the M-bit and on the > larger extensibility story given that > * Diameter routing depends also on the Application ID > * the M-bit indicates that intermediaries and other end points have to > support a certain functionality > Hence, the M-bit has various functionality mixed into a single piece > of information. > * the usage of "MAY/SHOULD use the M-bit" in the AVP flag table isn't > really considered in the extensibility story for Diameter [TOLGA]IMHO i- If there is new AVP where M-bit may/should/must be set ==> new ApplicationId ii- If for an existing AVP, M-bit setting changes so that it was previously not possible to set it and now it is ==> new ApplicationId > * adding functionality to resolve some of these problems isn't so easy > given that these are pretty core protocol features (hint: backward > compatibility). > > I don't see an easy way to solve some of these issues. I wonder whether > anyone of you has an opinion about this rather complicated subject. > > Ciao > Hannes > > PS: It might be good to start with a list of things we want and do not > want: > > * We clearly don't want to define new applications with every tiny > extension. Consider the following example. Think about the Diameter QoS > attribute draft. Imagine that we would have to define an application. > This would mean to define it to run it in the following environments: > - Diameter EAP + Diameter QoS attributes > - Diameter NASREQ + Diameter QoS attributes > - Diameter CC + Diameter QoS attributes > - Diameter Mobile IP + Diameter QoS attributes > - etc. [TOLGA]Yes, I think all this should not require a new ApplicationId (but it currently does). > > * We don't want to decide during design time whether intermediaries > should be involved. > The previous bullet shows the dilemma. The application ID is used to > tell intermediate nodes to participate in a particular exchange. On the > other hand we would like to have an easy way for network operators to > configure their nodes to process certain extensions. One way is > obviously to have these intermediaries to look through the entire > Diameter message for the presence (or absence) of certain AVPs. > > * It would help protocol designers to have an e2e capability indication > mechanism. > With the way how people extend Diameter applications already today I > don't see a way to avoid having such a capability. The question is only > whether we want to define a generic mechanism (even though it is a bit > late). [TOLGA]Currently the only way is to define a new ApplicationId. I don't think being late should be an issue here if a new mechanism is designed carefully: i- Should not cause existing nodes to break ii- Should allow the endpoints to determine, whether the message was routed by making use of this new mechanism iii- Should not require intermediaries which are capable of routing according to the new mechanism to be upgraded to support new extensions/applications. iv- Scope of changes signaled by extensions should be well-defined/limited > _______________________________________________ > DiME mailing list > DiME@ietf.org > http://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 11 23:36:51 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89FB53A6E0F; Mon, 11 Feb 2008 23:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liNPxfb4Ss4P; Mon, 11 Feb 2008 23:36:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93DE23A6DC8; Mon, 11 Feb 2008 23:36:50 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510BF3A6DC8 for ; Mon, 11 Feb 2008 23:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY9QgiaxS5et for ; Mon, 11 Feb 2008 23:36:49 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B12BD3A67DF for ; Mon, 11 Feb 2008 23:36:48 -0800 (PST) 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 m1C7cBNk004453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 08:38:11 +0100 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 m1C7cA5c013883 for ; Tue, 12 Feb 2008 08:38:10 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 08:38:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 08:38:07 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB756AD7@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bug in NASREQ Thread-Index: AchtAbNMEB7/ntv+TSik5xngly1JkQASDoIg From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Feb 2008 07:38:10.0657 (UTC) FILETIME=[37859D10:01C86D4A] Subject: [Dime] WG: Bug in NASREQ X-BeenThere: dime@ietf.org X-Mailman-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="===============0501133316==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0501133316== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86D4A.379A12B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C86D4A.379A12B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI =20 This relates to the discussion about Diameter extensibility. Not even the published IETF documents follow the extensibility rules of RFC 3588. It appears that everyone sets the M-bit almost randomly. I am sure that looking at the RADIUS-Diameter interoperability section of RADIUS documents the AVP flag tables would most likely scare us as well.=20 =20 Ciao Hannes ________________________________ Von: ext Avi Lior [mailto:avi@bridgewatersystems.com]=20 Gesendet: Dienstag, 12. Februar 2008 00:59 An: Tschofenig, Hannes (NSN - FI/Espoo) Cc: Mark Jones Betreff: Bug in NASREQ =20 Hannes, =20 We found a bug in NASREQ. NASREQ bases its Accounting Application ID on Diameter Base and at the same time it is adding 11 new AVPs with the 'M' bit set. We just need one to require the use of a new Application ID for accounting. As per 3588: =20 Basic accounting support is sufficient to handle any application that uses the ACR/ACA commands defined in this document, as long as no new mandatory AVPs are added. A mandatory AVP is defined as one which has the "M" bit set when sent within an accounting command, regardless of whether it is required or optional within the ABNF for the accounting application. =20 =20 The AVPs are defined in Section 8 of NASREQ. =20 Accounting- 363 8.1 Unsigned64 | M | P | | V | Y | Input-Octets | | | | | | Accounting- 364 8.2 Unsigned64 | M | P | | V | Y | Output-Octets | | | | | | Accounting- 365 8.3 Unsigned64 | M | P | | V | Y | Input-Packets | | | | | | Accounting- 366 8.4 Unsigned64 | M | P | | V | Y | Output-Packets | | | | | | Acct-Session-Time 46 8.5 Unsigned32 | M | P | | V | Y | Acct-Authentic 45 8.6 Enumerated | M | P | | V | Y | Acounting-Auth- 406 8.7 Enumerated | M | P | | V | Y | Method | | | | | | Acct-Delay-Time 41 8.8 Unsigned32 | M | P | | V | Y | Acct-Link-Count 51 8.9 Unsigned32 | M | P | | V | Y | Acct-Tunnel- 68 8.10 OctetString| M | P | | V | Y | Connection | | | | | | Acct-Tunnel- 86 8.11 Unsigned32 | M | P | | V | Y | Packets-Lost | | | | | | =20 ------_=_NextPart_001_01C86D4A.379A12B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI
 
This relates to the discussion about Diameter=20 extensibility. Not even the published IETF documents follow the = extensibility=20 rules of RFC 3588.
It appears that everyone sets the M-bit almost = randomly. I=20 am sure that looking at the RADIUS-Diameter interoperability section of = RADIUS=20 documents the AVP flag tables would most likely scare us as well.=20
 
Ciao
Hannes

Von: ext Avi Lior=20 [mailto:avi@bridgewatersystems.com]
Gesendet: Dienstag, 12. = Februar=20 2008 00:59
An: Tschofenig, Hannes (NSN - = FI/Espoo)
Cc: Mark=20 Jones
Betreff: Bug in NASREQ

 
Hannes,
 
We found a bug in = NASREQ. =20 NASREQ bases its Accounting Application ID on Diameter Base and at the = same time=20 it is adding 11 new AVPs with the 'M' bit set.  We just need one to = require=20 the use of a new Application ID for accounting.  As per = 3588:
 
   Basic = accounting=20 support is sufficient to handle any application that uses
   the = ACR/ACA commands=20 defined in this document, as long as no new
   mandatory = AVPs are=20 added.  A mandatory AVP is defined as one which
   has the = "M" bit set=20 when sent within an accounting command,
   regardless = of whether=20 it is required or optional within the ABNF for
   the = accounting=20 application.
 
 
The AVPs are defined in = Section 8=20 of NASREQ.
 
  =20 Accounting-      363  = 8.1    =20 Unsigned64 | M  |  P  |    |  V  = |=20 Y  |
    =20 Input-Octets          &= nbsp;           &n= bsp;   =20 |    |     |   =20 |     |    |
  =20 Accounting-      364  = 8.2    =20 Unsigned64 | M  |  P  |    |  V  = |=20 Y  |
    =20 Output-Octets          =             &= nbsp;  =20 |    |     |   =20 |     |    |
  =20 Accounting-      365  = 8.3    =20 Unsigned64 | M  |  P  |    |  V  = |=20 Y  |
    =20 Input-Packets          =             &= nbsp;  =20 |    |     |   =20 |     |    |
  =20 Accounting-      366  = 8.4    =20 Unsigned64 | M  |  P  |    |  V  = |=20 Y  |
    =20 Output-Packets          = ;            =   =20 |    |     |   =20 |     |    |
   = Acct-Session-Time=20 46  8.5     Unsigned32 | M  |  = P =20 |    |  V  | Y  |
  =20 Acct-Authentic    45  8.6     = Enumerated=20 | M  |  P  |    |  V  | Y =20 |
   = Acounting-Auth- =20 406  8.7     Enumerated | M  |  = P =20 |    |  V  | Y  |
    =20 Method           &= nbsp;           &n= bsp;        =20 |    |     |   =20 |     |    |
  =20 Acct-Delay-Time   41  8.8     = Unsigned32 |=20 M  |  P  |    |  V  | Y =20 |
  =20 Acct-Link-Count   51  8.9     = Unsigned32 |=20 M  |  P  |    |  V  | Y =20 |
  =20 Acct-Tunnel-      68  = 8.10   =20 OctetString| M  |  P  |    |  V  = |=20 Y  |
    =20 Connection          &nb= sp;           &nbs= p;     =20 |    |     |   =20 |     |    |
  =20 Acct-Tunnel-      86  = 8.11   =20 Unsigned32 | M  |  P  |    |  V  = |=20 Y  |
    =20 Packets-Lost          &= nbsp;           &n= bsp;   =20 |    |     |   =20 |     |    |
 
 ------_=_NextPart_001_01C86D4A.379A12B8-- --===============0501133316== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --===============0501133316==-- From dime-bounces@ietf.org Mon Feb 11 23:58:17 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E34928C0F3; Mon, 11 Feb 2008 23:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=-2.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 oQ0VnX55uoYw; Mon, 11 Feb 2008 23:58:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41E428C0E5; Mon, 11 Feb 2008 23:58:15 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076B928C0E5 for ; Mon, 11 Feb 2008 23:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wwRj3EUcBLE for ; Mon, 11 Feb 2008 23:58:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 5B29B28C0DF for ; Mon, 11 Feb 2008 23:58:12 -0800 (PST) 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 m1C7xZiS012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 08:59:35 +0100 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 m1C7xNp5009802 for ; Tue, 12 Feb 2008 08:59:35 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 08:59:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 08:59:25 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB756AE8@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with NASREQ Thread-Index: AchsxFCOkpDAmGONQZKP1wz3awVGkgAhfs7AAAC1FSA= From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Feb 2008 07:59:29.0751 (UTC) FILETIME=[31EBDE70:01C86D4D] Subject: Re: [Dime] Issue with NASREQ X-BeenThere: dime@ietf.org X-Mailman-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 Avi found yet another bug in NASREQ ... Ciao Hannes _____________________________________________ From: Mark Jones Sent: Wednesday, January 30, 2008 7:22 PM To: Avi Lior Cc: Tschofenig, Hannes (NSN - FI/Espoo) Subject: RE: Issue with NASREQ Looks like a bug in nasreq to me, Avi. I agree with your understanding of {} and the occurence table. Mark _____________________________________________ From: Avi Lior Sent: January 30, 2008 16:18 To: Mark Jones Cc: Tschofenig, Hannes (NSN - FI/Espoo) Subject: Issue with NASREQ Mark and Hannes, Sitting here in WiMAX doing diameter work. Another issue comes up. It was my understanding that in the ABNF when an attribute was in a {} brace then the table of occurances would also indicate on occurance of 1. Simillarly if the attribute is in a [] then the occurance table will indicate 0-1. In the base protocol this is exactly the case. Now looking at NASREQ this is not the case. Am I missing something? The point of this email and the previous one is that we are trying to do a proper design. Apparently this is done elsewhere as well. Here are some of the examples from NASREQ. +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Input-Octets | 1 | 0 | Accounting-Input-Packets | 1 | 0 | Accounting-Output-Octets | 1 | 0 | Accounting-Output-Packets | 1 | 0 | Acct-Session-Id etc..... ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Origin-AAA-Protocol ] [ Origin-State-Id ] [ Destination-Host ] [ Event-Timestamp ] [ Acct-Delay-Time ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port ] [ NAS-Port-Id ] [ NAS-Port-Type ] * [ Class ] [ Service-Type ] [ Termination-Cause ] [ Accounting-Input-Octets ] [ Accounting-Input-Packets ] [ Accounting-Output-Octets ] [ Accounting-Output-Packets ] [ Acct-Authentic ] [ Accounting-Auth-Method ] [ Acct-Link-Count ] [ Acct-Session-Time ] [ Acct-Tunnel-Connection ] [ Acct-Tunnel-Packets-Lost ] [ Callback-Id ] [ Callback-Number ] [ Called-Station-Id ] [ Calling-Station-Id ] * [ Connection-Info ] [ Originating-Line-Info ] [ Authorization-Lifetime ] [ Session-Timeout ] [ Idle-Timeout ] Calhoun, et al. Standards Track [Page 18] RFC 4005 Diameter Network Access Server Application August 2005 [ Port-Limit ] [ Accounting-Realtime-Required ] [ Acct-Interim-Interval ] * [ Filter-Id ] * [ NAS-Filter-Rule ] * [ Qos-Filter-Rule ] [ Framed-AppleTalk-Link ] [ Framed-AppleTalk-Network ] [ Framed-AppleTalk-Zone ] [ Framed-Compression ] [ Framed-Interface-Id ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] * [ Framed-IPv6-Prefix ] [ Framed-IPv6-Pool ] * [ Framed-IPv6-Route ] [ Framed-IPX-Network ] [ Framed-MTU ] [ Framed-Pool ] [ Framed-Protocol ] * [ Framed-Route ] [ Framed-Routing ] * [ Login-IP-Host ] * [ Login-IPv6-Host ] [ Login-LAT-Group ] [ Login-LAT-Node ] [ Login-LAT-Port ] [ Login-LAT-Service ] [ Login-Service ] [ Login-TCP-Port ] * [ Tunneling ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Auth-Method | 0-1 | 0 | Accounting-Input-Octets | 1 | 0 | Accounting-Input-Packets | 1 | 0 | Accounting-Output-Octets | 1 | 0 | Accounting-Output-Packets | 1 | 0 | Accounting-Record-Number | 0-1 | 0-1 | Accounting-Record-Type | 1 | 1 | Accounting-Realtime-Required | 0-1 | 0-1 | Accounting-Sub-Session-Id | 0-1 | 0-1 | Acct-Application-Id | 0-1 | 0-1 | Acct-Session-Id | 1 | 0-1 | Acct-Multi-Session-Id | 0-1 | 0-1 | Acct-Authentic | 1 | 0 | Acct-Delay-Time | 0-1 | 0 | Acct-Interim-Interval | 0-1 | 0-1 | Acct-Link-Count | 0-1 | 0 | Acct-Session-Time | 1 | 0 | Acct-Tunnel-Connection | 0-1 | 0 | Acct-Tunnel-Packets-Lost | 0-1 | 0 | Authorization-Lifetime | 0-1 | 0 | Callback-Id | 0-1 | 0 | Callback-Number | 0-1 | 0 | Called-Station-Id | 0-1 | 0 | Calling-Station-Id | 0-1 | 0 | Class | 0+ | 0+ | Connection-Info | 0+ | 0 | Destination-Host | 0-1 | 0 | Destination-Realm | 1 | 0 | Event-Timestamp | 0-1 | 0-1 | Error-Message | 0 | 0-1 | Error-Reporting-Host | 0 | 0-1 | Failed-AVP | 0 | 0+ | ---------------------------------------|-----+-----+ Calhoun, et al. Standards Track [Page 74] RFC 4005 Diameter Network Access Server Application August 2005 +-----------+ | Command | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Framed-AppleTalk-Link | 0-1 | 0 | Framed-AppleTalk-Network | 0-1 | 0 | Framed-AppleTalk-Zone | 0-1 | 0 | Framed-Compression | 0-1 | 0 | Framed-IP-Address | 0-1 | 0 | Framed-IP-Netmask | 0-1 | 0 | Framed-IPv6-Prefix | 0+ | 0 | Framed-IPv6-Pool | 0-1 | 0 | Framed-IPX-Network | 0-1 | 0 | Framed-MTU | 0-1 | 0 | Framed-Pool | 0-1 | 0 | Framed-Protocol | 0-1 | 0 | Framed-Route | 0-1 | 0 | Framed-Routing | 0-1 | 0 | NAS-Filter-Rule | 0+ | 0 | NAS-Identifier | 0-1 | 0-1 | NAS-IP-Address | 0-1 | 0-1 | NAS-IPv6-Address | 0-1 | 0-1 | NAS-Port | 0-1 | 0-1 | NAS-Port-Id | 0-1 | 0-1 | NAS-Port-Type | 0-1 | 0-1 | Origin-AAA-Protocol | 0-1 | 0-1 | Origin-Host | 1 | 1 | Origin-Realm | 1 | 1 | Origin-State-Id | 0-1 | 0-1 | Originating-Line-Info | 0-1 | 0 | Proxy-Info | 0+ | 0+ | QoS-Filter-Rule | 0+ | 0 | Route-Record | 0+ | 0+ | Result-Code | 0 | 1 | Service-Type | 0-1 | 0-1 | Session-Id | 1 | 1 | Termination-Cause | 0-1 | 0-1 | Tunnel-Assignment-Id | 0-1 | 0 | Tunnel-Client-Endpoint | 0-1 | 0 | Tunnel-Medium-Type | 0-1 | 0 | Tunnel-Private-Group-Id | 0-1 | 0 | Tunnel-Server-Endpoint | 0-1 | 0 | Tunnel-Type | 0-1 | 0 | User-Name | 0-1 | 0-1 | Vendor-Specific-Application-Id | 0-1 | 0-1 | ---------------------------------------|-----+-----+ _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 12 00:10:19 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6C028C0F7; Tue, 12 Feb 2008 00:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 y6RB9YgeKRyE; Tue, 12 Feb 2008 00:10:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FEAB28C0DD; Tue, 12 Feb 2008 00:10:18 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2CF28C0DD for ; Tue, 12 Feb 2008 00:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypLZyVleuYp0 for ; Tue, 12 Feb 2008 00:10:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E4E7C28C0DA for ; Tue, 12 Feb 2008 00:10:15 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2008 08:11:39 -0000 Received: from proxy3-nsn.nsn-inter.net (EHLO [217.115.75.231]) [217.115.75.231] by mail.gmx.net (mp050) with SMTP; 12 Feb 2008 09:11:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/tmEMfFmTtcFoeCs58GQQTt0v+3XlH42I45hJpZC gXA9EOrK1D/5Np Message-ID: <47B154B6.5080607@gmx.net> Date: Tue, 12 Feb 2008 10:11:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Cc: alejandro_perez@dif.um.es Subject: [Dime] [Fwd: Diameter Split] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net 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, Alejandro worked in an EU funded project, called ENABLE, and implemented the Diameter Mobile IPv6 split scenario. In his implementation he made a few enhancements; the description can be found below: ------------------------------------------------------------------------- Here you have a description of how we perform the split scenario: The MN starts the IKEv2 exchanges with the HA. When the HA receives the IKE_AUTH request message without EAP, it starts the Diameter-EAP application with the AAA server in order to AUTHENTICATE the MN. After a successful authentication, the MN sends the first BU to the HA. After receiving the BU, the HA starts the Diameter Mobile IPv6 application sending an AA-Request Command, in order to AUTHORISE the MN. If the MN is authorised to use the MIP6 service, then a BA is sent back and the mobility service can be used. Note that we use two different applications, Diameter-EAP as defined in the original RFC (without the MIP6 AVPs) and the Diameter Mobile IPv6 (as defined in your draft for Certificate or PSK authentication). So, we have two different processes, AUTHENTICATION and AUTHORIZATION. My comments are: * If you want to perform both processes together when using IKEv2 and EAP, you need to add the Authorization-Lifetime and related AVPs to the command description, because reader may become confused (how and where they are sent? Are they included in the "..." AVPs?). * How re-authorization is performed without execute again an EAP authentication? Best regards, Alejandro ------------------------------------------------------------------------ Feedback to his comments and thoughts are obviously encouraged. I think it would be useful to justify in the security consideration section of the draft why we decided to combined authentication and authorization together in one step. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 12 04:00:14 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8118328C11A; Tue, 12 Feb 2008 04:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 WGwt4zynJm-r; Tue, 12 Feb 2008 04:00:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B860828C1C2; Tue, 12 Feb 2008 04:00:13 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FD628C1C2 for ; Tue, 12 Feb 2008 04:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozF8fsA6Bzka for ; Tue, 12 Feb 2008 04:00:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2954A28C11A for ; Tue, 12 Feb 2008 04:00:02 -0800 (PST) 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 m1CC1PQX010472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 13:01:25 +0100 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 m1CC1PZs019429 for ; Tue, 12 Feb 2008 13:01:25 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 13:01:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 13:01:12 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB756BEA@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another M-Flag Example Thread-Index: AchtbvZyNUZaneZqQSeZFHtQi7+KSw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Feb 2008 12:01:25.0569 (UTC) FILETIME=[FE05EB10:01C86D6E] Subject: [Dime] Another M-Flag Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is another example of M-Flag usage example that violates RFC 3588 extensibility rules: http://www.ietf.org/rfc/rfc4675.txt +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ | | |SHLD| MUST| | Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| -------------------------------|----+-----+----+-----|----| Egress-VLANID OctetString| M | P | | V | Y | Ingress-Filters Enumerated | M | P | | V | Y | Egress-VLAN-Name UTF8String | M | P | | V | Y | User-Priority-Table OctetString| M | P | | V | Y | -------------------------------|----+-----+----+-----|----| According to the Diameter extensibility rules one would have to define a new Diameter application in the above case (since the M-bit is set with these AVPs). Obviously that wasn't done with RFC 4675. I strongly believe that we need to relax the M bit definition. The split between MUST, MAY, SHOULD NOT and MUST NOT isn't really so useful either. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 12 06:31:34 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57F928C2EC; Tue, 12 Feb 2008 06:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 c1Jxf8oR4wVI; Tue, 12 Feb 2008 06:31:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4B128C2C3; Tue, 12 Feb 2008 06:31:29 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FE6428C2C3 for ; Tue, 12 Feb 2008 06:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6yNM12fydyw for ; Tue, 12 Feb 2008 06:31:27 -0800 (PST) Received: from sonussf2.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 44D5028C26C for ; Tue, 12 Feb 2008 06:31:27 -0800 (PST) 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 m1CEWqSq012064; Tue, 12 Feb 2008 09:32:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Feb 2008 09:32:51 -0500 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E75097B5@sonusmail04.sonusnet.com> In-Reply-To: <5FB585F183235B42A9E70095055136FB756BEA@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Another M-Flag Example thread-index: AchtbvZyNUZaneZqQSeZFHtQi7+KSwAFK9mg References: <5FB585F183235B42A9E70095055136FB756BEA@DEMUEXC012.nsn-intra.net> From: "Asveren, Tolga" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , Subject: Re: [Dime] Another M-Flag Example X-BeenThere: dime@ietf.org X-Mailman-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 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, February 12, 2008 7:01 AM > To: dime@ietf.org > Subject: [Dime] Another M-Flag Example > > Here is another example of M-Flag usage example that violates RFC 3588 > extensibility rules: > http://www.ietf.org/rfc/rfc4675.txt > > +---------------------+ > | AVP Flag rules | > |----+-----+----+-----|----+ > | | |SHLD| MUST| | > Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| > -------------------------------|----+-----+----+-----|----| > Egress-VLANID OctetString| M | P | | V | Y | > Ingress-Filters Enumerated | M | P | | V | Y | > Egress-VLAN-Name UTF8String | M | P | | V | Y | > User-Priority-Table OctetString| M | P | | V | Y | > -------------------------------|----+-----+----+-----|----| > > According to the Diameter extensibility rules one would have to define a > new Diameter application in the above case > (since the M-bit is set with these AVPs). Obviously that wasn't done > with RFC 4675. > > I strongly believe that we need to relax the M bit definition. The split > between MUST, MAY, SHOULD NOT and MUST NOT isn't really so useful > either. [TOLGA]IMHO, this can't be done without redefining Diameter Base Protocol routing. Messages should be delivered to the entities, which know how to process them. Currently Application-Id is the only standard information for routing purposes. Having said that, I also agree we should do *something* about this. > > Ciao > Hannes > _______________________________________________ > DiME mailing list > DiME@ietf.org > http://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 12 12:30:18 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D3528C52F; Tue, 12 Feb 2008 12:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 DPfdEaTRZwJS; Tue, 12 Feb 2008 12:30:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A2D28C531; Tue, 12 Feb 2008 12:30:04 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7574528C4F8; Tue, 12 Feb 2008 12:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080212203001.7574528C4F8@core3.amsl.com> Date: Tue, 12 Feb 2008 12:30:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-api-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 : The Diameter API Author(s) : P. Calhoun, D. Frascone Filename : draft-ietf-dime-diameter-api-06.txt Pages : 48 Date : 2008-02-12 The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized 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-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-api-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-api-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-12122008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-api-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-api-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-12122008.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Feb 12 13:05:51 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C5328C51D; Tue, 12 Feb 2008 13:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 QKrjwNFihSWz; Tue, 12 Feb 2008 13:05:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E5D28C524; Tue, 12 Feb 2008 13:05:49 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8301628C2B0 for ; Tue, 12 Feb 2008 13:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48iYapgLhtUA for ; Tue, 12 Feb 2008 13:05:47 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A0BBF28C4BF for ; Tue, 12 Feb 2008 13:05:46 -0800 (PST) Received: (qmail invoked by alias); 12 Feb 2008 21:07:09 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.5]) [91.154.103.163] by mail.gmx.net (mp007) with SMTP; 12 Feb 2008 22:07:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+iLu16QF6itpU60aPRj3HLENhn6S9JasLHDh9UGp Nr12XhSPO8NJ9k Message-ID: <47B20A7B.9070309@gmx.net> Date: Tue, 12 Feb 2008 23:07:07 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: OPS ADs , The IESG X-Y-GMX-Trusted: 0 Cc: dime@ietf.org Subject: [Dime] PROTO Writeup for draft-ietf-dime-diameter-api-06.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net 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 Dan, please find the PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-06.txt at the following URL (and attached to this mail): http://www.tschofenig.priv.at/PROTO_draft-ietf-dime-diameter-api-06.txt The document is ready for publication. Ciao Hannes ------------------------------- PROTO WRITEUP for draft-ietf-dime-diameter-api-06.txt ====================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the Document Shepherd. I have reviewed the document personally, and find it to be ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been in the IETF for a number of years. It has been reviewed through several phases while it was in the AAA and subsequently moved over to the DIME working group. There are no concerns regarding the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No further reviews are required. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no current concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus in the working group to publish the document. Not everyone has, however, a strong opinion about publishing an API document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? ID nits got verified. There are no formal review criteria with regard to this document. The draft contains C-code. It came from Sun's working implementatation. The document shepherd reviewed the C-code and additionally it was reviewed by Victor Fajardo, our WG secretary and main developer of the OpenDiameter stack. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. References are split into normative and informative references. There is a normative reference to RFC 3493 "Basic Socket Interface Extensions for IPv6" (an informational RFC). However, the Diameter API document is an informational document. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? An IANA consideration section exists but there are no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document contains C-code (as noted already above). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Document Announcement Write-Up Technical Summary 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. Working Group Summary There is consensus in the WG to publish this document. Document Quality There are two known deployments of Diameter servers using this API. One of the implementation's maintainers has provided many comments and contributions to the document. Personnel Hannes Tschofenig shepherded this document. _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 12 21:04:22 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15813A6E97; Tue, 12 Feb 2008 21:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.148 X-Spam-Level: ** X-Spam-Status: No, score=2.148 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpLG0gWiMFcs; Tue, 12 Feb 2008 21:04:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDCA28C5A1; Tue, 12 Feb 2008 21:04:21 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F3E3A6CEB for ; Tue, 12 Feb 2008 21:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsTAvPnmLqUI for ; Tue, 12 Feb 2008 21:04:20 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id F0FE83A6E95 for ; Tue, 12 Feb 2008 21:03:45 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1D4qaLK016592 for ; Wed, 13 Feb 2008 10:22:36 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1D4qaH9016570 for ; Wed, 13 Feb 2008 10:22:36 +0530 To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Wed, 13 Feb 2008 10:35:51 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 13/02/2008 10:40:19 AM, Serialize complete at 13/02/2008 10:40:19 AM Subject: [Dime] Suggestion for Enhancement in RFC 3588 X-BeenThere: dime@ietf.org X-Mailman-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="===============1580114740==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1580114740== Content-Type: multipart/alternative; boundary="=_alternative 001C01B7652573EE_=" This is a multipart message in MIME format. --=_alternative 001C01B7652573EE_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpJIGhhdmUgYSBzdWdnZXN0aW9uIHdoaWNoIHNob3VsZCBjb25zaWRlciB3aGVuIHdl IGNvbWVvdXQgd2l0aCB0aGUgbmV4dCANCmJpcyBmb3IgUkZDIDM1ODguDQoNCkluIG15IG9waW5p b24sIHRoZXJlIGFyZSBzb21lIGluZm9ybWF0aW9uIHByb3ZpZGVkIGluIHRoZSBSRkMgMzU4OCBh bmQgaW4gDQp0aGUgbGF0ZXN0IGJpcyAsIHdoaWNoIGluIG15IG9waW5pb24gc2hvdWxkIG5vdCBi ZSB0aGUgcGFydCBvZiB0aGlzIFJGQy4NCg0KUkZDIDM1ODggc2hvdWxkIG9ubHkgc3BlY2lmeSB0 aGUgZGV0YWlsIG9mIHRoZSBkaWFtZXRlciBiYXNlIHByb2NlZHVyZXMgLCANCmNvbW1hbmRzIGFu ZCBBVlBzIHVzZWQgYnkgYmFzZSBtZXNzYWdlcy4NCg0KSXQgc2hvdWxkIG5vdCBkZWZpbmUgYW55 IG90aGVyIG1lc3NhZ2VzIGFuZCBpdHMnIEFCTkYsIHN0YXRlIG1hY2hpbmVzIGFuZCANCnByb2Nl ZHVyZXMuIFRoaXMgdW5uZWNlc3NhcmlseSBjcmVhdGVzIHRoZSBkdXBsaWNhdGlvbiBvZiB0aGUg aW5mb3JtYXRpb24gDQppbiB0aGUgbXVsdGlwbGUgUkZDcyBhbmQgY3JlYXRlcyB0aGUgIGluY29u c2lzdGVuY3kuDQoNClRvIHNpdGUgYW4gIGV4YW1wbGUsIGJhc2UgUkZDIGRlZmluZXMgdGhlIGFj Y291bnRpbmcgbWVzc2FnZXMsIA0KY29ycmVzcG9uZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBVlBz LiBJIGFtIG5vdCBhYmxlIHRvICB1bmRlcnN0YW5kIHdoeSBpdCANCmlzIGEgcmVxdWlyZW1lbnQg dG8gZGVmaW5lIHRoZXNlIGluIHRoZSBkaWFtZXRlciBiYXNlLiBBY2NvdW50aW5nIHNob3VsZCAN CmJlIHByZXJvZ2F0aXZlIG9mIHRoZSBhcHBsaWNhdGlvbiBzcGVjaWZpYyBSRkNzLiBBcHBsaWNh dGlvbiBzcGVjaWZpYyBSRkNzIA0Kc2hvdWxkIGRlZmluZSB0aGUgY29tbWFuZCBjb2RlcyBhbmQg Y29ycmVzcG9uZGluZyBwcm9jZWR1cmVzLg0KDQpIYXZpbmcgYWNjb3VudGluZyBpbiBkaWFtZXRl ciBiYXNlIHNob3VsZCBuZXZlciBiZSBhIHJlcXVpcmVtZW50Lg0KDQpSRkMgaW5kaWNhdGVzIHRo YXQgUkFSLCBBU1IgYW5kIFNUUiBhcmUgYmFzZSBtZXNzYWdlcy4gSW4gbXkgb3BpbmlvbiB0aGlz IA0Kc2hvdWxkIGNvbWUgdW5kZXIgYXBwbGljYXRpb24gc3BlY2lmaWMgbWVzc2FnZXMgYXMgRGlh bWV0ZXIgYmFzZSBpZGVhbGx5IA0Kd291bGQgbm90IG1haW50YWluIHRoZSBhcHBsaWNhdGlvbiBz ZXNzaW9ucy4gDQoNCg0KUmVnYXJkcw0KUHJlZXRpDQogDQoNCioqKioqKioqKioqKioqKioqKioq KioqICBBcmljZW50LVVuY2xhc3NpZmllZCAgICoqKioqKioqKioqKioqKioqKioqKioqDQoiRElT Q0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQg aXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkg cHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNp bmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlz IG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3Ig ZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRl ZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 001C01B7652573EE_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSBhIHN1Z2dlc3Rpb24gd2hp Y2ggc2hvdWxkIGNvbnNpZGVyDQp3aGVuIHdlIGNvbWVvdXQgd2l0aCB0aGUgbmV4dCBiaXMgZm9y IFJGQyAzNTg4LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+SW4gbXkgb3BpbmlvbiwgdGhlcmUgYXJlIHNvbWUgaW5mb3JtYXRpb24NCnByb3ZpZGVkIGlu IHRoZSBSRkMgMzU4OCBhbmQgaW4gdGhlIGxhdGVzdCBiaXMgLCB3aGljaCBpbiBteSBvcGluaW9u IHNob3VsZA0Kbm90IGJlIHRoZSBwYXJ0IG9mIHRoaXMgUkZDLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UkZDIDM1ODggc2hvdWxkIG9ubHkgc3BlY2lm eSB0aGUgZGV0YWlsDQpvZiB0aGUgZGlhbWV0ZXIgYmFzZSBwcm9jZWR1cmVzICwgY29tbWFuZHMg YW5kIEFWUHMgdXNlZCBieSBiYXNlIG1lc3NhZ2VzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SXQgc2hvdWxkIG5vdCBkZWZpbmUgYW55IG90aGVyIG1l c3NhZ2VzDQphbmQgaXRzJyBBQk5GLCBzdGF0ZSBtYWNoaW5lcyBhbmQgcHJvY2VkdXJlcy4gVGhp cyB1bm5lY2Vzc2FyaWx5IGNyZWF0ZXMNCnRoZSBkdXBsaWNhdGlvbiBvZiB0aGUgaW5mb3JtYXRp b24gaW4gdGhlIG11bHRpcGxlIFJGQ3MgYW5kIGNyZWF0ZXMgdGhlDQombmJzcDtpbmNvbnNpc3Rl bmN5LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VG8g c2l0ZSBhbiAmbmJzcDtleGFtcGxlLCBiYXNlIFJGQyBkZWZpbmVzDQp0aGUgYWNjb3VudGluZyBt ZXNzYWdlcywgY29ycmVzcG9uZGluZyBzdGF0ZSBtYWNoaW5lIGFuZCBBVlBzLiBJIGFtIG5vdA0K YWJsZSB0byAmbmJzcDt1bmRlcnN0YW5kIHdoeSBpdCBpcyBhIHJlcXVpcmVtZW50IHRvIGRlZmlu ZSB0aGVzZSBpbiB0aGUNCmRpYW1ldGVyIGJhc2UuIEFjY291bnRpbmcgc2hvdWxkIGJlIHByZXJv Z2F0aXZlIG9mIHRoZSBhcHBsaWNhdGlvbiBzcGVjaWZpYw0KUkZDcy4gQXBwbGljYXRpb24gc3Bl Y2lmaWMgUkZDcyBzaG91bGQgZGVmaW5lIHRoZSBjb21tYW5kIGNvZGVzIGFuZCBjb3JyZXNwb25k aW5nDQpwcm9jZWR1cmVzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SGF2aW5nIGFjY291bnRpbmcgaW4gZGlhbWV0ZXIgYmFzZSBzaG91bGQNCm5ldmVy IGJlIGEgcmVxdWlyZW1lbnQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5SRkMgaW5kaWNhdGVzIHRoYXQgUkFSLCBBU1IgYW5kIFNUUg0KYXJlIGJhc2Ug bWVzc2FnZXMuIEluIG15IG9waW5pb24gdGhpcyBzaG91bGQgY29tZSB1bmRlciBhcHBsaWNhdGlv biBzcGVjaWZpYw0KbWVzc2FnZXMgYXMgRGlhbWV0ZXIgYmFzZSBpZGVhbGx5IHdvdWxkIG5vdCBt YWludGFpbiB0aGUgYXBwbGljYXRpb24gc2Vzc2lvbnMuDQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlByZWV0aTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCjxi cj4NCioqKioqKioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtVW5jbGFzc2lmaWVkICZu YnNwOyAqKioqKioqKioqKioqKioqKioqKioqKjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29s b3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAwMDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVz c2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQg bWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNo b3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhh biBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNz YWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0 aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRl cmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50 IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZy b20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBp bmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFi bGU+ --=_alternative 001C01B7652573EE_=-- --===============1580114740== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --===============1580114740==-- From dime-bounces@ietf.org Wed Feb 13 04:03:34 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925F928C78E; Wed, 13 Feb 2008 04:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-1.545, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 c1PdINTUYIOS; Wed, 13 Feb 2008 04:03:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71BA628C791; Wed, 13 Feb 2008 04:03:33 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA5A28C78E for ; Wed, 13 Feb 2008 04:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LpKzW4GzxCW for ; Wed, 13 Feb 2008 04:03:31 -0800 (PST) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 217CC28C790 for ; Wed, 13 Feb 2008 04:03:30 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 13:04:51 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 13:04:51 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288AD8A@SEHAN021MB.tcad.telia.se> In-Reply-To: <47967CCB.4010903@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request routing considerations in 3588bis. was: RE: 3588bis review Thread-Index: AchdTuSVJ5i1Uff/TEu4/9u3TxYKyQQzXwwg References: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> <47967CCB.4010903@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 13 Feb 2008 12:04:51.0799 (UTC) FILETIME=[A35BDE70:01C86E38] Subject: [Dime] Request routing considerations in 3588bis. was: RE: 3588bis review X-BeenThere: dime@ietf.org X-Mailman-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 Victor, After reading (again) the request routing part of the 4588bis, I think the I-D should say more about the realm-based routing. For example, RFC4282 that this I-D also references to, allows "source routing" using decorated NAIs. There are already specs out there that assume Diameter realm routing supports this feature. To my understanding at least 3GPP and WiMAX use this feature to implement various roaming scenarios. However, I cannot find any indication of such in 3588bis. Basically, I would propose adding some text to sections 6.1. and 6.1.9. in order to cover decorated NAIs. Below is a draft proposal for a new text: 6.1. Diameter Request Routing Overview ... its ABNF. For Diameter clients, the value of the Destination- Realm AVP MAY be extracted from the User-Name AVP, or other application-specific methods. For Diameter relays and proxies, the values of the User-Name AVP and the Destination-Realm AVP MAY be modified if the User-Name AVP contains a NAI with multiple realms (see RFC 4282 [RFC4282] Section 2.7 Realm Construction). ... 6.1.9. Relaying and Proxying Requests ... Relay agents do not require full validation of incoming messages. At a minimum, validation of the message header and relevant routing AVPs has to be done when relaying messages. If both User-Name and Destination-Realm AVPs are present, then a relay or proxy SHOULD check whether the the User-Name AVP contains a NAI with multiple realms (as described in RFC 4282 [RFC4282] Section 2.7). If multiple realms are found in the NAI then the following steps are done: o The NAI in the User-Name AVP is processed and modified according to the NAI conversion rules defined in RFC 4282 [RFC4282] Section 2.7. o The Destination-Realm AVP is modified with the updated realm information extracted from the User-Name AVP. o The request is routed normally as described in Section 6.1.6. Any comments etc ? Cheers, Jouni > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: 23. tammikuuta 2008 1:31 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: dime@ietf.org > Subject: Re: 3588bis review was: Re: [Dime] (no subject) > > > Hi Jouni, > > Thanks :) We'll fix the nits. > > -- victor > > > Hi Victor, > > > > I have two more nits ;) > > > > o Section 4.1 AVP format acsii figure. It seems you > > forgot to put the deprecated 'P' bit back even if > > the text mentions it again. > > > > o Appendix B and DNS RR examples are still formatted > > wrong imho. They should be: > > > > ;; order pref flags service regexp > replacement > > IN NAPTR 50 50 "s" "AAA+D2S" "" > > _diameter._sctp.example.com > > IN NAPTR 100 50 "s" "AAA+D2T" "" > > _aaa._tcp.example.com > > > > and: > > > > ;; Priority Weight Port Target > > IN SRV 0 1 5060 server1.example.com > > IN SRV 0 2 5060 server2.example.com > > > > > > Cheers, > > Jouni > > > > > > > >> -----Original Message----- > >> From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > >> Sent: 22. tammikuuta 2008 18:26 > >> To: Jouni Korhonen > >> Cc: dime@ietf.org > >> Subject: Re: 3588bis review was: Re: [Dime] (no subject) > >> > >> > >> Hi Jouni, > >> > >> Thanks for the review and sorry for the very late reply. I'm > >> currently updating 3588bis based on comments from reviewers. > >> I've integrated most of your comments below. Some answers to > >> your post are inlined: > >> > >> > >> > >>>> ------------------ > >>>> > >>>> o This bis version e.g. deprecates a few things from the > >>>> > >> RFC3588 like > >> > >>>> E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are > >>>> > >> considerable > >> > >>>> changes in the security department. I would like to > see a small > >>>> section actually describing the major changes. For a new > >>>> > >> reader that > >> > >>>> would be a nice quick-start. > >>>> > >> Good idea. > >> > >> > >>>> o Application Id has been written using 3-4 different conventions > >>>> in the text. Pick one and stay with it ;) > >>>> > >> Ok. > >> > >> > >>>> Section 4.1. AVP Header > >>>> > >>>> I would actually leave the P-flag in place but have a > description > >>>> in flags related text stating something like "The 'P' > >>>> > >> bit has been > >> > >>>> deprecated and MUST be set to zero when sending and ignored on > >>>> receiving". IMHO this is more cleaner way than > changing it to 'r' > >>>> bit. > >>>> > >> Good point. > >> > >> > >> > >>>> 6.11. Vendor-Specific-Application-Id AVP > >>>> > >>>> ".. > >>>> The Vendor-Id AVP is an informational AVP pertaining > >>>> > >> to the vendor > >> > >>>> who may have authorship of the vendor-specific > >>>> > >> Diameter application. > >> > >>>> It MUST NOT be used as a means of defining a completely > >>>> separate > >>>> vendor-specific application identifier space. > >>>> > >>>> o A question.. now that section 11.3. under IANA > >>>> > >> considerations say: > >> > >>>> "Vendor-Specific Application Identifiers, are for > >>>> > >> Private Use. Vendor- > >> > >>>> Specific Application Identifiers are assigned on a > >>>> > >> First Come, First > >> > >>>> Served basis by IANA." > >>>> > >>>> o what is the actual value of having Vendor-Id AVP in > >>>> > >> the group if > >> > >>>> the vendor specific application Ids need to be > >>>> > >> reserved from AINA > >> > >>>> anyway? If it is just FYI, couldn't that be removed..? > >>>> > >> though that > >> > >>>> might hurt backwards compatibility, slightly ;) > >>>> > >> As you mentioned, backward compatibility is the reason why we > >> had to keep vendor-id avp despite it being redundant from the > >> base protocol perspective. If I'm not mistaken, its actually > >> being used by other SDO's. > >> > >> > >>>> 6.11. Vendor-Specific-Application-Id AVP > >>>> > >>>> ::= < AVP Header: 260 > > >>>> { Vendor-Id } > >>>> ({ Auth-Application-Id } / > >>>> { Acct-Application-Id }) > >>>> > >>>> o I think the above does not comply with the ABNF described in > >>>> section 3.2. > >>>> > >> We've fixed this by integrating reviews from Ralph. > >> > >> > >> regards, > >> victor > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> > >> > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 13 09:07:41 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC67A28C8C3; Wed, 13 Feb 2008 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 mc+vjwWKQEUL; Wed, 13 Feb 2008 09:07:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2058D28C83D; Wed, 13 Feb 2008 09:07:41 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C9628C826 for ; Wed, 13 Feb 2008 09:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ASK+k7kpTsg for ; Wed, 13 Feb 2008 09:07:34 -0800 (PST) Received: from bws14.bridgewatersystems.com (bws14.bridgewatersystems.com [216.113.7.14]) by core3.amsl.com (Postfix) with ESMTP id 96A2028C87A for ; Wed, 13 Feb 2008 09:07:34 -0800 (PST) From: Mark Jones To: "dime@ietf.org" Date: Wed, 13 Feb 2008 12:08:55 -0500 Message-ID: References: <5FB585F183235B42A9E70095055136FB756BEA@DEMUEXC012.nsn-intra.net> <033458F56EC2A64E8D2D7B759FA3E7E75097B5@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E75097B5@sonusmail04.sonusnet.com> Content-Language: en-US MIME-Version: 1.0 Subject: Re: [Dime] Another M-Flag Example X-BeenThere: dime@ietf.org X-Mailman-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 strongly believe that we need to relax the M bit definition. The > split > > between MUST, MAY, SHOULD NOT and MUST NOT isn't really so useful > > either. > [TOLGA]IMHO, this can't be done without redefining Diameter Base > Protocol routing. Messages should be delivered to the entities, which > know how to process them. Currently Application-Id is the > only standard > information for routing purposes. Having said that, I also agree we > should do *something* about this. [MJ] I agree with Tolga. A solution is required but relaxing the 'M' bit definition makes capability exchanges meaningless. The current 'M' bit definition is going to mean a prolification of application ids as new releases of applications will inevitably add mandatory-to-understand AVPs. I don't see a way to address this without revisiting some fundamental definitions in the Base Protocol. However, if we don't tackle this in Dime, I suspect one of the SDOs will extend the capability exchanges anyway. IMO, Application-Version/Release AVPs can't be far away and I'd much prefer them to have common definitions than SDO-specific variants. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 13 09:44:21 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC9C28C925; Wed, 13 Feb 2008 09:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 bEqbHmmPUjCu; Wed, 13 Feb 2008 09:44:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3E428C84D; Wed, 13 Feb 2008 09:44:20 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF4D28C8D5 for ; Wed, 13 Feb 2008 09:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtPFpKXm-EOW for ; Wed, 13 Feb 2008 09:44:18 -0800 (PST) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 645C43A6F9C for ; Wed, 13 Feb 2008 09:44:17 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Feb 2008 18:45:39 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Feb 2008 18:45:38 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288ADA1@SEHAN021MB.tcad.telia.se> In-Reply-To: <47B301CE.8010903@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request routing considerations in 3588bis. was: RE: 3588bis review Thread-Index: AchuT+xOetGl52m5TXi2Rr3reR/64wAE0Hcg References: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> <47967CCB.4010903@tari.toshiba.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288AD8A@SEHAN021MB.tcad.telia.se> <47B301CE.8010903@tari.toshiba.com> From: To: X-OriginalArrivalTime: 13 Feb 2008 17:45:39.0791 (UTC) FILETIME=[3F4FD5F0:01C86E68] Cc: dime@ietf.org Subject: Re: [Dime] Request routing considerations in 3588bis. was: RE: 3588bis review X-BeenThere: dime@ietf.org X-Mailman-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 Victor, > Hi Jouni, [snip] > > Any comments etc ? > > > > Mmmm .... for me, putting decorated NAI dependencies in the base is > probably going to confuse folks. To me decorated NAI is a > solution to a > very specific problem that should not be generalized in the It is a specific solution to enforce certain business models. > base. There > are other competing solutions to the "source routing" issue that does > not require changes to basic routing. So I think it is better if that > happens outside existing routing procedures. I understand your concern regarding the base protocol specification. However, I really would like to know how to deal with decorated NAIs and Diameter routing in general. IMHO we need it documented somewhere in IETF space. Can I assume e.g. NASREQ & EAP handle it, if those boxes implement 3588bis? Or do I always need a new application that is equivalent to e.g. EAP apart from modified routing? Cheers, Jouni > > regards, > victor > > _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 14 04:53:26 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32AC28CE5E; Thu, 14 Feb 2008 04:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_73=0.6, 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 2B0YJ2yI3OW8; Thu, 14 Feb 2008 04:53:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F028A28C6FD; Thu, 14 Feb 2008 04:53:24 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3DB28CCFE for ; Thu, 14 Feb 2008 04:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjJ00U1HvKfK for ; Thu, 14 Feb 2008 04:53:22 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 4F18028C6FD for ; Thu, 14 Feb 2008 04:53:20 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2008 12:54:41 -0000 Received: from proxy2-nsn.nsn-inter.net (EHLO [217.115.75.230]) [217.115.75.230] by mail.gmx.net (mp004) with SMTP; 14 Feb 2008 13:54:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19i4kE55LFijn+ehn52CDf8lVeO1PZhRjIiB9Al5x Dq9+e1Ki2IM8eB Message-ID: <47B43A05.1060609@gmx.net> Date: Thu, 14 Feb 2008 14:54:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Asveren, Tolga" References: <033458F56EC2A64E8D2D7B759FA3E7E75097B0@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E75097B0@sonusmail04.sonusnet.com> X-Y-GMX-Trusted: 0 Cc: dime@ietf.org Subject: Re: [Dime] Diameter Extensibility & M-Bit Usage X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net 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 Tolga, Asveren, Tolga wrote: > Hi Hannes, > > Please see below for comments/questions. > > Thanks, > Tolga > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> > Of > >> hannes.tschofenig@nsn.com >> Sent: Monday, February 11, 2008 10:08 AM >> To: dime@ietf.org >> Subject: [Dime] Diameter Extensibility & M-Bit Usage >> >> Hi all, >> >> as part of finishing the Diameter Base protocol-bis document we ran >> > into > >> the M-bit issue. Victor, the RFC3588bis draft editor, incorporated a >> discussion about the M bit into the latest version of the Diameter >> Design Guidelines document that lead me to believe that there is a >> problem. >> >> So, here is the text from Section 4.1 of RFC 3588: >> " >> The 'M' Bit, known as the Mandatory bit, indicates whether support of >> the AVP is required. If an AVP with the 'M' bit set is received by a >> Diameter client, server, proxy, or translation agent and either the >> > AVP > >> or its value is unrecognized, the message MUST be rejected. >> " >> >> Also note the extensibility rules; by adding an AVP with the M bit set >> to an existing application requires a new application id to be >> allocated. >> >> Let us, for the moment, focus only on the usage of the M bit for the >> > AVP > >> (rather than the values carried within an AVP). >> >> There is no direct dependency between the ABNF and the usage of the M >> bit but one can certainly say that a specification indicating within >> > the > >> ABNF that a certain AVP must at least occur 1 (or multiple) times >> requires the implementation to understand it. Hence, in this case the >> usage of the M bit is redundant. >> >> For the same application a couple of AVPs might be optional in the >> > ABNF > >> but the definition of the AVP flag table may allow the M bit to be >> > set. > >> This allows certain deployments to have a dynamic "capability >> indication" via probing. Having the AVP optional in the ABNF and at >> > the > >> same time require the M bit to be set just implies that the AVP has to >> be understood (= implemented) but not necessarily used. This >> > implements > >> the classical: mandatory to implement - optional to use behavior. >> > Hence, > >> for a newly defined Diameter application it is fine to indicate all >> > AVPs > >> as mandatory to implement (if this is the intention of the authors). >> > An > >> author of a specification would therefore have to think of what the >> minimum to implement functionality of a given specification has to be. >> > [TOLGA]IMHO whether the AVP is actually used in the messages at all is > orthogonal to whether support for it needs to be present (and whether it > would force a new applicationId to be defined). The latter is determined > whether the M-bit is set for the new AVP. > I should introduce some terminology here: Required AVP: AVP that is listed in the ABNF with {}. Mandatory AVP: AVP that has the M-bit flag set. Hence, in a case of required AVP then it is obviously mandatory as well (regardless of the setting of the M-flag). Hence, with the current extensibility rules you have a problem: * When you have AVPs with the M-bit set in the "MUST" column then it just means "MUST implement/MAY use". According to the extensibility rules a mandatory AVP would require a new application. * When you have AVPs with the M-bit set in the "MUST NOT" column then this is purely optional. * The semantic of the "SHOULD" and "MAY" column is not really well described. >> For certain use cases, the M bit merely serves the purpose of >> determining the support for certain features. When optional AVPs are >> available then there are essentially two points in time when to agree >> > on > >> a specific functionality: >> >> A) At Configuration Time: >> >> Two operators get together and agree to support a specific >> functionality. Based on the configuration of the stack certain AVPs >> > are > >> sent whereas others' aren't. We have seen this approach happening a >> > lot > >> (also at the interop). It is obviously more time consuming. >> >> B) At Run Time: >> >> This is the sort of zero-configuration approach where both figure out >> what they support during the protocol run. >> >> With the deployments we see today we are largely talking about (A) >> rather than (B). Nevertheless, Diameter provides functionality for (B) >> in the Diameter Base protocol and it is certainly useful and powerful. >> Unfortunately, this functionality is provided only in a very basic >> > form > >> since there is little feedback from the receiving end (and >> > intermediary) > >> when certain functionality is not supported (unless one incrementially >> probes to determine what went wrong). >> > [TOLGA]Are we talking about "Capability Exchange" when we refer to > "Diameter Base protocol mechanism to determine support"? If so, it is > only a hop-by-hop mechanism. I think it could be used to propagate > information about supported applications end-to-end if the > intermediaries are intelligent enough to update what they support(but > then there are relay agents which advertise support for all > applications) (and the mechanism lack the capability to signal support > for specific application per realm). > > No I am not talking about the Diameter base exchange capability exchange. I should have used a different term. This is about an E2E exchange built into applications by some protocol designers. >> More important is the usage of the M bit when it comes to the >> extensibility story. When a new application is extended by new AVPs >> > then > >> one could require support of the new functionality from the other end >> during run-time. When the ABNF is changed substantially then there is >> clearly a need for defining a new Diameter application, like it is >> necessary to register a new XML schema when you change it (rather than >> extending it). When you, however, only make use of the extension >> > points > >> to add new functionality then there is also with XML no need to change >> the parent schema(s). It seems to be interesting to re-use the same >> concepts in Diameter as well. >> >> Other protocols have similar concepts. For example, consider SIP that >> defines the supported / required feature. See Section 8.1.1.9 and >> Section 8.2.2.3 of RFC 3261. In some sense this refers to the >> "end-to-end capability" mechanism used in some of our documents and >> > that > >> is being used also in RADIUS in some places. Unfortunately, there has >> never been an attempt to define such a feature consistently so that it >> could be used by many Diameter extensions in a generic way. Note that >> the concept in SIP refers to "features" (an abstract functionality) >> rather than a specific header field or even a specific value in a >> > header > >> field. Corresponding error codes are defined in the SIP specification >> > as > >> well along with this mechanism. >> > [TOLGA]I guess your worry is whether combinations of supported > extensions should be enumerated in advance by a standards organization > (defining a new ApplicationId for each of them) or should be signaled as > listed exclusively by endpoints (maybe via an AVP). > I would like to have protocol designers to have a better understanding of the tradeoffs of certain design decisions. Creating monolithic applications is fine when intended that way. However, it took us a long time to figure out how to extend Diameter for our purpose; I could imagine that many other SDOs have similar problems. >> Example: SIP Location Conveyance -- >> http://tools.ietf.org/html/draft-ietf-sip-location-conveyance-09 -- >> specifies an option tag "geolocation" for usage with the Require, >> Supported and Unsupported headers. The document defines how to carry >> location information. Obviously, with the processing of location >> information many things can go wrong and could be misinterpreted by >> > the > >> receiving party. Hence, there are a large number of specific error >> > codes > >> that can be used. >> >> I am not sure what todo about the extensiblity rule regarding an AVP >> with the M bit set being added to an existing application that >> > requires > >> a new Diameter application to be defined. When comparing this to SIP >> > one > >> could argue that the application ID corresponds to the option tag. >> Unfortunately, it is not quite the same since the application ID is >> > used > >> in Diameter also for routing (but not in SIP) and hence it would >> correspond better to a Require header combined with a Proxy-Require >> header. Comparing this approach with XML and Relax NG schemas one >> > could > [TOLGA]I am not sure whether it would really correspond to > Require/Require-Proxy header. The field containing the information used > for routing is ApplicationId, just the content of the field changes. > Being able to route based on this information is part of the base > protocol. > The problem with the Application ID is that many people do not want to allocate a new Application ID with every tiny extension. The main reason is based on the fact that you essentially require separate exchanges for different Diameter applications. Furthermore, the usage of M-bit is (when you look at existing Diameter applications) almost random. Hence, it cannot seriously be used by a proxy to determine the behavior. >> also say that defining new AVPs in a specification is like defining a >> new XML / Relax NG schema and these schemas are typically registered >> > as > >> well. The comparison is, however, also not fully correct since most of >> the XML usage I have been using in the IETF was an end-to-end matter >> > and > >> hence the problem with intermediaries did not appear. Furthermore, XML >> schemas do not allow individual attributes or elements to be >> > registered > >> unless they appear in separate schemas. AVPs are, however, registered >> separately. Merging of several applications in a single Diameter >> > message > >> is, however, not possible. This has often been the concern when new >> Diameter applications are defined since new Diameter applications lead >> to additional message exchanges and cannot be piggy-backed on top of >> other applications without making a design decision to incorporate the >> functionality of another Diameter application. When you want to >> > develop > >> them independently then you might encounter an interesting >> > extensibility > >> story since you have very monolithic applications. >> >> Regarding the end-to-end capability negotation there is room to learn >> something from work done in other areas on extensiblity and maybe we >> don't need to re-invent the wheel every time we define another >> extension. Currently, capabilities are described using different >> > levels > >> of granularity. For example: >> >> In >> >> > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-07.t > >> xt we use the MIP6-Feature-Vector that is used to convey information >> from the NAS to the AAAH server. It is a bit map, as shown in Section >> 4.7.5. The same AVP is used in the reverse direction by the AAAH to >> indicate the authorization decision (e.g., whether the local domain is >> authorized to allocate a HA or not) in addition to implemented >> functionality that could be used for a specific protocol run. >> > [TOLGA]I think, the way Diameter base protocol stands right now, there > is little room to negotiate capabilities outside of as indicated by > ApplicationId. Anything other than that (e.g. with an AVP) would be > negotiating optional capabilities, whose lack of support shouldn't cause > the session to be terminated (because routing logic is unaware of these > optional capabilities and could route initial messages always to a > non-supporting endpoint) > I agree with your observation. Backwards compatibility is the challenge. >> As such, this functionality is more than the functionality used in SIP >> with the Require, Supported etc. headers. >> >> One problem I see is that the initial goal of routing with the help of >> Diameter application was to simplify progressing at Diameter proxies. >> > [TOLGA]Not only simplification. Routing based only on ApplicationId does > not require software updates on intermediaries as well. > Well. The software update comes when you want todo something meaningful based on the intercepted Diameter application messages. >> Instead of having to parse through the entire message in order to >> > figure > >> out whether there is something interesting in there for them to >> > process > >> they just had to inspect the Diameter application. Unforuntely, this >> hasn't really worked too well since there is no such functionality as >> the SIP Proxy Require that would delegate the decision to set a >> > certain > >> mode from the specification designer to the person that deploys it. >> > The > >> same problem already appeared with the usage of the application ID and >> the way of doing accounting. Hence, many decisions should be really >> configuration time or design time decisions rather than design time >> decision. >> > [TOLGA]Again, I think your real worry is whether combination of > capabilities should be enumerated in advance by SDOs; and I share your > concern. > >> It is kind of difficult to make a good decision on the M-bit and on >> > the > >> larger extensibility story given that >> * Diameter routing depends also on the Application ID >> * the M-bit indicates that intermediaries and other end points have to >> support a certain functionality >> Hence, the M-bit has various functionality mixed into a single piece >> of information. >> * the usage of "MAY/SHOULD use the M-bit" in the AVP flag table isn't >> really considered in the extensibility story for Diameter >> > [TOLGA]IMHO > i- If there is new AVP where M-bit may/should/must be set ==> new > ApplicationId > ii- If for an existing AVP, M-bit setting changes so that it was > previously not possible to set it and now it is ==> new ApplicationId > The problem is that this practice has not been followed within the IETF and also not by other SDOs. What should we do with all these documents? >> * adding functionality to resolve some of these problems isn't so easy >> given that these are pretty core protocol features (hint: backward >> compatibility). >> >> I don't see an easy way to solve some of these issues. I wonder >> > whether > >> anyone of you has an opinion about this rather complicated subject. >> >> Ciao >> Hannes >> >> PS: It might be good to start with a list of things we want and do not >> want: >> >> * We clearly don't want to define new applications with every tiny >> extension. Consider the following example. Think about the Diameter >> > QoS > >> attribute draft. Imagine that we would have to define an application. >> This would mean to define it to run it in the following environments: >> - Diameter EAP + Diameter QoS attributes >> - Diameter NASREQ + Diameter QoS attributes >> - Diameter CC + Diameter QoS attributes >> - Diameter Mobile IP + Diameter QoS attributes >> - etc. >> > [TOLGA]Yes, I think all this should not require a new ApplicationId (but > it currently does). > But the application ID is used to tell intermediaries to inspect and progress the messages. Without a new application ID the proxy would have to parse through the entire message. Essentially we would then move to a more flat architecture, like RADIUS has, and the proxy would have to look at more information than just the Application ID. >> * We don't want to decide during design time whether intermediaries >> should be involved. >> The previous bullet shows the dilemma. The application ID is used to >> tell intermediate nodes to participate in a particular exchange. On >> > the > >> other hand we would like to have an easy way for network operators to >> configure their nodes to process certain extensions. One way is >> obviously to have these intermediaries to look through the entire >> Diameter message for the presence (or absence) of certain AVPs. >> >> * It would help protocol designers to have an e2e capability >> > indication > >> mechanism. >> With the way how people extend Diameter applications already today I >> don't see a way to avoid having such a capability. The question is >> > only > >> whether we want to define a generic mechanism (even though it is a bit >> late). >> > [TOLGA]Currently the only way is to define a new ApplicationId. I don't > think being late should be an issue here if a new mechanism is designed > carefully: > i- Should not cause existing nodes to break > There are different nodes in Diameter and some of them are not really deployed, such as Diameter proxies. > ii- Should allow the endpoints to determine, whether the message was > routed by making use of this new mechanism > iii- Should not require intermediaries which are capable of routing > according to the new mechanism to be upgraded to support new > extensions/applications. > iv- Scope of changes signaled by extensions should be > well-defined/limited > Good design goals. Ciao Hannes >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> http://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > http://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 14 08:16:39 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FC928D0FE; Thu, 14 Feb 2008 08:16:39 -0800 (PST) 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 4+i+R9A7G8vq; Thu, 14 Feb 2008 08:16:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8489A28D0C0; Thu, 14 Feb 2008 08:15:04 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0593628D09B; Thu, 14 Feb 2008 08:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080214161502.0593628D09B@core3.amsl.com> Date: Thu, 14 Feb 2008 08:15:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-integrated-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Network Access Server to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-integrated-08.txt Pages : 21 Date : 2008-02-14 A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-integrated-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-integrated-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-14081202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-integrated-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-integrated-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-14081202.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Feb 14 08:22:17 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF4128CF38; Thu, 14 Feb 2008 08:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.792, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 D6qEIONcGQ8W; Thu, 14 Feb 2008 08:22:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2243A704F; Thu, 14 Feb 2008 08:22:16 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E267428CDD6 for ; Thu, 14 Feb 2008 08:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqh2OmAXemMv for ; Thu, 14 Feb 2008 08:22:15 -0800 (PST) Received: from sehan001bb.han.telia.se (sehan001bb.han.telia.se [131.115.18.152]) by core3.amsl.com (Postfix) with ESMTP id 605F13A706D for ; Thu, 14 Feb 2008 08:22:14 -0800 (PST) Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Feb 2008 17:23:33 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Feb 2008 17:23:28 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30288ADE7@SEHAN021MB.tcad.telia.se> In-Reply-To: <20080214161502.0593628D09B@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: I-D Action:draft-ietf-dime-mip6-integrated-08.txt Thread-Index: AchvJV257vv83thNSXKwnAGElBcs3QAAGLVw References: <20080214161502.0593628D09B@core3.amsl.com> From: To: X-OriginalArrivalTime: 14 Feb 2008 16:23:33.0948 (UTC) FILETIME=[F1B197C0:01C86F25] Subject: [Dime] FW: I-D Action:draft-ietf-dime-mip6-integrated-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org FYI Comments from various SDOs should now have been reflected in this revision. Especially, when it comes to local and visited network home agent assignment. Jouni > 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 > Network Access Server to Diameter Server Interaction > Author(s) : J. Korhonen, et al. > Filename : draft-ietf-dime-mip6-integrated-08.txt > Pages : 21 > Date : 2008-02-14 > > A Mobile IPv6 node requires a home agent address, a home address, and > a security association with its home agent before it can start > utilizing Mobile IPv6. RFC 3775 requires that some or all of these > parameters are statically configured. Mobile IPv6 bootstrapping work > aims to make this information dynamically available to the Mobile > Node. An important aspect of the Mobile IPv6 bootstrapping solution > is to support interworking with existing authentication, > authorization and accounting infrastructure. This document describes > the MIPv6 bootstrapping using the Diameter Network Access Server > (NAS) to home Authentication, Authorization and Accounting server > (HAAA) interface. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integ > rated-08.txt _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 14 20:10:31 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17113A69D2; Thu, 14 Feb 2008 20:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.015 X-Spam-Level: X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 QzwGymRMNXA0; Thu, 14 Feb 2008 20:10:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036753A6962; Thu, 14 Feb 2008 20:10:31 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4580C3A6868 for ; Thu, 14 Feb 2008 20:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 483A7PSj2mHA for ; Thu, 14 Feb 2008 20:10:29 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by core3.amsl.com (Postfix) with ESMTP id 186643A68B5 for ; Thu, 14 Feb 2008 20:10:29 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1DJfKnm072101; Wed, 13 Feb 2008 14:41:21 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47B347C8.7@tari.toshiba.com> Date: Wed, 13 Feb 2008 14:40:56 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> <47967CCB.4010903@tari.toshiba.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288AD8A@SEHAN021MB.tcad.telia.se> <47B301CE.8010903@tari.toshiba.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288ADA1@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288ADA1@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] Request routing considerations in 3588bis. was: RE: 3588bis review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, >> base. There >> are other competing solutions to the "source routing" issue that does >> not require changes to basic routing. So I think it is better if that >> happens outside existing routing procedures. >> > > I understand your concern regarding the base protocol specification. > However, I really would like to know how to deal with decorated NAIs > and Diameter routing in general. IMHO we need it documented somewhere > in IETF space. Can I assume e.g. NASREQ & EAP handle it, if those boxes > implement 3588bis? Or do I always need a new application that is > equivalent to e.g. EAP apart from modified routing? > I understand. Though it maybe more appropriate to document these issues in related extension draft (like Tina's draft). regards, victor _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 14 20:21:10 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DC03A69D1; Thu, 14 Feb 2008 20:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 edzJhvL3lV+R; Thu, 14 Feb 2008 20:21:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273B73A69D8; Thu, 14 Feb 2008 20:21:09 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 113BF3A6843 for ; Thu, 14 Feb 2008 20:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFTSNCrWUNAL for ; Thu, 14 Feb 2008 20:21:06 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by core3.amsl.com (Postfix) with ESMTP id F0C873A69CC for ; Thu, 14 Feb 2008 20:19:04 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1DEgklx070657; Wed, 13 Feb 2008 09:42:47 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47B301CE.8010903@tari.toshiba.com> Date: Wed, 13 Feb 2008 09:42:22 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com References: <59D7431DE2527D4CB0F1EFEDA5683ED30288A948@SEHAN021MB.tcad.telia.se> <47967CCB.4010903@tari.toshiba.com> <59D7431DE2527D4CB0F1EFEDA5683ED30288AD8A@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30288AD8A@SEHAN021MB.tcad.telia.se> Cc: dime@ietf.org Subject: Re: [Dime] Request routing considerations in 3588bis. was: RE: 3588bis review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jouni, > After reading (again) the request routing part of the 4588bis, > I think the I-D should say more about the realm-based routing. > For example, RFC4282 that this I-D also references to, allows > "source routing" using decorated NAIs. There are already specs > out there that assume Diameter realm routing supports this > feature. To my understanding at least 3GPP and WiMAX use this > feature to implement various roaming scenarios. However, I > cannot find any indication of such in 3588bis. Basically, I > would propose adding some text to sections 6.1. and 6.1.9. > in order to cover decorated NAIs. > > > Below is a draft proposal for a new text: > > > > 6.1. Diameter Request Routing Overview > > ... its ABNF. For Diameter clients, the value of the Destination- > Realm AVP MAY be extracted from the User-Name AVP, or other > application-specific methods. For Diameter relays and proxies, the > values of the User-Name AVP and the Destination-Realm AVP MAY be > modified if the User-Name AVP contains a NAI with multiple realms > (see RFC 4282 [RFC4282] Section 2.7 Realm Construction). > > ... > > > 6.1.9. Relaying and Proxying Requests > > ... > > Relay agents do not require full validation of incoming messages. At > a minimum, validation of the message header and relevant routing AVPs > has to be done when relaying messages. > > If both User-Name and Destination-Realm AVPs are present, then a > relay > or proxy SHOULD check whether the the User-Name AVP contains a NAI > with multiple realms (as described in RFC 4282 [RFC4282] Section > 2.7). > If multiple realms are found in the NAI then the following steps are > done: > > o The NAI in the User-Name AVP is processed and modified according to > the NAI conversion rules defined in RFC 4282 [RFC4282] Section 2.7. > > o The Destination-Realm AVP is modified with the updated realm > information extracted from the User-Name AVP. > > o The request is routed normally as described in Section 6.1.6. > > > > Any comments etc ? > Mmmm .... for me, putting decorated NAI dependencies in the base is probably going to confuse folks. To me decorated NAI is a solution to a very specific problem that should not be generalized in the base. There are other competing solutions to the "source routing" issue that does not require changes to basic routing. So I think it is better if that happens outside existing routing procedures. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 14 20:21:10 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5ECF3A6A01; Thu, 14 Feb 2008 20:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 Bs7JElPS4b+7; Thu, 14 Feb 2008 20:21:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509CE3A69EF; Thu, 14 Feb 2008 20:21:09 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E173A6843 for ; Thu, 14 Feb 2008 20:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xBhtJ61YcXE for ; Thu, 14 Feb 2008 20:21:06 -0800 (PST) Received: from toshi17.tari.toshiba.com (mgw.toshibaamericaresearch.com [165.254.55.12]) by core3.amsl.com (Postfix) with ESMTP id 760FB3A69D1 for ; Thu, 14 Feb 2008 20:19:05 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1DEWdHE070617; Wed, 13 Feb 2008 09:32:40 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47B2FF6E.2020409@tari.toshiba.com> Date: Wed, 13 Feb 2008 09:32:14 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Preeti Shandilya References: In-Reply-To: Cc: dime@ietf.org Subject: Re: [Dime] Suggestion for Enhancement in RFC 3588 X-BeenThere: dime@ietf.org X-Mailman-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, > I have a suggestion which should consider when we comeout with the next > bis for RFC 3588. > > In my opinion, there are some information provided in the RFC 3588 and in > the latest bis , which in my opinion should not be the part of this RFC. > > RFC 3588 should only specify the detail of the diameter base procedures , > commands and AVPs used by base messages. > > It should not define any other messages and its' ABNF, state machines and > procedures. This unnecessarily creates the duplication of the information > in the multiple RFCs and creates the inconsistency. > > To site an example, base RFC defines the accounting messages, > corresponding state machine and AVPs. I am not able to understand why it > is a requirement to define these in the diameter base. Accounting should > be prerogative of the application specific RFCs. Application specific RFCs > should define the command codes and corresponding procedures. > > Having accounting in diameter base should never be a requirement. > > RFC indicates that RAR, ASR and STR are base messages. In my opinion this > should come under application specific messages as Diameter base ideally > would not maintain the application sessions. > I think this discussion has been hashed before. Some folks (including me) agree that it would have been a better choice to have two(2) documents; a base protocol doc and session related doc. However, going with that approach this late is not productive and would cause even more delays in delivering the document as well as breaking an ever increasing document dependencies. -- victor _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 18 12:42:13 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16433A6D57; Mon, 18 Feb 2008 12:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 Q10mVmfK1nLK; Mon, 18 Feb 2008 12:42:13 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1F128C4A0; Mon, 18 Feb 2008 12:39:56 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5584D28C42E for ; Mon, 18 Feb 2008 12:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1tHLRNxSIsN for ; Mon, 18 Feb 2008 12:39:54 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C5A1C28C4A3 for ; Mon, 18 Feb 2008 12:38:34 -0800 (PST) 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 m1IKbset027467 for ; Mon, 18 Feb 2008 14:38:29 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.8]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Feb 2008 14:38:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Feb 2008 14:38:17 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D013C11D0@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: I-D Action:draft-sun-dime-itu-t-rw-00.txt Thread-Index: AchybJYSnP89qwr4TiGL5BFnLAniFQAAMSmw From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 18 Feb 2008 20:38:18.0959 (UTC) FILETIME=[31EC2DF0:01C8726E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [Dime] Fwd: I-D Action: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 Greetings, A new draft I-D is submitted for requesting new command code and vendor-specific application ID for a Diameter application defined by ITU-T (Rw interface). Regards, Dong Sun Alcatel-Lucent Chief Technology Office 600 Mountain Ave Murray Hill, NJ 07974 USA Tel/Fax: +1 908-582-2617 Email: dongsun@alcatel-lucent.com -------- Original Message -------- Subject: I-D Action:draft-sun-dime-itu-t-rw-00.txt Date: Mon, 18 Feb 2008 12:15:01 -0800 (PST) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Policy Enforcement Interface: ITU-T Rw Author(s) : D. Sun Filename : draft-sun-dime-itu-t-rw-00.txt Pages : 11 Date : 2008-02-18 This document describes the need for a new pair of IANA Diameter Command Codes and a new vendor-specific Application ID to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/responses for controlling the policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sun-dime-itu-t-rw-00.txt _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Feb 19 06:28:10 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA4B28C35D; Tue, 19 Feb 2008 06:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 eSlgFMGd-Bgw; Tue, 19 Feb 2008 06:28:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4EE3A6AB6; Tue, 19 Feb 2008 06:28:08 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A4C3A6AAF for ; Tue, 19 Feb 2008 06:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fFK+wPaHvTy for ; Tue, 19 Feb 2008 06:28:06 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A254A3A6A8B for ; Tue, 19 Feb 2008 06:28:05 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2008 14:28:01 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp046) with SMTP; 19 Feb 2008 15:28:01 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NAvl3xMZNIrKZ69At+ZQKSVCLSe8dto2bFtta56 1s9qYaAZqGTwNR Message-ID: <47BAE77B.8070208@gmx.net> Date: Tue, 19 Feb 2008 16:28:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] Design Team on Diameter Extensibility X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net 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 DIME chairs in discussion with our AD decided to create a design team with the intention to revisit the rules for Diameter extensibility (as described in RFC 3588, RFC 3588bis and the Diameter Design Guidelines document) to come up with a precise and short description on how Diameter has to be extended (considering backwards compatibility issues etc.). The design team members are: * Avi Lior * Jari Arkko * Glen Zorn * Victor Fajardo * Tolga Asveren * Mark Jones I am still waiting for a time commitment from Glenn McGregor and John Loughney. The design team is lead by the working group chairs: Dave Frascone and Hannes Tschofenig The design team will have regular phone conferences (starting with next week) and will have a face-to-face meeting at IETF#71. We hope to conclude our investigations soon to present a proposal for further discussion to the DIME working group. Ciao Hannes PS: The rules for design teams are described in http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 21 01:07:28 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9E528CA08; Thu, 21 Feb 2008 01:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 17VGDhVUqdr0; Thu, 21 Feb 2008 01:07:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B2328CA0B; Thu, 21 Feb 2008 01:07:22 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B35F28CA09 for ; Thu, 21 Feb 2008 01:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2e41Jk0ar58 for ; Thu, 21 Feb 2008 01:07:21 -0800 (PST) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by core3.amsl.com (Postfix) with ESMTP id E1E2528CA22 for ; Thu, 21 Feb 2008 01:07:20 -0800 (PST) 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.68) (envelope-from ) id 1JS7Od-0004ux-Ou; Thu, 21 Feb 2008 10:07:15 +0100 Message-ID: <47BD3F43.7000606@cs.uni-goettingen.de> Date: Thu, 21 Feb 2008 10:07:15 +0100 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: dime@ietf.org X-Virus-Scanned: (clean) by exiscan+sophie Subject: [Dime] Diameter 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hello everybody, my name is Niklas Neumann and currently I am working as a research assistant at the University of Goettingen. For my masters thesis I developed an approach to Diameter-based identity management for web applications. A part of this work is now available as an Internet-Draft: Title : Diameter Application for Authentication and Authorization in Web Applications Author(s) : N. Neumann, X. Fu Filename : draft-neumann-dime-webauth-00.txt Pages : 26 Date : 2008-2-18 This document specifies the Diameter Application for Authentication and Authorization in Web Applications (Diameter WebAuth). This Diameter application is intended to be used by Diameter clients to perform authentication and authorization operations with a Diameter server in web-based environments. It provides facilities to allow web sites to authenticate their web user clients using a number of (HTTP) authentication schemes. In addition, it supports user authorization using dedicated service identifiers. Diameter WebAuth may also be used by non web-based Diameter clients and servers that require a lightweight authentication and authorization Diameter application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-neumann-dime-webauth-00.txt I would really appreciate any comments and suggestions on this topic from you. Especially I'd like to know if there is interest in such a work from your side, bringing the Diameter protocol closer to the application level. The whole master thesis is available at http://www.net.informatik.uni-goettingen.de/publications/1495/master_thesis_niklas_neumann.pdf (if you are interested). It includes more details, an evaluation of other approaches to web-based identity management (OpenId, Liberty, etc.) and a section about the prototype implementation. The Internet-Draft only reflects a part of this work, some other aspects of the work done in the thesis are left out for now, but you have to start somewhere :) So long Niklas -- Niklas Neumann - University of Goettingen, Institute of Informatics http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-14419 _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Feb 25 01:00:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000CB3A6CC2; Mon, 25 Feb 2008 01:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 MfZI67aZ+w99; Mon, 25 Feb 2008 01:00:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27E628C211; Mon, 25 Feb 2008 01:00:03 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7E89428C0F6; Mon, 25 Feb 2008 01:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225090001.7E89428C0F6@core3.amsl.com> Date: Mon, 25 Feb 2008 01:00:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-02.txt Pages : 22 Date : 2008-02-24 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-parameters-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-parameters-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25004518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25004518.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Feb 25 01:45:17 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8174928C1A2; Mon, 25 Feb 2008 01:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 0tPj9+jIqML6; Mon, 25 Feb 2008 01:45:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE0528C329; Mon, 25 Feb 2008 01:45:15 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 214B13A6926; Mon, 25 Feb 2008 01:45:02 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225094502.214B13A6926@core3.amsl.com> Date: Mon, 25 Feb 2008 01:45:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-mip6-split-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 Mobile IPv6: Support for Home Agent to Diameter Server Interaction Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-mip6-split-07.txt Pages : 33 Date : 2008-02-25 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-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-mip6-split-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-mip6-split-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25014149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-mip6-split-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-mip6-split-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25014149.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Feb 25 06:15:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D628C28C5BF; Mon, 25 Feb 2008 06:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 dpNanl-7Z0Mj; Mon, 25 Feb 2008 06:15:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BA9428C338; Mon, 25 Feb 2008 06:15:04 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 19CF23A6C0B; Mon, 25 Feb 2008 06:15:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225141502.19CF23A6C0B@core3.amsl.com> Date: Mon, 25 Feb 2008 06:15:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter Author(s) : H. Tschofenig, et al. Filename : draft-ietf-dime-qos-attributes-05.txt Pages : 15 Date : 2008-02-25 This document extends the QoSFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-attributes-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-attributes-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25060544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-attributes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25060544.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Feb 25 06:30:08 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33B728C639; Mon, 25 Feb 2008 06:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 pT76CYa83joU; Mon, 25 Feb 2008 06:30:07 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC7B28C60E; Mon, 25 Feb 2008 06:30:06 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 026C728C40B; Mon, 25 Feb 2008 06:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225143002.026C728C40B@core3.amsl.com> Date: Mon, 25 Feb 2008 06:30:02 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-parameters-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: , Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Parameters for Usage with the AAA Framework Author(s) : J. Korhonen, H. Tschofenig Filename : draft-ietf-dime-qos-parameters-03.txt Pages : 22 Date : 2008-02-25 This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-qos-parameters-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-qos-parameters-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25062649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-qos-parameters-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-qos-parameters-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25062649.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Mon Feb 25 09:00:15 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49AA528C6A8; Mon, 25 Feb 2008 09:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 CPFLEN182DzM; Mon, 25 Feb 2008 09:00:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A3C428C5CE; Mon, 25 Feb 2008 09:00:11 -0800 (PST) X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 95AAF3A6D31; Mon, 25 Feb 2008 09:00:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225170001.95AAF3A6D31@core3.amsl.com> Date: Mon, 25 Feb 2008 09:00:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-diameter-qos-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: , 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-05.txt Pages : 56 Date : 2008-02-25 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-diameter-qos-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-diameter-qos-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-25085954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-diameter-qos-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-diameter-qos-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-25085954.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org http://www.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Tue Feb 26 21:41:34 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188E128C2CA; Tue, 26 Feb 2008 21:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.187 X-Spam-Level: ** X-Spam-Status: No, score=2.187 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEsFeSNveQ-h; Tue, 26 Feb 2008 21:41:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214D63A6CE8; Tue, 26 Feb 2008 21:41:33 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7884C3A6CE8 for ; Tue, 26 Feb 2008 21:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iHGWOL0k3Rw for ; Tue, 26 Feb 2008 21:41:27 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 546D73A68F4 for ; Tue, 26 Feb 2008 21:41:21 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1R5SEB7004601 for ; Wed, 27 Feb 2008 10:58:14 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1R5SDMT004580 for ; Wed, 27 Feb 2008 10:58:14 +0530 In-Reply-To: To: dime@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Wed, 27 Feb 2008 11:11:36 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 27/02/2008 11:16:31 AM, Serialize complete at 27/02/2008 11:16:31 AM Subject: [Dime] Redirect-Host-Usage AVP X-BeenThere: dime@ietf.org X-Mailman-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="===============1709274222==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1709274222== Content-Type: multipart/alternative; boundary="=_alternative 001F47E9652573FC_=" This is a multipart message in MIME format. --=_alternative 001F47E9652573FC_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgIQ0KDQpEZXNjcmlwdGlvbiBvZiBSZWRpcmVjdC1Ib3N0LVVzYWdlIEFWUCBpbiB0aGUgYmlz IG9mIFJGQzM1ODggKGJpcyA5KSANCmluZGljYXRlcyB0aGF0IGl0IGNhbiBoYXZlIHZhbHVlIEFM TF9TRVNTSU9ODQoNClNvIGlmIHJlZGlyZWN0IGFnZW50IHNlbmRzIFJlZGlyZWN0LUhvc3QtVXNh Z2UgQVZQIGFzIEFMTF9TRVNTSU9OLCB0aGlzIA0KaW5kaWNhdGVzIHRoYXQgY2xpZW50IHNob3Vs ZCBzZW5kIGFsbCB0aGUgc2Vzc2lvbiBvcmllbnRlZCBtZXNzYWdlcyB0byB0aGUgDQpzYW1lIHJl ZGlyZWN0IGhvc3QgdXNhZ2UgLCB3aGljaCByZWRpcmVjdCBhZ2VudCBoYXMgaW5mb3JtZWQgaW4g dGhlIA0KcmVkaXJlY3QgaW5kaWNhdGlvbiwgYXQgdGhlIHN0YXJ0IG9mIHRoZSBzZXNzaW9uLiBJ biBteSBvcGluaW9uLCB0aGlzIA0KcG9zc2libGUgdmFsdWUgb2YgUmVkaXJlY3QtSG9zdC1Vc2Fn ZSBBVlAgaXMgJ3JlZHVuZGFudCcuIFRoZXJlIHNoYWxsIGJlIA0Kbm8gcHJhY3RpY2FsIHNjZW5h cmlvLCB3aGVuIHN1YnNlcXVlbnQgbWVzc2FnZSBvbiB0aGUgc2FtZSBzZXNzaW9uIG1heSB0byAN CmRpZmZlcmVudCBob3N0Lg0KDQpJbiBteSBvcGluaW9uLCB3ZSBzaG91bGQgbm90IGhhdmUgQUxM X1NFU1NJT04gYXMgYSBwb3NzaWJsZSB2YWx1ZSBvZiB0aGUgDQpSZWRpcmVjdC1Ib3N0LVVzYWdl IEFWUCBhbmQgc2hvdWxkIGFzc3VtZSB0aGF0IGFsbCB0aGUgIHNlc3Npb24gb3JpZW50ZWQgDQpt ZXNzYWdlIHNob3VsZCBnbyB0byB0aGUgc2FtZSBob3N0IHRvIHdoaWNoIGZpcnN0IG1lc3NhZ2Ug Y29ycmVzcG9uZGluZyB0byANCnRoYXQgc2Vzc2lvbiB3YXMgc2VudC4gVGhlIHRpbWUgbGltaXQg Zm9yIHdoaWNoIHRoaXMgcm91dGluZyBpcyB2YWxpZCANCnNoYWxsIG9mLWNvdXJzZSBiZSBkcml2 ZW4gYnkgUmVkaXJlY3QtTWF4LUNhY2hlLVRpbWUgQVZQDQoNCkxldCBtZSBrbm93IGlmIEkgYW0g bWlzc2luZyBzb21ldGhpbmcgaGVyZQ0KDQpyZWdhcmRzDQpQcmVldGkNCg0KKioqKioqKioqKioq KioqKioqKioqKiogIEFyaWNlbnQtUmVzdHJpY3RlZCAgICoqKioqKioqKioqKioqKioqKioqKioq DQoiRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlzIHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFu ZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdo b20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5vdCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZv ciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBv cmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZy b20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBvciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBv ZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxv c3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFu c21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGluZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCg== --=_alternative 001F47E9652573FC_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpICE8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlc2NyaXB0aW9uIG9mIFJlZGlyZWN0 LUhvc3QtVXNhZ2UgQVZQDQppbiB0aGUgYmlzIG9mIFJGQzM1ODggKGJpcyA5KSBpbmRpY2F0ZXMg dGhhdCBpdCBjYW4gaGF2ZSB2YWx1ZSBBTExfU0VTU0lPTjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28gaWYgcmVkaXJlY3QgYWdlbnQgc2VuZHMgUmVk aXJlY3QtSG9zdC1Vc2FnZQ0KQVZQIGFzIEFMTF9TRVNTSU9OLCB0aGlzIGluZGljYXRlcyB0aGF0 IGNsaWVudCBzaG91bGQgc2VuZCBhbGwgdGhlIHNlc3Npb24NCm9yaWVudGVkIG1lc3NhZ2VzIHRv IHRoZSBzYW1lIHJlZGlyZWN0IGhvc3QgdXNhZ2UgLCB3aGljaCByZWRpcmVjdCBhZ2VudA0KaGFz IGluZm9ybWVkIGluIHRoZSByZWRpcmVjdCBpbmRpY2F0aW9uLCBhdCB0aGUgc3RhcnQgb2YgdGhl IHNlc3Npb24uIEluDQpteSBvcGluaW9uLCB0aGlzIHBvc3NpYmxlIHZhbHVlIG9mIFJlZGlyZWN0 LUhvc3QtVXNhZ2UgQVZQIGlzICdyZWR1bmRhbnQnLg0KVGhlcmUgc2hhbGwgYmUgbm8gcHJhY3Rp Y2FsIHNjZW5hcmlvLCB3aGVuIHN1YnNlcXVlbnQgbWVzc2FnZSBvbiB0aGUgc2FtZQ0Kc2Vzc2lv biBtYXkgdG8gZGlmZmVyZW50IGhvc3QuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5JbiBteSBvcGluaW9uLCB3ZSBzaG91bGQgbm90IGhhdmUgQUxMX1NF U1NJT04NCmFzIGEgcG9zc2libGUgdmFsdWUgb2YgdGhlIFJlZGlyZWN0LUhvc3QtVXNhZ2UgQVZQ IGFuZCBzaG91bGQgYXNzdW1lIHRoYXQNCmFsbCB0aGUgJm5ic3A7c2Vzc2lvbiBvcmllbnRlZCBt ZXNzYWdlIHNob3VsZCBnbyB0byB0aGUgc2FtZSBob3N0IHRvIHdoaWNoDQpmaXJzdCBtZXNzYWdl IGNvcnJlc3BvbmRpbmcgdG8gdGhhdCBzZXNzaW9uIHdhcyBzZW50LiBUaGUgdGltZSBsaW1pdCBm b3INCndoaWNoIHRoaXMgcm91dGluZyBpcyB2YWxpZCBzaGFsbCBvZi1jb3Vyc2UgYmUgZHJpdmVu IGJ5IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlJlZGlyZWN0LU1heC1D YWNoZS1UaW1lDQpBVlA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkxldCBtZSBrbm93IGlmIEkgYW0gbWlzc2luZyBzb21ldGhpbmcNCmhlcmU8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnJlZ2FyZHM8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlByZWV0aTxicj4NCjxicj4NCioq KioqKioqKioqKioqKioqKioqKioqICZuYnNwO0FyaWNlbnQtUmVzdHJpY3RlZCAmbmJzcDsgKioq KioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+DQo8dGFibGU+PHRyPjx0ZCBiZ2NvbG9yPSNmZmZm ZmY+PGZvbnQgY29sb3I9IzAwMDAwMD48cHJlPiJESVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMg cHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250 YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90 IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFueSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdo YXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBl cnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3Ug YXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9y IGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRoaXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRz IG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBvciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1 c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5n IGRhbWFnZSBmcm9tIHZpcnVzLiIKPC9wcmU+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPg== --=_alternative 001F47E9652573FC_=-- --===============1709274222== 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 --===============1709274222==-- From dime-bounces@ietf.org Tue Feb 26 23:31:47 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451D228C4E5; Tue, 26 Feb 2008 23:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 g16ymkTjC2uC; Tue, 26 Feb 2008 23:31:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AF528C49B; Tue, 26 Feb 2008 23:31:46 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F6828C43C for ; Tue, 26 Feb 2008 23:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeFsmewlYOX6 for ; Tue, 26 Feb 2008 23:31:38 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ABAB73A6DBC for ; Tue, 26 Feb 2008 23:31:37 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2008 07:31:29 -0000 Received: from proxy4-nsn.nsn-inter.net (EHLO [217.115.75.232]) [217.115.75.232] by mail.gmx.net (mp048) with SMTP; 27 Feb 2008 08:31:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX198qcIvpDx8UZQq3pqopE9S4jy5twd4xmf9+fTDc5 7TpfuPRf1DVw+Y Message-ID: <47C511C5.5020403@gmx.net> Date: Wed, 27 Feb 2008 09:31:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] DIME AGENDA (Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hannes.Tschofenig@gmx.net List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Here is the agenda proposal http://www3.ietf.org/proceedings/08mar/agenda/dime.txt This time it is difficult to work on the agenda. Here are the reasons: It is obvious that we want to finish our current working group items. Although we wanted to finish them already some time ago we are still left with a number of items. We got good feedback on the mobility issues from other SDOs, we encountered some problems with Diameter extensibility and now we have a design team, we got feedback on the QoS topic from other working groups. We submitted a publication request for the Diameter API and we are going todo the same for the Diameter Mobile IPv6 integrated scenario draft. At the last IETF meeting we rushed through the different topics and there was no time for discussion. We did not have too much discussion on the individual proposals at all. Almost no reviews sent to the list. It almost seems that the draft authors of the individual proposals just care about their work and nothing else. That's not great since we will never get the work done. Unfortunately, the list of documents relevant for rechartering did not got shorter; it got longer. In short, we have to think about this a bit more and see how we can deal with this in a reasonable fashion. Hence, we called the agenda item "rechartering discussion". Just repeating presentations again does not move us forward -- particularly if nobody has read the documents. Your feedback would obviously be welcome _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 27 06:09:49 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9BD3A69D6; Wed, 27 Feb 2008 06:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 V2XYHlax+Xou; Wed, 27 Feb 2008 06:09:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1123A6D84; Wed, 27 Feb 2008 06:09:34 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1B23A6A7D for ; Wed, 27 Feb 2008 06:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3J8jwME2YjN for ; Wed, 27 Feb 2008 06:09:32 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id BD8A23A6CF3 for ; Wed, 27 Feb 2008 06:09:32 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1RE9984038369; Wed, 27 Feb 2008 09:09:14 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47C56F01.4080600@tari.toshiba.com> Date: Wed, 27 Feb 2008 09:09:05 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Preeti Shandilya References: In-Reply-To: Cc: dime@ietf.org Subject: Re: [Dime] Redirect-Host-Usage AVP X-BeenThere: dime@ietf.org X-Mailman-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 Preeti, > Description of Redirect-Host-Usage AVP in the bis of RFC3588 (bis 9) > indicates that it can have value ALL_SESSION > > So if redirect agent sends Redirect-Host-Usage AVP as ALL_SESSION, this > indicates that client should send all the session oriented messages to the > same redirect host usage , which redirect agent has informed in the > redirect indication, at the start of the session. In my opinion, this > possible value of Redirect-Host-Usage AVP is 'redundant'. There shall be > no practical scenario, when subsequent message on the same session may to > different host. > > In my opinion, we should not have ALL_SESSION as a possible value of the > Redirect-Host-Usage AVP and should assume that all the session oriented > message should go to the same host to which first message corresponding to > that session was sent. The time limit for which this routing is valid > shall of-course be driven by Redirect-Max-Cache-Time AVP > I guess the point of ALL_SESSION is: how will you know to redirect messages for this session in the first place unless you get an ALL_SESSION redirection. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Feb 27 07:52:21 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C73128C5DC; Wed, 27 Feb 2008 07:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 LUj85cUusGek; Wed, 27 Feb 2008 07:52:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9EDD28C34F; Wed, 27 Feb 2008 07:52:15 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C7A28C25D for ; Wed, 27 Feb 2008 07:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhHLZHYMIAX5 for ; Wed, 27 Feb 2008 07:52:09 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id A63ED3A68A6 for ; Wed, 27 Feb 2008 07:52:09 -0800 (PST) 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 <0JWW00DRHMQPFM@usaga04-in.huawei.com> for dime@ietf.org; Wed, 27 Feb 2008 09:52:02 -0600 (CST) Received: from ny3104051930 ([10.124.12.58]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JWW00A88MQNUW@usaga04-in.huawei.com> for dime@ietf.org; Wed, 27 Feb 2008 09:52:01 -0600 (CST) Date: Wed, 27 Feb 2008 09:55:39 -0600 From: Frank Xia To: Hannes.Tschofenig@gmx.net, dime@ietf.org Message-id: <02b601c87959$33816f30$3a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal References: <47C511C5.5020403@gmx.net> Subject: Re: [Dime] DIME AGENDA (Proposal) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Hannes Probably you can list all the potential topics for rechartering, at the same time, you can list the dimensions for evaluate the topics, such as, deployment possibility, dependency with other IETF documents and so on. BR Frank ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Wednesday, February 27, 2008 1:31 AM Subject: [Dime] DIME AGENDA (Proposal) > Here is the agenda proposal > http://www3.ietf.org/proceedings/08mar/agenda/dime.txt > > This time it is difficult to work on the agenda. > Here are the reasons: > > It is obvious that we want to finish our current working group items. > Although we wanted to finish them already some time ago we are still left with a number of items. > We got good feedback on the mobility issues from other SDOs, we encountered some problems with Diameter extensibility and now we have a design team, we got feedback on the QoS topic from other working groups. We submitted a publication request for the Diameter API and we are going todo the same for the Diameter Mobile IPv6 integrated scenario draft. > > At the last IETF meeting we rushed through the different topics and there was no time for discussion. We did not have too much discussion on the individual proposals at all. Almost no reviews sent to the list. > > It almost seems that the draft authors of the individual proposals just care about their work and nothing else. That's not great since we will never get the work done. > > Unfortunately, the list of documents relevant for rechartering did not got shorter; it got longer. > > In short, we have to think about this a bit more and see how we can deal with this in a reasonable fashion. Hence, we called the agenda item "rechartering discussion". > > Just repeating presentations again does not move us forward -- particularly if nobody has read the documents. > > Your feedback would obviously be welcome > > > _______________________________________________ > 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 Feb 27 08:28:54 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A426F28C785; Wed, 27 Feb 2008 08:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 Zqf5HGcwQ7pb; Wed, 27 Feb 2008 08:28:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD8728C35A; Wed, 27 Feb 2008 08:28:49 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D083C28C35A; Wed, 27 Feb 2008 08:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rKvLEd7Xgdp; Wed, 27 Feb 2008 08:28:43 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 52E8428C2BD; Wed, 27 Feb 2008 08:28:43 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5C54F2087D; Wed, 27 Feb 2008 17:24:25 +0100 (CET) X-AuditID: c1b4fb3c-b08c0bb000007e19-e7-47c58eb952e3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48F3320583; Wed, 27 Feb 2008 17:24:25 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:24:24 +0100 Received: from [127.0.0.1] ([147.214.30.103]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Feb 2008 17:24:24 +0100 Message-ID: <47C58EB8.1000203@ericsson.com> Date: Wed, 27 Feb 2008 17:24:24 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: tsvwg X-OriginalArrivalTime: 27 Feb 2008 16:24:24.0722 (UTC) FILETIME=[3753D720:01C8795D] X-Brightmail-Tracker: AAAAAA== Cc: dime@ietf.org, NSIS Subject: [Dime] WG last call on draft-ietf-tsvwg-emergency-rsvp-05 X-BeenThere: dime@ietf.org X-Mailman-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 This announces the second WG last call on "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services" with the intended status of proposed standard: http://tools.ietf.org/id/draft-ietf-tsvwg-emergency-rsvp-05.txt This is the second one due to changes and the interaction with documents in the NSIS and DIME WG. Please provide any comments on the TSVWG mailing list no later than 28th of March. (Yes, it is long but that is due to the meeting and that we have several other WG last calls ongoing). Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 28 14:03:39 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A3E3A6ED5; Thu, 28 Feb 2008 14:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 fdUswiT+GCuj; Thu, 28 Feb 2008 14:03:34 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1133A6E04; Thu, 28 Feb 2008 14:03:31 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31B63A6ED2 for ; Thu, 28 Feb 2008 14:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6dDcFtTDiAL for ; Thu, 28 Feb 2008 14:03:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 462743A6F10 for ; Thu, 28 Feb 2008 14:03:02 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2008 22:02:54 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp041) with SMTP; 28 Feb 2008 23:02:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18bGgxiRQ8b5vkcZ+dIwaJiUqBCt85efds/uf8l+E 68brFgmub/HD/4 Message-ID: <47C72F8D.3040908@gmx.net> Date: Fri, 29 Feb 2008 00:02:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: dime@ietf.org X-Y-GMX-Trusted: 0 Subject: [Dime] NEW Wiki for DIME X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org I moved the Wiki to the following address: http://www.shingou.info/twiki/bin/view/Dime We plan to provide a DIME WG status update next week. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Feb 28 20:20:04 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558733A6A07; Thu, 28 Feb 2008 20:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.184 X-Spam-Level: ** X-Spam-Status: No, score=2.184 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQHDaZc1JBom; Thu, 28 Feb 2008 20:19:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE8B3A6A5D; Thu, 28 Feb 2008 20:19:58 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C040D3A67A9; Thu, 28 Feb 2008 20:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoRdksyGba7f; Thu, 28 Feb 2008 20:19:52 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [61.246.186.17]) by core3.amsl.com (Postfix) with ESMTP id 548A03A6A5D; Thu, 28 Feb 2008 20:19:51 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1T46dhG016636; Fri, 29 Feb 2008 09:36:39 +0530 Received: from sandesh.gur.aricent.com (sandesh [10.203.142.21]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id m1T46bMi016608; Fri, 29 Feb 2008 09:36:38 +0530 In-Reply-To: <47C56F01.4080600@tari.toshiba.com> To: Victor Fajardo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Preeti Shandilya Date: Fri, 29 Feb 2008 09:49:31 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 29/02/2008 09:55:00 AM, Serialize complete at 29/02/2008 09:55:00 AM Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Redirect-Host-Usage AVP X-BeenThere: dime@ietf.org X-Mailman-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="===============0019674173==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0019674173== Content-Type: multipart/alternative; boundary="=_alternative 0017C2DB652573FE_=" This is a multipart message in MIME format. --=_alternative 0017C2DB652573FE_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgVmljdG9yICENCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KDQpSZWRpcmVjdCBhZ2Vu dCBzaG91bGQgcHJvdmlkZSB0aGUgcmVkaXJlY3QgaG9zdCBBVlBzICwgc29sZWx5IGJhc2VkIHVw b24gDQp0aGUgcm91dGluZyB0YWJsZXMgYXZhaWxhYmxlIGF0IHRoZSByZWRpcmVjdCBhZ2VudC4g SXQgc2hvdWxkIG5vdCBjb25jZXJuIA0KYWJvdXQgYW55IHNlc3Npb24gISBTbyBhbGwgdGhlIHBv c3NpYmxlIHZhbHVlcyBmb3IgUmVkaXJlY3QtSG9zdCB1c2FnZSANCkFWUHMgbWVudGlvbmVkIGlu IHRoZSBSRkMsIGV4Y2VwdCBBTExfU0VTU0lPTiwgc29tZWhvdyBpbmRpY2F0ZXMgdGhlIA0Kcm91 dGluZyB0YWJsZSBhdCB0aGUgcmVkaXJlY3QgYWdlbnQuIA0KDQpGb3IgZmluZGluZyB0aGUgcm91 dGUgZm9yIHRoZSBmaXJzdCBtZXNzYWdlLCBmcm9tIHRoZSByZWRpcmVjdCBhZ2VudCwgaXMgDQpy ZXNwb25zaWJpbGl0eSBvZiB0aGUgY2xpZW50LiBXaHkgc2hvdWxkIHJlZGlyZWN0IGFnZW50IGJl IGNvbmNlcm5lZCBhYm91dCANCndoZXRoZXIgaXQgaXMgZmlyc3QgbWVzc2FnZSBvciB0aGUgc3Vi c2VxdWVudCBtZXNzYWdlIGZvciB0aGUgc2Vzc2lvbg0KDQpyZWdhcmRzDQpQcmVldGkNCg0KDQoN ClZpY3RvciBGYWphcmRvIDx2ZmFqYXJkb0B0YXJpLnRvc2hpYmEuY29tPiANClNlbnQgYnk6IGRp bWUtYm91bmNlc0BpZXRmLm9yZw0KMDIvMjcvMjAwOCAwNzozOSBQTQ0KDQoNClRvDQpQcmVldGkg U2hhbmRpbHlhL0hTU0BIU1MNCmNjDQpkaW1lQGlldGYub3JnDQpTdWJqZWN0DQpSZTogW0RpbWVd IFJlZGlyZWN0LUhvc3QtVXNhZ2UgQVZQDQoNCg0KDQoNCg0KDQpIaSBQcmVldGksDQo+IERlc2Ny aXB0aW9uIG9mIFJlZGlyZWN0LUhvc3QtVXNhZ2UgQVZQIGluIHRoZSBiaXMgb2YgUkZDMzU4OCAo YmlzIDkpIA0KPiBpbmRpY2F0ZXMgdGhhdCBpdCBjYW4gaGF2ZSB2YWx1ZSBBTExfU0VTU0lPTg0K Pg0KPiBTbyBpZiByZWRpcmVjdCBhZ2VudCBzZW5kcyBSZWRpcmVjdC1Ib3N0LVVzYWdlIEFWUCBh cyBBTExfU0VTU0lPTiwgdGhpcyANCj4gaW5kaWNhdGVzIHRoYXQgY2xpZW50IHNob3VsZCBzZW5k IGFsbCB0aGUgc2Vzc2lvbiBvcmllbnRlZCBtZXNzYWdlcyB0byANCnRoZSANCj4gc2FtZSByZWRp cmVjdCBob3N0IHVzYWdlICwgd2hpY2ggcmVkaXJlY3QgYWdlbnQgaGFzIGluZm9ybWVkIGluIHRo ZSANCj4gcmVkaXJlY3QgaW5kaWNhdGlvbiwgYXQgdGhlIHN0YXJ0IG9mIHRoZSBzZXNzaW9uLiBJ biBteSBvcGluaW9uLCB0aGlzIA0KPiBwb3NzaWJsZSB2YWx1ZSBvZiBSZWRpcmVjdC1Ib3N0LVVz YWdlIEFWUCBpcyAncmVkdW5kYW50Jy4gVGhlcmUgc2hhbGwgYmUgDQoNCj4gbm8gcHJhY3RpY2Fs IHNjZW5hcmlvLCB3aGVuIHN1YnNlcXVlbnQgbWVzc2FnZSBvbiB0aGUgc2FtZSBzZXNzaW9uIG1h eSANCnRvIA0KPiBkaWZmZXJlbnQgaG9zdC4NCj4NCj4gSW4gbXkgb3Bpbmlvbiwgd2Ugc2hvdWxk IG5vdCBoYXZlIEFMTF9TRVNTSU9OIGFzIGEgcG9zc2libGUgdmFsdWUgb2YgdGhlIA0KDQo+IFJl ZGlyZWN0LUhvc3QtVXNhZ2UgQVZQIGFuZCBzaG91bGQgYXNzdW1lIHRoYXQgYWxsIHRoZSAgc2Vz c2lvbiBvcmllbnRlZCANCg0KPiBtZXNzYWdlIHNob3VsZCBnbyB0byB0aGUgc2FtZSBob3N0IHRv IHdoaWNoIGZpcnN0IG1lc3NhZ2UgY29ycmVzcG9uZGluZyANCnRvIA0KPiB0aGF0IHNlc3Npb24g d2FzIHNlbnQuIFRoZSB0aW1lIGxpbWl0IGZvciB3aGljaCB0aGlzIHJvdXRpbmcgaXMgdmFsaWQg DQo+IHNoYWxsIG9mLWNvdXJzZSBiZSBkcml2ZW4gYnkgUmVkaXJlY3QtTWF4LUNhY2hlLVRpbWUg QVZQDQo+IA0KDQpJIGd1ZXNzIHRoZSBwb2ludCBvZiBBTExfU0VTU0lPTiBpczogaG93IHdpbGwg eW91IGtub3cgdG8gcmVkaXJlY3QgDQptZXNzYWdlcyBmb3IgdGhpcyBzZXNzaW9uIGluIHRoZSBm aXJzdCBwbGFjZSB1bmxlc3MgeW91IGdldCBhbiANCkFMTF9TRVNTSU9OIHJlZGlyZWN0aW9uLg0K DQpyZWdhcmRzLA0KdmljdG9yDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQoqKioqKioqKioqKioqKioq KioqKioqKiAgQXJpY2VudC1SZXN0cmljdGVkICAgKioqKioqKioqKioqKioqKioqKioqKioNCiJE SVNDTEFJTUVSOiBUaGlzIG1lc3NhZ2UgaXMgcHJvcHJpZXRhcnkgdG8gQXJpY2VudCAgYW5kIGlz IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiAKdGhlIGluZGl2aWR1YWwgdG8gd2hvbSBp dCBpcyBhZGRyZXNzZWQuIEl0IG1heSBjb250YWluIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFs IGluZm9ybWF0aW9uIGFuZCBzaG91bGQgbm90IGJlIApjaXJjdWxhdGVkIG9yIHVzZWQgZm9yIGFu eSBwdXJwb3NlIG90aGVyIHRoYW4gZm9yIHdoYXQgaXQgaXMgaW50ZW5kZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgCnBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3IgaW1tZWRpYXRlbHkuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUgbm90aWZpZWQgdGhhdCB5b3UgYXJlIHN0cmljdGx5CnByb2hpYml0ZWQgZnJvbSB1 c2luZywgY29weWluZywgYWx0ZXJpbmcsIG9yIGRpc2Nsb3NpbmcgdGhlIGNvbnRlbnRzIG9mIHRo aXMgbWVzc2FnZS4gQXJpY2VudCBhY2NlcHRzIG5vIHJlc3BvbnNpYmlsaXR5IGZvciAKbG9zcyBv ciBkYW1hZ2UgYXJpc2luZyBmcm9tIHRoZSB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0 dGVkIGJ5IHRoaXMgZW1haWwgaW5jbHVkaW5nIGRhbWFnZSBmcm9tIHZpcnVzLiIK --=_alternative 0017C2DB652573FE_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFZpY3RvciAhPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIg cmVzcG9uc2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5SZWRpcmVjdCBhZ2VudCBzaG91bGQgcHJvdmlkZSB0aGUgcmVkaXJlY3QNCmhvc3QgQVZQcyAs IHNvbGVseSBiYXNlZCB1cG9uIHRoZSByb3V0aW5nIHRhYmxlcyBhdmFpbGFibGUgYXQgdGhlIHJl ZGlyZWN0DQphZ2VudC4gSXQgc2hvdWxkIG5vdCBjb25jZXJuIGFib3V0IGFueSBzZXNzaW9uICEg U28gYWxsIHRoZSBwb3NzaWJsZSB2YWx1ZXMNCmZvciBSZWRpcmVjdC1Ib3N0IHVzYWdlIEFWUHMg bWVudGlvbmVkIGluIHRoZSBSRkMsIGV4Y2VwdCBBTExfU0VTU0lPTiwNCnNvbWVob3cgaW5kaWNh dGVzIHRoZSByb3V0aW5nIHRhYmxlIGF0IHRoZSByZWRpcmVjdCBhZ2VudC4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3IgZmluZGluZyB0aGUgcm91 dGUgZm9yIHRoZSBmaXJzdA0KbWVzc2FnZSwgZnJvbSB0aGUgcmVkaXJlY3QgYWdlbnQsIGlzIHJl c3BvbnNpYmlsaXR5IG9mIHRoZSBjbGllbnQuIFdoeQ0Kc2hvdWxkIHJlZGlyZWN0IGFnZW50IGJl IGNvbmNlcm5lZCBhYm91dCB3aGV0aGVyIGl0IGlzIGZpcnN0IG1lc3NhZ2Ugb3INCnRoZSBzdWJz ZXF1ZW50IG1lc3NhZ2UgZm9yIHRoZSBzZXNzaW9uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5yZWdhcmRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5QcmVldGk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQwJT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+VmljdG9yIEZhamFyZG8gJmx0O3ZmYWphcmRvQHRhcmkudG9z aGliYS5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5TZW50IGJ5OiBkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MDIvMjcvMjAwOCAwNzozOSBQTTwvZm9udD4NCjxicj4NCjx0 ZCB3aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRk IHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlByZWV0aSBTaGFuZGls eWEvSFNTQEhTUzwvZm9udD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpbWVAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHI+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdWJq ZWN0PC9mb250PjwvZGl2Pg0KPHRkIHZhbGlnbj10b3A+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBbRGltZV0gUmVkaXJlY3QtSG9zdC1Vc2FnZQ0KQVZQPC9mb250PjwvdGFibGU+ DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJy PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5IaSBQcmVldGksPGJy Pg0KJmd0OyBEZXNjcmlwdGlvbiBvZiBSZWRpcmVjdC1Ib3N0LVVzYWdlIEFWUCBpbiB0aGUgYmlz IG9mIFJGQzM1ODggKGJpcw0KOSkgPGJyPg0KJmd0OyBpbmRpY2F0ZXMgdGhhdCBpdCBjYW4gaGF2 ZSB2YWx1ZSBBTExfU0VTU0lPTjxicj4NCiZndDs8YnI+DQomZ3Q7IFNvIGlmIHJlZGlyZWN0IGFn ZW50IHNlbmRzIFJlZGlyZWN0LUhvc3QtVXNhZ2UgQVZQIGFzIEFMTF9TRVNTSU9OLA0KdGhpcyA8 YnI+DQomZ3Q7IGluZGljYXRlcyB0aGF0IGNsaWVudCBzaG91bGQgc2VuZCBhbGwgdGhlIHNlc3Np b24gb3JpZW50ZWQgbWVzc2FnZXMNCnRvIHRoZSA8YnI+DQomZ3Q7IHNhbWUgcmVkaXJlY3QgaG9z dCB1c2FnZSAsIHdoaWNoIHJlZGlyZWN0IGFnZW50IGhhcyBpbmZvcm1lZCBpbiB0aGUNCjxicj4N CiZndDsgcmVkaXJlY3QgaW5kaWNhdGlvbiwgYXQgdGhlIHN0YXJ0IG9mIHRoZSBzZXNzaW9uLiBJ biBteSBvcGluaW9uLCB0aGlzDQo8YnI+DQomZ3Q7IHBvc3NpYmxlIHZhbHVlIG9mIFJlZGlyZWN0 LUhvc3QtVXNhZ2UgQVZQIGlzICdyZWR1bmRhbnQnLiBUaGVyZSBzaGFsbA0KYmUgPGJyPg0KJmd0 OyBubyBwcmFjdGljYWwgc2NlbmFyaW8sIHdoZW4gc3Vic2VxdWVudCBtZXNzYWdlIG9uIHRoZSBz YW1lIHNlc3Npb24NCm1heSB0byA8YnI+DQomZ3Q7IGRpZmZlcmVudCBob3N0Ljxicj4NCiZndDs8 YnI+DQomZ3Q7IEluIG15IG9waW5pb24sIHdlIHNob3VsZCBub3QgaGF2ZSBBTExfU0VTU0lPTiBh cyBhIHBvc3NpYmxlIHZhbHVlDQpvZiB0aGUgPGJyPg0KJmd0OyBSZWRpcmVjdC1Ib3N0LVVzYWdl IEFWUCBhbmQgc2hvdWxkIGFzc3VtZSB0aGF0IGFsbCB0aGUgJm5ic3A7c2Vzc2lvbg0Kb3JpZW50 ZWQgPGJyPg0KJmd0OyBtZXNzYWdlIHNob3VsZCBnbyB0byB0aGUgc2FtZSBob3N0IHRvIHdoaWNo IGZpcnN0IG1lc3NhZ2UgY29ycmVzcG9uZGluZw0KdG8gPGJyPg0KJmd0OyB0aGF0IHNlc3Npb24g d2FzIHNlbnQuIFRoZSB0aW1lIGxpbWl0IGZvciB3aGljaCB0aGlzIHJvdXRpbmcgaXMgdmFsaWQN Cjxicj4NCiZndDsgc2hhbGwgb2YtY291cnNlIGJlIGRyaXZlbiBieSBSZWRpcmVjdC1NYXgtQ2Fj aGUtVGltZSBBVlA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQo8YnI+DQpJIGd1ZXNzIHRoZSBwb2lu dCBvZiBBTExfU0VTU0lPTiBpczogaG93IHdpbGwgeW91IGtub3cgdG8gcmVkaXJlY3QgPGJyPg0K bWVzc2FnZXMgZm9yIHRoaXMgc2Vzc2lvbiBpbiB0aGUgZmlyc3QgcGxhY2UgdW5sZXNzIHlvdSBn ZXQgYW4gPGJyPg0KQUxMX1NFU1NJT04gcmVkaXJlY3Rpb24uPGJyPg0KPGJyPg0KcmVnYXJkcyw8 YnI+DQp2aWN0b3I8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkRpTUUgbWFpbGluZyBsaXN0PGJyPg0KRGlNRUBpZXRmLm9yZzxi cj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQoq KioqKioqKioqKioqKioqKioqKioqKiAmbmJzcDtBcmljZW50LVJlc3RyaWN0ZWQgJm5ic3A7ICoq KioqKioqKioqKioqKioqKioqKioqPC9mb250Pg0KPHRhYmxlPjx0cj48dGQgYmdjb2xvcj0jZmZm ZmZmPjxmb250IGNvbG9yPSMwMDAwMDA+PHByZT4iRElTQ0xBSU1FUjogVGhpcyBtZXNzYWdlIGlz IHByb3ByaWV0YXJ5IHRvIEFyaWNlbnQgIGFuZCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgCnRoZSBpbmRpdmlkdWFsIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJdCBtYXkgY29u dGFpbiBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgc2hvdWxkIG5v dCBiZSAKY2lyY3VsYXRlZCBvciB1c2VkIGZvciBhbnkgcHVycG9zZSBvdGhlciB0aGFuIGZvciB3 aGF0IGl0IGlzIGludGVuZGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4g ZXJyb3IsIApwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIGltbWVkaWF0ZWx5LiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgeW91 IGFyZSBzdHJpY3RseQpwcm9oaWJpdGVkIGZyb20gdXNpbmcsIGNvcHlpbmcsIGFsdGVyaW5nLCBv ciBkaXNjbG9zaW5nIHRoZSBjb250ZW50cyBvZiB0aGlzIG1lc3NhZ2UuIEFyaWNlbnQgYWNjZXB0 cyBubyByZXNwb25zaWJpbGl0eSBmb3IgCmxvc3Mgb3IgZGFtYWdlIGFyaXNpbmcgZnJvbSB0aGUg dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsIGluY2x1ZGlu ZyBkYW1hZ2UgZnJvbSB2aXJ1cy4iCjwvcHJlPjwvZm9udD48L3RkPjwvdHI+PC90YWJsZT4= --=_alternative 0017C2DB652573FE_=-- --===============0019674173== 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 --===============0019674173==-- From dime-bounces@ietf.org Thu Feb 28 21:21:57 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C45328C951; Thu, 28 Feb 2008 21:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_38=0.6, 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 zK394OEhj5vY; Thu, 28 Feb 2008 21:21:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45B1A3A6A3F; Thu, 28 Feb 2008 21:21:51 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38323A67A9; Thu, 28 Feb 2008 21:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw+SCGLkdcB8; Thu, 28 Feb 2008 21:21:44 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with SMTP id 76C4728C3E9; Thu, 28 Feb 2008 21:21:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: liyaqatali@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1204262496!31943845!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27115 invoked from network); 29 Feb 2008 05:21:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 29 Feb 2008 05:21:36 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1T5LZmi023058; Thu, 28 Feb 2008 22:21:35 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m1T5LYbs010736; Thu, 28 Feb 2008 23:21:35 -0600 (CST) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m1T5LWbH010712; Thu, 28 Feb 2008 23:21:33 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 13:21:31 +0800 Message-ID: <60D839F897E571458DEEFEE669C5546C01D64B79@ZMY16EXM70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Redirect-Host-Usage AVP Thread-Index: Ach6ipew5Pl4/3p8Sw68wucGp7IUZQABtXsB References: From: "G Nadaf Liyaqatali-a21917" To: "Preeti Shandilya" , "Victor Fajardo" X-CFilter-Loop: Reflected Cc: dime-bounces@ietf.org, dime@ietf.org Subject: Re: [Dime] Redirect-Host-Usage AVP X-BeenThere: dime@ietf.org X-Mailman-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="===============2122330038==" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2122330038== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87A92.F17D83CF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87A92.F17D83CF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Preeti Your argument is that after an initial message of a session is sent to a = host, all the subsequent messages should be sent to the same host. This = is not necessarily true.=20 1. The redirect agent can be a load balancer. In which case, it can = chooses an appropriate host based on how the servers are loaded. And = yes, in this case all the servers have to be in sync. There are = implementations that support this. 2. In IMS, during registration, the S-CSCF before sending MAR and SAR = belonging to the same user same session can contact the SLF(redirect = agent) in a multiple HSS network deployment. Even in this case, SLF may = return different host names each time. Again, HSSes have to be in sync. = Further, In multiple SLF deployment, this is more likely to happen. Regards Liyaqatali G Nadaf -----Original Message----- From: dime-bounces@ietf.org on behalf of Preeti Shandilya Sent: Fri 2/29/2008 9:49 AM To: Victor Fajardo Cc: dime-bounces@ietf.org; dime@ietf.org Subject: Re: [Dime] Redirect-Host-Usage AVP =20 Hi Victor ! Thanks for your response. Redirect agent should provide the redirect host AVPs , solely based upon = the routing tables available at the redirect agent. It should not = concern=20 about any session ! So all the possible values for Redirect-Host usage=20 AVPs mentioned in the RFC, except ALL_SESSION, somehow indicates the=20 routing table at the redirect agent.=20 For finding the route for the first message, from the redirect agent, is = responsibility of the client. Why should redirect agent be concerned = about=20 whether it is first message or the subsequent message for the session regards Preeti Victor Fajardo =20 Sent by: dime-bounces@ietf.org 02/27/2008 07:39 PM To Preeti Shandilya/HSS@HSS cc dime@ietf.org Subject Re: [Dime] Redirect-Host-Usage AVP Hi Preeti, > Description of Redirect-Host-Usage AVP in the bis of RFC3588 (bis 9)=20 > indicates that it can have value ALL_SESSION > > So if redirect agent sends Redirect-Host-Usage AVP as ALL_SESSION, = this=20 > indicates that client should send all the session oriented messages to = the=20 > same redirect host usage , which redirect agent has informed in the=20 > redirect indication, at the start of the session. In my opinion, this=20 > possible value of Redirect-Host-Usage AVP is 'redundant'. There shall = be=20 > no practical scenario, when subsequent message on the same session may = to=20 > different host. > > In my opinion, we should not have ALL_SESSION as a possible value of = the=20 > Redirect-Host-Usage AVP and should assume that all the session = oriented=20 > message should go to the same host to which first message = corresponding=20 to=20 > that session was sent. The time limit for which this routing is valid=20 > shall of-course be driven by Redirect-Max-Cache-Time AVP >=20 I guess the point of ALL_SESSION is: how will you know to redirect=20 messages for this session in the first place unless you get an=20 ALL_SESSION redirection. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime *********************** Aricent-Restricted *********************** "DISCLAIMER: This message is proprietary to Aricent and is intended = solely for the use of=20 the individual to whom it is addressed. It may contain privileged or = confidential information and should not be=20 circulated or used for any purpose other than for what it is intended. = If you have received this message in error,=20 please notify the originator immediately. If you are not the intended = recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of = this message. Aricent accepts no responsibility for=20 loss or damage arising from the use of the information transmitted by = this email including damage from virus." ------_=_NextPart_001_01C87A92.F17D83CF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] Redirect-Host-Usage AVP

Hi Preeti

Your argument is that after an initial message of a session is sent to a = host, all the subsequent messages should be sent to the same host. This = is not necessarily true.

1. The redirect agent can be a load balancer. In which case, it can = chooses an appropriate host based on how the servers are loaded. And = yes, in this case all the servers have to be in sync. There are = implementations that support this.

2. In IMS, during registration, the S-CSCF before sending MAR and SAR = belonging to the same user same session can contact the SLF(redirect = agent) in a multiple HSS network deployment. Even in this case, SLF may = return different host names each time. Again, HSSes have to be in sync. = Further, In multiple SLF deployment, this is more likely to happen.



Regards
Liyaqatali G Nadaf



-----Original Message-----
From: dime-bounces@ietf.org on behalf of Preeti Shandilya
Sent: Fri 2/29/2008 9:49 AM
To: Victor Fajardo
Cc: dime-bounces@ietf.org; dime@ietf.org
Subject: Re: [Dime] Redirect-Host-Usage AVP

Hi Victor !

Thanks for your response.

Redirect agent should provide the redirect host AVPs , solely based = upon
the routing tables available at the redirect agent. It should not = concern
about any session ! So all the possible values for Redirect-Host = usage
AVPs mentioned in the RFC, except ALL_SESSION, somehow indicates the
routing table at the redirect agent.

For finding the route for the first message, from the redirect agent, = is
responsibility of the client. Why should redirect agent be concerned = about
whether it is first message or the subsequent message for the = session

regards
Preeti



Victor Fajardo <vfajardo@tari.toshiba.com>
Sent by: dime-bounces@ietf.org
02/27/2008 07:39 PM


To
Preeti Shandilya/HSS@HSS
cc
dime@ietf.org
Subject
Re: [Dime] Redirect-Host-Usage AVP






Hi Preeti,
> Description of Redirect-Host-Usage AVP in the bis of RFC3588 (bis = 9)
> indicates that it can have value ALL_SESSION
>
> So if redirect agent sends Redirect-Host-Usage AVP as ALL_SESSION, = this
> indicates that client should send all the session oriented messages = to
the
> same redirect host usage , which redirect agent has informed in = the
> redirect indication, at the start of the session. In my opinion, = this
> possible value of Redirect-Host-Usage AVP is 'redundant'. There = shall be

> no practical scenario, when subsequent message on the same session = may
to
> different host.
>
> In my opinion, we should not have ALL_SESSION as a possible value = of the

> Redirect-Host-Usage AVP and should assume that all the  = session oriented

> message should go to the same host to which first message = corresponding
to
> that session was sent. The time limit for which this routing is = valid
> shall of-course be driven by Redirect-Max-Cache-Time AVP
>

I guess the point of ALL_SESSION is: how will you know to redirect
messages for this session in the first place unless you get an
ALL_SESSION redirection.

regards,
victor

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



***********************  Aricent-Restricted   = ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is = intended solely for the use of
the individual to whom it is addressed. It may contain privileged or = confidential information and should not be
circulated or used for any purpose other than for what it is intended. = If you have received this message in error,
please notify the originator immediately. If you are not the intended = recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of = this message. Aricent accepts no responsibility for
loss or damage arising from the use of the information transmitted by = this email including damage from virus."

------_=_NextPart_001_01C87A92.F17D83CF-- --===============2122330038== 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 --===============2122330038==-- From dime-bounces@ietf.org Fri Feb 29 05:57:12 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521A53A6F69; Fri, 29 Feb 2008 05:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 kJY0Y1uOK1SM; Fri, 29 Feb 2008 05:57:06 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF773A6F5B; Fri, 29 Feb 2008 05:57:06 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9623A6F37 for ; Fri, 29 Feb 2008 05:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0tBVw9zGqpw for ; Fri, 29 Feb 2008 05:57:01 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 36D743A6F43 for ; Fri, 29 Feb 2008 05:57:00 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 11734198D63; Fri, 29 Feb 2008 15:56:52 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id BF53719880F; Fri, 29 Feb 2008 15:56:51 +0200 (EET) Message-ID: <47C80F25.5070709@piuha.net> Date: Fri, 29 Feb 2008 15:56:53 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: draft-ietf-dime-rfc3588bis@tools.ietf.org X-Virus-Scanned: ClamAV using ClamSMTP Cc: dime@ietf.org Subject: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org The draft should have an "Obsoletes: 3588 (if approved)" header at the top. Add the appropriate XML2RFC attribute to do that (obsoletes="3588"). > This document deprecates [RFC3588 ] but is fully backward compatible > with that document. Obsoletes, not deprecates. > In order to allocate a new AVP value for a standards track AVP, a > request MUST be sent to IANA [RFC2434], along with an explanation of > the new AVP value. IANA considerations for AVP values are discussed > in Section 11.4. This is not completely correct. IANA records the registrations, but since the spaces have been defined to be registered via IETF Consensus, you cannot simply go to IANA and ask for a value. You need to write an RFC and get it approved via a WG or AD sponsoring. Suggested text: ... track AVP, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations ... This section does not describe how to allocate values in other AVPs. Are there informational IETF Diameter AVPs? But there surely are vendor specific AVPs. I would suggest a reformulation of the entire paragraph as follows: In order to allocate a new AVP value for AVPs defined in the Diameter Base protocol, the IETF needs to approve a new RFC that describes the AVP value. IANA considerations for these AVP values are discussed in Section 11.4. The allocation of AVP values for other AVPs is guided by the IANA considerations of the documents that defines those AVPs. Typically, allocation of new values for an AVP defined in an IETF RFC should require IETF Review [2434bis], where as values for vendor-specific AVPs can be allocated by the vendor. Also, I would suggest switching to draft-narten-iana-considerations-rfc2434bis terminology rather than RFC 2434. It uses "IETF Review" instead of "IETF Consensus". > In order to create a new standards track AVP, a request MUST be sent > to IANA with a reference to the specification that defines the AVP. > IANA considerations for AVPs are discussed in Section 11.1.1. This has similar issues as from above. Again, the IANA considerations section is actually more informative than this. There are different cases, >3 attributes, <3 attributes, what kind of spec you are writing (ps/inf/otherrfc/othersdo), etc. I would rewrite the above as: The creation of new AVPs can happen in various ways. The recommended approach is to define a new general-purpose AVP in a standards track RFC approved by the IETF. However, as described in Section 11.1.1 there are also other mechanisms. > An implementation MAY add arbitrary non-mandatory AVPs to a command > defined in an application, including vendor-specific AVPs without > needing to define a new application. This can be done if the > commands ABNF allows for it. I am not happy with the last statement. There are some commands which do not allow any AVP to appear at the end, but I think that is a mistake and we should fix that bug. If you look at the RADIUS developments, the ability to add new attributes has been extremely useful. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 29 07:25:14 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 247E53A6F32; Fri, 29 Feb 2008 07:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 qaAC-7kz6Egb; Fri, 29 Feb 2008 07:25:08 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E43B3A6BD3; Fri, 29 Feb 2008 07:25:08 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410033A6A32 for ; Fri, 29 Feb 2008 07:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neb4C1UCDXMz for ; Fri, 29 Feb 2008 07:25:01 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id 9CA523A6F46 for ; Fri, 29 Feb 2008 07:25:01 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1TFOq10053929; Fri, 29 Feb 2008 10:24:52 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47C823B9.7040104@tari.toshiba.com> Date: Fri, 29 Feb 2008 10:24:41 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jari Arkko References: <47C80F25.5070709@piuha.net> In-Reply-To: <47C80F25.5070709@piuha.net> Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org Subject: Re: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jari, Comments inline: > The draft should have an "Obsoletes: 3588 (if approved)" header at the > top. Add the appropriate XML2RFC attribute to do that (obsoletes="3588"). > > >> This document deprecates [RFC3588 ] but is fully backward compatible >> with that document. >> > Obsoletes, not deprecates. > Ok > >> In order to allocate a new AVP value for a standards track AVP, a >> request MUST be sent to IANA [RFC2434], along with an explanation of >> the new AVP value. IANA considerations for AVP values are discussed >> in Section 11.4. >> > > This is not completely correct. IANA records the registrations, but > since the spaces have been defined to be registered via IETF Consensus, > you cannot simply go to IANA and ask for a value. You need to write an > RFC and get it approved via a WG or AD sponsoring. Suggested text: > > ... track AVP, the IETF needs to approve a new RFC that describes the > AVP value. IANA considerations ... > > This section does not describe how to allocate values in other AVPs. Are > there informational IETF Diameter AVPs? But there surely are vendor > specific AVPs. I would suggest a reformulation of the entire paragraph > as follows: > > In order to allocate a new AVP value for AVPs defined in the Diameter > Base > protocol, the IETF needs to approve a new RFC that describes the AVP > value. > IANA considerations for these AVP values are discussed in Section 11.4. > > The allocation of AVP values for other AVPs is guided by the IANA > considerations > of the documents that defines those AVPs. Typically, allocation of > new values > for an AVP defined in an IETF RFC should require IETF Review [2434bis], > where as values for vendor-specific AVPs can be allocated by the vendor. > This make sense. > Also, I would suggest switching to > draft-narten-iana-considerations-rfc2434bis terminology rather than RFC > 2434. It uses "IETF Review" instead of "IETF Consensus". > > >> In order to create a new standards track AVP, a request MUST be sent >> to IANA with a reference to the specification that defines the AVP. >> IANA considerations for AVPs are discussed in Section 11.1.1. >> > > This has similar issues as from above. Again, the IANA considerations > section is actually more informative than this. There are different > cases, >3 attributes, <3 attributes, what kind of spec you are writing > (ps/inf/otherrfc/othersdo), etc. I would rewrite the above as: > > The creation of new AVPs can happen in various ways. The recommended > approach is to define a new general-purpose AVP in a standards track RFC > approved by the IETF. However, as described in Section 11.1.1 there are > also other mechanisms. > Ok. > >> An implementation MAY add arbitrary non-mandatory AVPs to a command >> defined in an application, including vendor-specific AVPs without >> needing to define a new application. This can be done if the >> commands ABNF allows for it. >> > > I am not happy with the last statement. There are some commands which do > not allow any AVP to appear at the end, but I think that is a mistake > and we should fix that bug. If you look at the RADIUS developments, the > ability to add new attributes has been extremely useful. > Just to clarify, are we suggesting that we make "* [AVP]" implicit on any/all commands ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 29 08:41:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F70D28C587; Fri, 29 Feb 2008 08:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 sQ-MmeLaQ9iR; Fri, 29 Feb 2008 08:41:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7809328C15D; Fri, 29 Feb 2008 08:41:05 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6FF3A67D0 for ; Fri, 29 Feb 2008 08:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A85S4KuFFlkh for ; Fri, 29 Feb 2008 08:40:59 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D593B28C40D for ; Fri, 29 Feb 2008 08:40:58 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id A97EC198D69; Fri, 29 Feb 2008 18:40:50 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 49886198D63; Fri, 29 Feb 2008 18:40:50 +0200 (EET) Message-ID: <47C83593.9030303@piuha.net> Date: Fri, 29 Feb 2008 18:40:51 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Victor Fajardo References: <47C80F25.5070709@piuha.net> <47C823B9.7040104@tari.toshiba.com> In-Reply-To: <47C823B9.7040104@tari.toshiba.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: draft-ietf-dime-rfc3588bis@tools.ietf.org, dime@ietf.org Subject: Re: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Victor, >> >> I am not happy with the last statement. There are some commands which do >> not allow any AVP to appear at the end, but I think that is a mistake >> and we should fix that bug. If you look at the RADIUS developments, the >> ability to add new attributes has been extremely useful. >> > > Just to clarify, are we suggesting that we make "* [AVP]" implicit on > any/all commands ? Just recommend that this be in the ABNF of all commands. And fix the commands that don't have this right now, DPR, DPA, DWR, and DWA. Obviously, I don't think we are going to extend these commands but I think this is a good policy to have. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 29 09:08:38 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B7C28C46E; Fri, 29 Feb 2008 09:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 mCF2t6lEfTDO; Fri, 29 Feb 2008 09:08:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDB828C524; Fri, 29 Feb 2008 09:08:33 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243133A68D4 for ; Fri, 29 Feb 2008 09:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y4ijY+XV38b for ; Fri, 29 Feb 2008 09:08:26 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id B0E1A28C1C5 for ; Fri, 29 Feb 2008 09:08:24 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id m1TH8CbZ054383; Fri, 29 Feb 2008 12:08:12 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47C83BF0.5010007@tari.toshiba.com> Date: Fri, 29 Feb 2008 12:08:00 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Jari Arkko References: <47C80F25.5070709@piuha.net> <47C823B9.7040104@tari.toshiba.com> <47C83593.9030303@piuha.net> In-Reply-To: <47C83593.9030303@piuha.net> Cc: dime@ietf.org Subject: Re: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jari, > >>> I am not happy with the last statement. There are some commands which do >>> not allow any AVP to appear at the end, but I think that is a mistake >>> and we should fix that bug. If you look at the RADIUS developments, the >>> ability to add new attributes has been extremely useful. >>> >>> >> Just to clarify, are we suggesting that we make "* [AVP]" implicit on >> any/all commands ? >> > > Just recommend that this be in the ABNF of all commands. And fix the > commands that don't have this right now, DPR, DPA, DWR, and DWA. > Obviously, I don't think we are going to extend these commands but I > think this is a good policy to have. > I see. sounds reasonable. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 29 09:13:06 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4B03A6A90; Fri, 29 Feb 2008 09:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.192 X-Spam-Level: X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=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 wnlWWNXc2UNd; Fri, 29 Feb 2008 09:13:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90453A6B65; Fri, 29 Feb 2008 09:13:04 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89BD3A6968 for ; Fri, 29 Feb 2008 09:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37mUUhIEP6hr for ; Fri, 29 Feb 2008 09:12:57 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id A75F428C597 for ; Fri, 29 Feb 2008 09:12:51 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 18:12:42 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Feb 2008 18:12:39 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605549C54@ftrdmel2> In-Reply-To: <47C83BF0.5010007@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Some minor comments on the rfc3588bis draft Thread-Index: Ach69bklicjxYMcRQTmMQ8dx/mXhUAAABDxg References: <47C80F25.5070709@piuha.net> <47C823B9.7040104@tari.toshiba.com><47C83593.9030303@piuha.net> <47C83BF0.5010007@tari.toshiba.com> From: To: , X-OriginalArrivalTime: 29 Feb 2008 17:12:42.0189 (UTC) FILETIME=[4B2DB7D0:01C87AF6] Cc: dime@ietf.org Subject: Re: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org > >>> I am not happy with the last statement. There are some commands > >>> which do not allow any AVP to appear at the end, but I > think that is > >>> a mistake and we should fix that bug. If you look at the RADIUS > >>> developments, the ability to add new attributes has been > extremely useful. > >>> > >>> > >> Just to clarify, are we suggesting that we make "* [AVP]" > implicit on > >> any/all commands ? > >> > > > > Just recommend that this be in the ABNF of all commands. > And fix the > > commands that don't have this right now, DPR, DPA, DWR, and DWA. > > Obviously, I don't think we are going to extend these > commands but I > > think this is a good policy to have. > > > > I see. sounds reasonable. > I agree. Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Feb 29 10:59:31 2008 Return-Path: X-Original-To: ietfarch-dime-archive@core3.amsl.com Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80E43A6E84; Fri, 29 Feb 2008 10:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=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 Ytqgwoxk7Lgc; Fri, 29 Feb 2008 10:59:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF213A6D0F; Fri, 29 Feb 2008 10:59:31 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12FEE3A6D0F for ; Fri, 29 Feb 2008 10:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6i0Ba6BI3Gc for ; Fri, 29 Feb 2008 10:59:24 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 9C6F53A6BE9 for ; Fri, 29 Feb 2008 10:59:24 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Fri, 29 Feb 2008 13:59:16 -0500 From: Mark Jones To: Jari Arkko , Victor Fajardo Date: Fri, 29 Feb 2008 13:59:16 -0500 Thread-Topic: [Dime] Some minor comments on the rfc3588bis draft Thread-Index: Ach68fE80HpffDMRR+eHvgvZbeJFJAAEnHmA Message-ID: References: <47C80F25.5070709@piuha.net> <47C823B9.7040104@tari.toshiba.com> <47C83593.9030303@piuha.net> In-Reply-To: <47C83593.9030303@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] Some minor comments on the rfc3588bis 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Hi Jari, Victor, Comments inline... > >> I am not happy with the last statement. There are some > commands which do > >> not allow any AVP to appear at the end, but I think that > is a mistake > >> and we should fix that bug. If you look at the RADIUS > developments, the > >> ability to add new attributes has been extremely useful. > >> > > > > Just to clarify, are we suggesting that we make "* [AVP]" > implicit on > > any/all commands ? > > Just recommend that this be in the ABNF of all commands. And fix the > commands that don't have this right now, DPR, DPA, DWR, and DWA. > Obviously, I don't think we are going to extend these commands but I > think this is a good policy to have. > I agree. Why not extend this recommendation to Grouped AVPs for the same reason? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime