From dime-bounces@ietf.org Mon Oct 01 09:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLjE-0006nK-H8; Mon, 01 Oct 2007 09:54:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcLjD-0006nF-Ky for dime@ietf.org; Mon, 01 Oct 2007 09:54:31 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcLjD-000490-7j for dime@ietf.org; Mon, 01 Oct 2007 09:54:31 -0400 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 l91Dn0Gf066811; Mon, 1 Oct 2007 09:49:01 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4700FAD1.7060907@tari.toshiba.com> Date: Mon, 01 Oct 2007 09:49:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Design Guideline on Command reuse and Application-Id References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark, Sorry for the really late reply. Comments inline: > When 3GPP reused NASREQ commands in the Gx application (TS 29.212), a > question arose about which application id should populate the > Auth-Application-Id AVP. Gx is a vendor-specific application (3GPP is > the 'vendor') so it was initially thought that the > Vendor-Specific-Application-Id AVP should be used instead of > Auth-Application-Id. However, the Auth-Application-Id AVP is a required > AVP in the NASREQ commands so the AVP could not be replaced without > abandoning the command reuse. 3GPP decided to populate the > Auth-Application-Id AVP with the Gx application id. > > I think it would be useful for the Design Guidelines draft to capture > this scenario and suggest the following paragraph be added to section > 5.3 (Use of Application-Id in a Message): > > "For historical reasons, some IETF applications specify commands that > require application id AVPs (Auth-Application-Id or Acct-Application-Id) > in the message body. When designing vendor-specific applications which > reuse these IETF commands, designers should specify that the application > id contained in these AVPs is that assigned to the vendor-specific > application and not the original IETF application." > I think this is a more general case if a command is being reused in a new application for which a new app-id has been assigned. So we may want to re-word it that way instead: "In general, when a new application has been allocated with a new application id and it also reuses existing commands with or without modifications (Sec 4.1), it must use newly allocated application id in the header all relevant application id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body." Note that the rule should apply whether the imported command has been modified or not or whether its vendor specific or not. regards, victor > Any concerns? > > Regards > Mark > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDr-0003NP-0V; Tue, 02 Oct 2007 04:35:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDq-0003N7-Ip for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDq-0004Kb-1i for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 02 Oct 2007 10:35:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pDxAhKMmpLwCjdh8QPY5PiOaGqMRBwYanzSYUdH sqbo3K+h4LBrb9 Message-ID: <470202C4.4000909@gmx.net> Date: Tue, 02 Oct 2007 10:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, tsvwg IETF list , "nsis@ietf.org" , 'radext mailing list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDZ-0003Ge-OC; Tue, 02 Oct 2007 04:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDY-0003FU-FR for dime@ietf.org; Tue, 02 Oct 2007 04:35:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDN-0001qS-4a for dime@ietf.org; Tue, 02 Oct 2007 04:34:55 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:34:28 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 02 Oct 2007 10:34:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Yk8sxg6qYl7uggKtDDjOHDf9qJsIKQA4a8eiamz 2NiwDCVnwU5Kpi Message-ID: <47020294.1010506@gmx.net> Date: Tue, 02 Oct 2007 10:34:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and ExtentiFrom dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDr-0003NP-0V; Tue, 02 Oct 2007 04:35:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDq-0003N7-Ip for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDq-0004Kb-1i for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 02 Oct 2007 10:35:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pDxAhKMmpLwCjdh8QPY5PiOaGqMRBwYanzSYUdH sqbo3K+h4LBrb9 Message-ID: <470202C4.4000909@gmx.net> Date: Tue, 02 Oct 2007 10:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, tsvwg IETF list , "nsis@ietf.org" , 'radext mailing list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDZ-0003Ge-OC; Tue, 02 Oct 2007 04:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDY-0003FU-FR for dime@ietf.org; Tue, 02 Oct 2007 04:35:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDN-0001qS-4a for dime@ietf.org; Tue, 02 Oct 2007 04:34:55 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:34:28 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 02 Oct 2007 10:34:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Yk8sxg6qYl7uggKtDDjOHDf9qJsIKQA4a8eiamz 2NiwDCVnwU5Kpi Message-ID: <47020294.1010506@gmx.net> Date: Tue, 02 Oct 2007 10:34:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and ExtentiFrom dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDr-0003NP-0V; Tue, 02 Oct 2007 04:35:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDq-0003N7-Ip for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IcdDq-0004Kb-1i for dime@ietf.org; Tue, 02 Oct 2007 04:35:18 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp033) with SMTP; 02 Oct 2007 10:35:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pDxAhKMmpLwCjdh8QPY5PiOaGqMRBwYanzSYUdH sqbo3K+h4LBrb9 Message-ID: <470202C4.4000909@gmx.net> Date: Tue, 02 Oct 2007 10:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, tsvwg IETF list , "nsis@ietf.org" , 'radext mailing list' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Attributes for Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDZ-0003Ge-OC; Tue, 02 Oct 2007 04:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDY-0003FU-FR for dime@ietf.org; Tue, 02 Oct 2007 04:35:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDN-0001qS-4a for dime@ietf.org; Tue, 02 Oct 2007 04:34:55 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:34:28 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 02 Oct 2007 10:34:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Yk8sxg6qYl7uggKtDDjOHDf9qJsIKQA4a8eiamz 2NiwDCVnwU5Kpi Message-ID: <47020294.1010506@gmx.net> Date: Tue, 02 Oct 2007 10:34:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-05 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-05). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDn-0003Kp-Nw; Tue, 02 Oct 2007 04:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDl-0003KM-Rc for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDk-0001sC-GP for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 02 Oct 2007 10:35:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+30LB26ly3LJYamr0oFPTjcEUKtKq8GDj1W3gnou 93XYkhFh/5ziXW Message-ID: <470202BF.4000701@gmx.net> Date: Tue, 02 Oct 2007 10:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Parameters for Usage with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ons Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-05). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDn-0003Kp-Nw; Tue, 02 Oct 2007 04:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDl-0003KM-Rc for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDk-0001sC-GP for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 02 Oct 2007 10:35:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+30LB26ly3LJYamr0oFPTjcEUKtKq8GDj1W3gnou 93XYkhFh/5ziXW Message-ID: <470202BF.4000701@gmx.net> Date: Tue, 02 Oct 2007 10:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Parameters for Usage with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ons Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" (draft-ietf-dime-mip6-split-05). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 04:35:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDn-0003Kp-Nw; Tue, 02 Oct 2007 04:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcdDl-0003KM-Rc for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcdDk-0001sC-GP for dime@ietf.org; Tue, 02 Oct 2007 04:35:13 -0400 Received: (qmail invoked by alias); 02 Oct 2007 08:35:11 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 02 Oct 2007 10:35:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+30LB26ly3LJYamr0oFPTjcEUKtKq8GDj1W3gnou 93XYkhFh/5ziXW Message-ID: <470202BF.4000701@gmx.net> Date: Tue, 02 Oct 2007 10:35:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Quality of Service Parameters for Usage with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 09:39:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ichxw-0007j5-QY; Tue, 02 Oct 2007 09:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ichxw-0007io-45 for dime@ietf.org; Tue, 02 Oct 2007 09:39:12 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ichxp-0002Ol-ST for dime@ietf.org; Tue, 02 Oct 2007 09:39:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Design Guideline on Command reuse and Application-Id Date: Tue, 2 Oct 2007 09:38:54 -0400 Message-ID: In-Reply-To: <4700FAD1.7060907@tari.toshiba.com> References: <4700FAD1.7060907@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, Thanks for reviewing the proposed text. Comments below... > I think this is a more general case if a command is being reused in a=20 > new application for which a new app-id has been assigned. So=20 > we may want=20 > to re-word it that way instead: >=20 > "In general, when a new application has been allocated with a=20 > new application id > and it also reuses existing commands with or without=20 > modifications (Sec 4.1), it must > use newly allocated application id in the header all relevant=20 > application id AVPs > (Auth-Application-Id or Acct-Application-Id) present in the=20 > commands message body." >=20 I'm fine with the more general rule. I suggest a couple of minor changes to your text; to fix a typo (missing 'and') and add Vendor-Specific-Application-Id to your AVP list to cover the case where commands from a vendor-specific application are re-used. "When a new application has been allocated with a new application id and it also reuses existing commands with or without modifications (Sec 4.1), it must use the newly allocated application id in the header and all relevant application id AVPs (Auth-Application-Id, Acct-Application-Id, Vendor-Specific-Application-Id) present in the commands message body." Work for you? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 02 09:53:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IciBV-0000su-CL; Tue, 02 Oct 2007 09:53:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IciBU-0000sp-O5 for dime@ietf.org; Tue, 02 Oct 2007 09:53:12 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IciBU-0005Fg-C5 for dime@ietf.org; Tue, 02 Oct 2007 09:53:12 -0400 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 l92Dqw2Z080168; Tue, 2 Oct 2007 09:53:06 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47024D3A.8050108@tari.toshiba.com> Date: Tue, 02 Oct 2007 09:52:58 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Design Guideline on Command reuse and Application-Id References: <4700FAD1.7060907@tari.toshiba.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Looks ok to me. > >> I think this is a more general case if a command is being reused in a >> new application for which a new app-id has been assigned. So >> we may want >> to re-word it that way instead: >> >> "In general, when a new application has been allocated with a >> new application id >> and it also reuses existing commands with or without >> modifications (Sec 4.1), it must >> use newly allocated application id in the header all relevant >> application id AVPs >> (Auth-Application-Id or Acct-Application-Id) present in the >> commands message body." >> >> > > I'm fine with the more general rule. I suggest a couple of minor changes > to your text; to fix a typo (missing 'and') and add > Vendor-Specific-Application-Id to your AVP list to cover the case where > commands from a vendor-specific application are re-used. > > "When a new application has been allocated with a new application id > and it also reuses existing commands with or without modifications (Sec > 4.1), it must use the newly allocated application id in the header and > all relevant application id AVPs (Auth-Application-Id, > Acct-Application-Id, Vendor-Specific-Application-Id) present in the > commands message body." > > Work for you? > > Regards > Mark > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 03 06:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1jL-0006Ai-Nd; Wed, 03 Oct 2007 06:45:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id1jK-0006AH-CC for dime@ietf.org; Wed, 03 Oct 2007 06:45:26 -0400 Received: from jaguar.aricent.com ([61.246.186.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id1jH-0004FU-Md for dime@ietf.org; Wed, 03 Oct 2007 06:45:26 -0400 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id l93AbQUC002954 for ; Wed, 3 Oct 2007 16:07:26 +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 l93AbPlv002937; Wed, 3 Oct 2007 16:07:26 +0530 In-Reply-To: <4700FAD1.7060907@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] Design Guideline on Command reuse and Application-Id MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Aridaman Kaushik Date: Wed, 3 Oct 2007 16:16:46 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 03/10/2007 04:19:48 PM, Serialize complete at 03/10/2007 04:19:48 PM X-Spam-Score: 2.8 (++) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1664229013==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============1664229013== Content-Type: multipart/alternative; boundary="=_alternative 003B36FF65257369_=" This is a multipart message in MIME format. --=_alternative 003B36FF65257369_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: base64 SGkgVmljdG9yLA0KICAgICAgICAgICBOQVNSZXEgUkZDIDQwMDUgaXMgY29udHJhZGljdGluZyB3 aXRoIHRoZSBnaXZlbiBzdGF0ZW1lbnQgDQpiZWxvdy4gTkFTUmVxIHJldXNlcyBTVFIvQVNSL1JB UiBjb21tYW5kcyBmcm9tIGJhc2UuICBTZWN0aW9uIDEuMyBvZiBSRkMgDQo0MDA1IG1lbnRpb25z IHRoYXQgU1RSL0FTUi9SQVIgaXMgZGVmaW5lZCBieSBiYXNlLiBTbyB0aGVzZSBtZXNzYWdlIHNo b3VsZCANCnVzZSBiYXNlIGFwcGxpY2F0aW9uIElkIChoZWFkZXIgYW5kIGF1dGgtYXBwbGljYXRp b24taWQgYXZwKS4NCg0KU2hvdWxkIGl0IGJlIG1vZGlmaWVkLg0KDQpCZXN0IHJlZ2FyZHMNCkFy aWRhbWFuIGthdXNoaWsuIA0KDQoNCg0KVmljdG9yIEZhamFyZG8gPHZmYWphcmRvQHRhcmkudG9z aGliYS5jb20+IA0KMTAvMDEvMjAwNyAwNzoxOSBQTQ0KDQoNClRvDQpNYXJrIEpvbmVzIDxtYXJr LmpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20+DQpjYw0KDQpTdWJqZWN0DQpSZTogW0RpbWVd IERlc2lnbiBHdWlkZWxpbmUgb24gQ29tbWFuZCByZXVzZSBhbmQgQXBwbGljYXRpb24tSWQNCg0K DQoNCg0KDQoNCkhpIE1hcmssDQoNClNvcnJ5IGZvciB0aGUgcmVhbGx5IGxhdGUgcmVwbHkuIENv bW1lbnRzIGlubGluZToNCg0KPiBXaGVuIDNHUFAgcmV1c2VkIE5BU1JFUSBjb21tYW5kcyBpbiB0 aGUgR3ggYXBwbGljYXRpb24gKFRTIDI5LjIxMiksIGENCj4gcXVlc3Rpb24gYXJvc2UgYWJvdXQg d2hpY2ggYXBwbGljYXRpb24gaWQgc2hvdWxkIHBvcHVsYXRlIHRoZQ0KPiBBdXRoLUFwcGxpY2F0 aW9uLUlkIEFWUC4gR3ggaXMgYSB2ZW5kb3Itc3BlY2lmaWMgYXBwbGljYXRpb24gKDNHUFAgaXMN Cj4gdGhlICd2ZW5kb3InKSBzbyBpdCB3YXMgaW5pdGlhbGx5IHRob3VnaHQgdGhhdCB0aGUNCj4g VmVuZG9yLVNwZWNpZmljLUFwcGxpY2F0aW9uLUlkIEFWUCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFk IG9mDQo+IEF1dGgtQXBwbGljYXRpb24tSWQuIEhvd2V2ZXIsIHRoZSBBdXRoLUFwcGxpY2F0aW9u LUlkIEFWUCBpcyBhIHJlcXVpcmVkDQo+IEFWUCBpbiB0aGUgTkFTUkVRIGNvbW1hbmRzIHNvIHRo ZSBBVlAgY291bGQgbm90IGJlIHJlcGxhY2VkIHdpdGhvdXQNCj4gYWJhbmRvbmluZyB0aGUgY29t bWFuZCByZXVzZS4gM0dQUCBkZWNpZGVkIHRvIHBvcHVsYXRlIHRoZQ0KPiBBdXRoLUFwcGxpY2F0 aW9uLUlkIEFWUCB3aXRoIHRoZSBHeCBhcHBsaWNhdGlvbiBpZC4NCj4NCj4gSSB0aGluayBpdCB3 b3VsZCBiZSB1c2VmdWwgZm9yIHRoZSBEZXNpZ24gR3VpZGVsaW5lcyBkcmFmdCB0byBjYXB0dXJl DQo+IHRoaXMgc2NlbmFyaW8gYW5kIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggYmUg YWRkZWQgdG8gc2VjdGlvbg0KPiA1LjMgKFVzZSBvZiBBcHBsaWNhdGlvbi1JZCBpbiBhIE1lc3Nh Z2UpOg0KPg0KPiAiRm9yIGhpc3RvcmljYWwgcmVhc29ucywgc29tZSBJRVRGIGFwcGxpY2F0aW9u cyBzcGVjaWZ5IGNvbW1hbmRzIHRoYXQNCj4gcmVxdWlyZSBhcHBsaWNhdGlvbiBpZCBBVlBzIChB dXRoLUFwcGxpY2F0aW9uLUlkIG9yIEFjY3QtQXBwbGljYXRpb24tSWQpDQo+IGluIHRoZSBtZXNz YWdlIGJvZHkuIFdoZW4gZGVzaWduaW5nIHZlbmRvci1zcGVjaWZpYyBhcHBsaWNhdGlvbnMgd2hp Y2gNCj4gcmV1c2UgdGhlc2UgSUVURiBjb21tYW5kcywgZGVzaWduZXJzIHNob3VsZCBzcGVjaWZ5 IHRoYXQgdGhlIGFwcGxpY2F0aW9uDQo+IGlkIGNvbnRhaW5lZCBpbiB0aGVzZSBBVlBzIGlzIHRo YXQgYXNzaWduZWQgdG8gdGhlIHZlbmRvci1zcGVjaWZpYw0KPiBhcHBsaWNhdGlvbiBhbmQgbm90 IHRoZSBvcmlnaW5hbCBJRVRGIGFwcGxpY2F0aW9uLiINCj4gDQoNCkkgdGhpbmsgdGhpcyBpcyBh IG1vcmUgZ2VuZXJhbCBjYXNlIGlmIGEgY29tbWFuZCBpcyBiZWluZyByZXVzZWQgaW4gYSANCm5l dyBhcHBsaWNhdGlvbiBmb3Igd2hpY2ggYSBuZXcgYXBwLWlkIGhhcyBiZWVuIGFzc2lnbmVkLiBT byB3ZSBtYXkgd2FudCANCnRvIHJlLXdvcmQgaXQgdGhhdCB3YXkgaW5zdGVhZDoNCg0KIkluIGdl bmVyYWwsIHdoZW4gYSBuZXcgYXBwbGljYXRpb24gaGFzIGJlZW4gYWxsb2NhdGVkIHdpdGggYSBu ZXcgDQphcHBsaWNhdGlvbiBpZA0KYW5kIGl0IGFsc28gcmV1c2VzIGV4aXN0aW5nIGNvbW1hbmRz IHdpdGggb3Igd2l0aG91dCBtb2RpZmljYXRpb25zIChTZWMgDQo0LjEpLCBpdCBtdXN0DQp1c2Ug bmV3bHkgYWxsb2NhdGVkIGFwcGxpY2F0aW9uIGlkIGluIHRoZSBoZWFkZXIgYWxsIHJlbGV2YW50 IGFwcGxpY2F0aW9uIA0KaWQgQVZQcw0KKEF1dGgtQXBwbGljYXRpb24tSWQgb3IgQWNjdC1BcHBs aWNhdGlvbi1JZCkgcHJlc2VudCBpbiB0aGUgY29tbWFuZHMgDQptZXNzYWdlIGJvZHkuIg0KDQoN Ck5vdGUgdGhhdCB0aGUgcnVsZSBzaG91bGQgYXBwbHkgd2hldGhlciB0aGUgaW1wb3J0ZWQgY29t bWFuZCBoYXMgYmVlbiANCm1vZGlmaWVkIG9yIG5vdCBvciB3aGV0aGVyIGl0cyB2ZW5kb3Igc3Bl Y2lmaWMgb3Igbm90Lg0KDQpyZWdhcmRzLA0KdmljdG9yDQoNCg0KPiBBbnkgY29uY2VybnM/DQo+ DQo+IFJlZ2FyZHMNCj4gTWFyaw0KPg0KPg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEaU1FIG1haWxpbmcgbGlzdA0KPiBEaU1F QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUN Cj4NCj4NCj4NCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQoNCioqKioqKioqKioqKioqKioq KioqKioqICBBcmljZW50LVByaXZhdGUgICAqKioqKioqKioqKioqKioqKioqKioqKg0KIkRJU0NM QUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmljZW50ICBhbmQgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVhbCB0byB3aG9tIGl0IGlz IGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3IgdXNlZCBmb3IgYW55IHB1 cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGliaXRlZCBmcm9tIHVzaW5n LCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29udGVudHMgb2YgdGhpcyBt ZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkgZm9yIApsb3NzIG9yIGRh bWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQg YnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMuIgo= --=_alternative 003B36FF65257369_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFZpY3Rvciw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TkFTUmVxDQpSRkMgNDAwNSBpcyBjb250cmFkaWN0aW5nIHdpdGgg dGhlIGdpdmVuIHN0YXRlbWVudCBiZWxvdy4gTkFTUmVxIHJldXNlcw0KU1RSL0FTUi9SQVIgY29t bWFuZHMgZnJvbSBiYXNlLiAmbmJzcDtTZWN0aW9uIDEuMyBvZiBSRkMgNDAwNSBtZW50aW9ucw0K dGhhdCBTVFIvQVNSL1JBUiBpcyBkZWZpbmVkIGJ5IGJhc2UuIFNvIHRoZXNlIG1lc3NhZ2Ugc2hv dWxkIHVzZSBiYXNlIGFwcGxpY2F0aW9uDQpJZCAoaGVhZGVyIGFuZCBhdXRoLWFwcGxpY2F0aW9u LWlkIGF2cCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5TaG91bGQgaXQgYmUgbW9kaWZpZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkFyaWRhbWFuIGthdXNoaWsuICZuYnNwOyA8L2ZvbnQ+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VmljdG9yIEZhamFyZG8gJmx0 O3ZmYWphcmRvQHRhcmkudG9zaGliYS5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjEwLzAxLzIwMDcgMDc6MTkgUE08L2ZvbnQ+DQo8YnI+DQo8 dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48L2Rpdj4NCjx0 ZCB2YWxpZ249dG9wPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5NYXJrIEpvbmVzICZs dDttYXJrLmpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20mZ3Q7PC9mb250Pg0KPHRyPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2M8L2Zv bnQ+PC9kaXY+DQo8dGQgdmFsaWduPXRvcD4NCjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN1YmplY3Q8L2ZvbnQ+PC9kaXY+DQo8dGQg dmFsaWduPXRvcD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtEaW1lXSBEZXNp Z24gR3VpZGVsaW5lDQpvbiBDb21tYW5kIHJldXNlIGFuZCBBcHBsaWNhdGlvbi1JZDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgTWFy ayw8YnI+DQo8YnI+DQpTb3JyeSBmb3IgdGhlIHJlYWxseSBsYXRlIHJlcGx5LiBDb21tZW50cyBp bmxpbmU6PGJyPg0KPGJyPg0KJmd0OyBXaGVuIDNHUFAgcmV1c2VkIE5BU1JFUSBjb21tYW5kcyBp biB0aGUgR3ggYXBwbGljYXRpb24gKFRTIDI5LjIxMiksDQphPGJyPg0KJmd0OyBxdWVzdGlvbiBh cm9zZSBhYm91dCB3aGljaCBhcHBsaWNhdGlvbiBpZCBzaG91bGQgcG9wdWxhdGUgdGhlPGJyPg0K Jmd0OyBBdXRoLUFwcGxpY2F0aW9uLUlkIEFWUC4gR3ggaXMgYSB2ZW5kb3Itc3BlY2lmaWMgYXBw bGljYXRpb24gKDNHUFANCmlzPGJyPg0KJmd0OyB0aGUgJ3ZlbmRvcicpIHNvIGl0IHdhcyBpbml0 aWFsbHkgdGhvdWdodCB0aGF0IHRoZTxicj4NCiZndDsgVmVuZG9yLVNwZWNpZmljLUFwcGxpY2F0 aW9uLUlkIEFWUCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mPGJyPg0KJmd0OyBBdXRoLUFwcGxp Y2F0aW9uLUlkLiBIb3dldmVyLCB0aGUgQXV0aC1BcHBsaWNhdGlvbi1JZCBBVlAgaXMgYSByZXF1 aXJlZDxicj4NCiZndDsgQVZQIGluIHRoZSBOQVNSRVEgY29tbWFuZHMgc28gdGhlIEFWUCBjb3Vs ZCBub3QgYmUgcmVwbGFjZWQgd2l0aG91dDxicj4NCiZndDsgYWJhbmRvbmluZyB0aGUgY29tbWFu ZCByZXVzZS4gM0dQUCBkZWNpZGVkIHRvIHBvcHVsYXRlIHRoZTxicj4NCiZndDsgQXV0aC1BcHBs aWNhdGlvbi1JZCBBVlAgd2l0aCB0aGUgR3ggYXBwbGljYXRpb24gaWQuPGJyPg0KJmd0Ozxicj4N CiZndDsgSSB0aGluayBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIHRoZSBEZXNpZ24gR3VpZGVsaW5l cyBkcmFmdCB0byBjYXB0dXJlPGJyPg0KJmd0OyB0aGlzIHNjZW5hcmlvIGFuZCBzdWdnZXN0IHRo ZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGJlIGFkZGVkIHRvIHNlY3Rpb248YnI+DQomZ3Q7IDUuMyAo VXNlIG9mIEFwcGxpY2F0aW9uLUlkIGluIGEgTWVzc2FnZSk6PGJyPg0KJmd0Ozxicj4NCiZndDsg JnF1b3Q7Rm9yIGhpc3RvcmljYWwgcmVhc29ucywgc29tZSBJRVRGIGFwcGxpY2F0aW9ucyBzcGVj aWZ5IGNvbW1hbmRzDQp0aGF0PGJyPg0KJmd0OyByZXF1aXJlIGFwcGxpY2F0aW9uIGlkIEFWUHMg KEF1dGgtQXBwbGljYXRpb24tSWQgb3IgQWNjdC1BcHBsaWNhdGlvbi1JZCk8YnI+DQomZ3Q7IGlu IHRoZSBtZXNzYWdlIGJvZHkuIFdoZW4gZGVzaWduaW5nIHZlbmRvci1zcGVjaWZpYyBhcHBsaWNh dGlvbnMgd2hpY2g8YnI+DQomZ3Q7IHJldXNlIHRoZXNlIElFVEYgY29tbWFuZHMsIGRlc2lnbmVy cyBzaG91bGQgc3BlY2lmeSB0aGF0IHRoZSBhcHBsaWNhdGlvbjxicj4NCiZndDsgaWQgY29udGFp bmVkIGluIHRoZXNlIEFWUHMgaXMgdGhhdCBhc3NpZ25lZCB0byB0aGUgdmVuZG9yLXNwZWNpZmlj PGJyPg0KJmd0OyBhcHBsaWNhdGlvbiBhbmQgbm90IHRoZSBvcmlnaW5hbCBJRVRGIGFwcGxpY2F0 aW9uLiZxdW90Ozxicj4NCiZndDsgJm5ic3A7IDxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBpcyBh IG1vcmUgZ2VuZXJhbCBjYXNlIGlmIGEgY29tbWFuZCBpcyBiZWluZyByZXVzZWQgaW4gYSA8YnI+ DQpuZXcgYXBwbGljYXRpb24gZm9yIHdoaWNoIGEgbmV3IGFwcC1pZCBoYXMgYmVlbiBhc3NpZ25l ZC4gU28gd2UgbWF5IHdhbnQNCjxicj4NCnRvIHJlLXdvcmQgaXQgdGhhdCB3YXkgaW5zdGVhZDo8 YnI+DQo8YnI+DQomcXVvdDtJbiBnZW5lcmFsLCB3aGVuIGEgbmV3IGFwcGxpY2F0aW9uIGhhcyBi ZWVuIGFsbG9jYXRlZCB3aXRoIGEgbmV3DQphcHBsaWNhdGlvbiBpZDxicj4NCmFuZCBpdCBhbHNv IHJldXNlcyBleGlzdGluZyBjb21tYW5kcyB3aXRoIG9yIHdpdGhvdXQgbW9kaWZpY2F0aW9ucyAo U2VjDQo0LjEpLCBpdCBtdXN0PGJyPg0KdXNlIG5ld2x5IGFsbG9jYXRlZCBhcHBsaWNhdGlvbiBp ZCBpbiB0aGUgaGVhZGVyIGFsbCByZWxldmFudCBhcHBsaWNhdGlvbg0KaWQgQVZQczxicj4NCihB dXRoLUFwcGxpY2F0aW9uLUlkIG9yIEFjY3QtQXBwbGljYXRpb24tSWQpIHByZXNlbnQgaW4gdGhl IGNvbW1hbmRzIG1lc3NhZ2UNCmJvZHkuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KTm90ZSB0aGF0 IHRoZSBydWxlIHNob3VsZCBhcHBseSB3aGV0aGVyIHRoZSBpbXBvcnRlZCBjb21tYW5kIGhhcyBi ZWVuIDxicj4NCm1vZGlmaWVkIG9yIG5vdCBvciB3aGV0aGVyIGl0cyB2ZW5kb3Igc3BlY2lmaWMg b3Igbm90Ljxicj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KdmljdG9yPGJyPg0KPGJyPg0KPGJyPg0K Jmd0OyBBbnkgY29uY2VybnM/PGJyPg0KJmd0Ozxicj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsg TWFyazxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IERpTUVAaWV0Zi5vcmc8YnI+DQom Z3Q7IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQo8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRpTUUg bWFpbGluZyBsaXN0PGJyPg0KRGlNRUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KKioqKioqKioqKioqKioqKioq KioqKiogJm5ic3A7QXJpY2VudC1Qcml2YXRlICZuYnNwOyAqKioqKioqKioqKioqKioqKioqKioq KjwvZm9udD4NCjx0YWJsZT48dHI+PHRkIGJnY29sb3I9I2ZmZmZmZj48Zm9udCBjb2xvcj0jMDAw MDAwPjxwcmU+IkRJU0NMQUlNRVI6IFRoaXMgbWVzc2FnZSBpcyBwcm9wcmlldGFyeSB0byBBcmlj ZW50ICBhbmQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIAp0aGUgaW5kaXZpZHVh bCB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSXQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBvciBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIHNob3VsZCBub3QgYmUgCmNpcmN1bGF0ZWQgb3Ig dXNlZCBmb3IgYW55IHB1cnBvc2Ugb3RoZXIgdGhhbiBmb3Igd2hhdCBpdCBpcyBpbnRlbmRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCAKcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBpbW1lZGlhdGVseS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBub3RpZmllZCB0aGF0IHlvdSBhcmUgc3RyaWN0bHkKcHJvaGli aXRlZCBmcm9tIHVzaW5nLCBjb3B5aW5nLCBhbHRlcmluZywgb3IgZGlzY2xvc2luZyB0aGUgY29u dGVudHMgb2YgdGhpcyBtZXNzYWdlLiBBcmljZW50IGFjY2VwdHMgbm8gcmVzcG9uc2liaWxpdHkg Zm9yIApsb3NzIG9yIGRhbWFnZSBhcmlzaW5nIGZyb20gdGhlIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gdHJhbnNtaXR0ZWQgYnkgdGhpcyBlbWFpbCBpbmNsdWRpbmcgZGFtYWdlIGZyb20gdmlydXMu Igo8L3ByZT48L2ZvbnQ+PC90ZD48L3RyPjwvdGFibGU+ --=_alternative 003B36FF65257369_=-- --===============1664229013== 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://www1.ietf.org/mailman/listinfo/dime --===============1664229013==-- From dime-bounces@ietf.org Wed Oct 03 08:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3FY-0001Xf-RD; Wed, 03 Oct 2007 08:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3FC-0000b2-Aw for dime@ietf.org; Wed, 03 Oct 2007 08:22:26 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id3FB-0002US-6I for dime@ietf.org; Wed, 03 Oct 2007 08:22:26 -0400 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 l93CLf9B085386; Wed, 3 Oct 2007 08:21:47 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47038956.3070305@tari.toshiba.com> Date: Wed, 03 Oct 2007 08:21:42 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Aridaman Kaushik Subject: Re: [Dime] Design Guideline on Command reuse and Application-Id References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Aridaman, We had a discussion some time ago regarding this topic. 3588bis as it stands does specify using the app id of the application for these messages. Some of the discussion points can be found in: http://www.tschofenig.priv.at:8080/diameter-interop/issue5 A repercussion of this discussion is that existing apps may need updating. regards, victor > > Hi Victor, > NASReq RFC 4005 is contradicting with the given statement > below. NASReq reuses STR/ASR/RAR commands from base. Section 1.3 of > RFC 4005 mentions that STR/ASR/RAR is defined by base. So these > message should use base application Id (header and auth-application-id > avp). > > Should it be modified. > > Best regards > Aridaman kaushik. > > > *Victor Fajardo * > > 10/01/2007 07:19 PM > > > To > Mark Jones > cc > > Subject > Re: [Dime] Design Guideline on Command reuse and Application-Id > > > > > > > > > > Hi Mark, > > Sorry for the really late reply. Comments inline: > > > When 3GPP reused NASREQ commands in the Gx application (TS 29.212), a > > question arose about which application id should populate the > > Auth-Application-Id AVP. Gx is a vendor-specific application (3GPP is > > the 'vendor') so it was initially thought that the > > Vendor-Specific-Application-Id AVP should be used instead of > > Auth-Application-Id. However, the Auth-Application-Id AVP is a required > > AVP in the NASREQ commands so the AVP could not be replaced without > > abandoning the command reuse. 3GPP decided to populate the > > Auth-Application-Id AVP with the Gx application id. > > > > I think it would be useful for the Design Guidelines draft to capture > > this scenario and suggest the following paragraph be added to section > > 5.3 (Use of Application-Id in a Message): > > > > "For historical reasons, some IETF applications specify commands that > > require application id AVPs (Auth-Application-Id or Acct-Application-Id) > > in the message body. When designing vendor-specific applications which > > reuse these IETF commands, designers should specify that the application > > id contained in these AVPs is that assigned to the vendor-specific > > application and not the original IETF application." > > > > I think this is a more general case if a command is being reused in a > new application for which a new app-id has been assigned. So we may want > to re-word it that way instead: > > "In general, when a new application has been allocated with a new > application id > and it also reuses existing commands with or without modifications > (Sec 4.1), it must > use newly allocated application id in the header all relevant > application id AVPs > (Auth-Application-Id or Acct-Application-Id) present in the commands > message body." > > > Note that the rule should apply whether the imported command has been > modified or not or whether its vendor specific or not. > > regards, > victor > > > > Any concerns? > > > > Regards > > Mark > > > > > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > > *********************** Aricent-Private *********************** > "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." > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 04 16:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX68-0003MZ-Cv; Thu, 04 Oct 2007 16:15:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdX66-0003HV-N9; Thu, 04 Oct 2007 16:15:02 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdX66-0004gO-Am; Thu, 04 Oct 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 347492AC5F; Thu, 4 Oct 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdX65-00011y-UT; Thu, 04 Oct 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Oct 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-08.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-08.txt Pages : 158 Date : 2007-10-4 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-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-rfc3588bis-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-rfc3588bis-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: <2007-10-4155800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-4155800.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 https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Thu Oct 04 17:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdY2e-0005a8-Cq; Thu, 04 Oct 2007 17:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdY2a-0005Wh-V3; Thu, 04 Oct 2007 17:15:28 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdY2Z-0000zH-4p; Thu, 04 Oct 2007 17:15:28 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EBE8626EA0; Thu, 4 Oct 2007 21:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdY29-0006Db-QJ; Thu, 04 Oct 2007 17:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Oct 2007 17:15:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-03.txt Pages : 20 Date : 2007-10-4 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-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-app-design-guide-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-app-design-guide-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: <2007-10-4160100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-4160100.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 https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Fri Oct 05 03:34:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idhh7-0001y6-89; Fri, 05 Oct 2007 03:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Idhh6-0001xN-8T for dime@ietf.org; Fri, 05 Oct 2007 03:33:56 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Idhh0-0002ng-1m for dime@ietf.org; Fri, 05 Oct 2007 03:33:56 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Oct 2007 09:33:33 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-05 Date: Fri, 5 Oct 2007 09:33:33 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D394@SEHAN021MB.tcad.telia.se> In-Reply-To: <47020294.1010506@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-05 Thread-Index: AcgEz8J3VeUsfUvfTG2zOtfQ87k2YACTY6LQ References: <47020294.1010506@gmx.net> From: To: X-OriginalArrivalTime: 05 Oct 2007 07:33:33.0824 (UTC) FILETIME=[08D0C000:01C80722] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Having an operator hat on now.. The HA-AAA interface already contains MIP6-Feature-vector. From operational point of view I want to see a capability bit indicating whether Route Optimization is allowed for a particular mobile node. Of course we do not have (yet) IETF defined way of signaling such policy decision from HA to MN. There are mechanisms outside IETF so I would not worry about that. Anyway, in case of misbehaving mobile host the HA needs to know whether RO is OK or not. =09 Cheers, Jouni > Sent: Tuesday, October 02, 2007 11:34 AM >=20 > Hi all, >=20 > this message marks the issuance of a working group last call=20 > (WGLC) on DIME's Internet Draft entitled "Diameter Mobile=20 > IPv6: Support for Home Agent to Diameter Server Interaction"=20 > (draft-ietf-dime-mip6-split-05).=20 > You may view this document at > http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 >=20 > Please post comments and questions to the DIME mailing list (or to the > authors) no later than 16 October 2007. >=20 > Ciao > Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 09 11:17:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGpg-0008BC-7r; Tue, 09 Oct 2007 11:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGpf-0008B6-7O for dime@ietf.org; Tue, 09 Oct 2007 11:17:15 -0400 Received: from hs-out-0708.google.com ([64.233.178.247] helo=hs-out-2021.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGpZ-0002gQ-3F for dime@ietf.org; Tue, 09 Oct 2007 11:17:15 -0400 Received: by hs-out-2021.google.com with SMTP id 54so160267hsz for ; Tue, 09 Oct 2007 08:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=I9m6Sk2bCg+WybzPlkFXzYqRnxX9FcgmJLD5QXOSQmY=; b=a/MCVsXg/3qoncC0bjAo7191BmlmDXvtNIZ4EI3vk//ZsBBtzHA4gKsjkPBPYRiY2Qh+oQ6IMaAN5KJz+Dz5e6kAnjibIo1ecLaLrdNyNjC/j5qXwEEfopj6SCPE/SobehSesLLr3hfL7l0/iT6yldqjW1/my0VFJS0lJm95aeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=PeEYQ6OIBdvazStI1NUhsNYPRqerCHJ+F53W2HWl/ld9hEXyMU30KC9ZGmiqIzIBQW5c1p12qiBch1NNXwCw7k8m8w2EQ3bMsBFDBtKbHs0e0/MAmYm0TuecR4CSO/aLdD2jOsZNzqzwMKJGnOb4uhQxKX03tgAzBc3FL4hU6iM= Received: by 10.90.36.3 with SMTP id j3mr1384444agj.1191943001127; Tue, 09 Oct 2007 08:16:41 -0700 (PDT) Received: by 10.90.89.12 with HTTP; Tue, 9 Oct 2007 08:16:41 -0700 (PDT) Message-ID: Date: Tue, 9 Oct 2007 17:16:41 +0200 From: "Thomas Lindgren" To: dime@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Dime] E2E-Sequence AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1474004168==" Errors-To: dime-bounces@ietf.org --===============1474004168== Content-Type: multipart/alternative; boundary="----=_Part_6367_6560784.1191943001121" ------=_Part_6367_6560784.1191943001121 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All, I just looked through 3588bis version 08. As far as I can tell the E2E-Sequence AVP is not used anywhere and lacks a proper definition. (It is defined as 'grouped' in the table on p.57 and in 6.15, but 6.15 then does not provide a valid or useful definition.) Is there a good reason to retain this AVP in 3588bis? If so, it should be properly defined. But without such a reason, I propose we take this opportunity to get rid of it. Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_6367_6560784.1191943001121 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

I just looked through 3588bis version 08. As far as I can tell the E2E-Sequence AVP is not used anywhere and lacks a proper definition. (It is defined as 'grouped' in the table on p.57 and in 6.15, but 6.15 then does not provide a valid or useful definition.) Is there a good reason to retain this AVP in 3588bis? If so, it should be properly defined. But without such a reason, I propose we take this opportunity to get rid of it.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd


------=_Part_6367_6560784.1191943001121-- --===============1474004168== 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://www1.ietf.org/mailman/listinfo/dime --===============1474004168==-- From dime-bounces@ietf.org Tue Oct 09 11:31:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfH3l-0004tq-KB; Tue, 09 Oct 2007 11:31:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfH3k-0004a5-Nr for dime@ietf.org; Tue, 09 Oct 2007 11:31:48 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfH3c-000633-CB for dime@ietf.org; Tue, 09 Oct 2007 11:31:40 -0400 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 l99FVcCL011187; Tue, 9 Oct 2007 11:31:38 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <470B9ED8.1000501@tari.toshiba.com> Date: Tue, 09 Oct 2007 11:31:36 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Thomas Lindgren Subject: Re: [Dime] E2E-Sequence AVP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Thomas, Seems like in issue 51 (http://tschofenig.priv.at:8080/diameter-interop/issue51), we left the sequence avp alone for fear that somebody maybe using it. This is unlikely though so I think we can double check to see if this is truly the case and cleanup/remove this avp accordingly. regards, victor > All, > > I just looked through 3588bis version 08. As far as I can tell the > E2E-Sequence AVP is not used anywhere and lacks a proper definition. > (It is defined as 'grouped' in the table on p.57 and in 6.15, but 6.15 > then does not provide a valid or useful definition.) Is there a good > reason to retain this AVP in 3588bis? If so, it should be properly > defined. But without such a reason, I propose we take this opportunity > to get rid of it. > > Best, > Thomas > -- > Thomas Lindgren, Millpond Services Ltd > > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 10 07:45:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfZzV-0002CC-PK; Wed, 10 Oct 2007 07:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfZzT-0002Bv-RT for dime@ietf.org; Wed, 10 Oct 2007 07:44:39 -0400 Received: from smtp.dataconnection.com ([192.91.191.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfZzN-0005yX-Li for dime@ietf.org; Wed, 10 Oct 2007 07:44:39 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 12:44:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Oct 2007 12:44:26 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conflict with grouped & mandatory AVPs. Thread-Index: AcgKl7sDwTbHpHPjT/iVObXybh6rIQAmuG4w From: "Philip Crocker" To: X-OriginalArrivalTime: 10 Oct 2007 11:44:27.0040 (UTC) FILETIME=[E94BFA00:01C80B32] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Dime] Conflict with grouped & mandatory AVPs. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, =20 I have noticed what I think is a minor inconsistency between RFC3588 and the IMS Cx / Dx reference points, regarding the relation between grouped AVPs and mandatory AVPs. It seems to me that RFC3588 is too strict here, though I may have missed something (and my apologies if if this has already been discussed before). =20 RFC3588 section 4.4 states that 'if any of the AVPs encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.'. This is in keeping with RFC3588 section 4.1, which states that whenever an AVP with the M bit is unrecognised, the whole message must be rejected. As a result, it does not make sense for an optional grouped AVP to contain a mandatory sub-AVP that leads to the message being discarded, hence the requirement for grouped AVPs at the start of this paragraph. =20 This position seems to be in conflict with the principle of AVP reuse, where section 1.2 strongly recommends existing AVPs are reused wherever possible. =20 Together these rules require any new non-mandatory Grouped AVP to define non-mandatory sub-AVPs that are identical to pre-existing ones (except for the M flag), which seems a little unnecessary. =20 Additionally, I have found examples where a Diameter application breaks this statement in section 4.4 and defines an optional grouped AVP with mandatory sub-AVPs. =20 * In IMS Sh & Cx reference points, the "Supported-Applications AVP" is specified as MUST NOT have the 'M' bit set, whereas all its children (incl. Auth-Application-Id) are specified as MUST have the 'M' bit set. (Ref: 3GPP TS 29.229 6.3, RFC3588 4.5). =20 * A similar inconsistency exists with the IMS Sh & Cx "Supported-Features" AVP. =20 In my opinion it is reasonable for a Diameter application to be able to define an optional grouped AVP that reuses some mandatory AVPs as sub-AVPs. Does this seem reasonable to people? If so, I would propose rfc3588bis-08 is updated to this effect. =20 Regards, =20 Phil Crocker Network Protocols Division Data Connection Ltd. (DCL) _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 10 08:36:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifami-0005kG-VG; Wed, 10 Oct 2007 08:35:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifamg-0005TV-QC for dime@ietf.org; Wed, 10 Oct 2007 08:35:30 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifamb-00022O-A8 for dime@ietf.org; Wed, 10 Oct 2007 08:35:25 -0400 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 l9ACZNN8012983; Wed, 10 Oct 2007 08:35:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. Date: Wed, 10 Oct 2007 08:35:23 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188327@sonusmail04.sonusnet.com> In-Reply-To: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Conflict with grouped & mandatory AVPs. Thread-Index: AcgKl7sDwTbHpHPjT/iVObXybh6rIQAmuG4wAAHTPhA= References: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> From: "Asveren, Tolga" To: "Philip Crocker" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Philip, I think this makes sense. IMHO we should move forward with the change you proposed. Thanks, Tolga > -----Original Message----- > From: Philip Crocker [mailto:Philip.Crocker@dataconnection.com] > Sent: Wednesday, October 10, 2007 7:44 AM > To: dime@ietf.org > Subject: [Dime] Conflict with grouped & mandatory AVPs. >=20 > Hi all, >=20 > I have noticed what I think is a minor inconsistency between RFC3588 and > the IMS Cx / Dx reference points, regarding the relation between grouped > AVPs and mandatory AVPs. It seems to me that RFC3588 is too strict > here, though I may have missed something (and my apologies if if this > has already been discussed before). >=20 > RFC3588 section 4.4 states that 'if any of the AVPs encapsulated within > a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself > MUST also include the 'M' bit set.'. This is in keeping with RFC3588 > section 4.1, which states that whenever an AVP with the M bit is > unrecognised, the whole message must be rejected. As a result, it does > not make sense for an optional grouped AVP to contain a mandatory > sub-AVP that leads to the message being discarded, hence the requirement > for grouped AVPs at the start of this paragraph. >=20 > This position seems to be in conflict with the principle of AVP reuse, > where section 1.2 strongly recommends existing AVPs are reused wherever > possible. >=20 > Together these rules require any new non-mandatory Grouped AVP to define > non-mandatory sub-AVPs that are identical to pre-existing ones (except > for the M flag), which seems a little unnecessary. >=20 > Additionally, I have found examples where a Diameter application breaks > this statement in section 4.4 and defines an optional grouped AVP with > mandatory sub-AVPs. >=20 > * In IMS Sh & Cx reference points, the "Supported-Applications AVP" is > specified as MUST NOT have the 'M' bit set, whereas all its children > (incl. Auth-Application-Id) are specified as MUST have the 'M' bit set. > (Ref: 3GPP TS 29.229 6.3, RFC3588 4.5). >=20 > * A similar inconsistency exists with the IMS Sh & Cx > "Supported-Features" AVP. >=20 > In my opinion it is reasonable for a Diameter application to be able to > define an optional grouped AVP that reuses some mandatory AVPs as > sub-AVPs. Does this seem reasonable to people? If so, I would propose > rfc3588bis-08 is updated to this effect. >=20 > Regards, >=20 > Phil Crocker > Network Protocols Division > Data Connection Ltd. (DCL) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 10 12:18:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeGI-00058c-Ca; Wed, 10 Oct 2007 12:18:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfeGG-00056n-EB for dime@ietf.org; Wed, 10 Oct 2007 12:18:16 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfeG9-0001Pm-TP for dime@ietf.org; Wed, 10 Oct 2007 12:18:10 -0400 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 l9AGI6BB016877; Wed, 10 Oct 2007 12:18:07 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <470CFB36.6010603@tari.toshiba.com> Date: Wed, 10 Oct 2007 12:17:58 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. References: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> <033458F56EC2A64E8D2D7B759FA3E7E7188327@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188327@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: dime@ietf.org, Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Issues is in tracker: http://www.tschofenig.priv.at:8080/diameter-interop/issue64 regards, victor > Hi Philip, > > I think this makes sense. IMHO we should move forward with the change > you proposed. > > Thanks, > Tolga > > >> -----Original Message----- >> From: Philip Crocker [mailto:Philip.Crocker@dataconnection.com] >> Sent: Wednesday, October 10, 2007 7:44 AM >> To: dime@ietf.org >> Subject: [Dime] Conflict with grouped & mandatory AVPs. >> >> Hi all, >> >> I have noticed what I think is a minor inconsistency between RFC3588 >> > and > >> the IMS Cx / Dx reference points, regarding the relation between >> > grouped > >> AVPs and mandatory AVPs. It seems to me that RFC3588 is too strict >> here, though I may have missed something (and my apologies if if this >> has already been discussed before). >> >> RFC3588 section 4.4 states that 'if any of the AVPs encapsulated >> > within > >> a Grouped AVP has the 'M' (mandatory) bit set, the Grouped AVP itself >> MUST also include the 'M' bit set.'. This is in keeping with RFC3588 >> section 4.1, which states that whenever an AVP with the M bit is >> unrecognised, the whole message must be rejected. As a result, it >> > does > >> not make sense for an optional grouped AVP to contain a mandatory >> sub-AVP that leads to the message being discarded, hence the >> > requirement > >> for grouped AVPs at the start of this paragraph. >> >> This position seems to be in conflict with the principle of AVP reuse, >> where section 1.2 strongly recommends existing AVPs are reused >> > wherever > >> possible. >> >> Together these rules require any new non-mandatory Grouped AVP to >> > define > >> non-mandatory sub-AVPs that are identical to pre-existing ones (except >> for the M flag), which seems a little unnecessary. >> >> Additionally, I have found examples where a Diameter application >> > breaks > >> this statement in section 4.4 and defines an optional grouped AVP with >> mandatory sub-AVPs. >> >> * In IMS Sh & Cx reference points, the "Supported-Applications AVP" is >> specified as MUST NOT have the 'M' bit set, whereas all its children >> (incl. Auth-Application-Id) are specified as MUST have the 'M' bit >> > set. > >> (Ref: 3GPP TS 29.229 6.3, RFC3588 4.5). >> >> * A similar inconsistency exists with the IMS Sh & Cx >> "Supported-Features" AVP. >> >> In my opinion it is reasonable for a Diameter application to be able >> > to > >> define an optional grouped AVP that reuses some mandatory AVPs as >> sub-AVPs. Does this seem reasonable to people? If so, I would >> > propose > >> rfc3588bis-08 is updated to this effect. >> >> Regards, >> >> Phil Crocker >> Network Protocols Division >> Data Connection Ltd. (DCL) >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 10 14:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJj-0005VC-D1; Wed, 10 Oct 2007 14:29:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJi-0005Up-88 for dime@ietf.org; Wed, 10 Oct 2007 14:29:58 -0400 Received: from [125.236.61.195] (helo=smtp.eservglobal.co.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfgJh-0005xz-JT for dime@ietf.org; Wed, 10 Oct 2007 14:29:58 -0400 Received: from [192.168.7.230] (rloader.eservglobal.co.nz [192.168.7.230]) by smtp.eservglobal.co.nz (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l9AITi35005599; Thu, 11 Oct 2007 07:29:45 +1300 Message-ID: <470D1A18.1070206@eservglobal.co.nz> Date: Thu, 11 Oct 2007 07:29:44 +1300 From: Ralph Loader User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Philip Crocker Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. References: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> In-Reply-To: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4521/Wed Oct 10 20:58:01 2007 on smtp.eservglobal.co.nz X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org > In my opinion it is reasonable for a Diameter application to be able to > define an optional grouped AVP that reuses some mandatory AVPs as > sub-AVPs. Does this seem reasonable to people? If so, I would propose > rfc3588bis-08 is updated to this effect. I take it that the intention is that the sub-AVP still has the M bit set, but that the receiver never generates an 'unknown mandatory AVP' error for the sub-AVP. (An alternative would be to not set the M bit when putting such a sub-AVP into an optional AVP). Cheers, Ralph. > > Regards, > > Phil Crocker > Network Protocols Division > Data Connection Ltd. (DCL) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 05:14:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifu6V-0000Bt-St; Thu, 11 Oct 2007 05:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifu6U-0000Bn-Ok for dime@ietf.org; Thu, 11 Oct 2007 05:13:14 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifu6O-00083z-Is for dime@ietf.org; Thu, 11 Oct 2007 05:13:14 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Oct 2007 10:12:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. Date: Thu, 11 Oct 2007 10:12:58 +0100 Message-ID: <52A0FF47062B0B4C80862F2526E0240904A4CD01@enfimail2.datcon.co.uk> In-Reply-To: <470D1A18.1070206@eservglobal.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Conflict with grouped & mandatory AVPs. Thread-Index: AcgLa449DJssPpCFQMG2X4bKh933JwAdfEMA References: <52A0FF47062B0B4C80862F2526E0240904A4C788@enfimail2.datcon.co.uk> <470D1A18.1070206@eservglobal.co.nz> From: "Philip Crocker" To: "Ralph Loader" X-OriginalArrivalTime: 11 Oct 2007 09:12:59.0930 (UTC) FILETIME=[EB5EC7A0:01C80BE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ralph, Thanks for your feedback. I agree that it's best to keep the 'M' bit set in a sub-AVP if that AVP has been defined as mandatory (for one reason, it makes parsing an AVP simpler if you can expect an AVP to have the same flags no matter where the AVP is present in a message). As a result, I'd propose the following text changes to RFC3588-bis, which takes account of arbitrarily nested AVPs. - Edit RFC3588-bis section 4.1 to state that if an AVP with the 'M' bit is unrecognised, this should cause the message to be discarded if all Grouped AVPs in which that AVP is nested within also have the 'M' bit set. =20 - Remove the sentence from RFC3588-bis section 4.4 starting "Further, if any of the AVPs encapsulated within...". Regards, Phil Crocker Network Protocols Division Data Connection Ltd. (DCL) -----Original Message----- From: Ralph Loader [mailto:rloader@eservglobal.com]=20 Sent: 10 October 2007 19:30 To: Philip Crocker Cc: dime@ietf.org Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. > In my opinion it is reasonable for a Diameter application to be able=20 > to define an optional grouped AVP that reuses some mandatory AVPs as=20 > sub-AVPs. Does this seem reasonable to people? If so, I would=20 > propose > rfc3588bis-08 is updated to this effect. I take it that the intention is that the sub-AVP still has the M bit set, but that the receiver never generates an 'unknown mandatory AVP'=20 error for the sub-AVP. (An alternative would be to not set the M bit when putting such a sub-AVP into an optional AVP). Cheers, Ralph. > =20 > Regards, > =20 > Phil Crocker > Network Protocols Division > Data Connection Ltd. (DCL) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 08:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxAx-000480-RQ; Thu, 11 Oct 2007 08:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfxAv-0003qK-V2 for dime@ietf.org; Thu, 11 Oct 2007 08:30:02 -0400 Received: from outbound-blu.frontbridge.com ([65.55.251.16] helo=outbound7-blu-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfxAp-0006Xf-FL for dime@ietf.org; Thu, 11 Oct 2007 08:30:01 -0400 Received: from outbound7-blu.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound7-blu-R.bigfish.com (Postfix) with ESMTP id 4A685211F0E; Thu, 11 Oct 2007 12:29:36 +0000 (UTC) Received: from mail216-blu-R.bigfish.com (unknown [10.1.252.3]) by outbound7-blu.bigfish.com (Postfix) with ESMTP id 30C3516307F8; Thu, 11 Oct 2007 12:29:36 +0000 (UTC) Received: from mail216-blu (localhost.localdomain [127.0.0.1]) by mail216-blu-R.bigfish.com (Postfix) with ESMTP id DAF6315082CB; Thu, 11 Oct 2007 12:29:35 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 212.120.142.30; Service: EHS Received: by mail216-blu (MessageSwitch) id 1192105773514059_18522; Thu, 11 Oct 2007 12:29:33 +0000 (UCT) Received: from GSMDUBEX02.GSM.TLD (unknown [212.120.142.30]) by mail216-blu.bigfish.com (Postfix) with ESMTP id 54B304B0072; Thu, 11 Oct 2007 12:29:24 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. Date: Thu, 11 Oct 2007 13:28:54 +0100 Message-ID: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Conflict with grouped & mandatory AVPs. Thread-Index: AcgLa449DJssPpCFQMG2X4bKh933JwAdfEMAAAfGXlA= From: "Dan Warren" To: "Philip Crocker" , "Ralph Loader" X-Spam-Score: -4.0 (----) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Interesting discussion, particularly for me since I was one of the people that did a lot of the Cx and Sh work in 3GPP (you can Boo and through rocks at me privately). The intent was certainly to have something like 'the Grouped AVP is Optional, but when it is included it MUST include/comprehend the sub-AVP' which is why we included the 'M'. I guess that doesn't really work with current definition and comes down perhaps to the old chestnut of Mandatory inclusion vs Mandatory comprehension. So two questions;- - if the Grouped AVP is optional and not recognised by the receiver, could it be discarded silently even if it contains 'M' marked sub-AVPs? >From the discussions so far I am guessing that the answer is either 'No', or 'n/a since the situation should never occur. - For the intended convention of what we tried to achieve in 3GPP, what should we have written? I am guessing again it should be all Optional and describe conditions for behaviour in the text associated with nodal behaviour... Dan = > -----Original Message----- > From: Philip Crocker [mailto:Philip.Crocker@dataconnection.com] = > Sent: 11 October 2007 10:13 > To: Ralph Loader > Cc: dime@ietf.org > Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. > = > Hi Ralph, > = > Thanks for your feedback. I agree that it's best to keep the = > 'M' bit set in a sub-AVP if that AVP has been defined as = > mandatory (for one reason, it makes parsing an AVP simpler if = > you can expect an AVP to have the same flags no matter where = > the AVP is present in a message). > = > As a result, I'd propose the following text changes to = > RFC3588-bis, which takes account of arbitrarily nested AVPs. > = > - Edit RFC3588-bis section 4.1 to state that if an AVP with = > the 'M' bit is unrecognised, this should cause the message to = > be discarded if all Grouped AVPs in which that AVP is nested = > within also have the 'M' bit set. > = > - Remove the sentence from RFC3588-bis section 4.4 starting = > "Further, if any of the AVPs encapsulated within...". > = > Regards, > = > Phil Crocker > Network Protocols Division > Data Connection Ltd. (DCL) > = > = > -----Original Message----- > From: Ralph Loader [mailto:rloader@eservglobal.com] > Sent: 10 October 2007 19:30 > To: Philip Crocker > Cc: dime@ietf.org > Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. > = > = > > In my opinion it is reasonable for a Diameter application = > to be able = > > to define an optional grouped AVP that reuses some = > mandatory AVPs as = > > sub-AVPs. Does this seem reasonable to people? If so, I would = > > propose > > rfc3588bis-08 is updated to this effect. > = > I take it that the intention is that the sub-AVP still has the M bit > set, but that the receiver never generates an 'unknown mandatory AVP' = > error for the sub-AVP. (An alternative would be to not set the M bit > when putting such a sub-AVP into an optional AVP). > = > Cheers, > Ralph. > = > = > = > > = > > Regards, > > = > > Phil Crocker > > Network Protocols Division > > Data Connection Ltd. (DCL) > > = > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > = > = > = > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > = > = Forthcoming GSMA Events: = GSMA Mobile Asia Congress Macau 12 - 15 November 2007 www.mobileasiacongress.com = GSMA Mobile World Congress Barcelona 11 - 14 February 2008 www.mobileworldcongress.com This email and its attachments are intended for the above named only and ma= y be confidential. If they have come to you in error you must take no actio= n based on them, nor must you copy or show them to anyone; please reply to = this email or call +44 207 759 2300 and highlight the error _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 09:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifxnp-0000Mv-2U; Thu, 11 Oct 2007 09:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifxnn-0000If-LB for dime@ietf.org; Thu, 11 Oct 2007 09:10:11 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ifxnm-0008Qs-GO for dime@ietf.org; Thu, 11 Oct 2007 09:10:11 -0400 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 l9BD9aXD021785; Thu, 11 Oct 2007 09:09:36 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <470E2087.6020206@tari.toshiba.com> Date: Thu, 11 Oct 2007 09:09:27 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Dan Warren Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. References: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dime@ietf.org, Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Dan, > Interesting discussion, particularly for me since I was one of the > people that did a lot of the Cx and Sh work in 3GPP (you can Boo and > through rocks at me privately). The intent was certainly to have > something like 'the Grouped AVP is Optional, but when it is included it > MUST include/comprehend the sub-AVP' which is why we included the 'M'. > I guess there's always confusion with what it means to be an optional AVP and how it relates to 'M' bit. From what I understand (folks can correct me if I'm wrong), the core idea was an optional AVP means it does not have to appear in a message (controlled by the ABNF) but it may/may not have the 'M' bit set if it does appear. If it has the 'M' bit set then the receiver has to understand the AVP and its contents. Given this and the scenario you stated above (and depending on whether your piggybacking your AVP to an existing application), it may have been better to set the 'M' bit for the grouped avp as well to be 'cleaner'. Going back to the original discussion, I thinking a hierarchal approach is best given what we have now. So, if a grouped AVP does not have the 'M' bit set then its member AVP does not have to be recognizable even if some/all of them have 'M' bit set. Note that this applies to nesting of grouped AVPs as well. > I guess that doesn't really work with current definition and comes down > perhaps to the old chestnut of Mandatory inclusion vs Mandatory > comprehension. > > So two questions;- > > - if the Grouped AVP is optional and not recognised by the receiver, > could it be discarded silently even if it contains 'M' marked sub-AVPs? > >From the discussions so far I am guessing that the answer is either > 'No', or 'n/a since the situation should never occur. > We need to update the spec and say that if the parent grouped avp does not the 'M'-bit set then member AVPs need not be recognizable despite their M-bit settings. > - For the intended convention of what we tried to achieve in 3GPP, what > should we have written? I am guessing again it should be all Optional > and describe conditions for behaviour in the text associated with nodal > behaviour... > The 'all optional' approach is useful maybe only in the case where your piggybacking your AVP to an existing application; i.e. your not defining a new app. But if you are defining a new app and the app will have to recognize these AVPs, it maybe best to control optionality of an AVP via the command ABNF. best regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 10:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzPA-0002RZ-Bk; Thu, 11 Oct 2007 10:52:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfzP9-0002RO-7S for dime@ietf.org; Thu, 11 Oct 2007 10:52:51 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfzP8-0000Ws-L8 for dime@ietf.org; Thu, 11 Oct 2007 10:52:51 -0400 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 l9BEqQLj032483; Thu, 11 Oct 2007 10:52:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. Date: Thu, 11 Oct 2007 10:52:26 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188339@sonusmail04.sonusnet.com> In-Reply-To: <470E2087.6020206@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Conflict with grouped & mandatory AVPs. Thread-Index: AcgMCFy+gn54x5LxT1WAgc1DWJF5JwADKnTQ References: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> <470E2087.6020206@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" , "Dan Warren" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: dime@ietf.org, Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor,Dan, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Thursday, October 11, 2007 9:09 AM > To: Dan Warren > Cc: dime@ietf.org; Philip Crocker > Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. >=20 > Hi Dan, >=20 > > Interesting discussion, particularly for me since I was one of the > > people that did a lot of the Cx and Sh work in 3GPP (you can Boo and > > through rocks at me privately). The intent was certainly to have > > something like 'the Grouped AVP is Optional, but when it is included it > > MUST include/comprehend the sub-AVP' which is why we included the 'M'. > > >=20 > I guess there's always confusion with what it means to be an optional > AVP and how it relates to 'M' bit. From what I understand (folks can > correct me if I'm wrong), the core idea was an optional AVP means it > does not have to appear in a message (controlled by the ABNF) but it > may/may not have the 'M' bit set if it does appear. If it has the 'M' > bit set then the receiver has to understand the AVP and its contents. > Given this and the scenario you stated above (and depending on whether > your piggybacking your AVP to an existing application), it may have been > better to set the 'M' bit for the grouped avp as well to be 'cleaner'. [TOLGA]IMHO this really depends on the flexibility we want to provide. For example, if I want to indicate "That you can process this grouped AVP is optional but in case you want to do that please make sure that you know the semantics associated with certain sub-AVPs in it" then I would not set the M-bit for the grouped AVP but for the relevant sub-AVPs. >=20 > Going back to the original discussion, I thinking a hierarchal approach > is best given what we have now. So, if a grouped AVP does not have the > 'M' bit set then its member AVP does not have to be recognizable even if > some/all of them have 'M' bit set. Note that this applies to nesting of > grouped AVPs as well. >=20 > > I guess that doesn't really work with current definition and comes down > > perhaps to the old chestnut of Mandatory inclusion vs Mandatory > > comprehension. > > > > So two questions;- > > > > - if the Grouped AVP is optional and not recognised by the receiver, > > could it be discarded silently even if it contains 'M' marked sub-AVPs? > > >From the discussions so far I am guessing that the answer is either > > 'No', or 'n/a since the situation should never occur. > > >=20 > We need to update the spec and say that if the parent grouped avp does > not the 'M'-bit set then member AVPs need not be recognizable despite > their M-bit settings. [TOLGA]If we want to provide the type of flexibility I mentioned above, IMHO what we need to say is that a grouped AVP may be ignored it if its M-bit is not set regardless of the M-bit setting of its sub-AVPs. So, Dan, for your question, my answer would be "Yes". >=20 > > - For the intended convention of what we tried to achieve in 3GPP, what > > should we have written? I am guessing again it should be all Optional > > and describe conditions for behaviour in the text associated with nodal > > behaviour... [TOLGA]I think, if we update RFC3588 properly, the 3GPP usage for this case should be fine. > > >=20 > The 'all optional' approach is useful maybe only in the case where your > piggybacking your AVP to an existing application; i.e. your not defining > a new app. But if you are defining a new app and the app will have to > recognize these AVPs, it maybe best to control optionality of an AVP via > the command ABNF. >=20 >=20 > best regards, > victor >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 11:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzyu-0007gg-GN; Thu, 11 Oct 2007 11:29:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifzys-0007f4-UQ for dime@ietf.org; Thu, 11 Oct 2007 11:29:47 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifzys-00028W-E6 for dime@ietf.org; Thu, 11 Oct 2007 11:29:46 -0400 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 l9BFTf1W022453; Thu, 11 Oct 2007 11:29:42 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <470E415D.1010203@tari.toshiba.com> Date: Thu, 11 Oct 2007 11:29:33 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. References: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> <470E2087.6020206@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188339@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188339@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: dime@ietf.org, Dan Warren , Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >> I guess there's always confusion with what it means to be an optional >> AVP and how it relates to 'M' bit. From what I understand (folks can >> correct me if I'm wrong), the core idea was an optional AVP means it >> does not have to appear in a message (controlled by the ABNF) but it >> may/may not have the 'M' bit set if it does appear. If it has the 'M' >> bit set then the receiver has to understand the AVP and its contents. >> Given this and the scenario you stated above (and depending on whether >> your piggybacking your AVP to an existing application), it may have >> > been > >> better to set the 'M' bit for the grouped avp as well to be 'cleaner'. >> > [TOLGA]IMHO this really depends on the flexibility we want to provide. > For example, if I want to indicate "That you can process this grouped > AVP is optional but in case you want to do that please make sure that > you know the semantics associated with certain sub-AVPs in it" then I > would not set the M-bit for the grouped AVP but for the relevant > sub-AVPs. > I guess in the specific case where you really need to understand the contents of an AVP (whether grouped of not), it seems to make sense to have the M-bit set. Extending this to a hierarchal approach, the recognizability of inner AVP can be tied to its parent. The M-bit of the parent makes it easier to indicate this situation; i.e. you don't have to parse through inner AVPs to see which one has an M-bit or not to realize the recognizability of the entire group ... or I'm probably missing something :) Also in 3GPP apps, I think maybe the use of the ABNF to indicate optionality should be considered or at least not confused with the M-bit settings. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 12:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0lv-0003iL-4T; Thu, 11 Oct 2007 12:20:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0lu-0003hk-DX for dime@ietf.org; Thu, 11 Oct 2007 12:20:26 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig0lt-0004As-OW for dime@ietf.org; Thu, 11 Oct 2007 12:20:26 -0400 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 l9BGKOAh029637; Thu, 11 Oct 2007 12:20:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Conflict with grouped & mandatory AVPs. Date: Thu, 11 Oct 2007 12:20:23 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718833D@sonusmail04.sonusnet.com> In-Reply-To: <470E415D.1010203@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Conflict with grouped & mandatory AVPs. Thread-Index: AcgMG48Kd4TVfbGRQu+bh5hoeHtvswAAma5A References: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> <470E2087.6020206@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188339@sonusmail04.sonusnet.com> <470E415D.1010203@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: dime@ietf.org, Dan Warren , Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Victor, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Thursday, October 11, 2007 11:30 AM > To: Asveren, Tolga > Cc: Dan Warren; dime@ietf.org; Philip Crocker > Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. >=20 > Hi Tolga, >=20 > >> I guess there's always confusion with what it means to be an optional > >> AVP and how it relates to 'M' bit. From what I understand (folks can > >> correct me if I'm wrong), the core idea was an optional AVP means it > >> does not have to appear in a message (controlled by the ABNF) but it > >> may/may not have the 'M' bit set if it does appear. If it has the 'M' > >> bit set then the receiver has to understand the AVP and its contents. > >> Given this and the scenario you stated above (and depending on whether > >> your piggybacking your AVP to an existing application), it may have > >> > > been > > > >> better to set the 'M' bit for the grouped avp as well to be 'cleaner'. > >> > > [TOLGA]IMHO this really depends on the flexibility we want to provide. > > For example, if I want to indicate "That you can process this grouped > > AVP is optional but in case you want to do that please make sure that > > you know the semantics associated with certain sub-AVPs in it" then I > > would not set the M-bit for the grouped AVP but for the relevant > > sub-AVPs. > > >=20 > I guess in the specific case where you really need to understand the > contents of an AVP (whether grouped of not), it seems to make sense to > have the M-bit set. Extending this to a hierarchal approach, the > recognizability of inner AVP can be tied to its parent. The M-bit of the > parent makes it easier to indicate this situation; i.e. you don't have > to parse through inner AVPs to see which one has an M-bit or not to > realize the recognizability of the entire group ... or I'm probably > missing something :) [TOLGA]IMHO, not extending the meaning of M-bit of a sub-AVP to its parent is a better approach (or better said to have the flexibility to do so). If we forbid this, there won't be a way to indicate the behavior I described above. For example, if one wants to attach QoS-Capability AVP to a message without M-bit set, this would indicate that receiver does not really need to understand/process it. OTOH, QoS-Profile sub-AVP will have M-bit set to indicate that in case the receiver is able to process QoS-Capability AVP, it must know what to do with QoS-Profile AVP. Setting M-bit of the QoS-Capability AVP (the parent AVP) would make its processing mandatory, which may not be always the desired behavior. >=20 > Also in 3GPP apps, I think maybe the use of the ABNF to indicate > optionality should be considered or at least not confused with the M-bit > settings. [TOLGA]Yes, it is important to appreciate the difference between ABNF semantics and M-bit. I think there is some room for improvement at certain 3GPP specification regarding this issue but AFAIU what we discuss now does not fall into this category. Is there any concrete proposal for an ABNF based solution? _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 12:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0vK-00026B-AL; Thu, 11 Oct 2007 12:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig0vI-00023c-7Q for dime@ietf.org; Thu, 11 Oct 2007 12:30:08 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig0vC-0001Ns-2E for dime@ietf.org; Thu, 11 Oct 2007 12:30:08 -0400 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 l9BGTulF003702 for ; Thu, 11 Oct 2007 12:29:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Oct 2007 12:29:56 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718833E@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dime-qos-attributes-02.txt - Use of M-bit Thread-Index: AcgMI/W3el7qGjh3RYmtwNUOgxD3Ug== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Dime] draft-ietf-dime-qos-attributes-02.txt - Use of M-bit X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I noticed that for the new QoS AVPs, the M-bit is listed as "MAY". This would mean that this bit may be set and in such a case addition of such an AVP to an existing command is not allowed according to the extensibility rules we defined. We would need to define new commands and new commands would mean new applications. =20 I guess this is a good opportunity to test the practical applicability of the rules defined in the application design guidelines document. Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 14:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2PC-0003R4-G4; Thu, 11 Oct 2007 14:05:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig2P8-00036d-10 for dime@ietf.org; Thu, 11 Oct 2007 14:05:02 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig2Ox-000052-KU for dime@ietf.org; Thu, 11 Oct 2007 14:04:51 -0400 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 l9BI4TUK023180; Thu, 11 Oct 2007 14:04:29 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <470E65A8.5000802@tari.toshiba.com> Date: Thu, 11 Oct 2007 14:04:24 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. References: <6918D1F7F8770C4FB182838A7BDFD6C8017CDBC9@GSMDUBEX02.GSM.TLD> <470E2087.6020206@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188339@sonusmail04.sonusnet.com> <470E415D.1010203@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E718833D@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718833D@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org, Dan Warren , Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Tolga, >> parent makes it easier to indicate this situation; i.e. you don't have >> to parse through inner AVPs to see which one has an M-bit or not to >> realize the recognizability of the entire group ... or I'm probably >> missing something :) >> > [TOLGA]IMHO, not extending the meaning of M-bit of a sub-AVP to its > parent is a better approach (or better said to have the flexibility to > do so). If we forbid this, there won't be a way to indicate the behavior > I described above. For example, if one wants to attach QoS-Capability > AVP to a message without M-bit set, this would indicate that receiver > does not really need to understand/process it. OTOH, QoS-Profile sub-AVP > will have M-bit set to indicate that in case the receiver is able to > process QoS-Capability AVP, it must know what to do with QoS-Profile > AVP. Setting M-bit of the QoS-Capability AVP (the parent AVP) would make > its processing mandatory, which may not be always the desired behavior. > There maybe some confusion on what comments relates to where :) I guess your example above is what i meant with my original comment "whether we are piggybacking this AVP to an exsiting application". And given that we need to support this genericness, I agree we do need to remove some restrictions. However, commenting on applications/scenarios being from Dan, it may have been better to use the ABNF as optionality indicator rather than the M-bit in some of the 3gpp designs and use a hierarchal model. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 11 19:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig73V-0002ny-6B; Thu, 11 Oct 2007 19:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig73T-0002mU-Kc for dime@ietf.org; Thu, 11 Oct 2007 19:02:59 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig73N-0001ik-F1 for dime@ietf.org; Thu, 11 Oct 2007 19:02:59 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l9BN2e213875; Thu, 11 Oct 2007 23:02:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-05 Date: Thu, 11 Oct 2007 18:02:33 -0500 Message-ID: In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222D394@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC for draft-ietf-dime-mip6-split-05 thread-index: AcgEz8J3VeUsfUvfTG2zOtfQ87k2YACTY6LQAT0RJEA= References: <47020294.1010506@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222D394@SEHAN021MB.tcad.telia.se> From: "Ahmad Muhanna" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, Having my own hat on ... :-) I strongly agree and support this. Not only that but defining a less than 128 new code, which can be defined to mean Registration is successful but RO is not supported, is the most efficient and least harmful way of communicating RO authorization to the MN. I was actually under the impression that the majority of people on the mailing list have supported this.=20 Cheers! Regards, Ahmad > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Friday, October 05, 2007 9:34 AM > To: dime@ietf.org > Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-05 >=20 > Hi, >=20 > Having an operator hat on now.. >=20 > The HA-AAA interface already contains MIP6-Feature-vector.=20 > From operational point of view I want to see a capability bit=20 > indicating whether Route Optimization is allowed for a=20 > particular mobile node. >=20 > Of course we do not have (yet) IETF defined way of signaling=20 > such policy decision from HA to MN. There are mechanisms=20 > outside IETF so I would not worry about that. Anyway, in case=20 > of misbehaving mobile host the HA needs to know whether RO is=20 > OK or not. > =09 > Cheers, > Jouni >=20 > > Sent: Tuesday, October 02, 2007 11:34 AM > >=20 > > Hi all, > >=20 > > this message marks the issuance of a working group last call > > (WGLC) on DIME's Internet Draft entitled "Diameter Mobile > > IPv6: Support for Home Agent to Diameter Server Interaction"=20 > > (draft-ietf-dime-mip6-split-05).=20 > > You may view this document at > > http://tools.ietf.org/html/draft-ietf-dime-mip6-split-05 > >=20 > > Please post comments and questions to the DIME mailing list=20 > (or to the > > authors) no later than 16 October 2007. > >=20 > > Ciao > > Hannes & Dave >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 13 10:41:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igi9t-0004u9-Va; Sat, 13 Oct 2007 10:40:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igi9s-0004gg-Vo for dime@ietf.org; Sat, 13 Oct 2007 10:40:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Igi9k-0003y7-1H for dime@ietf.org; Sat, 13 Oct 2007 10:39:56 -0400 Received: (qmail invoked by alias); 13 Oct 2007 14:39:53 -0000 Received: from p54986FF4.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.111.244] by mail.gmx.net (mp057) with SMTP; 13 Oct 2007 16:39:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19q26xErD5ql3o3irx+PL7u6+kxa/qqd23QjhptjX Va3wpci6rFQd61 Message-ID: <4710D8BA.2020903@gmx.net> Date: Sat, 13 Oct 2007 17:39:54 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] draft-ietf-dime-qos-attributes-02.txt - Use of M-bit References: <033458F56EC2A64E8D2D7B759FA3E7E718833E@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718833E@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Tolga, that's a good catch. Thanks a lot for the comment. Regarding the Diameter Design Guidelines: Based on the received review comments we should say a bit more about this topic in the design guidelines document. I will post a separate mail about this subject to the list. Ciao Hannes Asveren, Tolga wrote: > I noticed that for the new QoS AVPs, the M-bit is listed as "MAY". This > would mean that this bit may be set and in such a case addition of such > an AVP to an existing command is not allowed according to the > extensibility rules we defined. We would need to define new commands and > new commands would mean new applications. > > I guess this is a good opportunity to test the practical applicability > of the rules defined in the application design guidelines document. > > Thanks, > Tolga > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 13 10:50:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgiJs-0008GD-QR; Sat, 13 Oct 2007 10:50:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgiJr-00081K-Tz for dime@ietf.org; Sat, 13 Oct 2007 10:50:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IgiJh-0004Nl-4m for dime@ietf.org; Sat, 13 Oct 2007 10:50:13 -0400 Received: (qmail invoked by alias); 13 Oct 2007 14:50:12 -0000 Received: from p54986FF4.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.111.244] by mail.gmx.net (mp032) with SMTP; 13 Oct 2007 16:50:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xh6lsU4hxRwUDqrVCvo8LKIPR7E+J9NS+U6eDsm w3IWZpKFuy6bzp Message-ID: <4710DB24.9050803@gmx.net> Date: Sat, 13 Oct 2007 17:50:12 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Dime] Diameter QoS attribute draft & Design Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, we receive a few review comments that relate to the Diameter Design Guidelines draft. There was at least the following interesting aspect that I would like to discuss with the group. Section 3 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt essentially indicates (in a verbose fashion) what existing Diameter applications may use these Diameter QoS attributes. There was the question why this is at all needed. Essentially, should we delete Section 3 from that draft? In some sense this is a question about extensibility. When you define a new AVP then you might want it to be used in every possible application or just in particular application where you currently see a need. In some sense it is not necessary to list these applications since the support for these AVPs is in fact optional. Hence, nothing happens when the Diameter client or the Diameter server does not provide support for it. When the client does not include any of the defined QoS AVPs then nothing happens at the server. If the client includes them and the server does not support them then the server will just ignore them and the client will not receive the corresponding response. Even the case where the client and the server understand different QoS models is supported. So, I guess it might be more reasonable to just delete Section 3 (and thereby shorten the draft) and instead provide some description about the different "error" cases. What do others think about this proposal? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 13 11:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igj0Z-000510-Oi; Sat, 13 Oct 2007 11:34:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Igj0Y-00050G-PX for dime@ietf.org; Sat, 13 Oct 2007 11:34:30 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Igj0Y-0005tU-Bt for dime@ietf.org; Sat, 13 Oct 2007 11:34:30 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (sccrmhc11) with SMTP id <200710131534290110053q0re>; Sat, 13 Oct 2007 15:34:30 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Date: Sat, 13 Oct 2007 11:34:26 -0400 To: dime@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: James Polk Subject: [Dime] draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, (brought to the list as requested, with slight modifications) Sections 4.9, 4.10, and 4.11 as written reflect the references attributed to each section. What I would like to suggest is to add some text that would reflect the objectives and priority related parameters of (soon to be version 4 with minor edits). Concerning 4.9, leave it as is. As I mentioned privately, our emergency-rsvp draft has no concept of defending or preemption priority. Rather, we wanted to define a new RSVP policy element that only conveyed an admission priority along with another element that carried numeric-only representations of the alpha-numeric RPH Namespace and RPH Value. Section 4.10 defines the semantics for the Admission Priority. In addition, you follow Y.1571 and define four pre-existing values: 0 (best effort), 1 (normal), 2 (high), and 255 (not used). Our emergency-rsvp draft also has an Admission Priority field (of the same size of Section 4.10), but with no pre-established values. Here we have a conundrum. Do we overload the parameter of 4.10 and use it for both Y.1571 and emergency-rsvp, or do we define a new parameter and have it dedicated to our draft. I would have a preference for the former. And if we do go with the overloading option, I would assume that we may want to define a bit flag so that it identifies the parameter as applying to Y.1571 or the emergency- rsvp draft. The structure and first part of Section 4.11 seems fine. Our emergency-rsvp draft has the same Namespace & Priority fields along with the same size for each field. The area of concern though is the latter part of the section where you state which permutations/cases are permissible. I'm sorry if I missed earlier discussions on the DIME list, but I don't understand why one must have whenever is used. Is this because this document relates to QoS and thus there must be some notion of desired service level as stated in Y.1571? And perhaps a more general questions is: if I wanted to use Diameter to provide AAA only for RPH headers of SIP messages (with no conveyance of desired QoS), do I need to define a new AVP? thoughts? -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 13 12:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgjYW-0000wT-It; Sat, 13 Oct 2007 12:09:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgjYV-0000en-Dk for dime@ietf.org; Sat, 13 Oct 2007 12:09:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IgjYN-0007F8-Ff for dime@ietf.org; Sat, 13 Oct 2007 12:09:28 -0400 Received: (qmail invoked by alias); 13 Oct 2007 16:09:25 -0000 Received: from p54986FF4.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.111.244] by mail.gmx.net (mp051) with SMTP; 13 Oct 2007 18:09:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/uWQ0a2CTu5cLM0FMKS2zMsl8u18JR+0byB9uWEd igeLjUYum5oy+n Message-ID: <4710EDB4.7080306@gmx.net> Date: Sat, 13 Oct 2007 19:09:24 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ken, thank you for the good feedback. Please find my comments below: ken carlberg wrote: > Hi Hannes, > > (brought to the list as requested, with slight modifications) > > Sections 4.9, 4.10, and 4.11 as written reflect the references > attributed to each section. What I would like to suggest is to add > some text that would reflect the objectives and priority related > parameters of (soon to be > version 4 with minor edits). > > Concerning 4.9, leave it as is. As I mentioned privately, our > emergency-rsvp draft has no concept of defending or preemption > priority. Rather, we wanted to define a new RSVP policy element that > only conveyed an admission priority along with another element that > carried numeric-only representations of the alpha-numeric RPH > Namespace and RPH Value. > > Section 4.10 defines the semantics for the Admission Priority. In > addition, you follow Y.1571 and define four pre-existing values: 0 > (best effort), 1 (normal), 2 (high), and 255 (not used). Our > emergency-rsvp draft also has an Admission Priority field (of the same > size of Section 4.10), but with no pre-established values. > > Here we have a conundrum. Do we overload the parameter of 4.10 and > use it for both Y.1571 and emergency-rsvp, or do we define a new > parameter and have it dedicated to our draft. I would have a > preference for the former. And if we do go with the overloading > option, I would assume that we may want to define a bit flag so that > it identifies the parameter as applying to Y.1571 or the > emergency-rsvp draft. > The term "overlapping" is not correct here. In some sense you are asking to generalize the attribute a bit by adding a "namespace" field. Obviously, the definition in Section 4.10 had it's origin in Y.1571 and I am sure that other groups/SDO will define their own values (in the same fashion as you did). Another question of interest with respect to this parameter is the following: In Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt you define more than just the Adm. Priority field. You also have the merge strategy defined. Do you believe that it would be important to add this field as well to the attribute? Is this something that could be treated as in independent attribute? > The structure and first part of Section 4.11 seems fine. Our > emergency-rsvp draft has the same Namespace & Priority fields along > with the same size for each field. The area of concern though is the > latter part of the section where you state which permutations/cases > are permissible. I'm sorry if I missed earlier discussions on the > DIME list, but I don't understand why one must have Priority> whenever is used. Is this because this > document relates to QoS and thus there must be some notion of desired > service level as stated in Y.1571? And perhaps a more general > questions is: if I wanted to use Diameter to provide AAA only for RPH > headers of SIP messages (with no conveyance of desired QoS), do I need > to define a new AVP? > > thoughts? > We inherited the description from NSIS. I personally don't see why it is necessary to restrict the occurrence of these attributes in such a way. I will bring this to the NSIS mailing list for discussion. I also got the impression that there is a little bit of mismatch in the registries created by IANA. Also a discussion between NSIS and TSVWG. In fact, the IANA consideration section of http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt reads like a snippet from a conversation between TSVWG and NSIS members.... Ciao Hannes > -ken > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Oct 14 14:45:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8SG-0004us-38; Sun, 14 Oct 2007 14:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ih8SF-0004pH-Er for dime@ietf.org; Sun, 14 Oct 2007 14:44:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ih8S6-0001nZ-Tz for dime@ietf.org; Sun, 14 Oct 2007 14:44:40 -0400 Received: (qmail invoked by alias); 14 Oct 2007 18:44:10 -0000 Received: from p549861B9.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.97.185] by mail.gmx.net (mp004) with SMTP; 14 Oct 2007 20:44:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kyvV3IRWk+nxroEIrC9Sku8W4xLaasW5lJGuq+b 7NzNEgEmi3KhJO Message-ID: <4712637A.2020500@gmx.net> Date: Sun, 14 Oct 2007 21:44:10 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg IETF list , "nsis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: dime@ietf.org Subject: [Dime] draft-ietf-tsvwg-emergency-rsvp-03.txt and draft-ietf-nsis-qspec-17.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, during the WGLC review comments for draft-ietf-dime-qos-attributes-02.txt and draft-ietf-dime-qos-parameters-01 we noticed that there is a mismatch regarding the IANA considerations for Resource Priority elements. Section 5 of says: " This document defines an ALRP Priority field in section 3.2 that contains a numerical value identifying the namespace of the application-level resource priority. The IANA already maintains the Resource-Priority Namespaces registry (under the SIP Parameters) listing all such namespace. However, that registry does not currently allocate a numerical value to each namespace. Hence, this document requests the IANA to extend the Resource-Priority Namespace registry in the following ways: - a new column should be added to the registry - the title of the new column should be "Namespace numerical Value *" - in the Legend, add a line saying "Namespace numerical Value = the unique numerical value identifying the namespace" - add a line at the bottom of the registry stating the following "* : [RFCXXX] " where XXX is the RFC number of the present document - allocate an actual numerical value to each namespace in the registry and state that value in the new "Namespace numerical Value *" column. A numerical value should be allocated immediately by IANA to all existing namespace. Then, in the future, IANA should automatically allocate a numerical value to any new namespace added to the registry. [draft-ietf-nsis-qspec] also uses numerical values for Resource- Priority Namespaces. The request IANA to create a new registry to allocate numerical values to each namespace. We suggest that the approach above be followed instead (i.e. extend the existing registry) and that [draft-ietf-nsis-qspec] also makes use of the values defined in the new "Namespace numerical Value *" column of the extended existing Resource-Priority Namespace registry. In any case, the IANA should only do one of the two approaches (an not both). " draft-ietf-nsis-qspec-17.txt says the following " RPH Priority Parameter (8 bits): dsn namespace: The allocation policies are as follows: 0-63: Standards Action 64-255: Reserved drsn namespace: The allocation policies are as follows: 0-63: Standards Action 64-255: Reserved Q735 namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: Q735 priority 4: q735.4 3: q735.3 2: q735.2 1: q735.1 0: q735.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved ets namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: ETS priority 4: ets.4 3: ets.3 2: ets.2 1: ets.1 0: ets.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved wts namespace: The following values are allocated by this specification: 0-4: assigned as specified in Section 6.2.10: WPS priority 4: wps.4 3: wps.3 2: wps.2 1: wps.1 0: wps.0 The allocation policies for further values are as follows: 5-63: Standards Action 64-255: Reserved " Clearly, there is a mismatch regarding the registration of the same values. I would therefore suggest that the authors get together and determine a solution. In draft-ietf-dime-qos-parameters-01 we unfortunately need to refer to a registry and would therefore appreciate to have a resolution soon. Furthermore, Ken posted a review of draft-ietf-dime-qos-parameters-01 to the DIME list that also points to an unnecessary constraint (in his view) regarding the usage of the priority parameters listed in Section 6.2.10. Ken's review can be found at: http://www1.ietf.org/mail-archive/web/dime/current/msg02089.html Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 09:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ8f-0003CA-5O; Mon, 15 Oct 2007 09:37:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ8e-0002y4-L8 for dime@ietf.org; Mon, 15 Oct 2007 09:37:44 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQ8M-000317-LC for dime@ietf.org; Mon, 15 Oct 2007 09:37:27 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (sccrmhc12) with SMTP id <2007101513372501200e9gm0e>; Mon, 15 Oct 2007 13:37:25 +0000 In-Reply-To: <4710EDB4.7080306@gmx.net> References: <4710EDB4.7080306@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Mon, 15 Oct 2007 09:37:22 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, >> Section 4.10 defines the semantics for the Admission Priority. In >> addition, you follow Y.1571 and define four pre-existing values: 0 >> (best effort), 1 (normal), 2 (high), and 255 (not used). Our >> emergency-rsvp draft also has an Admission Priority field (of the >> same size of Section 4.10), but with no pre-established values. >> >> Here we have a conundrum. Do we overload the parameter of 4.10 >> and use it for both Y.1571 and emergency-rsvp, or do we define a >> new parameter and have it dedicated to our draft. I would have a >> preference for the former. And if we do go with the overloading >> option, I would assume that we may want to define a bit flag so >> that it identifies the parameter as applying to Y.1571 or the >> emergency-rsvp draft. >> > The term "overlapping" is not correct here. In some sense you are > asking to generalize the attribute a bit by adding a "namespace" > field. ok, I wrote something and just deleted it because the term "namespace" can cause some confusion. what I'm suggesting is perhaps an "SDO-space" field because the output of one SDO has pre-defined values. my concern is that if we apply the admission priority field of 4.10 to both Y.1571 and the tsvwg-emergency-rsvp draft, then we burden the latter with predefined non-opaque values that are tagged with a perceived level of QoS. For example, given that a value of "0" == "best effort" for Y.1571, what if I choose a value corresponding to "scavenger service", which is considered less that best effort? My point being that I don't want to burden our tsvwg-emergency-rsvp draft with values set for Y.1571. One way out of this is to distinguish the association of the admission priority of 4.10 by a bit field. Another approach to the problem is to remove the pre-defined values from 4.10 and add some text stating that related work from other SDOs may have pre-defined values. I'm open to either, or some other idea to address my concerns. > Obviously, the definition in Section 4.10 had it's origin in Y.1571 > and I am sure that other groups/SDO will define their own values > (in the same fashion as you did). just to recap, tsvwg-emergency-rsvp hasn't defined any values for the field. > Another question of interest with respect to this parameter is the > following: In Section 3.1 of http://www.ietf.org/internet-drafts/ > draft-ietf-tsvwg-emergency-rsvp-03.txt you define more than just > the Adm. Priority field. You also have the merge strategy defined. > Do you believe that it would be important to add this field as well > to the attribute? Is this something that could be treated as in > independent attribute? that's a tough question. we have the merge field in cases where the rsvp policy attribute is used for multicast. however, I don't see any text describing the application of Diameter to multicast in rfc-3588, the current diameter base draft, nor the QoS related diameter drafts. without that text or further guidance from the Diameter group, I would be reluctant to add a merge field onto the attribute of 4.10. >> The structure and first part of Section 4.11 seems fine. Our >> emergency-rsvp draft has the same Namespace & Priority fields >> along with the same size for each field. The area of concern >> though is the latter part of the section where you state which >> permutations/cases are permissible. I'm sorry if I missed earlier >> discussions on the DIME list, but I don't understand why one must >> have whenever is used. Is >> this because this document relates to QoS and thus there must be >> some notion of desired service level as stated in Y.1571? And >> perhaps a more general questions is: if I wanted to use Diameter >> to provide AAA only for RPH headers of SIP messages (with no >> conveyance of desired QoS), do I need to define a new AVP? >> >> thoughts? >> > We inherited the description from NSIS. I personally don't see why > it is necessary to restrict the occurrence of these attributes in > such a way. I will bring this to the NSIS mailing list for discussion. > > I also got the impression that there is a little bit of mismatch in > the registries created by IANA. Also a discussion between NSIS and > TSVWG. In fact, the IANA consideration section of http:// > www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt > reads like a snippet from a conversation between TSVWG and NSIS > members.... some of us have had early discussions a while back with the authors of the Qspec draft http://www.ietf.org/internet-drafts/draft-ietf- nsis-qspec-17.txt, but that draft seemed to stall and had been on last call for quite a long time. we've had discussions about IANA considerations within TSVWG (I think mostly at the meetings, with recaps on the list) along with tapping our own experiences on the IANA considerations work done on the SIP Resource Priority header. cheers, -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 10:31:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQyZ-0006Us-SI; Mon, 15 Oct 2007 10:31:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQyY-0006Tp-Li for dime@ietf.org; Mon, 15 Oct 2007 10:31:22 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQyY-0004wj-6R for dime@ietf.org; Mon, 15 Oct 2007 10:31:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS attribute draft & Design Guidelines Date: Mon, 15 Oct 2007 10:31:20 -0400 Message-ID: In-Reply-To: <4710DB24.9050803@gmx.net> References: <4710DB24.9050803@gmx.net> From: "Mark Jones" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, I agree with the proposal to remove the command ABNF from this draft. This draft should minally provide the attribute definitions and stress their reusability in ALL applications. I have no problem with the examples in section 6 as they do a good job of explaining the semantic rules in section 5. Section 7 can also be deleted. Regards Mark > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: October 13, 2007 10:50 > To: dime@ietf.org > Subject: [Dime] Diameter QoS attribute draft & Design Guidelines >=20 > Hi all, >=20 > we receive a few review comments that relate to the Diameter Design=20 > Guidelines draft. There was at least the following interesting aspect=20 > that I would like to discuss with the group. >=20 > Section 3 of=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib utes-02.txt=20 > essentially indicates (in a verbose fashion) what existing Diameter=20 > applications may use these Diameter QoS attributes. >=20 > There was the question why this is at all needed.=20 > Essentially, should we=20 > delete Section 3 from that draft? >=20 > In some sense this is a question about extensibility. When=20 > you define a=20 > new AVP then you might want it to be used in every possible=20 > application=20 > or just in particular application where you currently see a need. In=20 > some sense it is not necessary to list these applications since the=20 > support for these AVPs is in fact optional. Hence, nothing=20 > happens when=20 > the Diameter client or the Diameter server does not provide=20 > support for=20 > it. When the client does not include any of the defined QoS AVPs then=20 > nothing happens at the server. If the client includes them and the=20 > server does not support them then the server will just ignore=20 > them and=20 > the client will not receive the corresponding response. Even the case=20 > where the client and the server understand different QoS models is=20 > supported. >=20 > So, I guess it might be more reasonable to just delete Section 3 (and=20 > thereby shorten the draft) and instead provide some description about=20 > the different "error" cases. >=20 > What do others think about this proposal? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 10:45:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRCJ-0007FT-9x; Mon, 15 Oct 2007 10:45:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRCH-0007FH-Pu for dime@ietf.org; Mon, 15 Oct 2007 10:45:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhRCH-0005WU-8e for dime@ietf.org; Mon, 15 Oct 2007 10:45:33 -0400 X-IronPort-AV: E=Sophos;i="4.21,277,1188770400"; d="scan'208";a="155816718" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2007 16:45:32 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9FEjW9L003803; Mon, 15 Oct 2007 16:45:32 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9FEjMV5026317; Mon, 15 Oct 2007 14:45:32 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:45:22 +0200 Received: from [10.0.0.42] ([10.61.81.64]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 16:45:22 +0200 In-Reply-To: <4710EDB4.7080306@gmx.net> References: <4710EDB4.7080306@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E5C287F-E4D1-44EB-B710-C775394E2D91@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: [RPH Priority] Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Mon, 15 Oct 2007 16:45:17 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 14:45:22.0322 (UTC) FILETIME=[039D4F20:01C80F3A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--25.293600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2486; t=1192459532; x=1193323532; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20[RPH=20Priority]=20Re=3A=20[Dime]=20draft-ietf-dime-qos-param eters-01 |Sender:=20; bh=N2F+QFM1ZNEgAaeOZw3D6ZFgHgkuo+Ahmrh21JbTT6g=; b=Cs0nyYlIx6u69c4aA80XywHw45Dbupo8XoTBkNPBUb6+z9iryiueTJrwBnyLz+4sDSxq9TGy 78BPVt5St/DLPpQX82ylH6Yj392Kl7YUnSEQMITayLvuy9c/CuqvdxWX; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello, >> The structure and first part of Section 4.11 seems fine. Our >> emergency-rsvp draft has the same Namespace & Priority fields >> along with the same size for each field. The area of concern >> though is the latter part of the section where you state which >> permutations/cases are permissible. I'm sorry if I missed earlier >> discussions on the DIME list, but I don't understand why one must >> have whenever is used. Is >> this because this document relates to QoS and thus there must be >> some notion of desired service level as stated in Y.1571? And >> perhaps a more general questions is: if I wanted to use Diameter >> to provide AAA only for RPH headers of SIP messages (with no >> conveyance of desired QoS), do I need to define a new AVP? >> >> thoughts? >> > So we now have many protocols (rsvp-emergency, nsis-qspec, radius, diameter) that need to encode : (i) the RPH namespace as a numerical value (ii) the RPH priority as a numerical value. Do we agree (as suggested in emergency-rsvp (*) ) that we would be better off with an IANA registry specifying these values (once for all protocols to use) instead of each protocol document re-specifying the encoding itself? > We inherited the description from NSIS. I personally don't see why > it is necessary to restrict the occurrence of these attributes in > such a way. I will bring this to the NSIS mailing list for discussion. I also don't see reasons to restrict the combinations. Thanks Francois PS: (*) emergency-rsvp-03 only discussed the RPH Namespace (but next version is intended to also discuss RPH Priority and propose that these values be also defined in an IANA registry) > > I also got the impression that there is a little bit of mismatch in > the registries created by IANA. Also a discussion between NSIS and > TSVWG. In fact, the IANA consideration section of http:// > www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt > reads like a snippet from a conversation between TSVWG and NSIS > members.... > > Ciao > Hannes > > >> -ken >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRSV-0007sU-76; Mon, 15 Oct 2007 11:02:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRST-0007ms-Oi for dime@ietf.org; Mon, 15 Oct 2007 11:02:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhRST-0006Wc-Bw for dime@ietf.org; Mon, 15 Oct 2007 11:02:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,277,1188770400"; d="scan'208";a="155818173" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2007 17:02:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9FF2GZt010340; Mon, 15 Oct 2007 17:02:16 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9FF2GUh003847; Mon, 15 Oct 2007 15:02:16 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 17:02:16 +0200 Received: from [10.0.0.42] ([10.61.81.64]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 17:02:15 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65A6AD49-F94B-424E-8156-4A153605D801@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Mon, 15 Oct 2007 17:02:10 +0200 To: ken carlberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 15:02:16.0138 (UTC) FILETIME=[5FE55AA0:01C80F3C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--8.920800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1114; t=1192460536; x=1193324536; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20[Preemption]=20Re=3A=20draft-ietf-dime-qos-parameters-01 |Sender:=20; bh=1Ff5Sl3Du8fQICZVjDxDFD7pfDLoCw6vMaksSq9HJq4=; b=LqTjg67uD9N/JqNgzKsuMS/aKq5NztRdBAdo6OuQFgiDkIoyc+kyiRZ/lV0xB19TGs/VRc/I CPUIU6jpMqr3xkWnkfJZM2MeJCFPv/GtV5OnQXjDoLBBhw+t9bJ4VY1X; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: James Polk , dime@ietf.org Subject: [Dime] [Preemption] Re: draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Ken and all, > > Concerning 4.9, leave it as is. As I mentioned privately, our > emergency-rsvp draft has no concept of defending or preemption > priority. Rather, we wanted to define a new RSVP policy element > that only conveyed an admission priority along with another element > that carried numeric-only representations of the alpha-numeric RPH > Namespace and RPH Value. > I think section 4.9 is fine as it is. The emergency-rsvp draft acknowledges the fact that the RSVP signaling messages may also contain an RFC3181 policy element (containing both a preemption priority and a defending priority). So this is all fine and consistent, I believe. An alternative approach, for section 4.9, could have been to purely point to RFC3181 for the semantics and encodings of the preemption and defending priority field (without reproducing text). The objectives being to avoid duplication of text which can potentially lead to inconsistencies (e.g. if RFC3181 was to be updated one day). But the text as is will make the document much easier to read. Francois _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:12:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRau-0006dt-Gz; Mon, 15 Oct 2007 11:11:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRas-0006Tn-PP for dime@ietf.org; Mon, 15 Oct 2007 11:10:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhRah-0000XS-EL for dime@ietf.org; Mon, 15 Oct 2007 11:10:48 -0400 Received: (qmail invoked by alias); 15 Oct 2007 15:10:46 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp054) with SMTP; 15 Oct 2007 17:10:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18aQp1XzWcaLi/eX0oFYJgpBQyvPsAqc2cAU9Y9Rm IYYSldhPwvyHAk Message-ID: <471382F3.10101@gmx.net> Date: Mon, 15 Oct 2007 18:10:43 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> In-Reply-To: <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ken, thanks for your quick response. Please find a few comments below: ken carlberg wrote: > Hannes, > >>> Section 4.10 defines the semantics for the Admission Priority. In >>> addition, you follow Y.1571 and define four pre-existing values: 0 >>> (best effort), 1 (normal), 2 (high), and 255 (not used). Our >>> emergency-rsvp draft also has an Admission Priority field (of the >>> same size of Section 4.10), but with no pre-established values. >>> >>> Here we have a conundrum. Do we overload the parameter of 4.10 and >>> use it for both Y.1571 and emergency-rsvp, or do we define a new >>> parameter and have it dedicated to our draft. I would have a >>> preference for the former. And if we do go with the overloading >>> option, I would assume that we may want to define a bit flag so that >>> it identifies the parameter as applying to Y.1571 or the >>> emergency-rsvp draft. >>> >> The term "overlapping" is not correct here. In some sense you are >> asking to generalize the attribute a bit by adding a "namespace" field. > > ok, I wrote something and just deleted it because the term "namespace" > can cause some confusion. what I'm suggesting is perhaps an > "SDO-space" field because the output of one SDO has pre-defined values. It seems that you are really looking at a vendor-specific registry that happens to include SDOs as well. See http://www.iana.org/assignments/enterprise-numbers > > my concern is that if we apply the admission priority field of 4.10 to > both Y.1571 and the tsvwg-emergency-rsvp draft, then we burden the > latter with predefined non-opaque values that are tagged with a > perceived level of QoS. For example, given that a value of "0" == > "best effort" for Y.1571, what if I choose a value corresponding to > "scavenger service", which is considered less that best effort? My > point being that I don't want to burden our tsvwg-emergency-rsvp draft > with values set for Y.1571. Right. Overloading values with a different semantic is not that great. > > One way out of this is to distinguish the association of the admission > priority of 4.10 by a bit field. Another approach to the problem is > to remove the pre-defined values from 4.10 and add some text stating > that related work from other SDOs may have pre-defined values. I'm > open to either, or some other idea to address my concerns. The flag just provides you a way to differentiate between Y.1571 and the tsvwg-emergency-rsvp. I am sure if we look at the work of some other SDOs then we will realize that they again have other values defined. The question therefore really is (from a Diameter/RADIUS perspective): Do we want to have an attribute that has a generic name instead of creating specific variants of it. The generic name would be "Admission Priority Parameter". When we have a generic attribute then we need to differentiate the semantic again by introducing a vendor-/SDO specific field. Alternatively, one could create one attribute called "Admission Priority Parameter for Y.1541" and other one "Admission Priority Parameter for RFC TBD" From a http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt point of view both approaches are fine. So, do you envision that there are many other SDOs defining their own admission priorities? Do you expect that additional information would be added to the admission priority field itself? I mentioned the "merge strategy" field in Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt. For further comments on it, see below. > >> Obviously, the definition in Section 4.10 had it's origin in Y.1571 >> and I am sure that other groups/SDO will define their own values (in >> the same fashion as you did). > > just to recap, tsvwg-emergency-rsvp hasn't defined any values for the > field. > >> Another question of interest with respect to this parameter is the >> following: In Section 3.1 of >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt >> you define more than just the Adm. Priority field. You also have the >> merge strategy defined. Do you believe that it would be important to >> add this field as well to the attribute? Is this something that could >> be treated as in independent attribute? > > that's a tough question. we have the merge field in cases where the > rsvp policy attribute is used for multicast. however, I don't see any > text describing the application of Diameter to multicast in rfc-3588, > the current diameter base draft, nor the QoS related diameter drafts. > without that text or further guidance from the Diameter group, I would > be reluctant to add a merge field onto the attribute of 4.10. Diameter does not really care too much about the type of traffic. Diameter is only providing the authorization and accounting functionality. I cannot tell whether it would make sense to allow the Diameter client to tell the Diameter server something about QoS reservation for the multicast traffic by indicating the merge strategy. Would this be useful for the Diameter server to know about? Would it make sense for the Diameter server to tell the Diameter client which type of merge strategy to use? > >>> The structure and first part of Section 4.11 seems fine. Our >>> emergency-rsvp draft has the same Namespace & Priority fields along >>> with the same size for each field. The area of concern though is >>> the latter part of the section where you state which >>> permutations/cases are permissible. I'm sorry if I missed earlier >>> discussions on the DIME list, but I don't understand why one must >>> have whenever is used. Is this >>> because this document relates to QoS and thus there must be some >>> notion of desired service level as stated in Y.1571? And perhaps a >>> more general questions is: if I wanted to use Diameter to provide >>> AAA only for RPH headers of SIP messages (with no conveyance of >>> desired QoS), do I need to define a new AVP? >>> >>> thoughts? >>> >> We inherited the description from NSIS. I personally don't see why it >> is necessary to restrict the occurrence of these attributes in such a >> way. I will bring this to the NSIS mailing list for discussion. >> >> I also got the impression that there is a little bit of mismatch in >> the registries created by IANA. Also a discussion between NSIS and >> TSVWG. In fact, the IANA consideration section of >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt >> reads like a snippet from a conversation between TSVWG and NSIS >> members.... > > some of us have had early discussions a while back with the authors of > the Qspec draft > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-17.txt, but > that draft seemed to stall and had been on last call for quite a long > time. we've had discussions about IANA considerations within TSVWG (I > think mostly at the meetings, with recaps on the list) along with > tapping our own experiences on the IANA considerations work done on > the SIP Resource Priority header. > Since I am not an author of draft-ietf-nsis-qspec-17.txt I cannot really comment. In fact I don't really care too much about these details as long as the Diameter work is able to move forward as planned. Ciao Hannes > cheers, > > -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRi4-00040L-AO; Mon, 15 Oct 2007 11:18:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRi2-0003zJ-Mt for dime@ietf.org; Mon, 15 Oct 2007 11:18:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhRi2-0000z8-8G for dime@ietf.org; Mon, 15 Oct 2007 11:18:22 -0400 X-IronPort-AV: E=Sophos;i="4.21,277,1188770400"; d="scan'208";a="155819987" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2007 17:18:20 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9FFIJUp026234; Mon, 15 Oct 2007 17:18:19 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9FFI7VF010210; Mon, 15 Oct 2007 15:18:19 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 17:18:18 +0200 Received: from [10.0.0.42] ([10.61.81.64]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 17:18:17 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77DB746A-85A3-4698-B382-2B44EA23CB46@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Mon, 15 Oct 2007 17:18:13 +0200 To: ken carlberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Oct 2007 15:18:17.0947 (UTC) FILETIME=[9D2DC2B0:01C80F3E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15480.000 X-TM-AS-Result: No--22.908400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1987; t=1192461499; x=1193325499; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20[Admission=20Priority]=20Re=3A=20draft-ietf-dime-qos-paramete rs-01 |Sender:=20; bh=D/NBrX0QdgYbZ3U6ii4gRz/TmOZiTTj1Jm8xOtGb954=; b=aMlBCfhHqF7/2xKrY4apj+E82S22DpMeSy8KMeWj/Sc9TiMtoygfHV5PZcDTs45m9e+jgPfr IHLv/quc1uOgS/DU6pjOYpgn/lpx6bX4HTPQUvY74vQimBjF9nnKNaSO; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: James Polk , dime@ietf.org Subject: [Dime] [Admission Priority] Re: draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Ken and all, > > Section 4.10 defines the semantics for the Admission Priority. In > addition, you follow Y.1571 and define four pre-existing values: 0 > (best effort), 1 (normal), 2 (high), and 255 (not used). Our > emergency-rsvp draft also has an Admission Priority field (of the > same size of Section 4.10), but with no pre-established values. > > Here we have a conundrum. Do we overload the parameter of 4.10 and > use it for both Y.1571 and emergency-rsvp, or do we define a new > parameter and have it dedicated to our draft. I would have a > preference for the former. And if we do go with the overloading > option, I would assume that we may want to define a bit flag so > that it identifies the parameter as applying to Y.1571 or the > emergency-rsvp draft. It is not clear to me why we would need to signal anything different in terms of Admission Priority in NSIS, RSVP or DIAMETER/RADIUS. Is there any reason for this? Assuming there is not, then I would say: * _if_ it is absolutely clear to everyone that the 4 values defined in Y.1571 are the only values that will be applicable to all networks ever, then all protocols could probably settle on those Y.1571 values. * _if_ it is not clear that these 4 values are the only ones that will ever be applicable to any network, then I would suggest that we take the same approach as for Preemption priority: ie just define the relative semantics ("Higher values represent higher Priority"). This would be equally applicable to NSIS, RSVP and DIAMETER/RADIUS. And then it is up to the network operator to decide what values they actually use. One network administrator may decide to use the values recommended by Y.1571. Another operator may decide to use different values. This should not be hard-coded in any protocol spec. Again, this is the approach taken for the Preemption priority. Does this make sense? Thanks Francois _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:38:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhS0i-0001vx-O0; Mon, 15 Oct 2007 11:37:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhS0h-0001vr-FR for dime@ietf.org; Mon, 15 Oct 2007 11:37:39 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhS0g-0001tX-Su for dime@ietf.org; Mon, 15 Oct 2007 11:37:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9FFavEc025267; Mon, 15 Oct 2007 18:37:28 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 18:37:16 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 10:37:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-nsis-qspec-17.txt was [Dime] draft-ietf-dime-qos-parameters-01 Date: Mon, 15 Oct 2007 10:37:09 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533AA24979@daebe104.NOE.Nokia.com> In-Reply-To: <471382F3.10101@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-nsis-qspec-17.txt was [Dime] draft-ietf-dime-qos-parameters-01 Thread-Index: AcgPPkUXTxcdnOyTSOWnEG7u64o9HwAAr9zQ References: <4710EDB4.7080306@gmx.net><7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> From: To: , X-OriginalArrivalTime: 15 Oct 2007 15:37:10.0033 (UTC) FILETIME=[3FF46010:01C80F41] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jmpolk@cisco.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-17.txt, but=20 >> that draft seemed to stall and had been on last call for quite a long >> time. we've had discussions about IANA considerations within TSVWG (I=20 >> think mostly at the meetings, with recaps on the list) along with=20 >> tapping our own experiences on the IANA considerations work done on=20 >> the SIP Resource Priority header. This is about to be sent to the IESG, the reason it has been 'stuck' is based upon the fact that the GIST document has been under IESG re-review. As soon as that is through, this document will be submitted to the IESG . John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:39:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhS2A-0002nP-Vt; Mon, 15 Oct 2007 11:39:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhS28-0002mu-US for dime@ietf.org; Mon, 15 Oct 2007 11:39:08 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhS28-0001xT-7r for dime@ietf.org; Mon, 15 Oct 2007 11:39:08 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9FFciMc009570; Mon, 15 Oct 2007 18:38:57 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 18:38:52 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 10:38:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: SDO-space RE: [Dime] draft-ietf-dime-qos-parameters-01 Date: Mon, 15 Oct 2007 10:38:48 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533AA2497C@daebe104.NOE.Nokia.com> In-Reply-To: <471382F3.10101@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDO-space RE: [Dime] draft-ietf-dime-qos-parameters-01 Thread-Index: AcgPPkUXTxcdnOyTSOWnEG7u64o9HwAAv17Q References: <4710EDB4.7080306@gmx.net><7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> From: To: , X-OriginalArrivalTime: 15 Oct 2007 15:38:49.0243 (UTC) FILETIME=[7B169EB0:01C80F41] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: jmpolk@cisco.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Just a highlevel comment on this: > ok, I wrote something and just deleted it because the term "namespace" > can cause some confusion. what I'm suggesting is perhaps an=20 > "SDO-space" field because the output of one SDO has pre-defined values. The IETF has no formal definition on what constitutes an SDO. You either have vendor extentions or formal IETF extensions. I don't think we can do=20 anything about this in the WG. I think using the Enterprise Numbers in IANA is the way to specify extensions outside of the IETF. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 11:59:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSLa-0007fH-59; Mon, 15 Oct 2007 11:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhSLY-0007es-FX for dime@ietf.org; Mon, 15 Oct 2007 11:59:12 -0400 Received: from sccrmhc12.comcast.net ([204.127.200.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhSLQ-0006rJ-FR for dime@ietf.org; Mon, 15 Oct 2007 11:59:12 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (sccrmhc12) with SMTP id <2007101515585901200eb7fae>; Mon, 15 Oct 2007 15:58:59 +0000 In-Reply-To: <471382F3.10101@gmx.net> References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Mon, 15 Oct 2007 11:58:54 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, >> ok, I wrote something and just deleted it because the term >> "namespace" can cause some confusion. what I'm suggesting is >> perhaps an "SDO-space" field because the output of one SDO has pre- >> defined values. > It seems that you are really looking at a vendor-specific registry > that happens to include SDOs as well. > See http://www.iana.org/assignments/enterprise-numbers ouch, no. i think the thread is leading to a level of granular information that was not my intention. At the worst, I would have just wanted to distinguish SDOs (and in particular, their priority related standards) *if* the need exists to do so within the parameter of 4.10. (more below) > The question therefore really is (from a Diameter/RADIUS > perspective): Do we want to have an attribute that has a generic > name instead of creating specific variants of it. brief answer, yes. > The generic name would be "Admission Priority Parameter". When we > have a generic attribute then we need to differentiate the semantic > again by introducing a vendor-/SDO specific field. only if we have pre-defined values as 4.10 as written now. if we take out these values and perhaps follow the more general approach just described by Francois, then most likely no. > So, do you envision that there are many other SDOs defining their > own admission priorities? yes. we have them in APCO, ITU, and others. > Do you expect that additional information would be added to the > admission priority field itself? yes. as we see in Y.1571 (and H.460.4), other SDOs have priority fields defined along with pre-defined values. but again, I'm leaning to follow Francois's suggestion for 4.10 to "just define the relative semantics ("Higher values represent higher Priority")". >> that's a tough question. we have the merge field in cases where >> the rsvp policy attribute is used for multicast. however, I don't >> see any text describing the application of Diameter to multicast >> in rfc-3588, the current diameter base draft, nor the QoS related >> diameter drafts. without that text or further guidance from the >> Diameter group, I would be reluctant to add a merge field onto the >> attribute of 4.10. > Diameter does not really care too much about the type of traffic. > Diameter is only providing the authorization and accounting > functionality. I cannot tell whether it would make sense to allow > the Diameter client to tell the Diameter server something about QoS > reservation for the multicast traffic by indicating the merge > strategy. Would this be useful for the Diameter server to know > about? Would it make sense for the Diameter server to tell the > Diameter client which type of merge strategy to use? well, we are speaking of receiver driven merges, so the server would be informing a merge point that is acting on behalf of an aggregate of receivers. Perhaps its better to punt on this topic and rely on a separate Diameter draft to deal with multicast flows. -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 14:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUiu-000064-LR; Mon, 15 Oct 2007 14:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUit-00005l-RS for dime@ietf.org; Mon, 15 Oct 2007 14:31:27 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhUin-0005kh-7C for dime@ietf.org; Mon, 15 Oct 2007 14:31:27 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 20:31:01 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS attribute draft & Design Guidelines Date: Mon, 15 Oct 2007 20:31:01 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222D60D@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS attribute draft & Design Guidelines Thread-Index: AcgPOFkIdQ79FwsDQGmI9gP4SErS/QAILtRQ References: <4710DB24.9050803@gmx.net> From: To: , , X-OriginalArrivalTime: 15 Oct 2007 18:31:01.0749 (UTC) FILETIME=[89BDEA50:01C80F59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hmmm.. I think I could be OK removing sections 3 and 7. However, then some more text is definitely needed to explain e.g. the intended use of QoS-Capability AVP.=20 Cheers, Jouni > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 > Sent: Monday, October 15, 2007 5:31 PM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Diameter QoS attribute draft & Design Guidelines >=20 >=20 > Hannes, >=20 > I agree with the proposal to remove the command ABNF from this draft. > This draft should minally provide the attribute definitions=20 > and stress their reusability in ALL applications. I have no=20 > problem with the examples in section 6 as they do a good job=20 > of explaining the semantic rules in section 5. Section 7 can=20 > also be deleted. >=20 > Regards > Mark >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: October 13, 2007 10:50 > > To: dime@ietf.org > > Subject: [Dime] Diameter QoS attribute draft & Design Guidelines > >=20 > > Hi all, > >=20 > > we receive a few review comments that relate to the Diameter Design=20 > > Guidelines draft. There was at least the following=20 > interesting aspect=20 > > that I would like to discuss with the group. > >=20 > > Section 3 of > > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib > utes-02.txt=20 > > essentially indicates (in a verbose fashion) what existing Diameter=20 > > applications may use these Diameter QoS attributes. > >=20 > > There was the question why this is at all needed.=20 > > Essentially, should we > > delete Section 3 from that draft? > >=20 > > In some sense this is a question about extensibility. When=20 > you define=20 > > a new AVP then you might want it to be used in every possible=20 > > application or just in particular application where you=20 > currently see=20 > > a need. In some sense it is not necessary to list these=20 > applications=20 > > since the support for these AVPs is in fact optional.=20 > Hence, nothing=20 > > happens when the Diameter client or the Diameter server does not=20 > > provide support for it. When the client does not include any of the=20 > > defined QoS AVPs then nothing happens at the server. If the client=20 > > includes them and the server does not support them then the server=20 > > will just ignore them and the client will not receive the=20 > > corresponding response. Even the case where the client and=20 > the server=20 > > understand different QoS models is supported. > >=20 > > So, I guess it might be more reasonable to just delete=20 > Section 3 (and=20 > > thereby shorten the draft) and instead provide some=20 > description about=20 > > the different "error" cases. > >=20 > > What do others think about this proposal? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 16:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWm2-0004if-1Q; Mon, 15 Oct 2007 16:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWm0-0004hr-19 for dime@ietf.org; Mon, 15 Oct 2007 16:42:48 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhWlu-0003GB-F9 for dime@ietf.org; Mon, 15 Oct 2007 16:42:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2007 16:42:29 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [Dime] Review of draft-ietf-dime-qos-attributes-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org As requested, here is my review of the QoS Attributes draft (02): Abstract:=20 I think this section should explain why the QoSFilterRule AVP needs extending, i.e. to incorporate support for the QoS parameters defined in . I suggest replacing the list of applications with a more inclusive statement: The ability to convey QoS information using these attributes is available to all new applications and existing applications where permitted by the command ABNF. 1. Introduction Same comment as Abstract: replace the list of applications. I think it would be useful to explain the relationship of this draft to the other QoS drafts (application and parameters) in this section. 3. Commands, AVPs and Advertising Application Support I agree with Hannes and suggest removing this section. This draft is defining AVPs and not a new application. The command ABNF here is confusing. 4.1. QoS-Capability AVP I assume this AVP could also be included in CER/CEA messages. If so it might be worth explaining this and which QoS-Capability takes precedence when it also appears in per-session messages. 4.3. QoS-Resources AVP The QoS-Resources AVP structure seems overly complex to model a set of QoS rules. I would have expected to see a QoS Rule grouped AVP that contains zero or more QoS classifers, a QoS Profile and/or zero or more QoS Params. I'd appreciate an explanation of the scenarios that led to the introduction of the QoS-ID before I propose an alternative (and hopefully simplified) ABNF. 4.4. Extended-QoS-Filter-Rule AVP Typo in first sentence "TheExtended-QoS-Filter-Rule" IMHO, NAS-Traffic-Rule is a relic from days of a flat-attribute space. I'd prefer to see traffic classifiers/filters modeled as grouped AVPs as proposed in 'draft-lior-diameter-classifier-00.txt'.=20 4.5. QoSBlob-Group AVP It's not clear to me why the QoS-ID AVP is needed in this grouped AVP. I also suggest renaming this AVP to something more meaningful than Blob (maybe QoS-Profile-Group?). 4.7. QoS-ObjectType I'm unclear on why this AVP is buried in the QoSBlob-Group. When I look at section 5, this AVP seems to be providing the context for this leg of the QoS exchange and so I'd expect it to appear directly in the QoS-Resources AVP. I found ObjectType too vague and suggest renaming this to the slightly less vague QoS-Context or QoS-Semantics. 4.8. QoSBlob AVP Does a single instance of this AVP contain many QoS params? Again I suggest renaming this to something more meaningful than Blob (maybe QoS-Parameters?). 4.10. QoS-Flow-Direction AVP Is an IANA registry for the flow direction enumerations really necessary? Doesn't Uplink/Downlink/Both basically cover all scenarios? 5. Semantics of QoS Parameters Regarding "QoS-Desired" vs "Minimum-QoS", I assume a server could respond to a "QoS-Desired" request with a QoS profile that is greater or less than that requested. However, it would only respond to a "Minimum-QoS" request with a profile equal or greater than the request. Is that correct? I think this needs more explanation in this section. Typo 'Adminission' in the type/direction/semantic table. 6. Examples 6.3. QoS Authorization It would be useful to include an alternative flow where the Server returns a QoS-Authorized containing a profile that doesn't meet the Desired-QoS in the request and the client rejects the end host (assuming I've correctly understood the semantics). 6.4. Diameter Server Initiated Re-authorization of QoS Typo in figure: "messag". 6.5. Diameter Credit Control with QoS Information Typo in use case description: "Accounitng". 11.1. Normative References Missing reference to QoS Application draft (assuming it gets mentioned in the Introduction as requested). Potentially Missing: I expected AVPs describing a collection of QoS rules to contain some reference to rule precedence. Is this an oversight? Or does the ordering of the QoS-Resources AVPs in the message imply rule precedence?=20 Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 16:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWvT-0001HS-OB; Mon, 15 Oct 2007 16:52:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWvR-00014s-N5 for dime@ietf.org; Mon, 15 Oct 2007 16:52:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhWvG-0000Fz-UQ for dime@ietf.org; Mon, 15 Oct 2007 16:52:23 -0400 Received: (qmail invoked by alias); 15 Oct 2007 20:52:21 -0000 Received: from p5498616C.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.97.108] by mail.gmx.net (mp042) with SMTP; 15 Oct 2007 22:52:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19xYKwJaAZxAGeTOe4JOTVkcS2ny32RbcsPGgk9uf fvulYeaVup7Otq Message-ID: <4713D304.9080709@gmx.net> Date: Mon, 15 Oct 2007 23:52:20 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [Dime] [Preemption] Re: draft-ietf-dime-qos-parameters-01 References: <65A6AD49-F94B-424E-8156-4A153605D801@cisco.com> In-Reply-To: <65A6AD49-F94B-424E-8156-4A153605D801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Francois, Francois Le Faucheur IMAP wrote: > Ken and all, > >> >> Concerning 4.9, leave it as is. As I mentioned privately, our >> emergency-rsvp draft has no concept of defending or preemption >> priority. Rather, we wanted to define a new RSVP policy element that >> only conveyed an admission priority along with another element that >> carried numeric-only representations of the alpha-numeric RPH >> Namespace and RPH Value. >> > > I think section 4.9 is fine as it is. > The emergency-rsvp draft acknowledges the fact that the RSVP signaling > messages may also contain an RFC3181 policy element (containing both a > preemption priority and a defending priority). So this is all fine and > consistent, I believe. > > An alternative approach, for section 4.9, could have been to purely > point to RFC3181 for the semantics and encodings of the preemption and > defending priority field (without reproducing text). The objectives > being to avoid duplication of text which can potentially lead to > inconsistencies (e.g. if RFC3181 was to be updated one day). But the > text as is will make the document much easier to read. I wonder whether this is more a comment towards draft-ietf-dime-qos-parameters-01 or draft-ietf-nsis-qspec-17.txt? I understand that the merging strategy only comes from the multicast use case and hence it would be outside the scope of NSIS and hence it would not be useful to have just a reference from draft-ietf-nsis-qspec-17.txt to emergency-rsvp. The most important question for me is whether the merging strategy would have to be included into the parameter of Section 4.9 and Section 4.10 of draft-ietf-dime-qos-parameters-01. Ciao Hannes > > Francois > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 15 17:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhX9A-0006Gi-7c; Mon, 15 Oct 2007 17:06:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhX97-00068N-8M for dime@ietf.org; Mon, 15 Oct 2007 17:06:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhX8w-0000jj-7k for dime@ietf.org; Mon, 15 Oct 2007 17:06:30 -0400 Received: (qmail invoked by alias); 15 Oct 2007 21:06:28 -0000 Received: from p5498616C.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.97.108] by mail.gmx.net (mp004) with SMTP; 15 Oct 2007 23:06:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX190VIx7Q2F0IF6ke3J7+ngfT1IVwviQMilXx0c5fY zHrXi72FGC6qGw Message-ID: <4713D654.4080703@gmx.net> Date: Tue, 16 Oct 2007 00:06:28 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> In-Reply-To: <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: James Polk , dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Here is a proposal: In Section 4.11 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt we currently have the following RPH Priority parameter: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 10 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPH Namespace | RPH Priority | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If we define a namespace for this parameter then we should define a namespace field for the Admission Priority parameter defined in Section 4.10 as well. Currently, the parameter has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 9 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admis.Priority| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We would change it to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 9 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace | Admis.Priority| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The "Namespace" field would indicate the context of the subsequent Admission Priority values. What do you think about the proposal? Would it make sense to make this change in draft-ietf-nsis-qspec-17.txt and in draft-ietf-tsvwg-emergency-rsvp-03.txt as well? Ciao Hannes ken carlberg wrote: > Hannes, > >>> ok, I wrote something and just deleted it because the term >>> "namespace" can cause some confusion. what I'm suggesting is >>> perhaps an "SDO-space" field because the output of one SDO has >>> pre-defined values. >> It seems that you are really looking at a vendor-specific registry >> that happens to include SDOs as well. >> See http://www.iana.org/assignments/enterprise-numbers > > ouch, no. i think the thread is leading to a level of granular > information that was not my intention. At the worst, I would have > just wanted to distinguish SDOs (and in particular, their priority > related standards) *if* the need exists to do so within the parameter > of 4.10. (more below) > >> The question therefore really is (from a Diameter/RADIUS >> perspective): Do we want to have an attribute that has a generic >> name instead of creating specific variants of it. > > brief answer, yes. > >> The generic name would be "Admission Priority Parameter". When we >> have a generic attribute then we need to differentiate the semantic >> again by introducing a vendor-/SDO specific field. > > only if we have pre-defined values as 4.10 as written now. if we take > out these values and perhaps follow the more general approach just > described by Francois, then most likely no. > > > >> So, do you envision that there are many other SDOs defining their own >> admission priorities? > > yes. we have them in APCO, ITU, and others. > >> Do you expect that additional information would be added to the >> admission priority field itself? > > yes. as we see in Y.1571 (and H.460.4), other SDOs have priority > fields defined along with pre-defined values. but again, I'm leaning > to follow Francois's suggestion for 4.10 to "just define the relative > semantics ("Higher values represent higher Priority")". > > > >>> that's a tough question. we have the merge field in cases where the >>> rsvp policy attribute is used for multicast. however, I don't see >>> any text describing the application of Diameter to multicast in >>> rfc-3588, the current diameter base draft, nor the QoS related >>> diameter drafts. without that text or further guidance from the >>> Diameter group, I would be reluctant to add a merge field onto the >>> attribute of 4.10. >> Diameter does not really care too much about the type of traffic. >> Diameter is only providing the authorization and accounting >> functionality. I cannot tell whether it would make sense to allow the >> Diameter client to tell the Diameter server something about QoS >> reservation for the multicast traffic by indicating the merge >> strategy. Would this be useful for the Diameter server to know about? >> Would it make sense for the Diameter server to tell the Diameter >> client which type of merge strategy to use? > > well, we are speaking of receiver driven merges, so the server would > be informing a merge point that is acting on behalf of an aggregate of > receivers. Perhaps its better to punt on this topic and rely on a > separate Diameter draft to deal with multicast flows. > > -ken > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 03:22:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgkQ-0000P7-3x; Tue, 16 Oct 2007 03:21:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgkO-0000HQ-4r for dime@ietf.org; Tue, 16 Oct 2007 03:21:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhgkD-00081q-P6 for dime@ietf.org; Tue, 16 Oct 2007 03:21:38 -0400 Received: (qmail invoked by alias); 16 Oct 2007 07:21:36 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp031) with SMTP; 16 Oct 2007 09:21:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182jKceX6A28HKBQWBMzvFOvNLiyxSWtshGYtO48V K3S9O6Dkxq9BDG Message-ID: <4714667F.5050205@gmx.net> Date: Tue, 16 Oct 2007 10:21:35 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Review of draft-ietf-dime-qos-attributes-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Mark, thanks a lot for the good and detailed review. Mark Jones wrote: > As requested, here is my review of the QoS Attributes draft (02): > > > Abstract: > > I think this section should explain why the QoSFilterRule AVP needs > extending, i.e. to incorporate support for the QoS parameters defined in > . > Sounds good to me. > I suggest replacing the list of applications with a more inclusive > statement: The ability to convey QoS information using these attributes > is available to all new applications and existing applications where > permitted by the command ABNF. > Fine with me. > 1. Introduction > > Same comment as Abstract: replace the list of applications. > > I think it would be useful to explain the relationship of this draft to > the other QoS drafts (application and parameters) in this section. > > In the discussion with the Diameter QoS application authors we were wondering whether it would make sense to have a sort of framework document. The text for such a framework already exists in the Diameter QoS application document but it would be more visible in a separate document. The document would essentially describe how the different pieces fit together. I thought it is worth thinking about it. > 3. Commands, AVPs and Advertising Application Support > > I agree with Hannes and suggest removing this section. This draft is > defining AVPs and not a new application. The command ABNF here is > confusing. > Thanks for the feedback. > 4.1. QoS-Capability AVP > > I assume this AVP could also be included in CER/CEA messages. If so it > might be worth explaining this and which QoS-Capability takes precedence > when it also appears in per-session messages. > That's a good hint. > 4.3. QoS-Resources AVP > > The QoS-Resources AVP structure seems overly complex to model a set of > QoS rules. I would have expected to see a QoS Rule grouped AVP that > contains zero or more QoS classifers, a QoS Profile and/or zero or more > QoS Params. I'd appreciate an explanation of the scenarios that led to > the introduction of the QoS-ID before I propose an alternative (and > hopefully simplified) ABNF. > You are essentially saying that * you don't like the AVP names * you don't like the QoS-ID AVP Everything else is fine for you. > 4.4. Extended-QoS-Filter-Rule AVP > > Typo in first sentence "TheExtended-QoS-Filter-Rule" > > IMHO, NAS-Traffic-Rule is a relic from days of a flat-attribute space. > I'd prefer to see traffic classifiers/filters modeled as grouped AVPs as > proposed in 'draft-lior-diameter-classifier-00.txt'. > Well. We can progress draft-lior-diameter-classifier-00.txt but if this document has a dependency on it then we will run into a problem since the document will be delayed considerably. We are a bit under pressure here since the 3GPP is waiting for this document. > > 4.5. QoSBlob-Group AVP > > It's not clear to me why the QoS-ID AVP is needed in this grouped AVP. I > also suggest renaming this AVP to something more meaningful than Blob > (maybe QoS-Profile-Group?). > The idea was to use the QoS-ID to associate a QoSBlob-Group to a Extended-QoS-Filter-Rule instance AND if subsequent messages have to be sent then the QoS-ID can refer to a non-changed parameter. An example for the 2nd functionality: Assume you exchange the QoS-Resources AVP at the beginning of the session. Later, when something in the QoS parameter changes but the Extended-QoS-Filter-Rule stay the same you just use the same QoS-ID in the QoSBlob-Group again without repeating the Extended-QoS-Filter-Rule. > 4.7. QoS-ObjectType > > I'm unclear on why this AVP is buried in the QoSBlob-Group. When I look > at section 5, this AVP seems to be providing the context for this leg of > the QoS exchange and so I'd expect it to appear directly in the > QoS-Resources AVP. I found ObjectType too vague and suggest renaming > this to the slightly less vague QoS-Context or QoS-Semantics. > I am fine with the name change. The reason why this AVP is attached to the QoS parameters itself and not placed at a higher layer is that the semantic is indeed attached to a particular QoS parameter itself. A single message may carry more than one QoS parameter with a different QoS type. > 4.10. QoS-Flow-Direction AVP > > Is an IANA registry for the flow direction enumerations really > necessary? Doesn't Uplink/Downlink/Both basically cover all scenarios? > It is not absolutely necessary. We can also omit it. > 5. Semantics of QoS Parameters > > Regarding "QoS-Desired" vs "Minimum-QoS", I assume a server could > respond to a "QoS-Desired" request with a QoS profile that is greater or > less than that requested. However, it would only respond to a > "Minimum-QoS" request with a profile equal or greater than the request. > Is that correct? I think this needs more explanation in this section. > There are two cases here. They would most likely be used independently of each other. Case 1: The Diameter Client asks for QoS authorization When a QoS based on a signaling protocol arrives at a network element then you can either * indicate what you want exactly and when these resources are not available then you fail or * you offer a minimum and the desired values. The minimum represents the lower bound. Now, when the network element forwards this information towards the Diameter server than the policy based admission control engine can exactly apply this policy. Case 2: The Diameter Server provisions the Diameter Client with QoS information Imagine a client attaches to the network and the Diameter Server has a QoS profile stored with the client. The server attaches the QoS profile after a successful network access authentication procedure. Now, instead of just providing a single value for the QoS parameter the Diameter server might again provide a bit more information in case that these resources are not available at the client. He provides a minimum and when the Diameter client is not able to provide that minimum then the session would either be terminated or continued with best effort; depending on the policy. > Typo 'Adminission' in the type/direction/semantic table. > > 6. Examples > > 6.3. QoS Authorization > > It would be useful to include an alternative flow where the Server > returns a QoS-Authorized containing a profile that doesn't meet the > Desired-QoS in the request and the client rejects the end host (assuming > I've correctly understood the semantics). > If the Diameter Server is not able to authorize the requested QoS parameters provided by the Diameter client then it would reject them right away and wouldn't provide information back on how much it would be able to authorize. Hence, the QoS-Authorized wouldn't be sent back to the Diameter client if the request to the Diameter server contained a Desired-QoS AVP that couldn't be fulfilled. > 6.4. Diameter Server Initiated Re-authorization of QoS > > Typo in figure: "messag". > > 6.5. Diameter Credit Control with QoS Information > > Typo in use case description: "Accounitng". > > > 11.1. Normative References > > Missing reference to QoS Application draft (assuming it gets mentioned > in the Introduction as requested). > > We don't have a normative dependency on the Diameter QoS application draft. It is fine to include it into the informative section. > Potentially Missing: > > I expected AVPs describing a collection of QoS rules to contain some > reference to rule precedence. Is this an oversight? Or does the ordering > of the QoS-Resources AVPs in the message imply rule precedence? > The ordering of the rules indicate precedence. If we haven't mentioned that so far then we certainly have to. Ciao Hannes > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 03:58:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhJU-0002N3-Kn; Tue, 16 Oct 2007 03:58:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhFY-0008AO-24 for dime@ietf.org; Tue, 16 Oct 2007 03:54:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IhhFX-0000V1-2u for dime@ietf.org; Tue, 16 Oct 2007 03:53:59 -0400 Received: (qmail invoked by alias); 16 Oct 2007 07:53:58 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 16 Oct 2007 09:53:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Mih0EbSUMqmR8RStrVgbqMia9B08oTuc3ft9U2g DhFMm2pfWl6Bym Message-ID: <47146E15.9090200@gmx.net> Date: Tue, 16 Oct 2007 10:53:57 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roland Bless References: <470202BF.4000701@gmx.net> <47146250.1000504@tm.uka.de> In-Reply-To: <47146250.1000504@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Subject: [Dime] Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Roland, thanks for your review. Please find a few comments below: Roland Bless wrote: > Hi Hannes and all, > > Hannes Tschofenig wrote: > > >> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 >> > > I'm not a AAA expert, so probably I don't get the point. > Unfortunately, I'm not very content with the draft, so I have some major > comments: > 1) The draft says: > "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." > > Since the rest of the draft seems to contain larger copy&paste > regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not > sufficient to use a QSPEC object as it is. To me it makes no sense > to do another format rewriting when creating a Diameter request > (QAR) from an NSIS RESERVE for example. Is there any technical > reason to not use a QSPEC object as it is? This would allow for > an easy interworking between NSIS and AAA and to re-use larger parts > of the RMF code. Conveying the parameters for AAA > in a different way is IMHO not necessary and source for new > implementation errors... > If there are technical reasons why using the QSPEC directly doesn't > work, please state it in the draft. > There are a couple of reasons why we did not want to re-use the QSPEC draft as is. The first reason is that the Diameter QoS attribute document and the Diameter QoS application document, see http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt are independent of NSIS. There is no dependency between NSIS and these documents although the Diameter interworking may also be used for NSIS. The second reason is that the QSPEC draft has a different focus in the sense that the description that is used for the front-end protocol (in this case NSIS) is somewhat different to the interaction that takes place at the backend. If you go through the QSPEC draft then you will notice that many aspects in the draft are so specific to the NSIS interactions. Unfortunately, the QSPEC is not just a collection of parameters. We did not want to let the reader figure out which parts of the document are relevant for them even if they use the Diameter QoS work for a different purpose (such as in the interaction with RSVP). In fact, in previous draft versions we just made references to the QSPEC and when this was brought to other SDOs then this was a real show stopper since people got totally confused. The third reason is that we are changing the format of the QSPEC headers. We tried to keep the changes at a minimum but still they are different. Some time back we even considered to use a Diameter specific format. There are still comments floating around suggesting it but at the moment the plain QoS parameters are still in the format of the QSPEC. We also make use of the registry created for the QoS parameters; some of my recent mails referred to the mismatch between the QSPEC registry and the registry created by a document in the TSVWG. The final reason is that we are changing the semantic of the extensibility mechanism. The concept of QoS models (QoSM) as defined in the QSPEC and the requirements for defining a QoSM does not work with the Diameter usage. Hence, we had to change it. See Section 5 and 6 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt I believe these reasons justify a new document. > 2) The draft doesn't provide a meaningful definition of which parameters > should be present together etc. It is only an unstructured list of > parameter objects and there is no hint given about which combinations > are allowed or meaningful etc. > That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to say anything about it. draft-ietf-dime-diameter-qos-01.txt and draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For example, when someone wants to use the IntServ Controlled-Load Service QoSM http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt and if an interaction with the Diameter backend infrastructure is desired then they would take the respective parameters from the received NSIS message and copy them into a Diameter message. The QoS profile would be set to a value as defined in the IntServ Controlled-Load Service QoSM (note that it has not been done yet). If there are specific issues that need to be said about the backend infrastructure interaction then they may be discussed in the respective QoSM but so far I have not heard about anything. For some other QoSMs, such as RMD, I have never heard that a AAA interaction would be desired. There, the usage model is different. Does this make sense to you? Ciao Hannes > Regards, > Roland > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 04:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhLr-0004R4-92; Tue, 16 Oct 2007 04:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihgys-0000Fe-7K; Tue, 16 Oct 2007 03:36:46 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihgyk-0008E2-Jx; Tue, 16 Oct 2007 03:36:46 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 10:41:36 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 16 Oct 2007 10:41:22 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 10:16:52 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgTW-0000SE-Ae; Tue, 16 Oct 2007 03:04:22 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhgTT-0000Ru-Gr for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 03:04:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgT2-0000Ex-05; Tue, 16 Oct 2007 03:03:52 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhgT1-0007OT-FL; Tue, 16 Oct 2007 03:03:51 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IhgSx-0002FA-Mt; Tue, 16 Oct 2007 09:03:49 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0006Z3-JG; Tue, 16 Oct 2007 09:03:47 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0000as-BL; Tue, 16 Oct 2007 09:03:46 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 922092FC00C; Tue, 16 Oct 2007 09:03:45 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IhgSv-0004xz-7D; Tue, 16 Oct 2007 09:03:45 +0200 Message-ID: <47146250.1000504@tm.uka.de> Date: Tue, 16 Oct 2007 09:03:44 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 References: <470202BF.4000701@gmx.net> In-Reply-To: <470202BF.4000701@gmx.net> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.2 MISSING_HEADERS Missing To: header 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 16 Oct 2007 07:16:56.0921 (UTC) FILETIME=[8928AC90:01C80FC4] X-Spam-Score: 1.6 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Tue, 16 Oct 2007 04:00:22 -0400 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Subject: [Dime] Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes and all, Hannes Tschofenig wrote: > http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 I'm not a AAA expert, so probably I don't get the point. Unfortunately, I'm not very content with the draft, so I have some major comments: 1) The draft says: "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." Since the rest of the draft seems to contain larger copy&paste regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not sufficient to use a QSPEC object as it is. To me it makes no sense to do another format rewriting when creating a Diameter request (QAR) from an NSIS RESERVE for example. Is there any technical reason to not use a QSPEC object as it is? This would allow for an easy interworking between NSIS and AAA and to re-use larger parts of the RMF code. Conveying the parameters for AAA in a different way is IMHO not necessary and source for new implementation errors... If there are technical reasons why using the QSPEC directly doesn't work, please state it in the draft. 2) The draft doesn't provide a meaningful definition of which parameters should be present together etc. It is only an unstructured list of parameter objects and there is no hint given about which combinations are allowed or meaningful etc. Regards, Roland _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 04:00:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhLr-0004Qx-1o; Tue, 16 Oct 2007 04:00:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhgT2-0000Ex-05; Tue, 16 Oct 2007 03:03:52 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhgT1-0007OT-FL; Tue, 16 Oct 2007 03:03:51 -0400 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IhgSx-0002FA-Mt; Tue, 16 Oct 2007 09:03:49 +0200 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0006Z3-JG; Tue, 16 Oct 2007 09:03:47 +0200 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IhgSw-0000as-BL; Tue, 16 Oct 2007 09:03:46 +0200 Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 922092FC00C; Tue, 16 Oct 2007 09:03:45 +0200 (CEST) Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1IhgSv-0004xz-7D; Tue, 16 Oct 2007 09:03:45 +0200 Message-ID: <47146250.1000504@tm.uka.de> Date: Tue, 16 Oct 2007 09:03:44 +0200 From: Roland Bless Organization: Institute of Telematics, University of Karlsruhe User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 References: <470202BF.4000701@gmx.net> In-Reply-To: <470202BF.4000701@gmx.net> X-Enigmail-Version: 0.94.4.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: -1.2 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.2 MISSING_HEADERS Missing To: header 0.0 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 16 Oct 2007 04:00:22 -0400 Cc: dime@ietf.org, 'radext mailing list' , "nsis@ietf.org" , tsvwg IETF list Subject: [Dime] Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes and all, Hannes Tschofenig wrote: > http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 I'm not a AAA expert, so probably I don't get the point. Unfortunately, I'm not very content with the draft, so I have some major comments: 1) The draft says: "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." Since the rest of the draft seems to contain larger copy&paste regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not sufficient to use a QSPEC object as it is. To me it makes no sense to do another format rewriting when creating a Diameter request (QAR) from an NSIS RESERVE for example. Is there any technical reason to not use a QSPEC object as it is? This would allow for an easy interworking between NSIS and AAA and to re-use larger parts of the RMF code. Conveying the parameters for AAA in a different way is IMHO not necessary and source for new implementation errors... If there are technical reasons why using the QSPEC directly doesn't work, please state it in the draft. 2) The draft doesn't provide a meaningful definition of which parameters should be present together etc. It is only an unstructured list of parameter objects and there is no hint given about which combinations are allowed or meaningful etc. Regards, Roland _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 07:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkwK-0001q5-OQ; Tue, 16 Oct 2007 07:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhkwJ-0001pY-4O for dime@ietf.org; Tue, 16 Oct 2007 07:50:23 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhkwC-0008IB-Fo for dime@ietf.org; Tue, 16 Oct 2007 07:50:23 -0400 X-IronPort-AV: E=Sophos;i="4.21,283,1188802800"; d="scan'208";a="406892912" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2007 04:50:04 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9GBo33T007180; Tue, 16 Oct 2007 13:50:03 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9GBngV9020936; Tue, 16 Oct 2007 11:50:03 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 13:49:44 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 13:49:43 +0200 In-Reply-To: <4713D654.4080703@gmx.net> References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Tue, 16 Oct 2007 13:49:39 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Oct 2007 11:49:43.0172 (UTC) FILETIME=[A4346440:01C80FEA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.001 X-TM-AS-Result: No--28.296500-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8739; t=1192535403; x=1193399403; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20draft-ietf-dime-qos-parameters-01 |Sender:=20; bh=tjkak1VLTmAD7eJvsyIfrZvBkHphhaEF6UJH9srm8Xo=; b=d80JSlZW5Z5leu3zlvmd3hCnJJlzFdLdqqOX9SLQeLipF5ABq+nv0v2zMuPksB/9R2KcT59S Aph4DivOP+y5jRNpjtE64ZkDHK+SzHq2NpGqE81LXNf6buXyGeI49s/Y; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: David Oran R , dime@ietf.org, =?ISO-8859-1?Q? =28IJ/ETH=29_Attila_B=E1der ?= , cornelia.kappler@nsn.com, James Polk X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hello Hannes, On 15 Oct 2007, at 23:06, Hannes Tschofenig wrote: > Here is a proposal: > > In Section 4.11 of http://www.ietf.org/internet-drafts/draft-ietf- > dime-qos-parameters-01.txt we currently have the following RPH > Priority parameter: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|r|r|r| 10 |r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | RPH Namespace | RPH Priority | (Reserved) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > If we define a namespace for this parameter then we should define a > namespace field for the Admission Priority parameter defined in > Section 4.10 as well. Not with the QoS signaling model I was picturing. In my mind, we do not want each and every router to have to understand "application level" priority requirements, nor be aware of every SDO's latest decision on whether 3, 4 or 10 levels of priorities is the way to go. To that end, the approach we have been following for rsvp-emergency (and I think is in line with RFC2753 defining "A Framework for Policy-based Admission Control") is the following: * there are a number of fundamental network mechanisms that every router involved in QoS signaling need to understand (i.e. preemption priority, admission priority). To allow routers to enforce those mechanisms, the corresponding information element needs to be included in the QoS signaling. Those contain semantics that are directly understandable by routers (e.g. Preemption Priority 10 is allowed to bump Defending Priority 5). * routers involved in QoS signaling need not understand application level requirements (ie routers do not necessarily know what is DSN's "flash-override-override", or the counterpart in other countries) * Policy Decision Points (typically at the edge of the network as well as at administrative boundaries) understand "application level requirements" and are responsible for mapping those into network mechanisms (i.e. preemption priority, admission priority). * To facilitate the mapping of "application-level" requirements into network mechanisms by PDPs, the application-level requirements (as specified for SIP usage) can be conveyed inside the QoS signaling protocol. However, they are intended to be relayed to PDPs and are not intended to be understood by each and every QoS signaling router. With such a model in mind, the proposal would be: * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an information element containing an "RPH namespace" field and an "RPH priority" field. These fields contain numerical values that are specified in an IANA registry. * dime-qos-parameters, nsis-qspec both define an information element containing a "Admission Priority" field and a "Defending Priority" field. These field contain numerical values whose semantics is in line with RFC3181 (ie "higher values represent higher priority"). * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an information element containing an "RPH namespace" field. This field contains a numerical value whose semantic is "higher values represent higher priority". Does the QoS model described above make sense to you too? What about the corresponding proposal? Cheers Francois PS: I'm keeping the "Merging" question out for now. I think it is worth converging on the high level model first, and I'd like to think more about the Merging. > Currently, the parameter has the following structure: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|r|r|r| 9 |r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Admis.Priority| (Reserved) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > We would change it to: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|r|r|r| 9 |r|r|r|r| 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Namespace | Admis.Priority| (Reserved) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The "Namespace" field would indicate the context of the subsequent > Admission Priority values. > > What do you think about the proposal? > > Would it make sense to make this change in draft-ietf-nsis- > qspec-17.txt and in draft-ietf-tsvwg-emergency-rsvp-03.txt as well? > > Ciao > Hannes > > > > ken carlberg wrote: >> Hannes, >> >>>> ok, I wrote something and just deleted it because the term >>>> "namespace" can cause some confusion. what I'm suggesting is >>>> perhaps an "SDO-space" field because the output of one SDO has >>>> pre-defined values. >>> It seems that you are really looking at a vendor-specific >>> registry that happens to include SDOs as well. >>> See http://www.iana.org/assignments/enterprise-numbers >> >> ouch, no. i think the thread is leading to a level of granular >> information that was not my intention. At the worst, I would have >> just wanted to distinguish SDOs (and in particular, their priority >> related standards) *if* the need exists to do so within the >> parameter of 4.10. (more below) >> >>> The question therefore really is (from a Diameter/RADIUS >>> perspective): Do we want to have an attribute that has a generic >>> name instead of creating specific variants of it. >> >> brief answer, yes. >> >>> The generic name would be "Admission Priority Parameter". When we >>> have a generic attribute then we need to differentiate the >>> semantic again by introducing a vendor-/SDO specific field. >> >> only if we have pre-defined values as 4.10 as written now. if we >> take out these values and perhaps follow the more general approach >> just described by Francois, then most likely no. >> >> >> >>> So, do you envision that there are many other SDOs defining their >>> own admission priorities? >> >> yes. we have them in APCO, ITU, and others. >> >>> Do you expect that additional information would be added to the >>> admission priority field itself? >> >> yes. as we see in Y.1571 (and H.460.4), other SDOs have priority >> fields defined along with pre-defined values. but again, I'm >> leaning to follow Francois's suggestion for 4.10 to "just define >> the relative semantics ("Higher values represent higher Priority")". >> >> >> >>>> that's a tough question. we have the merge field in cases where >>>> the rsvp policy attribute is used for multicast. however, I >>>> don't see any text describing the application of Diameter to >>>> multicast in rfc-3588, the current diameter base draft, nor the >>>> QoS related diameter drafts. without that text or further >>>> guidance from the Diameter group, I would be reluctant to add a >>>> merge field onto the attribute of 4.10. >>> Diameter does not really care too much about the type of traffic. >>> Diameter is only providing the authorization and accounting >>> functionality. I cannot tell whether it would make sense to allow >>> the Diameter client to tell the Diameter server something about >>> QoS reservation for the multicast traffic by indicating the merge >>> strategy. Would this be useful for the Diameter server to know >>> about? Would it make sense for the Diameter server to tell the >>> Diameter client which type of merge strategy to use? >> >> well, we are speaking of receiver driven merges, so the server >> would be informing a merge point that is acting on behalf of an >> aggregate of receivers. Perhaps its better to punt on this topic >> and rely on a separate Diameter draft to deal with multicast flows. >> >> -ken >> >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 09:29:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmTR-0002GW-7h; Tue, 16 Oct 2007 09:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmLw-0006Cl-1K; Tue, 16 Oct 2007 09:20:56 -0400 Received: from mta2.dhs.gov ([152.121.181.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhmLl-0003Fl-9R; Tue, 16 Oct 2007 09:20:53 -0400 Received: from dhsmail3.dhs.gov (dhsmail3.dhs.gov [161.214.63.41]) by mta2.dhs.gov with ESMTP; Tue, 16 Oct 2007 09:20:24 -0400 Received: from dhsmail3.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3619722F7; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0351.DHSNET.DS1.DHS (mx7.hq.dhs.gov [161.214.98.195]) by dhsmail3.dhs.gov (Postfix) with ESMTP id 2B6FC2145; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.15.18.80]) by ZAU1UG-0351.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 09:20:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Oct 2007 09:20:35 -0400 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 Thread-Index: AcgEz4SaZT+XWIPvRx6Rtb+XW3YE5gLJjEI8 References: <470202BF.4000701@gmx.net> From: "Nguyen, An P" To: "Hannes Tschofenig" , , "radext mailing list" , , "tsvwg IETF list" X-OriginalArrivalTime: 16 Oct 2007 13:20:35.0762 (UTC) FILETIME=[56339920:01C80FF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Tue, 16 Oct 2007 09:28:40 -0400 Cc: Subject: [Dime] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, Just a comment on a reference in Sect 4.10 - Admission Priority = Parameter: Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y.2171 ( = Admission Control Priority Levels in Next Generation Networks, Sept = 2006) to reflect the NGN work. I think you should add Y.2171 to Sect 9.2 - Informative References as = well. Regards, An =20 -----Original Message----- From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 10/2/2007 4:35 AM To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 =20 Hi all, this message marks the issuance of a working group last call (WGLC) on=20 DIME's Internet Draft entitled "Quality of Service Parameters for Usage=20 with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may=20 view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the=20 authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 09:44:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmig-0000AT-LK; Tue, 16 Oct 2007 09:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihmif-00009l-4l for dime@ietf.org; Tue, 16 Oct 2007 09:44:25 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IhmiY-0004GS-Iu for dime@ietf.org; Tue, 16 Oct 2007 09:44:25 -0400 Received: (qmail invoked by alias); 16 Oct 2007 13:44:07 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp030) with SMTP; 16 Oct 2007 15:44:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/XkLY4cqfXeP89Arz4SyF2vuD210a1mqgb6OhCqb nIgWM5pbcXraeO Message-ID: <4714C026.9050008@gmx.net> Date: Tue, 16 Oct 2007 16:44:06 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: David Oran R , dime@ietf.org, =?ISO-8859-1?Q?=22=28IJ/ETH=29_Attila_B=E1der=22?= , cornelia.kappler@nsn.com, James Polk X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Francois, thanks for your response. Please find my comment below: Francois Le Faucheur IMAP wrote: > Hello Hannes, > > On 15 Oct 2007, at 23:06, Hannes Tschofenig wrote: > >> Here is a proposal: >> >> In Section 4.11 of >> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt >> we currently have the following RPH Priority parameter: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M|r|r|r| 10 |r|r|r|r| 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | RPH Namespace | RPH Priority | (Reserved) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> If we define a namespace for this parameter then we should define a >> namespace field for the Admission Priority parameter defined in >> Section 4.10 as well. > > Not with the QoS signaling model I was picturing. > > In my mind, we do not want each and every router to have to understand > "application level" priority requirements, nor be aware of every SDO's > latest decision on whether 3, 4 or 10 levels of priorities is the way > to go. To that end, the approach we have been following for > rsvp-emergency (and I think is in line with RFC2753 defining "A > Framework for Policy-based Admission Control") is the following: > * there are a number of fundamental network mechanisms that every > router involved in QoS signaling need to understand (i.e. preemption > priority, admission priority). To allow routers to enforce those > mechanisms, the corresponding information element needs to be included > in the QoS signaling. Those contain semantics that are directly > understandable by routers (e.g. Preemption Priority 10 is allowed to > bump Defending Priority 5). > * routers involved in QoS signaling need not understand > application level requirements (ie routers do not necessarily know > what is DSN's "flash-override-override", or the counterpart in other > countries) > * Policy Decision Points (typically at the edge of the network as > well as at administrative boundaries) understand "application level > requirements" and are responsible for mapping those into network > mechanisms (i.e. preemption priority, admission priority). > * To facilitate the mapping of "application-level" requirements > into network mechanisms by PDPs, the application-level requirements > (as specified for SIP usage) can be conveyed inside the QoS signaling > protocol. However, they are intended to be relayed to PDPs and are not > intended to be understood by each and every QoS signaling router. > I think the usage of the term "application-level" requirements and non-application level requirements is quite confusing unless you speak about codecs in the context of the application layer (which nobody does so far). Hence, the entire question finally comes down to the issue of what do you assume a router to understand and what would other entities (such as Diameter proxies and Diameter servers) understand. You are essentially saying that the router should only support the functionality described in * RFC 3181, and * Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt If I understand you correctly then the text in Section 3.2 that lists the functionality of RFC 4412 (e.g., "dsn.flash-override") is just passed inside RSVP to be then forwarded towards the backend infrastructure. Then, it is interpreted there and translated to something the router understands (namely the functionality listed in the bullet list above). Finally, it is sent back to the router in a different form, namely the values of dsn.flash-override, etc. (which are just constants for priority values) are mapped into the priority values described in Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt. > With such a model in mind, the proposal would be: > > * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an > information element containing an "RPH namespace" field and an "RPH > priority" field. These fields contain numerical values that are > specified in an IANA registry. That's fine. The parameter is there already but there is just the mismatch between draft-ietf-tsvwg-emergency-rsvp and draft-ietf-nsis-qspec. > > * dime-qos-parameters, nsis-qspec both define an information > element containing a "Admission Priority" field and a "Defending > Priority" field. These field contain numerical values whose semantics > is in line with RFC3181 (ie "higher values represent higher priority"). Draft-ietf-nsis-qspec and draft-ietf-dime-qos-parameters-01 have a field for Admission Priority but it is focused on the Y.1571 defined values only. draft-ietf-tsvwg-emergency-rsvp does not define a stand-alone "Defending Priority" field either. The "Defending Priority" field is only defined via Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. I think this requirement calls only for http://gim.org.pl/rfcs/rfc3181.html functionality. With this document, however, the "Definding Priority" is only used in context of the Preemption Priority. > > * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an > information element containing an "RPH namespace" field. This field > contains a numerical value whose semantic is "higher values represent > higher priority". > I believe that this is incorrect. There is no order imposed on the namespace field. > Does the QoS model described above make sense to you too? I still have to understand a few things better.... > What about the corresponding proposal? > Seen from a higher layer we are essentially dealing with an issue of extensibility here. In your model you assume that the router only understands a certain set of QoS profiles (namely one where the parameters of RFC X and Y) are understood. That's fine. You would like to foward parameters that aren't understood to the backend infrastructure in order to get them translated to something you understand. That's fine. Within the Diameter QoS attribute document we allow the Diameter client to tell the Diameter server what it understands. The level of understanding may, however, vary. I believe that there are two cases: * The Diameter client receives a request from a QoS signaling protocol, such as RSVP. A message may contain objects where the Diameter client knows how todo the encapsulation but it realizes that the Resource Management function cannot deal with them. To have a specific example: Let's assume some SDO defines new priority elements and registers them. The Diameter QoS client (or the RMF) does not know how to interpret the specific priority values but it understands the object as such -- it understands that this is a priority parameter. * The second case is where the Diameter client obtains something from the QoS signaling protocol that it does not understand at all. This case is not covered and if we would like to support your model (in case I understood it correctly) then this means that we have to dump the received information into a container and forward it along with the other information to the Diameter server. The Diameter server would then try to understand it. Do I correctly capture the problem? Ciao Hannes > Cheers > > Francois > > > PS: I'm keeping the "Merging" question out for now. I think it is > worth converging on the high level model first, and I'd like to think > more about the Merging. > > > > >> Currently, the parameter has the following structure: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M|r|r|r| 9 |r|r|r|r| 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Admis.Priority| (Reserved) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> We would change it to: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |M|r|r|r| 9 |r|r|r|r| 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Namespace | Admis.Priority| (Reserved) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> The "Namespace" field would indicate the context of the subsequent >> Admission Priority values. >> >> What do you think about the proposal? >> >> Would it make sense to make this change in >> draft-ietf-nsis-qspec-17.txt and in >> draft-ietf-tsvwg-emergency-rsvp-03.txt as well? >> >> Ciao >> Hannes >> >> >> >> ken carlberg wrote: >>> Hannes, >>> >>>>> ok, I wrote something and just deleted it because the term >>>>> "namespace" can cause some confusion. what I'm suggesting is >>>>> perhaps an "SDO-space" field because the output of one SDO has >>>>> pre-defined values. >>>> It seems that you are really looking at a vendor-specific registry >>>> that happens to include SDOs as well. >>>> See http://www.iana.org/assignments/enterprise-numbers >>> >>> ouch, no. i think the thread is leading to a level of granular >>> information that was not my intention. At the worst, I would have >>> just wanted to distinguish SDOs (and in particular, their priority >>> related standards) *if* the need exists to do so within the >>> parameter of 4.10. (more below) >>> >>>> The question therefore really is (from a Diameter/RADIUS >>>> perspective): Do we want to have an attribute that has a generic >>>> name instead of creating specific variants of it. >>> >>> brief answer, yes. >>> >>>> The generic name would be "Admission Priority Parameter". When we >>>> have a generic attribute then we need to differentiate the semantic >>>> again by introducing a vendor-/SDO specific field. >>> >>> only if we have pre-defined values as 4.10 as written now. if we >>> take out these values and perhaps follow the more general approach >>> just described by Francois, then most likely no. >>> >>> >>> >>>> So, do you envision that there are many other SDOs defining their >>>> own admission priorities? >>> >>> yes. we have them in APCO, ITU, and others. >>> >>>> Do you expect that additional information would be added to the >>>> admission priority field itself? >>> >>> yes. as we see in Y.1571 (and H.460.4), other SDOs have priority >>> fields defined along with pre-defined values. but again, I'm >>> leaning to follow Francois's suggestion for 4.10 to "just define the >>> relative semantics ("Higher values represent higher Priority")". >>> >>> >>> >>>>> that's a tough question. we have the merge field in cases where >>>>> the rsvp policy attribute is used for multicast. however, I don't >>>>> see any text describing the application of Diameter to multicast >>>>> in rfc-3588, the current diameter base draft, nor the QoS related >>>>> diameter drafts. without that text or further guidance from the >>>>> Diameter group, I would be reluctant to add a merge field onto the >>>>> attribute of 4.10. >>>> Diameter does not really care too much about the type of traffic. >>>> Diameter is only providing the authorization and accounting >>>> functionality. I cannot tell whether it would make sense to allow >>>> the Diameter client to tell the Diameter server something about QoS >>>> reservation for the multicast traffic by indicating the merge >>>> strategy. Would this be useful for the Diameter server to know >>>> about? Would it make sense for the Diameter server to tell the >>>> Diameter client which type of merge strategy to use? >>> >>> well, we are speaking of receiver driven merges, so the server would >>> be informing a merge point that is acting on behalf of an aggregate >>> of receivers. Perhaps its better to punt on this topic and rely on >>> a separate Diameter draft to deal with multicast flows. >>> >>> -ken >>> >>> >>> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 10:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnSj-0000Az-JF; Tue, 16 Oct 2007 10:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihn2p-0002Az-5A; Tue, 16 Oct 2007 10:05:15 -0400 Received: from ccsmtpgate.mu.edu.tr ([194.27.32.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihn2g-0005Uq-72; Tue, 16 Oct 2007 10:05:15 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 17:11:15 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 16 Oct 2007 17:11:07 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 16:30:52 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmM0-0006Gq-6b; Tue, 16 Oct 2007 09:21:00 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IhmLy-0006FV-LU for nsis-confirm+ok@megatron.ietf.org; Tue, 16 Oct 2007 09:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmLw-0006Cl-1K; Tue, 16 Oct 2007 09:20:56 -0400 Received: from mta2.dhs.gov ([152.121.181.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhmLl-0003Fl-9R; Tue, 16 Oct 2007 09:20:53 -0400 Received: from dhsmail3.dhs.gov (dhsmail3.dhs.gov [161.214.63.41]) by mta2.dhs.gov with ESMTP; Tue, 16 Oct 2007 09:20:24 -0400 Received: from dhsmail3.dhs.gov (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3619722F7; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0351.DHSNET.DS1.DHS (mx7.hq.dhs.gov [161.214.98.195]) by dhsmail3.dhs.gov (Postfix) with ESMTP id 2B6FC2145; Tue, 16 Oct 2007 09:20:23 -0400 (EDT) Received: from ZAU1UG-0308.DHSNET.DS1.DHS ([10.15.18.80]) by ZAU1UG-0351.DHSNET.DS1.DHS with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 09:20:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Oct 2007 09:20:35 -0400 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 Thread-Index: AcgEz4SaZT+XWIPvRx6Rtb+XW3YE5gLJjEI8 References: <470202BF.4000701@gmx.net> From: "Nguyen, An P" To: "Hannes Tschofenig" , , "radext mailing list" , , "tsvwg IETF list" X-OriginalArrivalTime: 16 Oct 2007 13:20:35.0762 (UTC) FILETIME=[56339920:01C80FF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Tue, 16 Oct 2007 10:32:00 -0400 Cc: Subject: [Dime] [NSIS] RE: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 X-BeenThere: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, Just a comment on a reference in Sect 4.10 - Admission Priority = Parameter: Change the Y.1571 to Y.2171. The ITU SG-13 changed Y.1571 to Y.2171 ( = Admission Control Priority Levels in Next Generation Networks, Sept = 2006) to reflect the NGN work. I think you should add Y.2171 to Sect 9.2 - Informative References as = well. Regards, An =20 -----Original Message----- From: tsvwg-bounces@ietf.org on behalf of Hannes Tschofenig Sent: Tue 10/2/2007 4:35 AM To: dime@ietf.org; 'radext mailing list'; nsis@ietf.org; tsvwg IETF list Subject: [Tsvwg] WGLC for draft-ietf-dime-qos-parameters-01 =20 Hi all, this message marks the issuance of a working group last call (WGLC) on=20 DIME's Internet Draft entitled "Quality of Service Parameters for Usage=20 with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may=20 view this document at http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01 Please post comments and questions to the DIME mailing list (or to the=20 authors) no later than 16 October 2007. Ciao Hannes & Dave _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 10:46:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihng5-0008VI-UI; Tue, 16 Oct 2007 10:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihng4-0008Pl-Dw for dime@ietf.org; Tue, 16 Oct 2007 10:45:48 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihnfy-0006zf-92 for dime@ietf.org; Tue, 16 Oct 2007 10:45:48 -0400 Received: from [192.168.1.2] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (alnrmhc16) with SMTP id <20071016144525b1600mfjtke>; Tue, 16 Oct 2007 14:45:26 +0000 In-Reply-To: <4714C026.9050008@gmx.net> References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> <4714C026.9050008@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <274F4BD9-AF40-423B-B0C3-1A6997C44A40@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Tue, 16 Oct 2007 10:45:24 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: David Oran R , dime@ietf.org, =?ISO-8859-1?Q? =28IJ/ETH=29_Attila_B=E1der ?= , cornelia.kappler@nsn.com, James Polk X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, >> * dime-qos-parameters, nsis-qspec and rsvp-emergency all >> define an information element containing an "RPH namespace" field. >> This field contains a numerical value whose semantic is "higher >> values represent higher priority". >> > I believe that this is incorrect. There is no order imposed on the > namespace field. correct. Unless I misunderstood the point Francois was trying to make, the values in the RPH Namespace field only act as registered identifiers and have no sense of priority associated with them. Its the corresponding RPH Priority field associated with the RPH Namespace field that contains ordered values and that would be of the semantic "higher values represent higher priority". > Seen from a higher layer we are essentially dealing with an issue > of extensibility here. In your model you assume that the router > only understands a certain set of QoS profiles (namely one where > the parameters of RFC X and Y) are understood. That's fine. You > would like to foward parameters that aren't understood to the > backend infrastructure in order to get them translated to something > you understand. That's fine. Within the Diameter QoS attribute > document we allow the Diameter client to tell the Diameter server > what it understands. The level of understanding may, however, vary. > I believe that there are two cases: > * The Diameter client receives a request from a QoS signaling > protocol, such as RSVP. A message may contain objects where the > Diameter client knows how todo the encapsulation but it realizes > that the Resource Management function cannot deal with them. To > have a specific example: Let's assume some SDO defines new priority > elements and registers them. The Diameter QoS client (or the RMF) > does not know how to interpret the specific priority values but it > understands the object as such -- it understands that this is a > priority parameter. > * The second case is where the Diameter client obtains something > from the QoS signaling protocol that it does not understand at all. > This case is not covered and if we would like to support your model > (in case I understood it correctly) then this means that we have to > dump the received information into a container and forward it along > with the other information to the Diameter server. The Diameter > server would then try to understand it. > > Do I correctly capture the problem? At first glance, the above examples seem reasonable, although I personally wouldn't view them as the baseline reason (ie, not understanding certain parameters) for having network layer Admission Priority and upper layer RPH Namespace and RPH Priority values (but I'll let Francois give a more definitive response). A third scenario that I think is more likely to occur is that a PDP receives two ingress signaled messages with Admission Priority values (ie, policy elements), and each having been derived from different RPH Namespace.Priority tuples. The PDP would have a local policy that *may* rank one RPH Namespace.Priority tuple higher than another. By including the upper layer information in the RSVP message as another policy element, the PDP can then make a more informed decision about the network layer Admission Priority values. Now if this triggers the question of why don't we go back to your original suggestion of embedding the RPH info into the Admission Priority policy elements, then I would add to what Francois said earlier and say that we don't do this in order to maintain flexibility. At this point in time, we recognize the RPH values as *one* candidate for upper layer information. Later on, there may be others, at which point we simply define a new policy element to convey that information with no change made to the Admission Priority element. -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 16 10:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnpW-0006U5-FS; Tue, 16 Oct 2007 10:55:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnpU-0006Th-QI for dime@ietf.org; Tue, 16 Oct 2007 10:55:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhnpS-0006XR-T0 for dime@ietf.org; Tue, 16 Oct 2007 10:55:32 -0400 X-IronPort-AV: E=Sophos;i="4.21,284,1188770400"; d="scan'208";a="155882045" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2007 16:55:18 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9GEtHb7016098; Tue, 16 Oct 2007 16:55:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9GEtCUl007275; Tue, 16 Oct 2007 14:55:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 16:54:42 +0200 Received: from [144.254.53.188] ([144.254.53.188]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Oct 2007 16:54:41 +0200 In-Reply-To: <4714C026.9050008@gmx.net> References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> <4714C026.9050008@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 Date: Tue, 16 Oct 2007 16:54:37 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Oct 2007 14:54:41.0840 (UTC) FILETIME=[7B86BB00:01C81004] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15486.001 X-TM-AS-Result: No--28.675000-8.000000-2 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16218; t=1192546517; x=1193410517; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[Dime]=20draft-ietf-dime-qos-parameters-01 |Sender:=20; bh=Skcch2AGdt2X4vJwvU/pnuwzgHJDf+lnyRm5KnbRJh8=; b=ZyKk2TPBwbYmSQOzeG5HUgmxcv3XzvH0MUB7FwTnlEZLiQsgus77XhHvY8edK1n3z1suCj0P W7h5pGqRqYh2rcj5g7F0diic066G5Af7bWVkyhePglEkEJDbgiwiYJki; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 Cc: David Oran R , dime@ietf.org, =?ISO-8859-1?Q? =28IJ/ETH=29_Attila_B=E1der ?= , cornelia.kappler@nsn.com, James Polk X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, On 16 Oct 2007, at 15:44, Hannes Tschofenig wrote: > Hi Francois, > > thanks for your response. Please find my comment below: > > Francois Le Faucheur IMAP wrote: >> Hello Hannes, >> >> On 15 Oct 2007, at 23:06, Hannes Tschofenig wrote: >> >>> Here is a proposal: >>> >>> In Section 4.11 of http://www.ietf.org/internet-drafts/draft-ietf- >>> dime-qos-parameters-01.txt we currently have the following RPH >>> Priority parameter: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>> 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> |M|r|r|r| 10 |r|r|r|r| >>> 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> | RPH Namespace | RPH Priority | >>> (Reserved) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> >>> >>> If we define a namespace for this parameter then we should define >>> a namespace field for the Admission Priority parameter defined in >>> Section 4.10 as well. >> >> Not with the QoS signaling model I was picturing. >> >> In my mind, we do not want each and every router to have to >> understand "application level" priority requirements, nor be aware >> of every SDO's latest decision on whether 3, 4 or 10 levels of >> priorities is the way to go. To that end, the approach we have >> been following for rsvp-emergency (and I think is in line with >> RFC2753 defining "A Framework for Policy-based Admission Control") >> is the following: >> * there are a number of fundamental network mechanisms that >> every router involved in QoS signaling need to understand (i.e. >> preemption priority, admission priority). To allow routers to >> enforce those mechanisms, the corresponding information element >> needs to be included in the QoS signaling. Those contain semantics >> that are directly understandable by routers (e.g. Preemption >> Priority 10 is allowed to bump Defending Priority 5). >> * routers involved in QoS signaling need not understand >> application level requirements (ie routers do not necessarily know >> what is DSN's "flash-override-override", or the counterpart in >> other countries) >> * Policy Decision Points (typically at the edge of the network >> as well as at administrative boundaries) understand "application >> level requirements" and are responsible for mapping those into >> network mechanisms (i.e. preemption priority, admission priority). >> * To facilitate the mapping of "application-level" >> requirements into network mechanisms by PDPs, the application- >> level requirements (as specified for SIP usage) can be conveyed >> inside the QoS signaling protocol. However, they are intended to >> be relayed to PDPs and are not intended to be understood by each >> and every QoS signaling router. >> > > I think the usage of the term "application-level" requirements and > non-application level requirements is quite confusing unless you > speak about codecs in the context of the application layer (which > nobody does so far). By "application-level" requirements I mean something along the lines of the "Resource Priority" discussed in RFC4412. Something along the lines of: * "this call is being established by a Senior Vice President and is therefore more important than mine" or * "this call is being established by a 4-star general and is therefore more important than Hannes's call'" or * "this call is being established by a Fire Brigade captain" The point is we probably don't want routers to have to be aware of how to handle a call form a VP, a 4-star general or a Fire-Brigade captain. > > Hence, the entire question finally comes down to the issue of what > do you assume a router to understand and what would other entities > (such as Diameter proxies and Diameter servers) understand. > > You are essentially saying that the router should only support the > functionality described in > * RFC 3181, and > * Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf- > tsvwg-emergency-rsvp-03.txt Right. > > If I understand you correctly then the text in Section 3.2 that > lists the functionality of RFC 4412 (e.g., "dsn.flash-override") is > just passed inside RSVP to be then forwarded towards the backend > infrastructure. Then, it is interpreted there and translated to > something the router understands (namely the functionality listed > in the bullet list above). Right. > Finally, it is sent back to the router in a different form, namely > the values of dsn.flash-override, etc. (which are just constants > for priority values) are mapped into the priority values described > in Section 3.1 of http://www.ietf.org/internet-drafts/draft-ietf- > tsvwg-emergency-rsvp-03.txt. ... and or into RFC3181. For example: * RPHnamespace1/RPHpriority1 may get mapped into RFC3181 mechanism (ie a Preemption priority + Defending priority) * RPHnamespace2/RPHpriority2 may get mapped into rsvp-emergency section 3.1 mechanism (ie an Admission priority) * RPHnamespace3/RPHpriority3 may get mapped into RFC3181 mechanism (ie a Preemption priority + Defending priority) and an rsvp-emergency section 3.1 mechanism (ie an Admission priority). > >> With such a model in mind, the proposal would be: >> >> * dime-qos-parameters, nsis-qspec and rsvp-emergency all >> define an information element containing an "RPH namespace" field >> and an "RPH priority" field. These fields contain numerical values >> that are specified in an IANA registry. > That's fine. The parameter is there already but there is just the > mismatch between draft-ietf-tsvwg-emergency-rsvp and draft-ietf- > nsis-qspec. > >> >> * dime-qos-parameters, nsis-qspec both define an information >> element containing a "Admission Priority" field and a "Defending >> Priority" field. These field contain numerical values whose >> semantics is in line with RFC3181 (ie "higher values represent >> higher priority"). > Draft-ietf-nsis-qspec and draft-ietf-dime-qos-parameters-01 have a > field for Admission Priority but it is focused on the Y.1571 > defined values only. > draft-ietf-tsvwg-emergency-rsvp does not define a stand-alone > "Defending Priority" field either. My text above contained a very unfortunate typo (Sorry!). It was meant to read : * dime-qos-parameters, nsis-qspec both define an information element containing a "Preemption Priority" field and a "Defending Priority" field. These field contain numerical values whose semantics is in line with RFC3181 (ie "higher values represent higher priority"). > >> >> * dime-qos-parameters, nsis-qspec and rsvp-emergency all >> define an information element containing an "RPH namespace" field. >> This field contains a numerical value whose semantic is "higher >> values represent higher priority". My text above contained a another very unfortunate typo (I can't believe this. Sorry!). It was meant to read : * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an information element containing an "Admission Priority" field. This field contains a numerical value whose semantic is "higher values represent higher priority". Does this make sense now? > >> Does the QoS model described above make sense to you too? > I still have to understand a few things better... >> What about the corresponding proposal? Hope the proposal without typos makes more sense. >> > Seen from a higher layer we are essentially dealing with an issue > of extensibility here. In your model you assume that the router > only understands a certain set of QoS profiles (namely one where > the parameters of RFC X and Y) are understood. right. > That's fine. You would like to foward parameters that aren't > understood to the backend infrastructure in order to get them > translated to something you understand. right. > That's fine. Within the Diameter QoS attribute document we allow > the Diameter client to tell the Diameter server what it understands. > The level of understanding may, however, vary. I believe that there > are two cases: > * The Diameter client receives a request from a QoS signaling > protocol, such as RSVP. A message may contain objects where the > Diameter client knows how todo the encapsulation but it realizes > that the Resource Management function cannot deal with them. To > have a specific example: Let's assume some SDO defines new priority > elements and registers them. The Diameter QoS client (or the RMF) > does not know how to interpret the specific priority values but it > understands the object as such -- it understands that this is a > priority parameter. We want to consider two cases: -A- the SDO defines some network CAC handling that cannot be supported using the existing NSIS/RSVP mechanisms (ie Preemption Priority & Defending Priority, Admission Priority). Then IETF would have to specify a new additional mechanism and NSIS/RSVP signaling extensions for the corresponding new network mechanism. So far, all discussions about emergency and military handling concluded that we can support all the identified requirements with the above mechanisms. -B- the SDO defines a particular mapping like "in my environments I need 3 levels of preemption priorities and 2 levels of admission priority and here's how my calls get mapped on those...". Then I would hope that this has no impact on NSIS, RSVP or Diameter. The case brought up by An is interesting. the fact that ITU changed from Y.1571 to Y.2171 (or something else tomorrow) should not affect Diameter, NSIS or RSVP, should it? Cheers Francois PS: apologies again for the confusion created by the earlier typos. > * The second case is where the Diameter client obtains something > from the QoS signaling protocol that it does not understand at all. > This case is not covered and if we would like to support your model > (in case I understood it correctly) then this means that we have to > dump the received information into a container and forward it along > with the other information to the Diameter server. The Diameter > server would then try to understand it. > > Do I correctly capture the problem? > > Ciao > Hannes >> Cheers >> >> Francois >> >> >> PS: I'm keeping the "Merging" question out for now. I think it is >> worth converging on the high level model first, and I'd like to >> think more about the Merging. >> >> >> >> >>> Currently, the parameter has the following structure: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>> 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> |M|r|r|r| 9 |r|r|r|r| >>> 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> | Admis.Priority| >>> (Reserved) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> >>> We would change it to: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >>> 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> |M|r|r|r| 9 |r|r|r|r| >>> 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> | Namespace | Admis.Priority| >>> (Reserved) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >>> +-+-+ >>> >>> The "Namespace" field would indicate the context of the >>> subsequent Admission Priority values. >>> >>> What do you think about the proposal? >>> >>> Would it make sense to make this change in draft-ietf-nsis- >>> qspec-17.txt and in draft-ietf-tsvwg-emergency-rsvp-03.txt as well? >>> >>> Ciao >>> Hannes >>> >>> >>> >>> ken carlberg wrote: >>>> Hannes, >>>> >>>>>> ok, I wrote something and just deleted it because the term >>>>>> "namespace" can cause some confusion. what I'm suggesting is >>>>>> perhaps an "SDO-space" field because the output of one SDO has >>>>>> pre-defined values. >>>>> It seems that you are really looking at a vendor-specific >>>>> registry that happens to include SDOs as well. >>>>> See http://www.iana.org/assignments/enterprise-numbers >>>> >>>> ouch, no. i think the thread is leading to a level of granular >>>> information that was not my intention. At the worst, I would >>>> have just wanted to distinguish SDOs (and in particular, their >>>> priority related standards) *if* the need exists to do so within >>>> the parameter of 4.10. (more below) >>>> >>>>> The question therefore really is (from a Diameter/RADIUS >>>>> perspective): Do we want to have an attribute that has a >>>>> generic name instead of creating specific variants of it. >>>> >>>> brief answer, yes. >>>> >>>>> The generic name would be "Admission Priority Parameter". When >>>>> we have a generic attribute then we need to differentiate the >>>>> semantic again by introducing a vendor-/SDO specific field. >>>> >>>> only if we have pre-defined values as 4.10 as written now. if >>>> we take out these values and perhaps follow the more general >>>> approach just described by Francois, then most likely no. >>>> >>>> >>>> >>>>> So, do you envision that there are many other SDOs defining >>>>> their own admission priorities? >>>> >>>> yes. we have them in APCO, ITU, and others. >>>> >>>>> Do you expect that additional information would be added to the >>>>> admission priority field itself? >>>> >>>> yes. as we see in Y.1571 (and H.460.4), other SDOs have >>>> priority fields defined along with pre-defined values. but >>>> again, I'm leaning to follow Francois's suggestion for 4.10 to >>>> "just define the relative semantics ("Higher values represent >>>> higher Priority")". >>>> >>>> >>>> >>>>>> that's a tough question. we have the merge field in cases >>>>>> where the rsvp policy attribute is used for multicast. >>>>>> however, I don't see any text describing the application of >>>>>> Diameter to multicast in rfc-3588, the current diameter base >>>>>> draft, nor the QoS related diameter drafts. without that text >>>>>> or further guidance from the Diameter group, I would be >>>>>> reluctant to add a merge field onto the attribute of 4.10. >>>>> Diameter does not really care too much about the type of >>>>> traffic. Diameter is only providing the authorization and >>>>> accounting functionality. I cannot tell whether it would make >>>>> sense to allow the Diameter client to tell the Diameter server >>>>> something about QoS reservation for the multicast traffic by >>>>> indicating the merge strategy. Would this be useful for the >>>>> Diameter server to know about? Would it make sense for the >>>>> Diameter server to tell the Diameter client which type of merge >>>>> strategy to use? >>>> >>>> well, we are speaking of receiver driven merges, so the server >>>> would be informing a merge point that is acting on behalf of an >>>> aggregate of receivers. Perhaps its better to punt on this >>>> topic and rely on a separate Diameter draft to deal with >>>> multicast flows. >>>> >>>> -ken >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 18 03:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiPbU-0008VQ-4l; Thu, 18 Oct 2007 03:15:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiPbS-0008T7-HS for dime@ietf.org; Thu, 18 Oct 2007 03:15:34 -0400 Received: from jaguar.aricent.com ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiPbH-0004om-WF for dime@ietf.org; Thu, 18 Oct 2007 03:15:31 -0400 Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id l9I76dlD005213 for ; Thu, 18 Oct 2007 12:36:41 +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 l9I76aul005187; Thu, 18 Oct 2007 12:36:36 +0530 In-Reply-To: <470E65A8.5000802@tari.toshiba.com> To: Victor Fajardo Subject: Re: [Dime] Conflict with grouped & mandatory AVPs. MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Himanshu Bahl Date: Thu, 18 Oct 2007 12:44:55 +0530 X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 18/10/2007 12:49:35 PM, Serialize complete at 18/10/2007 12:49:35 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: dime@ietf.org, Dan Warren , Philip Crocker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0706515823==" Errors-To: dime-bounces@ietf.org This is a multipart message in MIME format. --===============0706515823== Content-Type: multipart/alternative; boundary="=_alternative 0027D22665257378_=" This is a multipart message in MIME format. --=_alternative 0027D22665257378_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20All,=0D=0AI=20have=20been=20following=20this=20discussion=20and=20be= lieve=20the=20situation=20of=20=0D=0AQoS-Capability=20AVP=20depicted=20be= low=20is=20a=20good=20example=20hence=20we=20should=20allow=20=0D=0Aouter= =20AVP=20as=20optional=20while=20inner(nested)=20AVPs=20can=20be=20mandat= ory=20(=20i.e=20with=20=0D=0AM=20bit=20set).=20=0D=0AWhat=20has=20been=20= the=20final=20accord=20on=20the=20issue=20?=0D=0A=0D=0AThanks,=0D=0AHiman= shu=0D=0AA=20R=20I=20C=20E=20N=20T=0D=0A=0D=0A?That's=20the=20spirit=20-= =20one=20part=20brave,=20three=20parts=20fool.?=0D=0A=0D=0A=0D=0A=0D=0AVi= ctor=20Fajardo=20=20=0D=0A10/11/2007=2011:34= =20PM=0D=0A=0D=0A=0D=0ATo=0D=0A"Asveren,=20Tolga"=20=0D=0Acc=0D=0Adime@ietf.org,=20Dan=20Warren=20,=20Phil= ip=20Crocker=20=0D=0A=0D=0ASubject=0D= =0ARe:=20[Dime]=20Conflict=20with=20grouped=20&=20mandatory=20AVPs.=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AHi=20Tolga,=0D=0A=0D=0A>>=20parent=20= makes=20it=20easier=20to=20indicate=20this=20situation;=20i.e.=20you=20do= n't=20have=0D=0A>>=20to=20parse=20through=20inner=20AVPs=20to=20see=20whi= ch=20one=20has=20an=20M-bit=20or=20not=20to=0D=0A>>=20realize=20the=20rec= ognizability=20of=20the=20entire=20group=20...=20or=20I'm=20probably=0D= =0A>>=20missing=20something=20:)=0D=0A>>=20=0D=0A>=20[TOLGA]IMHO,=20not= =20extending=20the=20meaning=20of=20M-bit=20of=20a=20sub-AVP=20to=20its= =0D=0A>=20parent=20is=20a=20better=20approach=20(or=20better=20said=20to= =20have=20the=20flexibility=20to=0D=0A>=20do=20so).=20If=20we=20forbid=20= this,=20there=20won't=20be=20a=20way=20to=20indicate=20the=20behavior=0D= =0A>=20I=20described=20above.=20For=20example,=20if=20one=20wants=20to=20= attach=20QoS-Capability=0D=0A>=20AVP=20to=20a=20message=20without=20M-bit= =20set,=20this=20would=20indicate=20that=20receiver=0D=0A>=20does=20not= =20really=20need=20to=20understand/process=20it.=20OTOH,=20QoS-Profile=20= sub-AVP=0D=0A>=20will=20have=20M-bit=20set=20to=20indicate=20that=20in=20= case=20the=20receiver=20is=20able=20to=0D=0A>=20process=20QoS-Capability= =20AVP,=20it=20must=20know=20what=20to=20do=20with=20QoS-Profile=0D=0A>= =20AVP.=20Setting=20M-bit=20of=20the=20QoS-Capability=20AVP=20(the=20pare= nt=20AVP)=20would=20make=0D=0A>=20its=20processing=20mandatory,=20which= =20may=20not=20be=20always=20the=20desired=20behavior.=0D=0A>=20=0D=0A=0D= =0AThere=20maybe=20some=20confusion=20on=20what=20comments=20relates=20to= =20where=20:)=20I=20guess=20=0D=0Ayour=20example=20above=20is=20what=20i= =20meant=20with=20my=20original=20comment=20"whether=20we=20=0D=0Aare=20p= iggybacking=20this=20AVP=20to=20an=20exsiting=20application".=20And=20giv= en=20that=20we=20=0D=0Aneed=20to=20support=20this=20genericness,=20I=20ag= ree=20we=20do=20need=20to=20remove=20some=20=0D=0Arestrictions.=20However= ,=20commenting=20on=20applications/scenarios=20being=20from=20=0D=0ADan,= =20it=20may=20have=20been=20better=20to=20use=20the=20ABNF=20as=20optiona= lity=20indicator=20=0D=0Arather=20than=20the=20M-bit=20in=20some=20of=20t= he=203gpp=20designs=20and=20use=20a=20hierarchal=20=0D=0Amodel.=0D=0A=0D= =0Aregards,=0D=0Avictor=0D=0A=0D=0A=0D=0A________________________________= _______________=0D=0ADiME=20mailing=20list=0D=0ADiME@ietf.org=0D=0Ahttps:= //www1.ietf.org/mailman/listinfo/dime=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A******= *****************=20=20Aricent-Unclassified=20=20=20*********************= **=0D=0A"DISCLAIMER:=20This=20message=20is=20proprietary=20to=20Aricent= =20=20and=20is=20intended=20solely=20for=20the=20use=20of=20=0Athe=20indi= vidual=20to=20whom=20it=20is=20addressed.=20It=20may=20contain=20privileg= ed=20or=20confidential=20information=20and=20should=20not=20be=20=0Acircu= lated=20or=20used=20for=20any=20purpose=20other=20than=20for=20what=20it= =20is=20intended.=20If=20you=20have=20received=20this=20message=20in=20er= ror,=20=0Aplease=20notify=20the=20originator=20immediately.=20If=20you=20= are=20not=20the=20intended=20recipient,=20you=20are=20notified=20that=20y= ou=20are=20strictly=0Aprohibited=20from=20using,=20copying,=20altering,= =20or=20disclosing=20the=20contents=20of=20this=20message.=20Aricent=20ac= cepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20arising=20fro= m=20the=20use=20of=20the=20information=20transmitted=20by=20this=20email= =20including=20damage=20from=20virus."=0A --=_alternative 0027D22665257378_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A
Hi=20All,=0D=0AI=20have=20been=20following=20th= is=20discussion=0D=0Aand=20believe=20the=20situation=20of=20QoS-Capability=20AVP=0D=0Adepicted=20below=20is=20a=20good=20example=20hence=20w= e=20should=20allow=20outer=20AVP=20as=20optional=0D=0Awhile=20inner(neste= d)=20AVPs=20can=20be=20mandatory=20(=20i.e=20with=20M=20bit=20set).=20=0D=0A
What=20has=20been=20= the=20final=20accord=20on=20the=0D=0Aissue=20?=0D=0A
=0D=0A
= Thanks,=0D=0A
Himanshu
=0D=0AA=20R=20I=20C=20E=20N=20T=0D= =0A
=0D=0A

“That's=20the=20spirit=20-=20one= =20part=20brave,=20three=20parts=20fool.”=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0AVictor=20Fajardo= =20<vfajardo@tari.toshiba.com>=0D=0A=0D=0A

10/11/2007=2011:34=20PM=0D=0A
=0D= =0A=0D=0A=0D=0A=0D=0A=0D= =0ATo<= /div>=0D=0A&quo= t;Asveren,=20Tolga"=0D=0A<tasveren@sonusnet.com>=0D=0A<= tr>=0D=0A=0D=0Acc=0D=0Adime@ietf.org,=20Dan=20Warren=0D=0A<DWarren@gsm.org>,= =20Philip=20Crocker=20<Philip.Crocker@dataconnection.com>=0D= =0A=0D=0A=0D=0ASubject=0D=0ARe:=20[Dime]=20Conflict=20with=0D=0Agrouped=20&= ;=20mandatory=20AVPs.=0D=0A
=0D=0A=0D=0A=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A=
=0D=0A
Hi=20Tolga,
=0D=0A
=0D=0A>>= ;=20parent=20makes=20it=20easier=20to=20indicate=20this=20situation;=20i.= e.=20you=20don't=0D=0Ahave
=0D=0A>>=20to=20parse=20through=20inn= er=20AVPs=20to=20see=20which=20one=20has=20an=20M-bit=20or=20not=0D=0Ato<= br>=0D=0A>>=20realize=20the=20recognizability=20of=20the=20entire= =20group=20...=20or=20I'm=20probably
=0D=0A>>=20missing=20someth= ing=20:)
=0D=0A>>=20 =20 =20
=0D=0A>=20[TOLGA]IM= HO,=20not=20extending=20the=20meaning=20of=20M-bit=20of=20a=20sub-AVP=20t= o=20its
=0D=0A>=20parent=20is=20a=20better=20approach=20(or=20bette= r=20said=20to=20have=20the=20flexibility=0D=0Ato
=0D=0A>=20do=20so)= .=20If=20we=20forbid=20this,=20there=20won't=20be=20a=20way=20to=20indica= te=20the=20behavior
=0D=0A>=20I=20described=20above.=20For=20exampl= e,=20if=20one=20wants=20to=20attach=20QoS-Capability
=0D=0A>=20AVP= =20to=20a=20message=20without=20M-bit=20set,=20this=20would=20indicate=20= that=20receiver
=0D=0A>=20does=20not=20really=20need=20to=20underst= and/process=20it.=20OTOH,=20QoS-Profile=20sub-AVP
=0D=0A>=20will=20= have=20M-bit=20set=20to=20indicate=20that=20in=20case=20the=20receiver=20= is=20able=0D=0Ato
=0D=0A>=20process=20QoS-Capability=20AVP,=20it=20= must=20know=20what=20to=20do=20with=20QoS-Profile
=0D=0A>=20AVP.=20= Setting=20M-bit=20of=20the=20QoS-Capability=20AVP=20(the=20parent=20AVP)= =20would=0D=0Amake
=0D=0A>=20its=20processing=20mandatory,=20which= =20may=20not=20be=20always=20the=20desired=20behavior.
=0D=0A>=20&n= bsp;=20
=0D=0A
=0D=0AThere=20maybe=20some=20confusion=20on=20what= =20comments=20relates=20to=20where=20:)=20I=20guess=0D=0A
=0D=0Ayour= =20example=20above=20is=20what=20i=20meant=20with=20my=20original=20comme= nt=20"whether=0D=0Awe=20
=0D=0Aare=20piggybacking=20this=20AVP=20= to=20an=20exsiting=20application".=20And=20given=20that=0D=0Awe=20=0D=0Aneed=20to=20support=20this=20genericness,=20I=20agree=20we=20do= =20need=20to=20remove=20some=20
=0D=0Arestrictions.=20However,=20comme= nting=20on=20applications/scenarios=20being=20from=0D=0A
=0D=0ADan,=20= it=20may=20have=20been=20better=20to=20use=20the=20ABNF=20as=20optionalit= y=20indicator=20
=0D=0Arather=20than=20the=20M-bit=20in=20some=20of=20= the=203gpp=20designs=20and=20use=20a=20hierarchal=0D=0A
=0D=0Amodel.=0D=0A
=0D=0Aregards,
=0D=0Avictor
=0D=0A
=0D=0A
=0D=0A_= ______________________________________________
=0D=0ADiME=20mailing=20= list
=0D=0ADiME@ietf.org
=0D=0Ahttps://www1.ietf.org/mailman/listin= fo/dime
=0D=0A
=0D=0A=0D=0A

=0D=0A
=0D=0A***********************=20 Arice= nt-Unclassified=20 =20***********************=0D=0A
"DISCLAIMER:=20This=
=20message=20is=20proprietary=20to=20Aricent=20=20and=20is=20intended=20s=
olely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=
=20addressed.=20It=20may=20contain=20privileged=20or=20confidential=20inf=
ormation=20and=20should=20not=20be=20=0Acirculated=20or=20used=20for=20an=
y=20purpose=20other=20than=20for=20what=20it=20is=20intended.=20If=20you=
=20have=20received=20this=20message=20in=20error,=20=0Aplease=20notify=20=
the=20originator=20immediately.=20If=20you=20are=20not=20the=20intended=
=20recipient,=20you=20are=20notified=20that=20you=20are=20strictly=0Aproh=
ibited=20from=20using,=20copying,=20altering,=20or=20disclosing=20the=20c=
ontents=20of=20this=20message.=20Aricent=20accepts=20no=20responsibility=
=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20of=20the=20=
information=20transmitted=20by=20this=20email=20including=20damage=20from=
=20virus."=0A
--=_alternative 0027D22665257378_=-- --===============0706515823== 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://www1.ietf.org/mailman/listinfo/dime --===============0706515823==-- From dime-bounces@ietf.org Thu Oct 18 04:59:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRDL-0005TG-G1; Thu, 18 Oct 2007 04:58:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiRDJ-0005NF-QW for dime@ietf.org; Thu, 18 Oct 2007 04:58:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IiRD8-0007fP-5z for dime@ietf.org; Thu, 18 Oct 2007 04:58:41 -0400 Received: (qmail invoked by alias); 18 Oct 2007 08:58:12 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp045) with SMTP; 18 Oct 2007 10:58:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+M17EHU1GMl7Vs/9W8WsqWrIIKJ3MK3iK3Ur1ON+ HC14pMuncgeyCA Message-ID: <47172023.6000508@gmx.net> Date: Thu, 18 Oct 2007 10:58:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Francois Le Faucheur IMAP Subject: Re: [Dime] draft-ietf-dime-qos-parameters-01 References: <4710EDB4.7080306@gmx.net> <7AE49DF0-833D-4CA1-9C5D-A3AD5A40A2C8@g11.org.uk> <471382F3.10101@gmx.net> <820D7225-8B7D-4B89-8858-9F4687F70360@g11.org.uk> <4713D654.4080703@gmx.net> <4714C026.9050008@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: David Oran R , dime@ietf.org, =?ISO-8859-1?Q?=22=28IJ/ETH=29_Attila_B=E1der=22?= , cornelia.kappler@nsn.com, James Polk X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Francois, thanks for your mail. Please find a few comments below: Francois Le Faucheur IMAP wrote: > Hi, > > On 16 Oct 2007, at 15:44, Hannes Tschofenig wrote: > >> Hi Francois, >> >> thanks for your response. Please find my comment below: >> >> Francois Le Faucheur IMAP wrote: >>> Hello Hannes, >>> >>> On 15 Oct 2007, at 23:06, Hannes Tschofenig wrote: >>> >>>> Here is a proposal: >>>> >>>> In Section 4.11 of >>>> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt >>>> we currently have the following RPH Priority parameter: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |M|r|r|r| 10 |r|r|r|r| 1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | RPH Namespace | RPH Priority | (Reserved) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> If we define a namespace for this parameter then we should define a >>>> namespace field for the Admission Priority parameter defined in >>>> Section 4.10 as well. >>> >>> Not with the QoS signaling model I was picturing. >>> >>> In my mind, we do not want each and every router to have to >>> understand "application level" priority requirements, nor be aware >>> of every SDO's latest decision on whether 3, 4 or 10 levels of >>> priorities is the way to go. To that end, the approach we have been >>> following for rsvp-emergency (and I think is in line with RFC2753 >>> defining "A Framework for Policy-based Admission Control") is the >>> following: >>> * there are a number of fundamental network mechanisms that >>> every router involved in QoS signaling need to understand (i.e. >>> preemption priority, admission priority). To allow routers to >>> enforce those mechanisms, the corresponding information element >>> needs to be included in the QoS signaling. Those contain semantics >>> that are directly understandable by routers (e.g. Preemption >>> Priority 10 is allowed to bump Defending Priority 5). >>> * routers involved in QoS signaling need not understand >>> application level requirements (ie routers do not necessarily know >>> what is DSN's "flash-override-override", or the counterpart in other >>> countries) >>> * Policy Decision Points (typically at the edge of the network >>> as well as at administrative boundaries) understand "application >>> level requirements" and are responsible for mapping those into >>> network mechanisms (i.e. preemption priority, admission priority). >>> * To facilitate the mapping of "application-level" requirements >>> into network mechanisms by PDPs, the application-level requirements >>> (as specified for SIP usage) can be conveyed inside the QoS >>> signaling protocol. However, they are intended to be relayed to PDPs >>> and are not intended to be understood by each and every QoS >>> signaling router. >>> >> >> I think the usage of the term "application-level" requirements and >> non-application level requirements is quite confusing unless you >> speak about codecs in the context of the application layer (which >> nobody does so far). > > By "application-level" requirements I mean something along the lines > of the "Resource Priority" discussed in RFC4412. Something along the > lines of: > * "this call is being established by a Senior Vice President and > is therefore more important than mine" or > * "this call is being established by a 4-star general and is > therefore more important than Hannes's call'" or > * "this call is being established by a Fire Brigade captain" The interesting thing with the resource priority work is that you cannot express these type of things. Additionally, the resource priority header claims to be conveying the priority information for evaluation at the other communication end point. > > The point is we probably don't want routers to have to be aware of how > to handle a call form a VP, a 4-star general or a Fire-Brigade captain. Well. In some sense that's what Diameter would do for you. The Diameter server does the authentication step, then when the Diameter client asks for a particular authorization decision information stored at the Diameter server (e.g., roles associated with a specific user) is used to make a decision. I believe that the current resource priority work just does not talk about how to make this authorization step.... I agree with you that the router should not need to worry about the roles of users in a phone call. > > >> >> Hence, the entire question finally comes down to the issue of what do >> you assume a router to understand and what would other entities (such >> as Diameter proxies and Diameter servers) understand. >> >> You are essentially saying that the router should only support the >> functionality described in >> * RFC 3181, and >> * Section 3.1 of >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt >> > > Right. > >> >> If I understand you correctly then the text in Section 3.2 that lists >> the functionality of RFC 4412 (e.g., "dsn.flash-override") is just >> passed inside RSVP to be then forwarded towards the backend >> infrastructure. Then, it is interpreted there and translated to >> something the router understands (namely the functionality listed in >> the bullet list above). > > Right. > >> Finally, it is sent back to the router in a different form, namely >> the values of dsn.flash-override, etc. (which are just constants for >> priority values) are mapped into the priority values described in >> Section 3.1 of >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-03.txt. >> > > ... and or into RFC3181. Correct. > > For example: > * RPHnamespace1/RPHpriority1 may get mapped into RFC3181 mechanism > (ie a Preemption priority + Defending priority) > * RPHnamespace2/RPHpriority2 may get mapped into rsvp-emergency > section 3.1 mechanism (ie an Admission priority) > * RPHnamespace3/RPHpriority3 may get mapped into RFC3181 mechanism > (ie a Preemption priority + Defending priority) and an rsvp-emergency > section 3.1 mechanism (ie an Admission priority). Ok. > >> >>> With such a model in mind, the proposal would be: >>> >>> * dime-qos-parameters, nsis-qspec and rsvp-emergency all define >>> an information element containing an "RPH namespace" field and an >>> "RPH priority" field. These fields contain numerical values that are >>> specified in an IANA registry. >> That's fine. The parameter is there already but there is just the >> mismatch between draft-ietf-tsvwg-emergency-rsvp and >> draft-ietf-nsis-qspec. >> >>> >>> * dime-qos-parameters, nsis-qspec both define an information >>> element containing a "Admission Priority" field and a "Defending >>> Priority" field. These field contain numerical values whose >>> semantics is in line with RFC3181 (ie "higher values represent >>> higher priority"). >> Draft-ietf-nsis-qspec and draft-ietf-dime-qos-parameters-01 have a >> field for Admission Priority but it is focused on the Y.1571 defined >> values only. >> draft-ietf-tsvwg-emergency-rsvp does not define a stand-alone >> "Defending Priority" field either. > > My text above contained a very unfortunate typo (Sorry!). It was meant > to read : > * dime-qos-parameters, nsis-qspec both define an information > element containing a "Preemption Priority" field and a "Defending > Priority" field. These field contain numerical values whose semantics > is in line with RFC3181 (ie "higher values represent higher priority"). Correct. > > >> >>> >>> * dime-qos-parameters, nsis-qspec and rsvp-emergency all define >>> an information element containing an "RPH namespace" field. This >>> field contains a numerical value whose semantic is "higher values >>> represent higher priority". > > My text above contained a another very unfortunate typo (I can't > believe this. Sorry!). It was meant to read : > * dime-qos-parameters, nsis-qspec and rsvp-emergency all define an > information element containing an "Admission Priority" field. This > field contains a numerical value whose semantic is "higher values > represent higher priority". > > Does this make sense now? Yep; That makes sense. > >> >>> Does the QoS model described above make sense to you too? >> I still have to understand a few things better... >>> What about the corresponding proposal? > > Hope the proposal without typos makes more sense. Yep. > > >>> >> Seen from a higher layer we are essentially dealing with an issue of >> extensibility here. In your model you assume that the router only >> understands a certain set of QoS profiles (namely one where the >> parameters of RFC X and Y) are understood. > > right. > >> That's fine. You would like to foward parameters that aren't >> understood to the backend infrastructure in order to get them >> translated to something you understand. > > right. > >> That's fine. Within the Diameter QoS attribute document we allow the >> Diameter client to tell the Diameter server what it understands. >> The level of understanding may, however, vary. I believe that there >> are two cases: >> * The Diameter client receives a request from a QoS signaling >> protocol, such as RSVP. A message may contain objects where the >> Diameter client knows how todo the encapsulation but it realizes that >> the Resource Management function cannot deal with them. To have a >> specific example: Let's assume some SDO defines new priority elements >> and registers them. The Diameter QoS client (or the RMF) does not >> know how to interpret the specific priority values but it understands >> the object as such -- it understands that this is a priority parameter. > > We want to consider two cases: > > -A- the SDO defines some network CAC handling that cannot be > supported using the existing NSIS/RSVP mechanisms (ie Preemption > Priority & Defending Priority, Admission Priority). Then IETF would > have to specify a new additional mechanism and NSIS/RSVP signaling > extensions for the corresponding new network mechanism. So far, all > discussions about emergency and military handling concluded that we > can support all the identified requirements with the above mechanisms. Correct. > > -B- the SDO defines a particular mapping like "in my environments > I need 3 levels of preemption priorities and 2 levels of admission > priority and here's how my calls get mapped on those...". Then I would > hope that this has no impact on NSIS, RSVP or Diameter. The case > brought up by An is interesting. the fact that ITU changed from Y.1571 > to Y.2171 (or something else tomorrow) should not affect Diameter, > NSIS or RSVP, should it? The problem is that I don't really know the details of the Y.1571 to Y.2171 change. I would have to read through the documents. Ideally, if you have a different "profile" then you might want to define this somewhere. For example, consider the priority values specified by the IEEE for some of their link layers. When you want to use Diameter todo the authorization then it would be good to know what the allowed value range is. While we have a way to express the namespace for RPH Priority parameter we don't have it for the Admission Priority parameter. That was one of the open issues I saw. Based on the discussion we had I do believe that there is a need to document the basic model described earlier in this mail in some document. This is more or less a framework aspect that might be good to capture. I don't think it is a protocol aspect or something that causes interoperability issues but still good to highlight. Ciao Hannes > > Cheers > > Francois > > PS: apologies again for the confusion created by the earlier typos. > > > >> * The second case is where the Diameter client obtains something from >> the QoS signaling protocol that it does not understand at all. This >> case is not covered and if we would like to support your model (in >> case I understood it correctly) then this means that we have to dump >> the received information into a container and forward it along with >> the other information to the Diameter server. The Diameter server >> would then try to understand it. >> >> Do I correctly capture the problem? >> >> Ciao >> Hannes >>> Cheers >>> >>> Francois >>> >>> >>> PS: I'm keeping the "Merging" question out for now. I think it is >>> worth converging on the high level model first, and I'd like to >>> think more about the Merging. >>> >>> >>> >>> >>>> Currently, the parameter has the following structure: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |M|r|r|r| 9 |r|r|r|r| 1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Admis.Priority| (Reserved) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> We would change it to: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |M|r|r|r| 9 |r|r|r|r| 1 | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Namespace | Admis.Priority| (Reserved) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> The "Namespace" field would indicate the context of the subsequent >>>> Admission Priority values. >>>> >>>> What do you think about the proposal? >>>> >>>> Would it make sense to make this change in >>>> draft-ietf-nsis-qspec-17.txt and in >>>> draft-ietf-tsvwg-emergency-rsvp-03.txt as well? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> ken carlberg wrote: >>>>> Hannes, >>>>> >>>>>>> ok, I wrote something and just deleted it because the term >>>>>>> "namespace" can cause some confusion. what I'm suggesting is >>>>>>> perhaps an "SDO-space" field because the output of one SDO has >>>>>>> pre-defined values. >>>>>> It seems that you are really looking at a vendor-specific >>>>>> registry that happens to include SDOs as well. >>>>>> See http://www.iana.org/assignments/enterprise-numbers >>>>> >>>>> ouch, no. i think the thread is leading to a level of granular >>>>> information that was not my intention. At the worst, I would have >>>>> just wanted to distinguish SDOs (and in particular, their priority >>>>> related standards) *if* the need exists to do so within the >>>>> parameter of 4.10. (more below) >>>>> >>>>>> The question therefore really is (from a Diameter/RADIUS >>>>>> perspective): Do we want to have an attribute that has a generic >>>>>> name instead of creating specific variants of it. >>>>> >>>>> brief answer, yes. >>>>> >>>>>> The generic name would be "Admission Priority Parameter". When we >>>>>> have a generic attribute then we need to differentiate the >>>>>> semantic again by introducing a vendor-/SDO specific field. >>>>> >>>>> only if we have pre-defined values as 4.10 as written now. if we >>>>> take out these values and perhaps follow the more general approach >>>>> just described by Francois, then most likely no. >>>>> >>>>> >>>>> >>>>>> So, do you envision that there are many other SDOs defining their >>>>>> own admission priorities? >>>>> >>>>> yes. we have them in APCO, ITU, and others. >>>>> >>>>>> Do you expect that additional information would be added to the >>>>>> admission priority field itself? >>>>> >>>>> yes. as we see in Y.1571 (and H.460.4), other SDOs have priority >>>>> fields defined along with pre-defined values. but again, I'm >>>>> leaning to follow Francois's suggestion for 4.10 to "just define >>>>> the relative semantics ("Higher values represent higher Priority")". >>>>> >>>>> >>>>> >>>>>>> that's a tough question. we have the merge field in cases where >>>>>>> the rsvp policy attribute is used for multicast. however, I >>>>>>> don't see any text describing the application of Diameter to >>>>>>> multicast in rfc-3588, the current diameter base draft, nor the >>>>>>> QoS related diameter drafts. without that text or further >>>>>>> guidance from the Diameter group, I would be reluctant to add a >>>>>>> merge field onto the attribute of 4.10. >>>>>> Diameter does not really care too much about the type of traffic. >>>>>> Diameter is only providing the authorization and accounting >>>>>> functionality. I cannot tell whether it would make sense to allow >>>>>> the Diameter client to tell the Diameter server something about >>>>>> QoS reservation for the multicast traffic by indicating the merge >>>>>> strategy. Would this be useful for the Diameter server to know >>>>>> about? Would it make sense for the Diameter server to tell the >>>>>> Diameter client which type of merge strategy to use? >>>>> >>>>> well, we are speaking of receiver driven merges, so the server >>>>> would be informing a merge point that is acting on behalf of an >>>>> aggregate of receivers. Perhaps its better to punt on this topic >>>>> and rely on a separate Diameter draft to deal with multicast flows. >>>>> >>>>> -ken >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Oct 18 06:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiSqV-0000h2-Gz; Thu, 18 Oct 2007 06:43:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiSqU-0000fV-Gk for dime@ietf.org; Thu, 18 Oct 2007 06:43:18 -0400 Received: from bela.ifi.unizh.ch ([130.60.156.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IiSqU-0001QE-5a for dime@ietf.org; Thu, 18 Oct 2007 06:43:18 -0400 Received: from [130.60.155.174] (ifidyn174.ifi.unizh.ch [130.60.155.174]) by bela.ifi.unizh.ch (Postfix) with ESMTP id 3650416AF4 for ; Thu, 18 Oct 2007 12:43:11 +0200 (CEST) Message-ID: <471738BE.3070104@ifi.uzh.ch> Date: Thu, 18 Oct 2007 12:43:10 +0200 From: Cristian Morariu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Dime] New draft: Diameter Grid Accounting Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, my name is Cristian Morariu and I am a PhD student at University of Zurich. During the last three years me and my colleagues from the Communication Systems Group (CSG - http://www.csg.uzh.ch/) were involved in the European-funded project Akogrimo (http://www.akogrimo.org/) where we developed a Diameter-based integrated A4C (AAA+Auditing+Charging) infrastructure for networkork and grid services. For accounting of grid-services we defined a list of new AVPs that we included in an IETF draft proposal submitted to IETF that you can check under: http://www.ietf.org/internet-drafts/draft-morariu-dime-grid-accounting-00.txt We are looking forward for your feedback. Kind regards, Cristian Morariu _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Oct 22 16:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3zB-0000rp-1T; Mon, 22 Oct 2007 16:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik3z9-0000qU-D6 for dime@ietf.org; Mon, 22 Oct 2007 16:34:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ik3yD-0006Z2-C6 for dime@ietf.org; Mon, 22 Oct 2007 16:34:51 -0400 Received: (qmail invoked by alias); 22 Oct 2007 20:33:32 -0000 Received: from p54987A8A.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.138] by mail.gmx.net (mp029) with SMTP; 22 Oct 2007 22:33:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/o37d8qyjos253yueW2ucLcr7FWjrQOQG+p6z1Xg ZNXNwjC+q8mnN8 Message-ID: <471D091C.8000008@gmx.net> Date: Mon, 22 Oct 2007 22:33:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cristian Morariu Subject: Re: [Dime] New draft: Diameter Grid Accounting Application References: <471738BE.3070104@ifi.uzh.ch> In-Reply-To: <471738BE.3070104@ifi.uzh.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Christian, thanks for the work. What do you expect the group todo with your document? Do you plan to implement your proposal or is open source code already available? Who do you expect is going to deploy your proposal? Two high-level questions: 1) When writing your document have you had a chance to look at the Diameter Design Guidelines document http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-03.txt We would appreciate comments from document authors extending Diameter. 2) You have QoS specific attributes in your document. Have you had a chance to look at the ongoing QoS work http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt Ciao Hannes Cristian Morariu wrote: > Hi, > > my name is Cristian Morariu and I am a PhD student at University of > Zurich. During the last three years me and my colleagues from the > Communication Systems Group (CSG - http://www.csg.uzh.ch/) were involved > in the European-funded project Akogrimo (http://www.akogrimo.org/) where > we developed a Diameter-based integrated A4C (AAA+Auditing+Charging) > infrastructure for networkork and grid services. > > For accounting of grid-services we defined a list of new AVPs that we > included in an IETF draft proposal submitted to IETF that you can check > under: > > http://www.ietf.org/internet-drafts/draft-morariu-dime-grid-accounting-00.txt > > We are looking forward for your feedback. > > Kind regards, > Cristian Morariu > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 23 03:37:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEKI-0001Qx-AX; Tue, 23 Oct 2007 03:37:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEKD-0001Ke-LQ for dime@ietf.org; Tue, 23 Oct 2007 03:37:17 -0400 Received: from bela.ifi.unizh.ch ([130.60.156.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkEKD-0001sI-4d for dime@ietf.org; Tue, 23 Oct 2007 03:37:17 -0400 Received: from [130.60.155.174] (ifidyn174.ifi.unizh.ch [130.60.155.174]) by bela.ifi.unizh.ch (Postfix) with ESMTP id A1E2E16B18; Tue, 23 Oct 2007 09:36:18 +0200 (CEST) Message-ID: <471DA473.7020005@ifi.uzh.ch> Date: Tue, 23 Oct 2007 09:36:19 +0200 From: Cristian Morariu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] New draft: Diameter Grid Accounting Application References: <471738BE.3070104@ifi.uzh.ch> <471D091C.8000008@gmx.net> In-Reply-To: <471D091C.8000008@gmx.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Hannes, thank you for the links. I will take those into consideration when updating the draft. Regarding your questions: a) What do you expect the group todo with your document? I would like some feedback and I would be also like to know if other people are looking into implementing Diameter-based accounting for services other than network services. b) Do you plan to implement your proposal or is open source code already available? We implemented an accounting server as well as an accounting client for grid services. This was tested in the Akogrimo project and will most probably be released as open source. Currently the code still has to be "cleaned" in order to be made public. Our implementation includes also a federated-identity provisioning mechanism based on Diameter and SAML but this I think goes beyond the focus of the draft. c) Who do you expect is going to deploy your proposal? Commercial grid-service providers and grid-platform operators should have an incentive for adopting Diameter-based accounting so they may easier interract with accounting systems of network providers. The final goal would be to have all services being charged for by the user's home network provider. Regards, Cristian Hannes Tschofenig wrote: > Hi Christian, > > thanks for the work. What do you expect the group todo with your > document? > Do you plan to implement your proposal or is open source code already > available? > Who do you expect is going to deploy your proposal? > > Two high-level questions: > > 1) When writing your document have you had a chance to look at the > Diameter Design Guidelines document > http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-03.txt > > > We would appreciate comments from document authors extending Diameter. > > 2) You have QoS specific attributes in your document. > Have you had a chance to look at the ongoing QoS work > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt > > Ciao > Hannes > > Cristian Morariu wrote: >> Hi, >> >> my name is Cristian Morariu and I am a PhD student at University of >> Zurich. During the last three years me and my colleagues from the >> Communication Systems Group (CSG - http://www.csg.uzh.ch/) were involved >> in the European-funded project Akogrimo (http://www.akogrimo.org/) where >> we developed a Diameter-based integrated A4C (AAA+Auditing+Charging) >> infrastructure for networkork and grid services. >> >> For accounting of grid-services we defined a list of new AVPs that we >> included in an IETF draft proposal submitted to IETF that you can check >> under: >> >> http://www.ietf.org/internet-drafts/draft-morariu-dime-grid-accounting-00.txt >> >> >> We are looking forward for your feedback. >> >> Kind regards, >> Cristian Morariu >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 23 03:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkERe-0001W8-4H; Tue, 23 Oct 2007 03:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkERb-0001SK-5L for dime@ietf.org; Tue, 23 Oct 2007 03:44:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkEQf-00017y-PV for dime@ietf.org; Tue, 23 Oct 2007 03:44:55 -0400 Received: (qmail invoked by alias); 23 Oct 2007 07:43:37 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp034) with SMTP; 23 Oct 2007 09:43:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Fr2NP3L4FV+ZHiyM7oFO0b3T+pzpweBHDGzuWfR 7vmuQaqZEnVZbV Message-ID: <471DA62B.9050706@gmx.net> Date: Tue, 23 Oct 2007 09:43:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Dime] DIME Status Update, October 2007 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I have compiled a short status update based on the work we did the last 2 months: http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate In short, it seems that we are doing fine. Since we are about to finish a couple of documents in the next month we should think about rechartering. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 23 03:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEVN-0007Iq-FG; Tue, 23 Oct 2007 03:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkEVJ-00076Z-OE for dime@ietf.org; Tue, 23 Oct 2007 03:48:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IkEVD-0001SJ-D6 for dime@ietf.org; Tue, 23 Oct 2007 03:48:40 -0400 Received: (qmail invoked by alias); 23 Oct 2007 07:48:33 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp046) with SMTP; 23 Oct 2007 09:48:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nuBMkJPBn6P6QLX3iF8fbwSC4OwrJBZlmc12IrY 9qlz5Y4tqkhnFn Message-ID: <471DA752.7010103@gmx.net> Date: Tue, 23 Oct 2007 09:48:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] Milestone Update X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, for some reason our last milestone update got lost. Hence, I am going to submit a new one. Here is the proposal: Nov 2007 Submit "Diameter API" to the IESG for consideration as an Informational RFC Dec 2007 Submit Revision of "Diameter Base Protocol" to the IESG for consideration as a Proposed Standard Nov 2007 Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards: * "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" * "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" Jan 2008 Submit "Diameter QoS Application" to the IESG for consideration as a Proposed Standard Dec 2007 Submit "Diameter Application Design Guidelines" to the IESG for consideration as an Informational RFC Thoughts? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Oct 23 04:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkErE-0007fc-5S; Tue, 23 Oct 2007 04:11:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkErC-0007f4-QZ for dime@ietf.org; Tue, 23 Oct 2007 04:11:22 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IkErB-0003Xy-Ly for dime@ietf.org; Tue, 23 Oct 2007 04:11:22 -0400 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 l9N8BKrS016070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2007 10:11:20 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l9N8BB5q018425; Tue, 23 Oct 2007 10:11:15 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Oct 2007 10:11:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] New draft: Diameter Grid Accounting Application Date: Tue, 23 Oct 2007 10:11:11 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB436544@DEMUEXC012.nsn-intra.net> In-Reply-To: <471DA473.7020005@ifi.uzh.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] New draft: Diameter Grid Accounting Application Thread-Index: AcgVR/KoZPK4tIFOQKmbzJ2j71ZzBQAAxoSg References: <471738BE.3070104@ifi.uzh.ch> <471D091C.8000008@gmx.net> <471DA473.7020005@ifi.uzh.ch> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext Cristian Morariu" , "Hannes Tschofenig" X-OriginalArrivalTime: 23 Oct 2007 08:11:12.0343 (UTC) FILETIME=[466EE670:01C8154C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Christian,=20 > Hi Hannes, >=20 > thank you for the links. I will take those into consideration when > updating the draft. Let us know if you have some comments. These documents have passed the 1st working group last call already =3D they are getting close to leave the working group. It would therefore be the right time for feedback.=20 >=20 > Regarding your questions: > a) What do you expect the group todo with your document? > I would like some feedback and I would be also like to=20 > know if other > people are looking into implementing Diameter-based accounting for > services other than network services. I can tell you that people use Diameter for application layer services, such as VoIP or other applications.=20 Maybe you have read the Diameter Credit Control application as well. It is used for real-time accounting; also for application layer services.=20 Regarding feedback: My experience showed me that it is more likely to get review comments when you have commented other people's work beforehand.=20 >=20 > b) Do you plan to implement your proposal or is open source=20 > code already > available? > We implemented an accounting server as well as an=20 > accounting client > for grid services. This was tested in the Akogrimo project=20 > and will most > probably be released as open source. Currently the code still=20 > has to be > "cleaned" in order to be made public. Good to know. Please let the group know when it becomes available.=20 Is your accounting application based on OpenDiameter?=20 Our implementation=20 > includes also a > federated-identity provisioning mechanism based on Diameter=20 > and SAML but > this I think goes beyond the focus of the draft. Have you published some papers that provide more background on what you did?=20 The usage of SAML in combination with Diameter and RADIUS appeared already a couple of times in the IETF.=20 Would be interesting to know whether everyone had the same ideas... >=20 > c) Who do you expect is going to deploy your proposal? > Commercial grid-service providers and grid-platform=20 > operators should > have an incentive for adopting Diameter-based accounting so they may > easier interract with accounting systems of network providers. The > final goal would be to have all services being charged for by=20 > the user's > home network provider. Have you had a chance to talk to commerical grid service providers? Do you have some of them in our EU funded project?=20 Thanks for the info.=20 Ciao Hannes > Regards, > Cristian >=20 > Hannes Tschofenig wrote: > > Hi Christian, > > > > thanks for the work. What do you expect the group todo with your > > document? > > Do you plan to implement your proposal or is open source=20 > code already > > available? > > Who do you expect is going to deploy your proposal? > > > > Two high-level questions: > > > > 1) When writing your document have you had a chance to look at the > > Diameter Design Guidelines document > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design > -guide-03.txt > > > > > > We would appreciate comments from document authors=20 > extending Diameter. > > > > 2) You have QoS specific attributes in your document. > > Have you had a chance to look at the ongoing QoS work > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attrib utes-02.txt > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parame ters-01.txt > > > > Ciao > > Hannes > > > > Cristian Morariu wrote: > >> Hi, > >> > >> my name is Cristian Morariu and I am a PhD student at University of > >> Zurich. During the last three years me and my colleagues from the > >> Communication Systems Group (CSG - http://www.csg.uzh.ch/)=20 > were involved > >> in the European-funded project Akogrimo=20 > (http://www.akogrimo.org/) where > >> we developed a Diameter-based integrated A4C=20 > (AAA+Auditing+Charging) > >> infrastructure for networkork and grid services. > >> > >> For accounting of grid-services we defined a list of new=20 > AVPs that we > >> included in an IETF draft proposal submitted to IETF that=20 > you can check > >> under: > >> =20 > >>=20 > http://www.ietf.org/internet-drafts/draft-morariu-dime-grid-ac counting-00.txt > >> > >> > >> We are looking forward for your feedback. > >> =20 > >> Kind regards, > >> Cristian Morariu > >> > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dime > >> =20 > > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 26 10:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQMW-0007u6-Jk; Fri, 26 Oct 2007 10:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQMV-0007qc-16; Fri, 26 Oct 2007 10:40:35 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlQMS-0007WN-KS; Fri, 26 Oct 2007 10:40:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8733C3287E; Fri, 26 Oct 2007 14:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IlQLy-0004lx-Dm; Fri, 26 Oct 2007 10:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Oct 2007 10:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-app-design-guide-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-app-design-guide-04.txt Pages : 20 Date : 2007-10-26 The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol which further explains and/or clarify these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-04.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-app-design-guide-04.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-app-design-guide-04.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: <2007-10-26103605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-app-design-guide-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-26103605.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 https://www1.ietf.org/mailman/listinfo/dime --NextPart-- From dime-bounces@ietf.org Fri Oct 26 10:43:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQPc-0000n1-Jr; Fri, 26 Oct 2007 10:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQPX-0000mX-Qr for dime@ietf.org; Fri, 26 Oct 2007 10:43:47 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlQPR-0007cO-L8 for dime@ietf.org; Fri, 26 Oct 2007 10:43:43 -0400 Received: from [192.168.1.3] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (rwcrmhc11) with SMTP id <20071026144331m11004nmm1e>; Fri, 26 Oct 2007 14:43:31 +0000 In-Reply-To: <471DA62B.9050706@gmx.net> References: <471DA62B.9050706@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Dime] DIME Status Update, October 2007 Date: Fri, 26 Oct 2007 10:43:29 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hannes, What are your thoughts about defining a new AVP exclusively for priority? I don't have concerns about the inclusion of priority in the QoS parameters draft. However, I recently came across an email exchange related to IMS where one of the participants didn't want to consider using the QoS parameters draft for validating SIP R-P information because of the bundled QoS. I'm sure there are work-arounds to mitigate the technical concerns of that individual. However, at times its easier to provide an atomic solution to a topic than to a multi-faceted one that gets paired down with profiles of set values (eg, to only exericise Priority parameters in the QoS-parameters draft, set all other fields to X, Y, Z). -ken On Oct 23, 2007, at 3:43 AM, Hannes Tschofenig wrote: > I have compiled a short status update based on the work we did the > last 2 months: > http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate > > In short, it seems that we are doing fine. Since we are about to > finish a couple of documents in the next month we should think > about rechartering. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 26 10:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQc2-0004MU-4k; Fri, 26 Oct 2007 10:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQc0-0004LW-Ut for dime@ietf.org; Fri, 26 Oct 2007 10:56:36 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlQbz-00087j-NN for dime@ietf.org; Fri, 26 Oct 2007 10:56:36 -0400 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 l9QEu8GV093765 for ; Fri, 26 Oct 2007 10:56:08 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <47220005.4020105@tari.toshiba.com> Date: Fri, 26 Oct 2007 10:56:05 -0400 From: Victor Fajardo User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] I-D Action:draft-ietf-dime-app-design-guide-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org FYI. A quick summary of changes for the Diameter Application Design Guide: * Added text in Sec 5.3 explaining what app-id should be contained in the auth, acct and VSA-app-id AVP when defining new apps. * Added text in Sec 6.2 discussing how a document should reference commands that can carry optional AVP. Related to recent discussion on Qos attribute draft where the draft listed the applications/commands which can carry the AVP. * Editorial nits. regards, victor > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. > > > Title : Diameter Applications Design Guidelines > Author(s) : V. Fajardo, et al. > Filename : draft-ietf-dime-app-design-guide-04.txt > Pages : 20 > Date : 2007-10-26 > > The Diameter Base protocol provides updated rules on how to extend > Diameter by modifying and/or deriving from existing applications or > creating entirely new applications. This is a companion document to > the Diameter Base protocol which further explains and/or clarify > these rules. It is meant as a guidelines document and therefore it > does not add, remove or change existing rules. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-04.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-app-design-guide-04.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-app-design-guide-04.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. > > ------------------------------------------------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 26 11:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQwq-00033E-73; Fri, 26 Oct 2007 11:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlQwp-000338-J4 for dime@ietf.org; Fri, 26 Oct 2007 11:18:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IlQwj-0000ix-7j for dime@ietf.org; Fri, 26 Oct 2007 11:18:07 -0400 Received: (qmail invoked by alias); 26 Oct 2007 15:17:45 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp051) with SMTP; 26 Oct 2007 17:17:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Fz/4VjB4F6+e3OX/JRNk5rvDvwns2RJW/hrU307 jvp4hKKGdk3Ju/ Message-ID: <47220518.1020006@gmx.net> Date: Fri, 26 Oct 2007 17:17:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg Subject: Re: [Dime] DIME Status Update, October 2007 References: <471DA62B.9050706@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ken, ken carlberg wrote: > Hannes, > > What are your thoughts about defining a new AVP exclusively for > priority? I don't have concerns about the inclusion of priority in > the QoS parameters draft. However, I recently came across an email > exchange related to IMS where one of the participants didn't want to > consider using the QoS parameters draft for validating SIP R-P > information because of the bundled QoS. Can you more specific on how the desired approach would look like? > > I'm sure there are work-arounds to mitigate the technical concerns of > that individual. However, at times its easier to provide an atomic > solution to a topic than to a multi-faceted one that gets paired down > with profiles of set values (eg, to only exericise Priority parameters > in the QoS-parameters draft, set all other fields to X, Y, Z). > Ciao Hannes > -ken > > > On Oct 23, 2007, at 3:43 AM, Hannes Tschofenig wrote: > >> I have compiled a short status update based on the work we did the >> last 2 months: >> http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate >> >> In short, it seems that we are doing fine. Since we are about to >> finish a couple of documents in the next month we should think about >> rechartering. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Oct 26 11:55:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRWl-0001fv-DP; Fri, 26 Oct 2007 11:55:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlRWk-0001d9-1a for dime@ietf.org; Fri, 26 Oct 2007 11:55:14 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlRWj-0006pz-OL for dime@ietf.org; Fri, 26 Oct 2007 11:55:13 -0400 Received: from [192.168.1.3] (c-69-250-218-72.hsd1.md.comcast.net[69.250.218.72]) by comcast.net (alnrmhc12) with SMTP id <20071026155513b1200b8d4je>; Fri, 26 Oct 2007 15:55:13 +0000 In-Reply-To: <47220518.1020006@gmx.net> References: <471DA62B.9050706@gmx.net> <47220518.1020006@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk> Content-Transfer-Encoding: 7bit From: ken carlberg Subject: Re: [Dime] DIME Status Update, October 2007 Date: Fri, 26 Oct 2007 11:55:11 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote: > Hi Ken, > > ken carlberg wrote: >> Hannes, >> >> What are your thoughts about defining a new AVP exclusively for >> priority? I don't have concerns about the inclusion of priority >> in the QoS parameters draft. However, I recently came across an >> email exchange related to IMS where one of the participants didn't >> want to consider using the QoS parameters draft for validating SIP >> R-P information because of the bundled QoS. > Can you more specific on how the desired approach would look like? at a very high level, an approach that strips out the QoS elements discussed in draft-ietf-dime-diameter-qos-01.txt draft-ietf-dime-qos-parameters-01.txt and focuses on the application of AAA of Priority values we may see from protocols like SIP and its R-P header. And yes, this probably equates to thinner documents :-) -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 27 06:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljMd-0002Qk-EF; Sat, 27 Oct 2007 06:57:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IljMc-0002QQ-1E for dime@ietf.org; Sat, 27 Oct 2007 06:57:58 -0400 Received: from [59.36.102.60] (helo=21cn.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IljMW-0001jx-BC for dime@ietf.org; Sat, 27 Oct 2007 06:57:53 -0400 HMM_SOURCE_IP: 10.27.2.2:57705.90693426 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from 21cn.com (dgproxy2.inner-hermes.com [10.27.2.2]) by 21cn.com (HERMES) with ESMTP id CF5EF38049 for ; Sat, 27 Oct 2007 18:57:46 +0800 (CST) Received: from aisp2-smtp?dg (dgproxy2.inner-hermes.com [10.27.2.2]) by 21cn.com (HERMES) with ESMTP for ; Sat, 27 Oct 2007 18:57:46 +0800 (CST) Received: from zhangjj([221.137.90.38]) by aisp2-smtp@dg(Knowledge-based Antispam Gateway 2.126g1) with ESMTP id local19082.1193482665 for ; Sat Oct 27 18:57:47 2007 +0800 X-Original-AuthLogin: zlupin@21cn.com Date: Sat, 27 Oct 2007 18:57:53 +0800 From: "zlupin" To: "dime" Message-ID: <200710271857520311767@21cn.com> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Dime] redirect answer X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1356828423==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1356828423== Content-Type: multipart/alternative; boundary="=====003_Dragon870104874061_=====" This is a multi-part message in MIME format. --=====003_Dragon870104874061_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hello, As RFC 3588 said 6.1.7. Redirecting requests When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in separate Redirect-Host AVP. I have a doubt. If the redirect answer would only contain the Result-Code AVP and Redirect-Host AVP? Will those mandatory AVPs be in the redirect answer? Eg. for UAR, if Auth-Session-State in the redirect answer? Thanks 2007-10-27 zlupin --=====003_Dragon870104874061_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit

Hello,
 
As RFC 3588 said
6.1.7.  Redirecting requests
   When a redirect agent receives a request whose routing entry is set
   to REDIRECT, it MUST reply with an answer message with the 'E' bit
   set, while maintaining the Hop-by-Hop Identifier in the header, and
   include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION.  Each of
   the servers associated with the routing entry are added in separate
   Redirect-Host AVP.
I have a doubt.
If the redirect answer would only contain the Result-Code AVP and Redirect-Host AVP?
Will those mandatory AVPs be in the redirect answer?
Eg. for UAR,  if Auth-Session-State in the redirect answer?
 
Thanks
 
 
2007-10-27
zlupin
--=====003_Dragon870104874061_=====-- --===============1356828423== 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://www1.ietf.org/mailman/listinfo/dime --===============1356828423==-- From dime-bounces@ietf.org Sat Oct 27 15:50:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilrfi-0000gf-Cw; Sat, 27 Oct 2007 15:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ilrfh-0000gE-4t for dime@ietf.org; Sat, 27 Oct 2007 15:50:13 -0400 Received: from igate.tek.com ([192.65.41.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlrfW-00068o-10 for dime@ietf.org; Sat, 27 Oct 2007 15:50:08 -0400 Received: from tektronix.tek.com (tektronix.tek.com [128.181.6.43]) by igate.tek.com (8.13.8+Sun/8.12.10) with ESMTP id l9RJnd9G001660; Sat, 27 Oct 2007 12:49:39 -0700 (PDT) Received: from us-bv-m20.global.tektronix.net (us-bv-m20.bv.tek.com [128.181.2.146]) by tektronix.tek.com (8.13.8+Sun/8.13.8) with SMTP id l9RJnap4022967; Sat, 27 Oct 2007 12:49:38 -0700 (PDT) From: sunil.khiani@tektronix.com Received: from us-rich-m01.global.tektronix.net ([192.158.160.18]) by us-bv-m20.global.tektronix.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Oct 2007 12:49:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] redirect answer Date: Sat, 27 Oct 2007 14:49:34 -0500 Message-ID: <0B161234D9EAC142ACCFE7C49AA97BA52A505E@us-rich-m01.global.tektronix.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] redirect answer Thread-Index: AcgY0Ycp6linbeNjTlSCgipel8mN+g== References: <200710271857520311767@21cn.com> To: , X-OriginalArrivalTime: 27 Oct 2007 19:49:36.0286 (UTC) FILETIME=[80C82BE0:01C818D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org To expand on zlupin's question. If application encounters error, it can = give hint in the answer using the AVPS - Result code and FailedAVPs. = But does the application need to send the mandatory AVPs in the answer = message? Thanks, sunil Tektronix -----Original Message----- From: zlupin [mailto:zlupin@21cn.com] Sent: Sat 10/27/2007 5:57 AM To: dime Subject: [Dime] redirect answer =20 Hello, As RFC 3588 said 6.1.7. Redirecting requests When a redirect agent receives a request whose routing entry is set to REDIRECT, it MUST reply with an answer message with the 'E' bit set, while maintaining the Hop-by-Hop Identifier in the header, and include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of the servers associated with the routing entry are added in separate Redirect-Host AVP. I have a doubt.=20 If the redirect answer would only contain the Result-Code AVP and = Redirect-Host AVP? Will those mandatory AVPs be in the redirect answer? Eg. for UAR, if Auth-Session-State in the redirect answer? Thanks 2007-10-27=20 zlupin=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Oct 27 17:45:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IltSV-0001jg-3b; Sat, 27 Oct 2007 17:44:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IltST-0001Qn-SZ for dime@ietf.org; Sat, 27 Oct 2007 17:44:41 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IltSJ-0001Zl-Nf for dime@ietf.org; Sat, 27 Oct 2007 17:44:37 -0400 Received: by py-out-1112.google.com with SMTP id d32so3981482pye for ; Sat, 27 Oct 2007 14:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=BxaUoYMrbEejiPVttgn6lqdHqCVZNbYxsAQt/F4nKpo=; b=nHHg2lXWfF6WZJmM//PgzT/J2+hqdP9J/1Cc501eJ0XxbzJ8TH89DvxfEXmxiKgnX0bd+Up8Isy8Ly83nN2nFihlzq9sNMs6B2U/y/WrKY/M+npBJnKu6j5XBkDI9IIi2wgUhHy+IjBFnIkLEnVglB2VbWtutE+1tp5dFbqGyBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KeGdDVm1itv3W4ErPsaWubcQampVGaLUSppX+5Lc8BMLEKgKslza2r2FpGzIzvD+LtKp+K3EnBlaMcq2MqzVGN1HavN12/dwKqtEilI12kSfJjRqYoJ75mnxp3tFUlrzbWQadSg9prmDDEoGzzrVOuiaHYtXShitEIPpIgy9LP4= Received: by 10.35.63.2 with SMTP id q2mr5238255pyk.1193521419320; Sat, 27 Oct 2007 14:43:39 -0700 (PDT) Received: by 10.35.68.15 with HTTP; Sat, 27 Oct 2007 14:43:39 -0700 (PDT) Message-ID: Date: Sat, 27 Oct 2007 23:43:39 +0200 From: "Thomas Lindgren" To: "sunil.khiani@tektronix.com" Subject: Re: [Dime] redirect answer In-Reply-To: <0B161234D9EAC142ACCFE7C49AA97BA52A505E@us-rich-m01.global.tektronix.net> MIME-Version: 1.0 References: <200710271857520311767@21cn.com> <0B161234D9EAC142ACCFE7C49AA97BA52A505E@us-rich-m01.global.tektronix.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: zlupin@21cn.com, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============0225184324==" Errors-To: dime-bounces@ietf.org --===============0225184324== Content-Type: multipart/alternative; boundary="----=_Part_3525_30414662.1193521419311" ------=_Part_3525_30414662.1193521419311 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/27/07, sunil.khiani@tektronix.com wrote: > > To expand on zlupin's question. If application encounters error, it can > give hint in the answer using the AVPS - Result code and FailedAVPs. But > does the application need to send the mandatory AVPs in the answer message? As I understand it, redirects are classified as protocol errors with the E-bit set (7.1.3), so they should conform to Section 7.2 rather than the command-specific grammar. (References are to RFC 3588.) Best, Thomas -- Thomas Lindgren, Millpond Services Ltd ------=_Part_3525_30414662.1193521419311 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 10/27/07, sunil.khiani@tektronix.com <sunil.khiani@tektronix.com > wrote:
To expand on zlupin's question.  If application encounters error, it can give hint in the answer using the AVPS - Result code and FailedAVPs.  But does the application need to send the mandatory AVPs in the answer message?

As I understand it, redirects are classified as protocol errors with the E-bit set (7.1.3), so they should conform to Section 7.2 rather than the command-specific grammar. (References are to RFC 3588.)

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd



------=_Part_3525_30414662.1193521419311-- --===============0225184324== 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://www1.ietf.org/mailman/listinfo/dime --===============0225184324==-- From dime-bounces@ietf.org Sun Oct 28 08:18:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im756-0007sE-1q; Sun, 28 Oct 2007 08:17:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im754-0007ld-Vh for dime@ietf.org; Sun, 28 Oct 2007 08:17:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Im74u-00006a-Fv for dime@ietf.org; Sun, 28 Oct 2007 08:17:17 -0400 Received: (qmail invoked by alias); 28 Oct 2007 12:17:03 -0000 Received: from p54984246.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.66.70] by mail.gmx.net (mp024) with SMTP; 28 Oct 2007 13:17:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19sWjkZ6lNspriYH0dBcYA+qM1/OUAxC7sK2ElqC6 ++JwKgln4FycQD Message-ID: <47247DBF.9090101@gmx.net> Date: Sun, 28 Oct 2007 13:17:03 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg References: <471DA62B.9050706@gmx.net> <47220518.1020006@gmx.net> <8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk> In-Reply-To: <8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: dime@ietf.org Subject: [Dime] RPH Example X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Ken, let me give you a concrete example. Let's assume a SIP proxy receives a RPH and wants to ask the AAA server whether this user is authorized to use this specific RPH. Here is how this could look like, assuming that Filter-Rules are not important in this specific case (they are optional anyway). AAA client -> AAA server: ---------------------------- * QoS-ObjectType with the information that the provided QoS information is of type "QoS-Desired". The semantic is "Please authorize the indicated QoS" * RPH Priority Parameter (from Section 4.11 of http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt) encapsulated in the QoSBlob AVP (as the only QoS parameter in this example). These two AVPs are encapsulated in the QoSBlob-Group and contained in the QoS-Resources AVP. This encapsulation is simply necessary when you use grouped AVPs. Without using grouped AVPs one would have to add additional fields to indicate how the individual AVPs relate to each other. Note that the QoS-Profile AVP, which indicates the QoS profile, is not necessary in this example since the RPH Priority refers to a parameter from the base profile document. (This is not yet in the draft since we haven't published the updated draft based on the provided feedback yet). AAA client <- AAA server: ---------------------------- Authorization successful or failed. No QoS information needs to be repeated here in our example. Now you tell me what should be further removed. Is this really complicated or does the current document just look complicated? Ciao Hannes ken carlberg wrote: > > On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote: > >> Hi Ken, >> >> ken carlberg wrote: >>> Hannes, >>> >>> What are your thoughts about defining a new AVP exclusively for >>> priority? I don't have concerns about the inclusion of priority in >>> the QoS parameters draft. However, I recently came across an email >>> exchange related to IMS where one of the participants didn't want to >>> consider using the QoS parameters draft for validating SIP R-P >>> information because of the bundled QoS. >> Can you more specific on how the desired approach would look like? > > at a very high level, an approach that strips out the QoS elements > discussed in > draft-ietf-dime-diameter-qos-01.txt > draft-ietf-dime-qos-parameters-01.txt > and focuses on the application of AAA of Priority values we may see >> from protocols like SIP and its R-P header. And yes, this probably > equates to thinner documents :-) > > -ken _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Oct 28 14:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImDCT-0003fC-G7; Sun, 28 Oct 2007 14:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImDCS-0003UA-BE for dime@ietf.org; Sun, 28 Oct 2007 14:49:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ImDCD-0005jU-04 for dime@ietf.org; Sun, 28 Oct 2007 14:49:19 -0400 Received: (qmail invoked by alias); 28 Oct 2007 18:48:45 -0000 Received: from p54984246.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.66.70] by mail.gmx.net (mp053) with SMTP; 28 Oct 2007 19:48:45 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+uSXhQkISuvU71b6SWPBUvIarXt1AJf1VhGrg3Z/ m3fVlSt69xJy9Q Message-ID: <4724D989.4060401@gmx.net> Date: Sun, 28 Oct 2007 19:48:41 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ken carlberg Subject: Re: [Dime] RPH Example References: <471DA62B.9050706@gmx.net> <47220518.1020006@gmx.net> <8A325B3A-255F-4576-A2C9-9108DE26E6CD@g11.org.uk> <47247DBF.9090101@gmx.net> In-Reply-To: <47247DBF.9090101@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I should also add that there is no problem with the fact that the draft-ietf-dime-qos-parameters-01.txt document defines a large number of parameters. If only a subset of them are needed in a specific environment then a new QoS profile is defined that might include a subset of these parameters and potentially defines new parameters. The extensibility model provides other SDOs the ability to define their own parameters and also to register a new QoS model. We specifically considered these aspects since other SDOs have already defined their own QoS parameters. These parameters can then easily be used. Hope that this helps. Ciao Hannes Hannes Tschofenig wrote: > Hi Ken, > > let me give you a concrete example. > > Let's assume a SIP proxy receives a RPH and wants to ask the AAA > server whether this user is authorized to use this specific RPH. > Here is how this could look like, assuming that Filter-Rules are not > important in this specific case (they are optional anyway). > > > AAA client -> AAA server: > ---------------------------- > > * QoS-ObjectType > > with the information that the provided QoS information is of type > "QoS-Desired". The semantic is > "Please authorize the indicated QoS" > > * RPH Priority Parameter (from Section 4.11 of > http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt) > encapsulated > in the QoSBlob AVP (as the only QoS parameter in this example). > > These two AVPs are encapsulated in the QoSBlob-Group and contained in > the QoS-Resources AVP. This encapsulation is simply necessary when you > use grouped AVPs. Without using grouped AVPs one would have to add > additional fields to indicate how the individual AVPs relate to each > other. > > Note that the QoS-Profile AVP, which indicates the QoS profile, is not > necessary in this example since the RPH Priority refers to a parameter >> from the base profile document. (This is not yet in the draft since we > haven't published the updated draft based on the provided feedback yet). > > > > AAA client <- AAA server: > ---------------------------- > > Authorization successful or failed. No QoS information needs to be > repeated here in our example. > > > Now you tell me what should be further removed. Is this really > complicated or does the current document just look complicated? > > > Ciao > Hannes > > ken carlberg wrote: >> >> On Oct 26, 2007, at 11:17 AM, Hannes Tschofenig wrote: >> >>> Hi Ken, >>> >>> ken carlberg wrote: >>>> Hannes, >>>> >>>> What are your thoughts about defining a new AVP exclusively for >>>> priority? I don't have concerns about the inclusion of priority in >>>> the QoS parameters draft. However, I recently came across an email >>>> exchange related to IMS where one of the participants didn't want >>>> to consider using the QoS parameters draft for validating SIP R-P >>>> information because of the bundled QoS. >>> Can you more specific on how the desired approach would look like? >> >> at a very high level, an approach that strips out the QoS elements >> discussed in >> draft-ietf-dime-diameter-qos-01.txt >> draft-ietf-dime-qos-parameters-01.txt >> and focuses on the application of AAA of Priority values we may see >>> from protocols like SIP and its R-P header. And yes, this probably >> equates to thinner documents :-) >> >> -ken > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Oct 31 19:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMcX-0001Sh-GB; Wed, 31 Oct 2007 19:05:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMcW-0001Rj-3O for dime@ietf.org; Wed, 31 Oct 2007 19:05:08 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InMcN-0005XV-CN for dime@ietf.org; Wed, 31 Oct 2007 19:05:08 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l9VN4w7P006489 for ; Wed, 31 Oct 2007 18:04:58 -0500 (CDT) Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.11]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 18:04:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Dime]: A Potential Issue with the New Text for RFC 3558bis Date: Wed, 31 Oct 2007 18:04:56 -0500 Message-ID: <5531D43D854B3445955E3AD9CEBA28D0EE761C@ILEXC2U03.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime]: A Potential Issue with the New Text for RFC 3558bis Thread-Index: AcgcEnRCfzaiB6YhS9OpHPB1q6848A== From: "Zeltsan, Zachary \(Zachary\)" To: X-OriginalArrivalTime: 31 Oct 2007 23:04:57.0864 (UTC) FILETIME=[750A0880:01C81C12] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 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="===============1245028577==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1245028577== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81C12.74C09264" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81C12.74C09264 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have noticed what appears to be an omission in draft-ietf-dime-rfc3558bis.=20 Whereas RFC 3558 explicitly required IPsec for the client with an option for TLS, now the TLS is mentioned as an OPTION, but nothing is said about IPsec. Is IPsec still mandatory? If not, is it still an option? I strongly believe that the text must be explicit. Zachary Zeltsan ------_=_NextPart_001_01C81C12.74C09264 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [Dime]: A Potential Issue with the New Text for RFC = 3558bis

I have noticed what appears to be an = omission in draft-ietf-dime-rfc3558bis.
Whereas RFC 3558 explicitly required = IPsec for the client with an option for TLS, now the TLS is mentioned as = an OPTION, but nothing is said about IPsec. Is IPsec still mandatory? If = not, is it still an option? I strongly believe that the text must be = explicit.

Zachary Zeltsan

------_=_NextPart_001_01C81C12.74C09264-- --===============1245028577== 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://www1.ietf.org/mailman/listinfo/dime --===============1245028577==--