From dime-bounces@ietf.org Wed Aug 01 03:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG8bZ-0002Pk-89; Wed, 01 Aug 2007 03:26:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG8bX-0002O1-Oi for dime@ietf.org; Wed, 01 Aug 2007 03:26:47 -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 1IG8bX-0004QG-28 for dime@ietf.org; Wed, 01 Aug 2007 03:26:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l717QPXE024260; Wed, 1 Aug 2007 10:26:41 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 10:26:39 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 02:26:37 -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: RE: [Dime] Vendor-Specific Commands Date: Wed, 1 Aug 2007 02:26:36 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfQcc0oGPBYjiupQCqeghAIg0ncsQDmrJ3Q References: From: To: , X-OriginalArrivalTime: 01 Aug 2007 07:26:37.0619 (UTC) FILETIME=[4BE32830:01C7D40D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Mark, Here is my 2 cents on this. When this was an issue with the IESG, the IESG at that time wanted strong change control over Diameter, like there is with SIP. There was a concern that some vendor extensions might become defacto standards that would negative impact upon interop. I have heard similar complaints with RADIUS, where small companies must licence vendor specs from large companies (as a note, I do work for a large company with proprietary RADIUS extentions). This is a real issue for some parts of RADIUS in certain network deployments. There is another issue about SDO usage of vendor codes. For some SDOs, like 3GPP, it is less of an issue because 3GPP specifications are relatively easy to access. However, for some SDOs, you have to either be a member of that SDO to access the specifications or pay money to access those specifications. What the IESG had hoped was that SDOs would submit their Diameter extensions to the IETF, so that these specifications would be at least available for anyone who wanted to implement them. I would think that the best possible solution for vendor specifc command code would be to allocate a range of codes that IANA would freely handout as long as there was a specification pubically available. Ideally this would be an information RFC (perhaps even submitted directly to the RFC editor) so that there would be documentation on the extension. John=20 >-----Original Message----- >From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 >Sent: 27 July, 2007 20:15 >To: dime@ietf.org >Subject: [Dime] Vendor-Specific Commands > >The Diameter command header originally contained a Vendor Id=20 >to allow vendor-specific commands. If I remember correctly, it=20 >was removed following IESG review due to interop concerns.=20 >However, the command mangling that is occurring now due to the=20 >lack of vendor-specific commands is complicating command=20 >routing and will lead to interop issues. > >The least invasive way to bring back vendor-specific commands=20 >is to sub-divide the Command code namespace (as was done for=20 >Application Id) to allow a vendor-specific range that is=20 >allocated by IANA on a 'First Come First Served' basis. We=20 >should take the opportunity to address this in 3588bis. > >Vendor-specific applications are allocated by IANA on a 'First=20 >Come First Served' basis. Vendor-specific AVPs just require a=20 >vendor id (also 'First Come First Served'). The 'IETF=20 >Consensus' policy for new Command codes is so incongruous that=20 >it looks like a 'bug' in RFC3588 to me. I suspect this=20 >restrictive policy was originally just intended for IETF=20 >commands and we should also fix this in 3588bis. > >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 Wed Aug 01 04:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9yG-0007NU-MT; Wed, 01 Aug 2007 04:54:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG9yF-0007NO-NF for dime@ietf.org; Wed, 01 Aug 2007 04:54:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IG9yF-0007Lc-6p for dime@ietf.org; Wed, 01 Aug 2007 04:54:19 -0400 Received: (qmail invoked by alias); 01 Aug 2007 08:54:17 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp036) with SMTP; 01 Aug 2007 10:54:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1//iTMMLH7/1adL0B/x2s8nKXQkcomPg+Ki5V7bia M9gEnQq6zFIhSe Message-ID: <46B04A34.3040706@gmx.net> Date: Wed, 01 Aug 2007 10:54:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: d17f825e43c9aed4fd65b7edddddec89 Cc: "David B. Nelson" Subject: [Dime] Diameter QoS Draft Reviewers 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 would like to thank * Tolga Asveren * Victor Fajardo * David B. Nelson for their willingness to review the Diameter QoS draft within the next 2 weeks. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 04:56: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 1IGA04-0000HQ-EU; Wed, 01 Aug 2007 04:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGA03-0000HK-Rf for dime@ietf.org; Wed, 01 Aug 2007 04:56:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGA02-0005aC-Ce for dime@ietf.org; Wed, 01 Aug 2007 04:56:11 -0400 Received: (qmail invoked by alias); 01 Aug 2007 08:56:08 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp049) with SMTP; 01 Aug 2007 10:56:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+EjPVbp1CEjLZvgp1r510HmJIEU7T2i4kgVhEt/5 11ooxzMHIQPlmn Message-ID: <46B04AA6.1020400@gmx.net> Date: Wed, 01 Aug 2007 10:56:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Dime] Diameter QoS Attributes Reviewers 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 would like to thank * Victor Fajardo * Frank Xia for their willingness to review the Diameter QoS Attributes draft within the next 2 weeks. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 04:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGA3Z-0002u1-DQ; Wed, 01 Aug 2007 04:59:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGA3Y-0002tD-9q for dime@ietf.org; Wed, 01 Aug 2007 04:59:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGA3X-0007Qn-Ol for dime@ietf.org; Wed, 01 Aug 2007 04:59:47 -0400 Received: (qmail invoked by alias); 01 Aug 2007 08:59:46 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp044) with SMTP; 01 Aug 2007 10:59:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Xb98JyQKX9+fGjH68ITISPoILgwUoAJDgkd2myW 5uG2oRtBrbvjRF Message-ID: <46B04B7E.4040404@gmx.net> Date: Wed, 01 Aug 2007 10:59:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Ulf Bodin , aland@nitros9.org, Wolfgang.Steigerwald@t-systems.com Subject: [Dime] Diameter Design Guidelines Draft Reviewers 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 would like to thank * Wolfgang Steigerwald * Ulf Bodin * Alan DeKok for their willingness to review the Diameter Design Guidelines draft within the next 2 weeks. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 05:07: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 1IGAAi-000352-S1; Wed, 01 Aug 2007 05:07:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGA5k-0005xW-PE for dime@ietf.org; Wed, 01 Aug 2007 05:02:04 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGA5k-0007Tq-7U for dime@ietf.org; Wed, 01 Aug 2007 05:02:04 -0400 Received: (qmail invoked by alias); 01 Aug 2007 09:02:02 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp037) with SMTP; 01 Aug 2007 11:02:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19j9ngf8UJjOrEEeCszc35kYEX0S40ozcLrjJPQUC fPvat+OGKS73Ve Message-ID: <46B04C06.3040002@gmx.net> Date: Wed, 01 Aug 2007 11:01:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Dime] Diameter Mobile IPv6: HA<->AAA Draft Reviewers 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 would like to thank * Jouni Korhonen * Ahmad Muhanna for their willingness to review the Diameter Mobile IPv6: HA<->AAA draft within the next 2 weeks. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 05:18:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGALF-0005xu-Ry; Wed, 01 Aug 2007 05:18:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGA9P-0001jT-5n for dime@ietf.org; Wed, 01 Aug 2007 05:05:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGA9O-0007a1-Cy for dime@ietf.org; Wed, 01 Aug 2007 05:05:50 -0400 Received: (qmail invoked by alias); 01 Aug 2007 09:05:49 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp041) with SMTP; 01 Aug 2007 11:05:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/hsfFMcJfhKfkqL5kbXdfq75jIvY1MEFyQS2tLm7 CQB6E/M+yz1fJ6 Message-ID: <46B04CEB.5010407@gmx.net> Date: Wed, 01 Aug 2007 11:05:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Dime] MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 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 Ahmad, you raised some interesting discussions during the DIME working group meeting. Unfortunately, there was not enough time to address all questions. I would be great if you could * summarize your presentation, and * address some of the raised questions on the mailing list. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 05:31: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 1IGAYL-0005nV-L0; Wed, 01 Aug 2007 05:31:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGAHJ-0002XV-9L for dime@ietf.org; Wed, 01 Aug 2007 05:14:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGAHI-0007kI-Q6 for dime@ietf.org; Wed, 01 Aug 2007 05:14:01 -0400 Received: (qmail invoked by alias); 01 Aug 2007 09:13:59 -0000 Received: from ip-90-186-91-117.web.vodafone.de (EHLO [90.186.91.117]) [90.186.91.117] by mail.gmx.net (mp050) with SMTP; 01 Aug 2007 11:13:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Mnh4m4smMGnuWarn2WBZ/P7IVqjL9vhas8XTq/S WbmHSocNtEGJWg Message-ID: <46B04ED5.7090208@gmx.net> Date: Wed, 01 Aug 2007 11:13:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) 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: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Dime] "AAA Framework for Multicasting" Reviewers 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 would like to thank * Jouni Korhonen * Tina Tsou for their willingness to review the "AAA Framework for Multicasting" (draft-ietf-mboned-multiaaa-framework-04.txt) draft within the next 2 weeks. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 08:10: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 1IGD2S-0003k1-SG; Wed, 01 Aug 2007 08:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGD2R-0003jw-KP for dime@ietf.org; Wed, 01 Aug 2007 08:10:51 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGD2R-0003cL-8l for dime@ietf.org; Wed, 01 Aug 2007 08:10:51 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71CAls05527; Wed, 1 Aug 2007 12:10:48 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 Date: Wed, 1 Aug 2007 07:10:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115E693A4@zrc2hxm2.corp.nortel.com> In-Reply-To: <46B04CEB.5010407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGKopg References: <46B04CEB.5010407@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Mohamed Khalil , McCann Peter-A001034 Subject: [Dime] RE: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 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, Thanks a lot for giving me the chance. I really Appreciate it. As far as the raised issues I can summarize them as follows and I will have separate threads (probably end of day or early tomorrow) for each one of them. 1. Is there any field data which support the use case that the draft is trying to address. (Issue raised by: Madjid and Jouni) 2. Is there any security issue when the FA relay the retransmitted initial RRQ without consulting AAA in the case of RADIUS-Mode. (Issue raised by: Pete McCann) Based on the discussion, I would like to update the draft and submit a new revision and possibly discuss the next steps. All, Please, let me know if there is any issue that was raised and I missed. Best Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, August 01, 2007 4:06 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: MIPv4 Authentication Performance Using RADIUS and=20 > Diameter MIPv4 >=20 > Hi Ahmad, >=20 > you raised some interesting discussions during the DIME=20 > working group meeting. Unfortunately, there was not enough=20 > time to address all questions. >=20 > I would be great if you could > * summarize your presentation, and > * address some of the raised questions > on the mailing list. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 08:27: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 1IGDIZ-0002Pf-KG; Wed, 01 Aug 2007 08:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDIY-0002PG-U8 for dime@ietf.org; Wed, 01 Aug 2007 08:27:30 -0400 Received: from legolas.restena.lu ([158.64.1.34] helo=smtp.restena.lu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGDIY-0003y7-0s for dime@ietf.org; Wed, 01 Aug 2007 08:27:30 -0400 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 17FFA3027257; Wed, 1 Aug 2007 14:27:29 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id 0697A3027241; Wed, 1 Aug 2007 14:27:29 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: radiusext@ops.ietf.org, dime@ietf.org Date: Wed, 1 Aug 2007 14:28:01 +0200 User-Agent: KMail/1.9.7 X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [Dime] First results on Diameter vs. RadSec patent research: EP1147635 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="===============0173265968==" Errors-To: dime-bounces@ietf.org --===============0173265968== Content-Type: multipart/signed; boundary="nextPart7300169.drvr3jyHbZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart7300169.drvr3jyHbZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, (sorry for cross-posting, this may also be of interest for dime) when presenting the RadSec draft in IETF69 Chicago, I mentioned the patent= =20 claims of Nokia concerning Diameter. As a reaction, some participants claim= ed=20 that RadSec itself implements a subset of the Diameter features and may ver= y=20 well itself be subject to these patents. So I started an investigation in=20 this respect. I started the research myself by grabbing a copy of patent EP1147635 by Nok= ia,=20 which is claiming to affect Diameter. My focus of the patent's examination= =20 was whether this patent might also affect RadSec. The content of this patent is, in short, that packets on a network get tagg= ed=20 as "possible duplicate" on retransmission in order to make the endpoint awa= re=20 that the received content may be a duplicate of a previous packet. It also= =20 provides a mechanism to correlate the multiple copies even when the packets= =20 took different paths through the network. Diameter does exactly that, described in section 5.5.4 "Failover and Failba= ck=20 Procedures" of RFC3588: a bit in the Diameter header, the "T" bit, is set=20 whenever a Diameter packet needed to be retransmitted. Also, Diameter packe= ts=20 carry an end-to-end identifier that makes it possible to identify duplicate= s. This means that at least from my point of view, Nokia's claim concerning=20 Diameter is true. Every implementation of the Diameter base protocol will u= se=20 the patented technology and needs to either license it or will violate it.= =20 (Note: I am not a lawyer. This is just my interpretation; consider my=20 knowledge being "Slashdot-level"). =46rom the wording in this section 5.5.4 and the explanation of the T bit i= n=20 chapter 3, it seems that setting the T bit is mandatory on retransmissions,= =20 so adhering to the protocol specification leaves no room for circumventing= =20 the content of the patent (e.g., by keeping it 0 at all times). Luckily, RadSec does not implement such a sophisticated duplicate packet=20 detection algorithm. So, this particular patent appears not to be of any=20 concern for implementors of RadSec. I will continue investigating the bunch of other patents and patent=20 applications relating to Diameter as soon as I get copies of them. For=20 reference, here is Nokia's claim statement concerning Diameter (as submitte= d=20 to the IETF IPR tracker): =2D--------- Title: Nokia's Statement About IPR Claimed in RFC 3588 Received: January 6, 2004 =46rom: harri.t.honkasalo@nokia.com This is to advise the IETF that Nokia believes the Nokia=20 patents: EP1147635 and AU757984, and the related patent=20 applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102,=20 JP2000-595452 and US09/903863 may be relevant to Diameter Base=20 Protocol RFC3588. Nokia agrees not to assert those claims in Nokia above mentioned=20 patents that apply to the RFC3588 and are technically necessary=20 to implement this IETF standard specification against any other=20 party in respect of its implementation of the specification, provided=20 that the party relying on this commitment does not assert its patents=20 against Nokia. Regards, Harri Honkasalo Director of IPR, Standard Technology Nokia Corporation =2D--------- Greetings, Stefan Winter =2D-=20 Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale= et de=20 la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224= 73 --nextPart7300169.drvr3jyHbZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsHxV+jm90f8eFWYRAk80AJ9wcXaA0GQY378kr+rg5QUcyq+CngCfRVqQ CTn9jCcaLF/s8ZCXvyWe7G4= =NX7w -----END PGP SIGNATURE----- --nextPart7300169.drvr3jyHbZ-- --===============0173265968== 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 --===============0173265968==-- From dime-bounces@ietf.org Wed Aug 01 08:57: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 1IGDlZ-0002US-Mn; Wed, 01 Aug 2007 08:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGDlX-0002R8-HW for dime@ietf.org; Wed, 01 Aug 2007 08:57:27 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGDlW-0005C1-2M for dime@ietf.org; Wed, 01 Aug 2007 08:57:27 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l71CvL912033; Wed, 1 Aug 2007 12:57:21 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 Date: Wed, 1 Aug 2007 07:57:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437115E69437@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710F5008A2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGKopgAAB2vqA= References: <46B04CEB.5010407@gmx.net> <6FC4416DDE56C44DA0AEE67BC7CA43710F5008A2@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Mohamed Khalil , McCann Peter-A001034 Subject: [Dime] RE: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 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, Sorry, I forgot to summarize my presentation. Here is the summary: The basic idea of this draft is the following: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Since some SDO's is considering the full deployment of Diameter for MIP4 Authentication, Authorization, and possibly MSA allocation, the following question presents itself: What is the anticipated impact of Diameter Mobile IPv4 Application for MIPv4 Authentication, Authorization, and possibly MSA dynamic allocation on the MIPv4 session setup in comparison of RADIUS-Model MIPv4 Authentication and Authorization, etc. High Level Summary of Diameter Mobile IPv4 Application: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D 1. The main functionality of the Diameter MIP4 Application is to Authenticate, Authorize, and optionally allocate Mobility Security Association of MN-HA and FA-HA. 2. In order for Diameter MIP4 Application to achieve step 1, Diameter MIP4 Application uses the AAA infrastructure and Diameter protocol not only to exchange Authentication and Authorization related parameters, BUT it also, include the MIPv4 RRQ and RRP. 3. In other words, the Foreign Agent does not directly relay the RRQ received from the MN to the Home Agent as per RFC3344, it includes the RRQ in the Diameter message AMA and receives the RRP in the Diameter message AMR. Criteria used for Comparison: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D 1. RFC3344 mandates; when the MN uses timestamp for replay protection, the MN must not retransmit a RRQ before 1 second. 2. In wireless networks, most MIPv4 clients sets the first retransmit timer to 1 second. This is important in order to get the session setup quickly and not waste air resources. 3. Then, what happens if due to some network condition the Mobile Node does not receive MIPv4 RRP within 1 second? How retransmitted initial MIPv4 RRQ message in handled in both models? ---------------------------------------------------------------------- RADIUS-Model MIP4 Auth Case: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D- 1. In the case of RADIUS Model MIPv4 Authentication, AAA infrastructure is used for Authentication, Authorization, etc. BUT NOT used for exchanging MIP4 RRQ and RRP between FA and HA. 2. Only in one condition (FA state), RADIUS-model will reauthenticate the MIPv4 user by contacting AAA server, it is the case when FA receives a retransmitted initial RRQ while waiting for AAA response. 3. In all other states, waiting for RRP, Received RRP, or Relayed RRP, the FA considers the user has been authenticated and relays the retransmitted RRQ directly to the HA without going through AAA infrastructure. Diameter MIP4 Application Case: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 1. In the case of Diameter MIPv4 Application,. AAA infrastructure is used for Authentication, Authorization, etc. AND is USED for exchanging MIP4 RRQ and RRP between FA and HA. 2. In all conditions (FA states), Diameter MIPv4 Application will reauthenticate the MIPv4 user by contacting AAA server. 3. Let us also remember that re-authentication of the user in the case of Diameter MIP4 Application is far more complicated and time consuming than in the case of RADIUS-Model. Conclusion: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In case the network condition creates a situation that the Mobile Node does not receive initial MIPv4 RRP within one second, Diameter MIPv4 Application will worsen the network condition by unnecessarily relaying the retransmitted RRQ via AAA (Diameter) infrastructure and re-authenticating the user instead of relaying the retransmitted RRQ DIRECTLY to the Home Agent. Best Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10)=20 > Sent: Wednesday, August 01, 2007 7:11 AM > To: 'Hannes Tschofenig'; 'dime@ietf.org' > Cc: 'Madjid Nakhjiri'; 'McCann Peter-A001034';=20 > 'jouni.korhonen@teliasonera.com'; Khalil, Mohamed=20 > (RICH2:2S20); 'Avi Lior' > Subject: RE: MIPv4 Authentication Performance Using RADIUS=20 > and Diameter MIPv4 >=20 > Hi Hannes, >=20 > Thanks a lot for giving me the chance. I really Appreciate it. >=20 > As far as the raised issues I can summarize them as follows=20 > and I will have separate threads (probably end of day or=20 > early tomorrow) for each one of them. >=20 > 1. Is there any field data which support the use case that=20 > the draft is trying to address. (Issue raised by: Madjid and=20 > Jouni) 2. Is there any security issue when the FA relay the=20 > retransmitted initial RRQ without consulting AAA in the case=20 > of RADIUS-Mode. (Issue raised by: Pete McCann) >=20 > Based on the discussion, I would like to update the draft and=20 > submit a new revision and possibly discuss the next steps. >=20 > All, > Please, let me know if there is any issue that was raised and=20 > I missed. >=20 > Best Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, August 01, 2007 4:06 AM > > To: dime@ietf.org > > Cc: Muhanna, Ahmad (RICH1:2H10) > > Subject: MIPv4 Authentication Performance Using RADIUS and Diameter=20 > > MIPv4 > >=20 > > Hi Ahmad, > >=20 > > you raised some interesting discussions during the DIME=20 > working group=20 > > meeting. Unfortunately, there was not enough time to address all=20 > > questions. > >=20 > > I would be great if you could > > * summarize your presentation, and > > * address some of the raised questions on the mailing list. > >=20 > > Ciao > > Hannes > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 10:09: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 1IGEtb-0005Mo-0T; Wed, 01 Aug 2007 10:09:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGEtZ-0005Ka-Rg for dime@ietf.org; Wed, 01 Aug 2007 10:09:49 -0400 Received: from gws03.mail.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGEtS-00006O-8H for dime@ietf.org; Wed, 01 Aug 2007 10:09:49 -0400 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id DF3BD37C194 for ; Wed, 1 Aug 2007 19:33:30 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws03.hcl.in (Postfix) with ESMTP id CD5C637C18Ffor ; Wed, 1 Aug 2007 19:33:30 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.15]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 19:39:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Aug 2007 19:39:13 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC601F7CF9D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Clarification regarding the election process Thread-Index: AcfUMYv6MKOJWWIFTNSTSPO05V9fWQAADk7wAAASmAAAAOJTUAAA0XYgAAGKv5 A= From: "Balamurugan T, TLS-Chennai" To: X-OriginalArrivalTime: 01 Aug 2007 14:09:37.0262 (UTC) FILETIME=[9813E0E0:01C7D445] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-8.9128 TC:1F TRN:95 TV:3.6.1039(15336.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.4 (++) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 Subject: [Dime] Clarification regarding the election process 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="===============0451865888==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0451865888== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7D445.5808925D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D445.5808925D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7D445.5808925D" ------_=_NextPart_002_01C7D445.5808925D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi All, =20 I need some clarification regarding the election process in peer state machine. =20 According to=20 http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite -04.txt ,=20 =20 The election process is described as below=20 =20 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.1.2. Election =20 This test case refers to Section 5.6.4 of [RFC3588]. Responders must be able to resolve contention with initiator peers. =20 o Positive test for establishment of connection with responder having higher identity than initiator. Vendor A initiates connection followed by B doing the same a few milliseconds later. Vendor A having a higher identity should close B's connection attempt. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + =20 =20 =20 But, in RFC 3588, section 5.6. Peer State Machine, 5th paragraph explains =20 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down. The responder connection will survive if the Origin-Host of the local Diameter entity is higher than that of the peer; the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ =20 These are contradicting. I guess the test draft should be corrected. As per RFC3588, =20 If A and B are two Peers, =20 =20 =20 Ai is the initiator of the connection C1; Br is the responder for the connection C1 Bi is the initiator of the connection C2; Ar is the responder for the connection C2 =20 Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process. =20 But the test draft,=20 http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite -04.txt explains differently. Please confirm that this draft needs to be corrected. =20 =20 Thanks, Bala =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_002_01C7D445.5808925D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi All,

 

    I need some= clarification regarding the election process in peer state machine.

 

   According= to http://www.opendiameter.org/public/draft-fajardo-di= me-interop-test-suite-04.txt, 

 
The election=
 process is described as below 
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++++
3.1.1.2. =
 Election
 
  =
 This test case refers to Section 5.6.4 of [RFC3588].  Responders=
 must
  =
 be able to resolve contention with initiator=
 peers.
 
  =
 o  Positive test for establishment of connection with=
 responder
      having higher identity=
 than initiator.  Vendor A=
 initiates
      connection followed by=
 B doing the same a few milliseconds=
 later.
      Vendor A having a higher identity should=
 close B's connection
     =
 attempt.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++

 

 

 

But, in RFC 3588, section  5.6. = Peer State Machine, 5th paragraph explains

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   A CER message is always sent on the initiating connection immediately

   after the connection request is successfully completed.  In the case

   of an election, one of the two connections will shut down. = The

   responder connection will survive if the Origin-Host of the= local

   Diameter= entity is higher than that of the peer; the initiator

   connection will survive if the= peer's Origin-Host is higher.  All

   subsequent messages are sent on the surviving connection.  Note that

   the results of an election on one= peer are guaranteed to be the

   inverse of the results on the= other.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

These are contradicting. I guess the test draft should be corrected. As per RFC3588,

 

If A and B are two= Peers,

 

 

Ai is the initiator of the connection C1; Br is= the responder for the connection C1

Bi is the initiator of the connection C2; Ar is= the responder for the connection C2

 

Now, during the election process, if Host IP= address of A is greater than that of B, C1 is closed and C2 is kept open for= further process. Similarly if the Host IP address of B is greater than that of A,= then C2 is closed and C1 is kept open for the further= process.

 

But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime= -interop-test-suite-04.txt explains differently. Please confirm that this draft needs to be= corrected.

 

 

Thanks,

Bala

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender= immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_002_01C7D445.5808925D-- ------_=_NextPart_001_01C7D445.5808925D Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhyQE4AXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAJADJ ARQBhQAAAAAAAA0NDRUVFR0dHQgICAEBARgYGBYWFhwcHDMzMz8/PyAgIDs7Ozc3NzY2Njk5OV9f X0ZGRkdHR0BAQFVVVUNDQ1FRUXt7e39/f319fXJycnBwcGxsbI+Pj5mZmZ+fn7+/v9PT09fX19/f 38PDw/7+/uXl5ejo6Ofn5/f39////wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwb/QIBwSCwah6ukcslsOp+ro3RKrVqv2Kx2y+16v+Cw eNyFms9OslqKbqPX8Lh8Tq/b73W3/okP7/9LfYKDhIWGh3eAiohaioCMkJGSk5Ryjn+VbJd6mZ2e n6CRm5yhQqNupamqq6xbp22pr2+ttLW2sbJmqrm6t76/wIa8ULjDTcHIycpwxmnFaAGXy9PU1VYm UAHa29Kle9GL1uLj1dhm4CvomM/n6Y7k8PG/5tlL6qShetH3qPL+/6roPVHHDxa7egUNAlzIcJJA J+gSzsrXJuKjhhgzGnrYZJu2dwchKpHYS6PJk3M4MiEYjiI0jxdRypwpRqW9lTFd1ru5jqbP/59Y bI7E2RNUs2NAkyo9cpTJrqZKlkpdCjWqt6pRpmr9iTXr1apbw8rsGtKY2LMmyZYdhrYtQ7Vfn5xA Mcqt3X9oRJxCFuCu37t9NQb+S/js4IyHCytemphh48WQfT5eODmyZcEmK1/e7PikZs6g430WHbp0 w9GkTauWh5pc69Wwf70eN5spgCi4b+vOzXu3797AfcceLqV2NeNFuk4kzhwAcmrPkSgv2Xx4dGXX b08nVp159mTZt3PvHvt7sPDinZEv79lPeqTrV5sHhv59oPiw59N3b98qftP6+VLfSx+xdIkJ/8nX HhgV2QMONwd6lSBoAd4y4E48JUESGghOWP9ahXMEJ+JvJPamQIkoAtdORxkqgo2HoUWT4owj1kjj bybkqOOOPPboo48YYPDjkD2esaE7B8IYI5FMNunkk9o1lUEGUB15pBkvKrnZlf0pN2WV0GzSoZaX cdlllEd92ZSVYkpI5mJmdlmVmmuyOFSSb1oWp31oNkNnnXcG6qKbeRK2p5xpUonoJoVGdmh6fRrz 56ItNWoopbLwc+SkmOJj6aUDefSoLJFiuAennfbzqWHaELGhRanidCiqsVK36laiDvFqi9OVKtKh ESww5bDEFmvsscgmq+yyxWoggXPQ9iVttNROa2212F6rbbbcbuttt+B+K2645I5rbrnonqv/brrs eivqRytqWOtQ9xw5AQMU5Kvvvvz2m28DDgQs8MAEF2zwwQg78IAA7zbs8MMQRyzxxBRXbPHFGGes 8cYcd+wxvBjWm86onDQor4abKsrorY3m6pyRMI0EMqKwnmwGrZ6yTKZHrhrZIsmYVBSzzVDgnLPO Sja2a4ZADyMy0U8YrRDSqy4daNMl+8w0GlJPTXXLWhONNaVdn/H1rWODNafK3ZwN9rzTlW2r22+m DZWvucg9N91Jwx0325XyvbPfSeAti97jCa6l3U2ZcqONwVVQAeQzKl7345hTrrlud4BoeYKe0xL6 5/iN3orppHeHuiqrp95c66nA7jp7mM2u/7jsoeBuO4CZ7S647p8A7ztnwmdS/PBlLog81cdT0vzy cCoPPcvPS1L99H9dH4n22LvFPSLfd49W+IeQLz6uvZ9ftfTq52k+Ie+3zxj78i+efv3u04+/h/EL 0v/+NPlfHwQIQP0BhIAFvB9iEpg0BTIQdAZ8oOocKMH4INAOF6zgPzI4Bw5qkDUR/KB1KCjC14Ww hAqqHQonSMIV5qeFLkyhCmM4whnSkHY2vKFqPBgHHuoQPCf8oZ5gKMQtBbGI0cshEol3xCUaiohO TKISowgZH67BilQ8XROz6D0octEvWFRDGL+YOy+SsYtmPKNh0qhGsYxxDG9sYyXiCAY6yv9xEnb8 Qh7vyIg9csGPfCzfFgOpFEBqwZCEHAQis7DIRHaOjY4ESiOvMMlIdhCSlgzgIDMpk0pSwZOcvOIm Q4nJ45DSjaM8JUZAWRxVoq+UruzMFGOpSVjScoO2vKU/WNlKXUoyl76EBy+PMMxgWqGYrjLmT5CZ TGXOhJlCgKYzjSBNaE1TDZvLJubCIM1qTm9R3EzlNZmCqHDOcpyuKGcdxYlOIoBznedsJxbeqUd2 ytNwvYLnAu/5BXp6oZreXJ4/u9BNfn5BKA4qkMyANqZ/2lOeCBXbgwT1h4YSFJj3jKimxOYIi/4x IABAkEhDStKRmrSkKDXpBjaQ0paedKT/hDImQgtC046GYQAjcKlOX7rTnvL0pFhBnHquOVN92BQM BCAB4fB5CqEO1ZlFNZmLwpBUwgUVcDmZZlTDNlWkKtVvTB2FU+Gj1XiZqqtfqKpVoTLW+4xTo3ZC kpio+lW4hXUTbXVrWblaM7lWlK5rZStWizLNgXJBrXZdWxNSQFhlGnYLiA2sWfXwpxRwoAB7aOdj tRDZhEKIV40zKiDUZNkCzMxrjlVnWusqEqjFah+jzUBph4ba1MoJsKZiXNbCNCsLmPZjwA2ucIdL 3OIa97jITS5wDVACs+rWaX51x2mXkAEMeOAAogqBdrfL3e6G4APy7AAAxEve8Zq3vOg9/69608te 84oBAayN69OwEtaafTZqVFKBBxhw39oaNBWdXQltp9ulvqZsCSDgb2b/W4sA/wy0R6nvgLmGVRA0 lsGlcDBF+yqn+R54ZRhmhYahxuHQclWuHwZxiAEcX6JwVLI3G+yCV6yKEVPqrpfIq39oHAobwzjH Mj4ajz3h43Iqti5D7nGLf9zUIKsqyZ8o8m2PrGIoZyIBS+7UI61sDYBy2ZTx/LKFHirmThS0zMvw MpqBGOY1s0LNbt5Pm+McOzLTGRJnvrOA7KxnQc65z56AM6C1+OdBz5HPhvYfRhNdCEEzuhR5fnSd Fy1pPES60qBwNKbNTOlN10HTnnZep+JDLQdQk3p7oz61KFOtajiyutViMDWsDXHpWfcR0bbW5ypz bT1c8/qihf51qX0t7EO+utiMJDayKXnsZR9T2c7+ZLOjPQVZU7uH0742NaGt7SLUutvDzja4rbnP cdPB2uY2Z7nTjW1xg/vb7Ha1u7sN73ire932lje+8x1rbpu73vwGdrADXu1509vf4wY4wY1t8Gsr fOFYQDfEnz3wiXsb4e9uuMMxfvCKW1xXHNf2wz9ecI1He+QkJ2bIN+5xkks85dtu+cdfDvNm7rvm VaA5zsm9651HfOXURrnPde7zUgQBADs= ------_=_NextPart_001_01C7D445.5808925D-- --===============0451865888== 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 --===============0451865888==-- From dime-bounces@ietf.org Wed Aug 01 10:45: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 1IGFRt-00077I-Of; Wed, 01 Aug 2007 10:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFRs-00077A-6S for dime@ietf.org; Wed, 01 Aug 2007 10:45:16 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFRn-0000MT-O8 for dime@ietf.org; Wed, 01 Aug 2007 10:45:15 -0400 Received: by nf-out-0910.google.com with SMTP id c10so60540nfd for ; Wed, 01 Aug 2007 07:45:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=IRWQS1jtO6Tw0M5fYVztbINN0ps63zfRyOZn386KgOIKtMbdpzd5IfB4AnMlM1OarWOGWx5ciPpAohN3DDw/uoBRnox620jMLgWYedqR7cOEo93QLVhC40fmKcLXhgUgPf8BfDCbZozC7BJU4I4AK7wdmEKOvVC0vBV5ocmItfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HNunSC7OD2CCaSd3laRdAqPJaPqa2YvPlM+qZAHVU4SyrhKNSyhrTHmGikBTmNx8jr0R3mhKJIvRi49d0znmuLA41yP7WXdCBw3UTzSzPvr83+vDC90AoYHNgHia36k77EhvoKclyL7AEsQWC7xf66ravMS/SFFdgfcM5lBeqoY= Received: by 10.82.152.16 with SMTP id z16mr931588bud.1185979510512; Wed, 01 Aug 2007 07:45:10 -0700 (PDT) Received: by 10.82.118.16 with HTTP; Wed, 1 Aug 2007 07:45:09 -0700 (PDT) Message-ID: <9cf5ced20708010745m2952427eq866d3ab1a3c6bb9b@mail.gmail.com> Date: Wed, 1 Aug 2007 10:45:10 -0400 From: "David Frascone" To: "john.loughney@nokia.com" Subject: Re: [Dime] Vendor-Specific Commands In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> MIME-Version: 1.0 References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> X-Google-Sender-Auth: 3c936ad63680a65f X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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="===============1049000214==" Errors-To: dime-bounces@ietf.org --===============1049000214== Content-Type: multipart/alternative; boundary="----=_Part_86352_7138219.1185979510419" ------=_Part_86352_7138219.1185979510419 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The problem here is that companies that want to develop something are just going to make a vendor specific application, then simply misuse existing commands. I'll be willing to wager that this is already happening. Since we already have vendor-specific applications and vendor-specific AVP's, I don't see any point in *not* having vendor-specific command codes. I would probably agree with you, if vendor-specific applications did not exist. So, now that people are already doing this, why not let the protocol actually allow it, instead of having everyone misuse the protocol to get their tasks done? -Dave (Again, the guy, not the chair) On 8/1/07, john.loughney@nokia.com wrote: > > Hi Mark, > > Here is my 2 cents on this. When this was an issue with the IESG, > the IESG at that time wanted strong change control over Diameter, like > there is with SIP. There was a concern that some vendor extensions > might > become defacto standards that would negative impact upon interop. > > I have heard similar complaints with RADIUS, where small companies must > licence vendor specs from large companies (as a note, I do work for a > large > company with proprietary RADIUS extentions). This is a real issue for > some parts of RADIUS in certain network deployments. > > There is another issue about SDO usage of vendor codes. For some SDOs, > like > 3GPP, it is less of an issue because 3GPP specifications are relatively > easy > to access. However, for some SDOs, you have to either be a member of > that > SDO to access the specifications or pay money to access those > specifications. > What the IESG had hoped was that SDOs would submit their Diameter > extensions > to the IETF, so that these specifications would be at least available > for anyone > who wanted to implement them. > > I would think that the best possible solution for vendor specifc command > code > would be to allocate a range of codes that IANA would freely handout as > long > as there was a specification pubically available. Ideally this would be > an > information RFC (perhaps even submitted directly to the RFC editor) so > that > there would be documentation on the extension. > > John > > >-----Original Message----- > >From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com] > >Sent: 27 July, 2007 20:15 > >To: dime@ietf.org > >Subject: [Dime] Vendor-Specific Commands > > > >The Diameter command header originally contained a Vendor Id > >to allow vendor-specific commands. If I remember correctly, it > >was removed following IESG review due to interop concerns. > >However, the command mangling that is occurring now due to the > >lack of vendor-specific commands is complicating command > >routing and will lead to interop issues. > > > >The least invasive way to bring back vendor-specific commands > >is to sub-divide the Command code namespace (as was done for > >Application Id) to allow a vendor-specific range that is > >allocated by IANA on a 'First Come First Served' basis. We > >should take the opportunity to address this in 3588bis. > > > >Vendor-specific applications are allocated by IANA on a 'First > >Come First Served' basis. Vendor-specific AVPs just require a > >vendor id (also 'First Come First Served'). The 'IETF > >Consensus' policy for new Command codes is so incongruous that > >it looks like a 'bug' in RFC3588 to me. I suspect this > >restrictive policy was originally just intended for IETF > >commands and we should also fix this in 3588bis. > > > >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 > -- David Frascone Know what I hate? I hate rhetorical questions! ------=_Part_86352_7138219.1185979510419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The problem here is that companies that want to develop something are just going to make a vendor specific application, then simply misuse existing commands.  I'll be willing to wager that this is already happening.

Since we already have vendor-specific applications and vendor-specific AVP's, I don't see any point in *not* having vendor-specific command codes.

I would probably agree with you, if vendor-specific applications did not exist.

So, now that people are already doing this, why not let the protocol actually allow it, instead of having everyone misuse the protocol to get their tasks done?

-Dave
(Again, the guy, not the chair)

On 8/1/07, john.loughney@nokia.com <john.loughney@nokia.com> wrote:
Hi Mark,

Here is my 2 cents on this.  When this was an issue with the IESG,
the IESG at that time wanted strong change control over Diameter, like
there is with SIP.  There was a concern that some vendor extensions
might
become defacto standards that would negative impact upon interop.

I have heard similar complaints with RADIUS, where small companies must
licence vendor specs from large companies (as a note, I do work for a
large
company with proprietary RADIUS extentions).  This is a real issue for
some parts of RADIUS in certain network deployments.

There is another issue about SDO usage of vendor codes.  For some SDOs,
like
3GPP, it is less of an issue because 3GPP specifications are relatively
easy
to access.  However, for some SDOs, you have to either be a member of
that
SDO to access the specifications or pay money to access those
specifications.
What the IESG had hoped was that SDOs would submit their Diameter
extensions
to the IETF, so that these specifications would be at least available
for anyone
who wanted to implement them.

I would think that the best possible solution for vendor specifc command
code
would be to allocate a range of codes that IANA would freely handout as
long
as there was a specification pubically available.  Ideally this would be
an
information RFC (perhaps even submitted directly to the RFC editor) so
that
there would be documentation on the extension.

John

>-----Original Message-----
>From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com ]
>Sent: 27 July, 2007 20:15
>To: dime@ietf.org
>Subject: [Dime] Vendor-Specific Commands
>
>The Diameter command header originally contained a Vendor Id
>to allow vendor-specific commands. If I remember correctly, it
>was removed following IESG review due to interop concerns.
>However, the command mangling that is occurring now due to the
>lack of vendor-specific commands is complicating command
>routing and will lead to interop issues.
>
>The least invasive way to bring back vendor-specific commands
>is to sub-divide the Command code namespace (as was done for
>Application Id) to allow a vendor-specific range that is
>allocated by IANA on a 'First Come First Served' basis. We
>should take the opportunity to address this in 3588bis.
>
>Vendor-specific applications are allocated by IANA on a 'First
>Come First Served' basis. Vendor-specific AVPs just require a
>vendor id (also 'First Come First Served'). The 'IETF
>Consensus' policy for new Command codes is so incongruous that
>it looks like a 'bug' in RFC3588 to me. I suspect this
>restrictive policy was originally just intended for IETF
>commands and we should also fix this in 3588bis.
>
>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



--
David Frascone

Know what I hate? I hate rhetorical questions! ------=_Part_86352_7138219.1185979510419-- --===============1049000214== 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 --===============1049000214==-- From dime-bounces@ietf.org Wed Aug 01 11:36: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 1IGGEy-0001r2-Ek; Wed, 01 Aug 2007 11:36:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGEw-0001qv-Qk for dime@ietf.org; Wed, 01 Aug 2007 11:35:58 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGGEw-0002Ue-EU for dime@ietf.org; Wed, 01 Aug 2007 11:35:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Vendor-Specific Commands Date: Wed, 1 Aug 2007 11:35:48 -0400 Message-ID: In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 would think that the best possible solution for vendor=20 > specific command code > would be to allocate a range of codes that IANA would freely=20 > handout as long > as there was a specification publicly available. =20 Excellent suggestion, John. This is already being done for Application Ids and IANA could follow the same reference rules for new command codes assignments: - IETF: Reference an RFC. - Non-IETF SDO: Reference an information RFC (preferred) or SDO spec. - Non-SDO Vendor: Reference is email of vendor contact person. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 12:11:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGnF-0001H1-1W; Wed, 01 Aug 2007 12:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGnD-0001Gw-FP for dime@ietf.org; Wed, 01 Aug 2007 12:11:23 -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 1IGGnD-0002ae-5u for dime@ietf.org; Wed, 01 Aug 2007 12:11:23 -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 l71GAnX7043893; Wed, 1 Aug 2007 12:10:49 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46B0B088.307@tari.toshiba.com> Date: Wed, 01 Aug 2007 12:10:48 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Vendor-Specific Commands References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> 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: 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 Hi Mark, >> I would think that the best possible solution for vendor >> specific command code >> would be to allocate a range of codes that IANA would freely >> handout as long >> as there was a specification publicly available. >> > > Excellent suggestion, John. This is already being done for Application > Ids and IANA could follow the same reference rules for new command codes > assignments: > > - IETF: Reference an RFC. > > - Non-IETF SDO: Reference an information RFC (preferred) or SDO spec. > This is ok. > - Non-SDO Vendor: Reference is email of vendor contact person. > I'm not sure if we should start distinguishing between non-IETF SDOs and vendors. It maybe better if they fall in the same category as the 'Non-IETF' above. Besides, 'vendor contact person' does not seem helpful if we want publicly available specification. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 12:31: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 1IGH6p-0001Bi-A3; Wed, 01 Aug 2007 12:31:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGH6n-0001Az-Pn for dime@ietf.org; Wed, 01 Aug 2007 12:31:37 -0400 Received: from smtp108.rog.mail.re2.yahoo.com ([68.142.225.206]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGH6n-00044C-Cw for dime@ietf.org; Wed, 01 Aug 2007 12:31:37 -0400 Received: (qmail 75909 invoked from network); 1 Aug 2007 16:31:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=LzLtQivs59IVY3JZIe30MR5ExSpHAa+JMiTd35nDuETBEIRj1iEUPLw4IEuQVw7S45MiJNKnvLmjNA7nVwNgeVKSgRgK41sRIdAiFF8qrqE1pjWwR2VllrPWASs0UMF8oG/VzDpGCv8DbkHmUAAJJh/zm0oVLQzQQ2kBW/G/TPE= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 1 Aug 2007 16:31:36 -0000 X-YMail-OSG: xmFWUKIVM1nqZ60Z1ncoqGt5LcoO.yKxFhETz6dEhHCgLdkV2DTZSYUocBWvgbqNkQ-- Message-ID: <46B0B568.80005@rogers.com> Date: Wed, 01 Aug 2007 12:31:36 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Vendor-Specific Commands References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> <46B0B088.307@tari.toshiba.com> In-Reply-To: <46B0B088.307@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Megaco packages have a public and private numbering space. For private numbers, only a package name and contact are needed. Any SDO can request a public space number upon production of a specification which is subject to expert review. Victor Fajardo wrote: > Hi Mark, > >>> I would think that the best possible solution for vendor specific >>> command code >>> would be to allocate a range of codes that IANA would freely handout >>> as long >>> as there was a specification publicly available. >> >> Excellent suggestion, John. This is already being done for Application >> Ids and IANA could follow the same reference rules for new command codes >> assignments: >> >> - IETF: Reference an RFC. >> >> - Non-IETF SDO: Reference an information RFC (preferred) or SDO spec. >> > > This is ok. > >> - Non-SDO Vendor: Reference is email of vendor contact person. >> > > I'm not sure if we should start distinguishing between non-IETF SDOs and > vendors. It maybe better if they fall in the same category as the > 'Non-IETF' above. Besides, 'vendor contact person' does not seem helpful > if we want publicly available specification. > > regards, > victor > > > _______________________________________________ > 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 Aug 01 13:12: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 1IGHkU-00048m-2n; Wed, 01 Aug 2007 13:12:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHkS-00045M-Ma for dime@ietf.org; Wed, 01 Aug 2007 13:12:36 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGHkR-0004E4-1s for dime@ietf.org; Wed, 01 Aug 2007 13:12:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71HCGhP030880; Wed, 1 Aug 2007 20:12:30 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 20:12:23 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 12:12: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: RE: [Dime] Vendor-Specific Commands Date: Wed, 1 Aug 2007 12:12:07 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59D745@daebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfUUa5+nA0uP1jZStm38RibGyMmEQADTmLg References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 01 Aug 2007 17:12:10.0063 (UTC) FILETIME=[1874ADF0:01C7D45F] X-Nokia-AV: Clean 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 Mark, Unfortunately, the IETF does not recognize the difference between SDOs and vendors. SDOs and Vendors would be in the same class. I think that there should be an stable reference of the spec that can be used for the command code for either SDOs and Vendors. Most likely, vendors could file an informational=20 RFC, if they like. John=20 >-----Original Message----- >From: ext Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 >Sent: 01 August, 2007 18:36 >To: Loughney John (Nokia-NRC/PaloAlto) >Cc: dime@ietf.org >Subject: RE: [Dime] Vendor-Specific Commands > >> I would think that the best possible solution for vendor specific=20 >> command code would be to allocate a range of codes that IANA would=20 >> freely handout as long as there was a specification publicly=20 >> available. > >Excellent suggestion, John. This is already being done for=20 >Application Ids and IANA could follow the same reference rules=20 >for new command codes >assignments: > >- IETF: Reference an RFC. > >- Non-IETF SDO: Reference an information RFC (preferred) or SDO spec. > >- Non-SDO Vendor: Reference is email of vendor contact person. > >Regards >Mark > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 13:15: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 1IGHnG-0007sl-1q; Wed, 01 Aug 2007 13:15:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHnA-0007qS-Lv; Wed, 01 Aug 2007 13:15:24 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGHn8-0005Ib-Ba; Wed, 01 Aug 2007 13:15:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l71HF26X013853; Wed, 1 Aug 2007 20:15:17 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 20:15:16 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 12:15:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 1 Aug 2007 12:15:02 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjA From: To: , , X-OriginalArrivalTime: 01 Aug 2007 17:15:06.0937 (UTC) FILETIME=[81E18290:01C7D45F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b83962958e2d910ed948e2f9e138d171 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: , Content-Type: multipart/mixed; boundary="===============0923404556==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0923404556== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D45F.8194DEFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I was asked to forward this to the DiME, RADext and OPSA WG mailing = lists. =20 =20 Thanks, John Dear Stefan, I asked John to forward this message as I'm not a regular on the DIME = list. I'm responsible for handling IETF related IPR cases in Nokia. As you suggested, Nokia believes EP1147635, and other members of the = same patent family, are essential to practice RFC3588. However, I do suggest that you, and other folks interested, contact = your respective legal folks regarding the implication of the existence = of the patent, in conjunction with our patent declaration. I do not = believe that Stefan's claim is correct: Every implementation of the =20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 In order to help the group to understand our declaration, please allow = me to provide a simplistic explanation. As for the binding legal = language, please see the declaration itself (cited correctly by Stefan = in his original email): Nokia agrees not to assert those claims in Nokia above =20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Our licensing declaration is what is commonly known as a "non-assert" = statement. What it says is that if you don't come after Nokia with your = patents, Nokia will not use its patents against your RFC 3588 = implementation. =20 Non-assert statements like this are widely used in the IETF, as they = are believed to provide sufficient defensive protection for the owner, = while still allowing implementers and users to exercise the protected = technology without a license and for free, as long as they behave = similarly nice (i.e. not going after Nokia with their patents). In = that, non-asserts are believed to be compatible with most open source = licenses. =09 =09 Feel free to contact me in private if you have more questions. =20 Best regards, Stephan Wenger Stephan.Wenger@nokia.com =20 -----Original Message----- From: ext Stefan Winter [mailto:stefan.winter@restena.lu]=20 Sent: 01 August, 2007 15:28 To: radiusext@ops.ietf.org; dime@ietf.org Subject: [Dime] First results on Diameter vs. RadSec patent=20 research:EP1147635 Hello all, (sorry for cross-posting, this may also be of interest for dime) when presenting the RadSec draft in IETF69 Chicago, I=20 mentioned the patent claims of Nokia concerning Diameter. As a=20 reaction, some participants claimed that RadSec itself=20 implements a subset of the Diameter features and may very well=20 itself be subject to these patents. So I started an=20 investigation in this respect. I started the research myself by grabbing a copy of patent=20 EP1147635 by Nokia, which is claiming to affect Diameter. My=20 focus of the patent's examination was whether this patent=20 might also affect RadSec. The content of this patent is, in short, that packets on a=20 network get tagged as "possible duplicate" on retransmission=20 in order to make the endpoint aware that the received content=20 may be a duplicate of a previous packet. It also provides a=20 mechanism to correlate the multiple copies even when the=20 packets took different paths through the network. Diameter does exactly that, described in section 5.5.4=20 "Failover and Failback Procedures" of RFC3588: a bit in the=20 Diameter header, the "T" bit, is set whenever a Diameter=20 packet needed to be retransmitted. Also, Diameter packets=20 carry an end-to-end identifier that makes it possible to=20 identify duplicates. This means that at least from my point of view, Nokia's claim=20 concerning Diameter is true. Every implementation of the=20 Diameter base protocol will use the patented technology and=20 needs to either license it or will violate it.=20 (Note: I am not a lawyer. This is just my interpretation;=20 consider my knowledge being "Slashdot-level"). From the wording in this section 5.5.4 and the explanation of=20 the T bit in chapter 3, it seems that setting the T bit is=20 mandatory on retransmissions, so adhering to the protocol=20 specification leaves no room for circumventing the content of=20 the patent (e.g., by keeping it 0 at all times). Luckily, RadSec does not implement such a sophisticated=20 duplicate packet detection algorithm. So, this particular=20 patent appears not to be of any concern for implementors of RadSec. I will continue investigating the bunch of other patents and=20 patent applications relating to Diameter as soon as I get=20 copies of them. For reference, here is Nokia's claim statement=20 concerning Diameter (as submitted to the IETF IPR tracker): ---------- Title: Nokia's Statement About IPR Claimed in RFC 3588 Received: January 6, 2004 From: harri.t.honkasalo@nokia.com This is to advise the IETF that Nokia believes the Nokia patents: EP1147635 and AU757984, and the related patent applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, JP2000-595452 and US09/903863 may be relevant to Diameter Base=20 Protocol RFC3588. Nokia agrees not to assert those claims in Nokia above=20 mentioned patents that apply to the RFC3588 and are=20 technically necessary to implement this IETF standard=20 specification against any other party in respect of its=20 implementation of the specification, provided that the party=20 relying on this commitment does not assert its patents against Nokia. Regards, Harri Honkasalo Director of IPR, Standard Technology Nokia Corporation ---------- Greetings, Stefan Winter -- Stefan WINTER RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education=20 Nationale et de la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu Tel.: +352 424409-1=20 http://www.restena.lu Fax: +352 422473 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C7D45F.8194DEFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I was asked to forward this to the DiME, = RADext=20 and OPSA WG mailing lists.  
 
Thanks,
John

Dear Stefan,

I asked John to forward this message as I'm not a regular on the = DIME=20 list.  I'm responsible for handling IETF related IPR cases in=20 Nokia.

As you suggested, Nokia believes EP1147635, and other members of = the same=20 patent family, are essential to practice RFC3588.

However, I do suggest that you, and other folks interested, = contact your=20 respective legal folks regarding the implication of the existence of = the=20 patent, in conjunction with our patent declaration.  I do not = believe=20 that Stefan's claim is correct:
Every=20 implementation of the 
Diameter base protocol will use the patented = technology=20 and 
needs to either license it or will violate=20 it. 

In order to help the group to understand our declaration, please = allow me=20 to provide a simplistic explanation.  As for the binding legal = language,=20 please see the declaration itself (cited correctly by Stefan in his = original=20 email):

Nokia agrees not to assert those claims in = Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Our licensing declaration is what is commonly known as a = "non-assert"=20 statement.  What it says is that if you don't come after Nokia = with your=20 patents, Nokia will not use its patents against your RFC 3588=20 implementation.
  
Non-assert statements like this are widely used in the IETF, as = they are=20 believed to provide sufficient defensive protection for the owner, = while still=20 allowing implementers and users to exercise the protected technology = without a=20 license and for free, as long as they behave similarly nice (i.e. not = going=20 after Nokia with their patents).  In that, non-asserts are = believed to be=20 compatible with most open source licenses.
Feel free to contact me in private if you have more = questions.
 
Best regards,
Stephan Wenger
Stephan.Wenger@nokia.com
 
 -----Original=20 Message-----
From: ext Stefan Winter [mailto:stefan.winter@restena.lu<= /A>] 
Sent: 01 August, 2007 15:28
To: radiusext@ops.ietf.org; = dime@ietf.org
Subject: [Dime] First results on = Diameter vs.=20 RadSec patent 
research:EP1147635

Hello all,

(sorry for cross-posting, this may also = be of=20 interest for dime)

when presenting the RadSec draft in = IETF69=20 Chicago, I 
mentioned the patent claims of Nokia = concerning=20 Diameter. As a 
reaction, some participants claimed = that RadSec=20 itself 
implements a subset of the Diameter = features and=20 may very well 
itself be subject to these patents. So = I started=20 an 
investigation in this respect.

I started the research myself by = grabbing a copy=20 of patent 
EP1147635 by Nokia, which is claiming = to affect=20 Diameter. My 
focus of the patent's examination was = whether=20 this patent 
might also affect RadSec.

The content of this patent is, in = short, that=20 packets on a 
network get tagged as "possible = duplicate" on=20 retransmission 
in order to make the endpoint aware = that the=20 received content 
may be a duplicate of a previous = packet. It also=20 provides a 
mechanism to correlate the multiple = copies even=20 when the 
packets took different paths through = the=20 network.

Diameter does exactly that, described = in section=20 5.5.4 
"Failover and Failback Procedures" of = RFC3588: a=20 bit in the 
Diameter header, the "T" bit, is set = whenever a=20 Diameter 
packet needed to be retransmitted. = Also, Diameter=20 packets 
carry an end-to-end identifier that = makes it=20 possible to 
identify duplicates.

This means that at least from my point = of view,=20 Nokia's claim 
concerning Diameter is true. Every = implementation=20 of the 
Diameter base protocol will use the = patented=20 technology and 
needs to either license it or will = violate=20 it. 
(Note: I am not a lawyer. This is just = my=20 interpretation; 
consider my knowledge being=20 "Slashdot-level").
From the wording in this section 5.5.4 = and the=20 explanation of 
the T bit in chapter 3, it seems that = setting the=20 T bit is 
mandatory on retransmissions, so = adhering to the=20 protocol 
specification leaves no room for = circumventing=20 the content of 
the patent (e.g., by keeping it 0 at = all=20 times).

Luckily, RadSec does not implement such = a=20 sophisticated 
duplicate packet detection algorithm. = So, this=20 particular 
patent appears not to be of any concern = for=20 implementors of RadSec.

I will continue investigating the bunch = of other=20 patents and 
patent applications relating to = Diameter as soon=20 as I get 
copies of them. For reference, here is = Nokia's=20 claim statement 
concerning Diameter (as submitted to = the IETF IPR=20 tracker):

----------

Title: Nokia's Statement About IPR = Claimed in RFC=20 3588
Received: January 6, 2004
From: harri.t.honkasalo@nokia.com

This is to advise the IETF that Nokia = believes=20 the Nokia
patents: EP1147635 and AU757984, and = the related=20 patent
applications: BRPI0007603-1, CA2360093, = CN00804050.8, FI990102,
JP2000-595452 and US09/903863 may be = relevant to=20 Diameter Base 
Protocol RFC3588.

Nokia agrees not to assert those claims = in Nokia=20 above 
mentioned patents that apply to the = RFC3588 and=20 are 
technically necessary to implement this = IETF=20 standard 
specification against any other party = in respect=20 of its 
implementation of the specification, = provided=20 that the party 
relying on this commitment does not = assert its=20 patents against Nokia.

Regards,

Harri Honkasalo

Director of IPR, Standard = Technology

Nokia Corporation

----------


Greetings,

Stefan Winter

--
Stefan WINTER

RESTENA Foundation - R=E9seau = T=E9l=E9informatique de=20 l'Education 
Nationale et de la Recherche R&D=20 Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: stefan.winter@restena.lu =  =20   Tel.:     +352 424409-1 
http://www.restena.lu   =  =20           Fax:      +352=20 422473

<signature.asc>
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime

------_=_NextPart_001_01C7D45F.8194DEFE-- --===============0923404556== 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 --===============0923404556==-- From dime-bounces@ietf.org Wed Aug 01 14:41: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 1IGJ8F-0008MU-2P; Wed, 01 Aug 2007 14:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJ89-0008AP-4l for dime@ietf.org; Wed, 01 Aug 2007 14:41:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGJ87-0006Qo-Ts for dime@ietf.org; Wed, 01 Aug 2007 14:41:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Aug 2007 11:41:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAF5wsEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,210,1183359600"; d="scan'208"; a="192611901:sNHT143034741" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l71If713002172; Wed, 1 Aug 2007 11:41:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l71If2jc012544; Wed, 1 Aug 2007 18:41:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 11:41:03 -0700 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] Vendor-Specific Commands Date: Wed, 1 Aug 2007 11:41:08 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504B648A2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D745@daebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfUUa5+nA0uP1jZStm38RibGyMmEQADTmLgAAL4JYA= References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> <19EBBEC503C3B5469070E0A6674A533A59D745@daebe104.NOE.Nokia.com> From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 01 Aug 2007 18:41:03.0132 (UTC) FILETIME=[83366DC0:01C7D46B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=936; t=1185993667; x=1186857667; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Vendor-Specific=20Commands |Sender:=20; bh=V1MElkImbKCXSLmtOlSV04AkjvKaWL7Qqd3M3hCBjnQ=; b=V2At6ZomH3qfVPRvN6r8PxblN7sQ1eJ9jigNnZFR2I3a112A8AAQL9DEJFGkdS6dFpMh85oQ U164/RGVUKu/U3WRhLk6JVOnpvI5Vb1QhqgNtqr7SSttxpIB8/Senfpc; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 john.loughney@nokia.com allegedly scribbled on Wednesday, August 01, 2007 10:12 AM: > Mark, >=20 > Unfortunately, the IETF does not recognize the difference between > SDOs and vendors. SDOs and Vendors would be in the same class. I > think that there should be an stable reference of the spec that can > be used for the command code for either SDOs and Vendors. =20 That would probably be desirable, but I don't see why it should be required. After all, these are _vendor-specific_ extensions: even in the case of SDOs, I can't see any real reason why anyone outside the organization really needs to know how they work. As for your earlier comment about vendors having to join SDOs or license proprietary extensions from other vendors: if you want to play, you have to pay. > Most likely, vendors could file an informational RFC, if they like. =20 Ditto for SDOs. =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 14:47: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 1IGJEE-0001so-Qw; Wed, 01 Aug 2007 14:47:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJED-0001sj-EX for dime@ietf.org; Wed, 01 Aug 2007 14:47:25 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJED-0007la-2O for dime@ietf.org; Wed, 01 Aug 2007 14:47:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Vendor-Specific Commands Date: Wed, 1 Aug 2007 14:47:23 -0400 Message-ID: In-Reply-To: <46B0B088.307@tari.toshiba.com> References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com> <46B0B088.307@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > > - Non-SDO Vendor: Reference is email of vendor contact person. > > =20 >=20 > I'm not sure if we should start distinguishing between=20 > non-IETF SDOs and=20 > vendors. It maybe better if they fall in the same category as the=20 > 'Non-IETF' above. Besides, 'vendor contact person' does not=20 > seem helpful=20 > if we want publicly available specification. >=20 I agree that a reference to a publicly available spec SHOULD be included when requesting a new app/command code. However, tightening the 'SHOULD' to a 'MUST' would result in IANA refusing to assign an id for apps that are unpublished because they are company confidential and I think that is unnecessarily restrictive. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 15:00: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 1IGJQg-0003HA-BF; Wed, 01 Aug 2007 15:00:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJQe-0003Gq-Sa; Wed, 01 Aug 2007 15:00:16 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJQd-00081l-Uz; Wed, 01 Aug 2007 15:00:16 -0400 Received: from hotmail.com ([207.46.8.96]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 1 Aug 2007 12:00:15 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Aug 2007 12:00:14 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 01 Aug 2007 19:00:10 GMT X-Originating-IP: [131.107.0.74] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> From: "Bernard Aboba" To: opsawg@ietf.org, dime@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 01 Aug 2007 12:00:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Aug 2007 19:00:14.0812 (UTC) FILETIME=[31AAD9C0:01C7D46E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Please note that the publication date of RFC 3588 (which included a Nokia author) was September 2003, and that this Nokia IPR claim was submitted to the IETF on January 6, 2004, several months after the Diameter RFC was published. As co-chair of the AAA WG, I would not have allowed RFC 3588 to be submitted to the IESG for publication without WG discussion of the IPR claim, had the IPR claim been submitted prior to publication of the Diameter RFC. >From: >To: , , >Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter >vs. RadSec patent research:EP1147635 >Date: Wed, 1 Aug 2007 12:15:02 -0500 > >Hi all, > >I was asked to forward this to the DiME, RADext and OPSA WG mailing lists. > >Thanks, >John > > > Dear Stefan, > > I asked John to forward this message as I'm not a regular on the DIME >list. I'm responsible for handling IETF related IPR cases in Nokia. > > As you suggested, Nokia believes EP1147635, and other members of the same >patent family, are essential to practice RFC3588. > > However, I do suggest that you, and other folks interested, contact your >respective legal folks regarding the implication of the existence of the >patent, in conjunction with our patent declaration. I do not believe that >Stefan's claim is correct: > > Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > > > In order to help the group to understand our declaration, please allow me >to provide a simplistic explanation. As for the binding legal language, >please see the declaration itself (cited correctly by Stefan in his >original email): > > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > > Our licensing declaration is what is commonly known as a "non-assert" >statement. What it says is that if you don't come after Nokia with your >patents, Nokia will not use its patents against your RFC 3588 >implementation. > > Non-assert statements like this are widely used in the IETF, as they are >believed to provide sufficient defensive protection for the owner, while >still allowing implementers and users to exercise the protected technology >without a license and for free, as long as they behave similarly nice (i.e. >not going after Nokia with their patents). In that, non-asserts are >believed to be compatible with most open source licenses. > > > Feel free to contact me in private if you have more questions. > > Best regards, > Stephan Wenger > Stephan.Wenger@nokia.com > > -----Original Message----- > > From: ext Stefan Winter [mailto:stefan.winter@restena.lu] > Sent: 01 August, 2007 15:28 > To: radiusext@ops.ietf.org; dime@ietf.org > Subject: [Dime] First results on Diameter vs. RadSec patent > research:EP1147635 > > Hello all, > > (sorry for cross-posting, this may also be of interest for dime) > > when presenting the RadSec draft in IETF69 Chicago, I > mentioned the patent claims of Nokia concerning Diameter. As a > reaction, some participants claimed that RadSec itself > implements a subset of the Diameter features and may very well > itself be subject to these patents. So I started an > investigation in this respect. > > I started the research myself by grabbing a copy of patent > EP1147635 by Nokia, which is claiming to affect Diameter. My > focus of the patent's examination was whether this patent > might also affect RadSec. > > The content of this patent is, in short, that packets on a > network get tagged as "possible duplicate" on retransmission > in order to make the endpoint aware that the received content > may be a duplicate of a previous packet. It also provides a > mechanism to correlate the multiple copies even when the > packets took different paths through the network. > > Diameter does exactly that, described in section 5.5.4 > "Failover and Failback Procedures" of RFC3588: a bit in the > Diameter header, the "T" bit, is set whenever a Diameter > packet needed to be retransmitted. Also, Diameter packets > carry an end-to-end identifier that makes it possible to > identify duplicates. > > This means that at least from my point of view, Nokia's claim > concerning Diameter is true. Every implementation of the > Diameter base protocol will use the patented technology and > needs to either license it or will violate it. > (Note: I am not a lawyer. This is just my interpretation; > consider my knowledge being "Slashdot-level"). > From the wording in this section 5.5.4 and the explanation of > the T bit in chapter 3, it seems that setting the T bit is > mandatory on retransmissions, so adhering to the protocol > specification leaves no room for circumventing the content of > the patent (e.g., by keeping it 0 at all times). > > Luckily, RadSec does not implement such a sophisticated > duplicate packet detection algorithm. So, this particular > patent appears not to be of any concern for implementors of RadSec. > > I will continue investigating the bunch of other patents and > patent applications relating to Diameter as soon as I get > copies of them. For reference, here is Nokia's claim statement > concerning Diameter (as submitted to the IETF IPR tracker): > > ---------- > > Title: Nokia's Statement About IPR Claimed in RFC 3588 > Received: January 6, 2004 > From: harri.t.honkasalo@nokia.com > > This is to advise the IETF that Nokia believes the Nokia > patents: EP1147635 and AU757984, and the related patent > applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102, > JP2000-595452 and US09/903863 may be relevant to Diameter Base > Protocol RFC3588. > > Nokia agrees not to assert those claims in Nokia above > mentioned patents that apply to the RFC3588 and are > technically necessary to implement this IETF standard > specification against any other party in respect of its > implementation of the specification, provided that the party > relying on this commitment does not assert its patents against Nokia. > > Regards, > > Harri Honkasalo > > Director of IPR, Standard Technology > > Nokia Corporation > > ---------- > > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > > RESTENA Foundation - Réseau Téléinformatique de l'Education > Nationale et de la Recherche R&D Engineer > > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > email: stefan.winter@restena.lu Tel.: +352 424409-1 > http://www.restena.lu Fax: +352 422473 > > > > > _______________________________________________ > 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 Aug 01 15:14: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 1IGJeh-0001N3-Lb; Wed, 01 Aug 2007 15:14:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJeg-0001Mo-4J for dime@ietf.org; Wed, 01 Aug 2007 15:14:46 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJef-0008T5-9C for dime@ietf.org; Wed, 01 Aug 2007 15:14:46 -0400 Received: from [88.234.220.192] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IGJeN3nam-0006XC; Wed, 01 Aug 2007 15:14:38 -0400 From: "Alper Yegin" To: "'Ahmad Muhanna'" , "'Hannes Tschofenig'" , Subject: RE: [Dime] RE: MIPv4 Authentication Performance Using RADIUS andDiameter MIPv4 Date: Wed, 1 Aug 2007 22:14:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437115E69437@zrc2hxm2.corp.nortel.com> Thread-index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGKopgAAB2vqAADobesA== X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Message-ID: <0MKpCa-1IGJeN3nam-0006XC@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+LydOfFYNAA+64K8Wm3hwWG+6+C14ry4kiANt eAsAwY6ao6DfwmaHDbt40yFJlLIm4UBCThAGZwfB3fX1AY95xL WNiaUu/S2RlJY4Erd8/+w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: 'McCann Peter-A001034' , 'Mohamed Khalil' 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 It always struck me as a bizarre protocol design how Diameter tunnels MIP4. More so than the timer issue Ahmad describes, I'd be concerned about the architectural misalignment of RADIUS and Diameter. Architectures that are using RADIUS would have to jump some additional hoops to adapt to Diameter when using MIP4. It does not have to be that way. Alper > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Wednesday, August 01, 2007 3:57 PM > To: Hannes Tschofenig; dime@ietf.org > Cc: Mohamed Khalil; McCann Peter-A001034 > Subject: [Dime] RE: MIPv4 Authentication Performance Using RADIUS > andDiameter MIPv4 > > > Hi Hannes, > Sorry, I forgot to summarize my presentation. Here is the summary: > > The basic idea of this draft is the following: > ============================================== > Since some SDO's is considering the full deployment of Diameter for MIP4 > Authentication, Authorization, and possibly MSA allocation, the > following question presents itself: > > What is the anticipated impact of Diameter Mobile IPv4 Application for > MIPv4 Authentication, Authorization, and possibly MSA dynamic allocation > on the MIPv4 session setup in comparison of RADIUS-Model MIPv4 > Authentication and Authorization, etc. > > High Level Summary of Diameter Mobile IPv4 Application: > ======================================================= > 1. The main functionality of the Diameter MIP4 Application is to > Authenticate, Authorize, and optionally allocate Mobility Security > Association of MN-HA and FA-HA. > > 2. In order for Diameter MIP4 Application to achieve step 1, Diameter > MIP4 Application uses the AAA infrastructure and Diameter protocol not > only to exchange Authentication and Authorization related parameters, > BUT it also, include the MIPv4 RRQ and RRP. > > 3. In other words, the Foreign Agent does not directly relay the RRQ > received from the MN to the Home Agent as per RFC3344, it includes the > RRQ in the Diameter message AMA and receives the RRP in the Diameter > message AMR. > > > Criteria used for Comparison: > ============================= > 1. RFC3344 mandates; when the MN uses timestamp for replay protection, > the MN must not retransmit a RRQ before 1 second. > 2. In wireless networks, most MIPv4 clients sets the first retransmit > timer to 1 second. This is important in order to get the session setup > quickly and not waste air resources. > 3. Then, what happens if due to some network condition the Mobile Node > does not receive MIPv4 RRP within 1 second? > > > How retransmitted initial MIPv4 RRQ message in handled in both models? > ---------------------------------------------------------------------- > > RADIUS-Model MIP4 Auth Case: > ============================- > 1. In the case of RADIUS Model MIPv4 Authentication, AAA infrastructure > is used for Authentication, Authorization, etc. BUT NOT used for > exchanging MIP4 RRQ and RRP between FA and HA. > > 2. Only in one condition (FA state), RADIUS-model will reauthenticate > the MIPv4 user by contacting AAA server, it is the case when FA receives > a retransmitted initial RRQ while waiting for AAA response. > > 3. In all other states, waiting for RRP, Received RRP, or Relayed RRP, > the FA considers the user has been authenticated and relays the > retransmitted RRQ directly to the HA without going through AAA > infrastructure. > > > Diameter MIP4 Application Case: > =============================== > 1. In the case of Diameter MIPv4 Application,. AAA infrastructure is > used for Authentication, Authorization, etc. AND is USED for exchanging > MIP4 RRQ and RRP between FA and HA. > > 2. In all conditions (FA states), Diameter MIPv4 Application will > reauthenticate the MIPv4 user by contacting AAA server. > > 3. Let us also remember that re-authentication of the user in the case > of Diameter MIP4 Application is far more complicated and time consuming > than in the case of RADIUS-Model. > > > Conclusion: > =========== > In case the network condition creates a situation that the Mobile Node > does not receive initial MIPv4 RRP within one second, Diameter MIPv4 > Application will worsen the network condition by unnecessarily relaying > the retransmitted RRQ via AAA (Diameter) infrastructure and > re-authenticating the user instead of relaying the retransmitted RRQ > DIRECTLY to the Home Agent. > > > Best Regards, > Ahmad > > > > -----Original Message----- > > From: Muhanna, Ahmad (RICH1:2H10) > > Sent: Wednesday, August 01, 2007 7:11 AM > > To: 'Hannes Tschofenig'; 'dime@ietf.org' > > Cc: 'Madjid Nakhjiri'; 'McCann Peter-A001034'; > > 'jouni.korhonen@teliasonera.com'; Khalil, Mohamed > > (RICH2:2S20); 'Avi Lior' > > Subject: RE: MIPv4 Authentication Performance Using RADIUS > > and Diameter MIPv4 > > > > Hi Hannes, > > > > Thanks a lot for giving me the chance. I really Appreciate it. > > > > As far as the raised issues I can summarize them as follows > > and I will have separate threads (probably end of day or > > early tomorrow) for each one of them. > > > > 1. Is there any field data which support the use case that > > the draft is trying to address. (Issue raised by: Madjid and > > Jouni) 2. Is there any security issue when the FA relay the > > retransmitted initial RRQ without consulting AAA in the case > > of RADIUS-Mode. (Issue raised by: Pete McCann) > > > > Based on the discussion, I would like to update the draft and > > submit a new revision and possibly discuss the next steps. > > > > All, > > Please, let me know if there is any issue that was raised and > > I missed. > > > > Best Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Wednesday, August 01, 2007 4:06 AM > > > To: dime@ietf.org > > > Cc: Muhanna, Ahmad (RICH1:2H10) > > > Subject: MIPv4 Authentication Performance Using RADIUS and Diameter > > > MIPv4 > > > > > > Hi Ahmad, > > > > > > you raised some interesting discussions during the DIME > > working group > > > meeting. Unfortunately, there was not enough time to address all > > > questions. > > > > > > I would be great if you could > > > * summarize your presentation, and > > > * address some of the raised questions on the mailing list. > > > > > > 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 Wed Aug 01 16: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 1IGKaH-0005EH-IP; Wed, 01 Aug 2007 16:14:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGKaH-0005EC-2L for dime@ietf.org; Wed, 01 Aug 2007 16:14:17 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGKaG-000205-Kl for dime@ietf.org; Wed, 01 Aug 2007 16:14:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2007 16:14:15 -0400 Message-ID: In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504B648A2@xmb-sjc-215.amer.cisco.com> References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A59D745@daebe104.NOE.Nokia.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B648A2@xmb-sjc-215.amer.cisco.com> From: "Avi Lior" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [Dime] Issue with Accounting Multisession id 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 Not sure if this is covered. RFC3855 describes Acct-Multi-Session-Id as UTF8String. RADIUS defines Acct-Multi-Session-Id as String that SHOULD contain UTF8 String. Thus this difference can create interoperability issues between RADIUS and Diameter. The suggested remedy is to define Acct-MultiSession-Id in the similar sense as in RADIUS that is as an OctetString. That should be sufficient. However, we could say that it SHOULD contain UTF-8 characters. Note NASREQ (4005) is silent about this descrepency. -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: Wednesday, August 01, 2007 2:41 PM To: john.loughney@nokia.com Cc: dime@ietf.org Subject: RE: [Dime] Vendor-Specific Commands john.loughney@nokia.com allegedly scribbled on Wednesday, August 01, 2007 10:12 AM: > Mark, >=20 > Unfortunately, the IETF does not recognize the difference between SDOs > and vendors. SDOs and Vendors would be in the same class. I think=20 > that there should be an stable reference of the spec that can be used=20 > for the command code for either SDOs and Vendors. That would probably be desirable, but I don't see why it should be required. After all, these are _vendor-specific_ extensions: even in the case of SDOs, I can't see any real reason why anyone outside the organization really needs to know how they work. As for your earlier comment about vendors having to join SDOs or license proprietary extensions from other vendors: if you want to play, you have to pay. > Most likely, vendors could file an informational RFC, if they like. =20 Ditto for SDOs. =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 Aug 01 18:02: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 1IGMGa-00086l-Qd; Wed, 01 Aug 2007 18:02:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGMGZ-00086f-Cr for dime@ietf.org; Wed, 01 Aug 2007 18:02:03 -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 1IGMGY-0004Us-Su for dime@ietf.org; Wed, 01 Aug 2007 18:02:03 -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 l71M20wW048790; Wed, 1 Aug 2007 18:02:00 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46B102D8.2090201@tari.toshiba.com> Date: Wed, 01 Aug 2007 18:02:00 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Issue with Accounting Multisession id References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com><19EBBEC503C3B5469070E0A6674A533A59D745@daebe104.NOE.Nokia.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B648A2@xmb-sjc-215.amer.cisco.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: d8ae4fd88fcaf47c1a71c804d04f413d 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 Thanks Avi, I've added this into the tracker: http://www.tschofenig.priv.at:8080/diameter-interop/issue59 -- victor > Not sure if this is covered. > > RFC3855 describes Acct-Multi-Session-Id as UTF8String. > > RADIUS defines Acct-Multi-Session-Id as String that SHOULD contain UTF8 > String. > > Thus this difference can create interoperability issues between RADIUS > and Diameter. > > The suggested remedy is to define Acct-MultiSession-Id in the similar > sense as in RADIUS that is as an OctetString. That should be > sufficient. However, we could say that it SHOULD contain UTF-8 > characters. > > Note NASREQ (4005) is silent about this descrepency. > > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: Wednesday, August 01, 2007 2:41 PM > To: john.loughney@nokia.com > Cc: dime@ietf.org > Subject: RE: [Dime] Vendor-Specific Commands > > john.loughney@nokia.com allegedly > scribbled on Wednesday, August 01, 2007 10:12 AM: > > >> Mark, >> >> Unfortunately, the IETF does not recognize the difference between SDOs >> > > >> and vendors. SDOs and Vendors would be in the same class. I think >> that there should be an stable reference of the spec that can be used >> for the command code for either SDOs and Vendors. >> > > That would probably be desirable, but I don't see why it should be > required. After all, these are _vendor-specific_ extensions: even in > the case of SDOs, I can't see any real reason why anyone outside the > organization really needs to know how they work. As for your earlier > comment about vendors having to join SDOs or license proprietary > extensions from other vendors: if you want to play, you have to pay. > > >> Most likely, vendors could file an informational RFC, if they like. >> > > Ditto for SDOs. > > ... > > _______________________________________________ > 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 Aug 01 18:26:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGMeO-0005tw-5k; Wed, 01 Aug 2007 18:26:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGMeN-0005tr-6u for dime@ietf.org; Wed, 01 Aug 2007 18:26:39 -0400 Received: from ironport.comverse.com ([192.118.49.220] helo=ns6.comverse.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGMeM-0004vR-GN for dime@ietf.org; Wed, 01 Aug 2007 18:26:39 -0400 X-SBRS: None X-IronPort-AV: E=Sophos;i="4.19,210,1183323600"; d="scan'208";a="142334670" Received: from us-nj-mail1.comverse.com ([10.230.12.76]) by si-sin-mail01.comverse.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 06:27:54 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2007 18:25:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vendor-Specific Commands Thread-Index: AcfUVVNUnIRsjRCcQ0qzd54SkOO7WwAMHoMg References: From: "Daily William" To: X-OriginalArrivalTime: 01 Aug 2007 22:27:54.0657 (UTC) FILETIME=[34505110:01C7D48B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [Dime] RE: Vendor-Specific Commands 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 Perhaps this is a naive question, but it seems to be worth asking anyway. It seems to me that the command code is already in a namespace, this being defined by the application id. This concept is used by other protocols, most notably TCAP, where the operations codes (or commands in Diameter) are defined within the domain of the application-context-name (or Application-Id in Diameter). A quick check of the Mobile Application Part (MAP) and CAMEL Application Part (CAP) does show overlap. If one accepts the observation, then it stands to reason that when the vender specific Application-Id is used all command codes used by messages with the vender specific Application-id are vender specific already. With respect to routing, it seems odd to me that the command code would need to understood by the routing algorithm in order for inter opt to work. What seems to be the only necessary information needed by the routing would be: { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] For the request and in the response: { Result-Code } { Origin-Host } { Origin-Realm } * [ Proxy-Info ] In addition to the above, the peers would need to agree that the application-id can be supported in peer connection CER/CEA exchange, which should not be a problem for routers. Diameter does not segment the information to support the base protocol functions from the data necessary for support of the application (everything is an AVP). Since there is no clean delineation between the bits for base and everything else we need to rely on best practice to insure that the inter operation works. If one accepts the premise that the command code is within the domain of the Application ID, then perhaps the best solution is a description of what the minimum requirements are for a new application and the best practice to achieve this in a vender specific application. Regards, Bill Daily Comverse, Inc. =20 -----Original Message----- From: dime-request@ietf.org [mailto:dime-request@ietf.org]=20 Sent: Wednesday, August 01, 2007 12:01 PM To: dime@ietf.org Subject: DiME Digest, Vol 20, Issue 3 Send DiME mailing list submissions to dime@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/dime or, via email, send a message with subject or body 'help' to dime-request@ietf.org You can reach the person managing the list at dime-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of DiME digest..." Today's Topics: 1. RE: Vendor-Specific Commands (Mark Jones) ---------------------------------------------------------------------- Message: 1 Date: Wed, 1 Aug 2007 11:35:48 -0400 From: "Mark Jones" Subject: RE: [Dime] Vendor-Specific Commands To: Cc: dime@ietf.org Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" > I would think that the best possible solution for vendor=20 > specific command code > would be to allocate a range of codes that IANA would freely=20 > handout as long > as there was a specification publicly available. =20 Excellent suggestion, John. This is already being done for Application Ids and IANA could follow the same reference rules for new command codes assignments: - IETF: Reference an RFC. - Non-IETF SDO: Reference an information RFC (preferred) or SDO spec. - Non-SDO Vendor: Reference is email of vendor contact person. Regards Mark ------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime End of DiME Digest, Vol 20, Issue 3 *********************************** _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 01 23:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGRBO-00087M-8M; Wed, 01 Aug 2007 23:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGRBM-00087E-AK for dime@ietf.org; Wed, 01 Aug 2007 23:17:00 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGRBK-0000fK-4M for dime@ietf.org; Wed, 01 Aug 2007 23:17:00 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM40090PMF1VX@szxga02-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 11:16:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM400K0QMET5E@szxga02-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 11:16:13 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM4003GPMETK2@szxml04-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 11:16:05 +0800 (CST) Date: Thu, 02 Aug 2007 11:16:05 +0800 From: Tina TSOU To: dime@ietf.org Message-id: <005501c7d4b3$7691ce50$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [Dime] One scenario related to QoS Appl. 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="===============2071492001==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============2071492001== Content-type: multipart/alternative; boundary="Boundary_(ID_8flnsnq/79Fm2rBHbU2hcg)" This is a multi-part message in MIME format. --Boundary_(ID_8flnsnq/79Fm2rBHbU2hcg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, One scenario to be discussed is as below. One user is going to make a call with his friend. He estimates it will take about 20 minutes to complete the call. Prices for calls at different QoS levels are different, good quality calls will cost more than low quality ones do. So he gotta know the QoS level at which his account balance can provide 20 minutes quotas or more for him. Is it supported by the current QoS Appl.? B. R. Tina +86-755-28972912 (Office) +86-13922884380 (Mobile) Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com --Boundary_(ID_8flnsnq/79Fm2rBHbU2hcg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
One scenario to be discussed is as below.
 
One user is going to make a call with his friend. He estimates it will take about 20 minutes to complete the call. Prices for calls at different QoS levels are different, good quality calls will cost more than low quality ones do. So he gotta know the QoS level at which his account balance can provide 20 minutes quotas or more for him.
 
Is it supported by the current QoS Appl.?
B. R.
Tina
+86-755-28972912 (Office)    +86-13922884380 (Mobile)
Messengers:
MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com
 
--Boundary_(ID_8flnsnq/79Fm2rBHbU2hcg)-- --===============2071492001== 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 --===============2071492001==-- From dime-bounces@ietf.org Thu Aug 02 00:40: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 1IGSU2-0007I6-45; Thu, 02 Aug 2007 00:40:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGSTz-0007Hx-CL for dime@ietf.org; Thu, 02 Aug 2007 00:40:20 -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 1IGSTy-0004Mu-Od for dime@ietf.org; Thu, 02 Aug 2007 00:40:19 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l724dqOc027575; Thu, 2 Aug 2007 07:40:14 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 07:40:12 +0300 Received: from daebe104.NOE.Nokia.com ([10.241.36.13]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 23:40:11 -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: RE: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Date: Wed, 1 Aug 2007 23:40:10 -0500 Message-ID: <19EBBEC503C3B5469070E0A6674A533A59DC77@daebe104.NOE.Nokia.com> In-Reply-To: <00ec01c7d463$06547e80$5d1216ac@xpsuperdvd2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635 Thread-Index: AcfUTlY2JnIgGVJeSrmDIKoz0szKWwAENHjAAACHXSAAF29sUA== References: <19EBBEC503C3B5469070E0A6674A533A59D74D@daebe104.NOE.Nokia.com> <00ec01c7d463$06547e80$5d1216ac@xpsuperdvd2> From: To: , , X-OriginalArrivalTime: 02 Aug 2007 04:40:11.0210 (UTC) FILETIME=[35EFD2A0:01C7D4BF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Stephan.Wenger@nokia.com 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 David, I copied Stephan on the mail, as he asked to be contacted for any follow-up questions.=20 With respect to being compatible to Open Source, what is meant is that Nokia will not assert its patents against open source implementations (as far as I know), though Stephan can correct me. John >-----Original Message----- >From: ext David B. Nelson [mailto:dnelson@elbrysnetworks.com]=20 >Sent: 01 August, 2007 20:40 >To: Loughney John (Nokia-NRC/PaloAlto); dime@ietf.org;=20 >radiusext@ops.ietf.org >Subject: RE: Nokia Patent discussion FW: [Dime] First results=20 >on Diameter vs. RadSec patent research:EP1147635 > >> Non-assert statements like this are widely used in the IETF, as they=20 >> are believed to provide sufficient defensive protection for=20 >the owner,=20 >> while still allowing implementers and users to exercise the=20 >protected=20 >> technology without a license and for free, as long as they behave=20 >> similarly nice... > >It is true that "non-assert" IPR statements are frequently=20 >issued these days. > >> In that, non-asserts are believed to be compatible with most open=20 >> source licenses. > >Compatible? What does that mean? > >A reciprocal non-assert is not quite the same thing as open=20 >source. Open source has to do with copyright IPR, not patent=20 >IPR. Additionally, reciprocal non-asserts would appear to=20 >apply to all patents that an organization may hold, not only=20 >those that are related to standards. In that regard, it is=20 >tantamount to an implicit (and broad) cross-licensing=20 >agreement, which would include patents covering proprietary=20 >technology as well as open standards based technology. > >Still, it is better than nothing, and very useful to companies=20 >that don't intend to enforce _any_ of their patent portfolio=20 >against infringement by the non-assert grantors. Of course,=20 >it also works out fine for companies that don't have patents=20 >to enforce. :-) > >Standard disclaimer: I am not a lawyer. > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 02:34: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 1IGUGS-00013U-Fv; Thu, 02 Aug 2007 02:34:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGUGR-00013K-1m for dime@ietf.org; Thu, 02 Aug 2007 02:34:27 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGUGP-0004wI-1h for dime@ietf.org; Thu, 02 Aug 2007 02:34:26 -0400 Received: by py-out-1112.google.com with SMTP id f31so1386823pyh for ; Wed, 01 Aug 2007 23:34:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=kqtN7G3x0F5Rjrrw3tsCQhsuCJIlNTYpb2lgFBOcxtJsrauI2ssl5eltUltFggrhuHuW4n/4L+sMngXs+tQ5Xky0eB+vBiwMZK+yiJy0mxyF7+qEWqcsDyETyp7of0n1+JOO9oLGbrv3tRnXKU5cIj7NUGVjcx0xHY1X27Zfvd8= 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=tBTxa1scPME5z9QcIUqpGOactCLOmO3kwP9oEPH63Wp8JTV/v51zxLb3DRxvfzpHnFewbPBnWG8BGcOXgu9/+XYQVWePa2+mInro38deRXNGSFAfLUHO44TvyR73DT5zeVn87sRRAJUV6ieuz2YgwsCBy8sgFk+qhfB9EpU6Ymc= Received: by 10.65.114.11 with SMTP id r11mr2508006qbm.1186036464231; Wed, 01 Aug 2007 23:34:24 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Wed, 1 Aug 2007 23:34:24 -0700 (PDT) Message-ID: Date: Thu, 2 Aug 2007 12:04:24 +0530 From: "Harish R Prabhu" To: "Balamurugan T, TLS-Chennai" Subject: Fwd: [Dime] Clarification regarding the election process In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC601F7CF9D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> MIME-Version: 1.0 References: <66E8AEE9980BB44CA5FCAD39EBA56AC601F7CF9D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 3.1 (+++) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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="===============0171685056==" Errors-To: dime-bounces@ietf.org --===============0171685056== Content-Type: multipart/related; boundary="----=_Part_73937_21421163.1186036464172" ------=_Part_73937_21421163.1186036464172 Content-Type: multipart/alternative; boundary="----=_Part_73936_9366648.1186036464172" ------=_Part_73936_9366648.1186036464172 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Bala, I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node. 1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.) 2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side). Hope this helps. cheers, Harish ---------- Forwarded message ---------- From: Balamurugan T, TLS-Chennai Date: Aug 1, 2007 7:39 PM Subject: [Dime] Clarification regarding the election process To: dime@ietf.org Hi All, I need some clarification regarding the election process in peer state machine. According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, The election process is described as below +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.1.2. Election This test case refers to Section 5.6.4 of [RFC3588]. Responders must be able to resolve contention with initiator peers. o Positive test for establishment of connection with responder having higher identity than initiator. Vendor A initiates connection followed by B doing the same a few milliseconds later. *Vendor A having a higher identity should close B's connection* * attempt.* +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ But, in RFC 3588, section 5.6. Peer State Machine, 5th paragraph explains ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down*. The* * responder connection will survive if the Origin-Host of the local* * Diameter entity is higher than that of the peer;* the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ These are contradicting. I guess the test draft should be corrected. As per RFC3588, If A and B are two Peers, Ai is the initiator of the connection C1; Br is the responder for the connection C1 Bi is the initiator of the connection C2; Ar is the responder for the connection C2 Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process. But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txtexplains differently. Please confirm that this draft needs to be corrected. Thanks, Bala DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------=_Part_73936_9366648.1186036464172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Bala,

I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node.

1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.)

2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side).

Hope this helps.

cheers,
Harish

---------- Forwarded message ----------
From: Balamurugan T, TLS-Chennai < tbalamurugan@hcl.in>
Date: Aug 1, 2007 7:39 PM
Subject: [Dime] Clarification regarding the election process
To: dime@ietf.org

 

Hi All,

 

     I need some clarification regarding the election process in peer state machine.

 

   According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, 

 
The election process is described as below 
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3.1.1.2.  Election

 
   This test case refers to Section 5.6.4 of [RFC3588].  Responders must

   be able to resolve contention with initiator peers.

 
   o  Positive test for establishment of connection with responder

      having higher identity than initiator.  Vendor A initiates
      connection followed by B doing the same a few milliseconds later.

      Vendor A having a higher identity should close B's connection

      attempt.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

 

But, in RFC 3588, section  5.6.  Peer State Machine, 5th paragraph explains

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   A CER message is always sent on the initiating connection immediately

   after the connection request is successfully completed.  In the case

   of an election, one of the two connections will shut down.  The

   responder connection will survive if the Origin-Host of the local

   Diameter entity is higher than that of the peer; the initiator

   connection will survive if the peer's Origin-Host is higher.  All

   subsequent messages are sent on the surviving connection.  Note that

   the results of an election on one peer are guaranteed to be the

   inverse of the results on the other.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

These are contradicting. I guess the test draft should be corrected. As per RFC3588,

 

If A and B are two Peers,

 

 

Ai is the initiator of the connection C1; Br is the responder for the connection C1

Bi is the initiator of the connection C2; Ar is the responder for the connection C2

 

Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process.

 

But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt explains differently. Please confirm that this draft needs to be corrected.

 

 

Thanks,

Bala

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
------=_Part_73936_9366648.1186036464172-- ------=_Part_73937_21421163.1186036464172 Content-Type: image/gif; name=image001.gif Content-Transfer-Encoding: base64 Content-ID: Content-Location: image001.gif X-Attachment-Id: 0.0.1 Content-Disposition: inline; filename="image001.gif" R0lGODlhyQE4AXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAJADJ ARQBhQAAAAAAAA0NDRUVFR0dHQgICAEBARgYGBYWFhwcHDMzMz8/PyAgIDs7Ozc3NzY2Njk5OV9f X0ZGRkdHR0BAQFVVVUNDQ1FRUXt7e39/f319fXJycnBwcGxsbI+Pj5mZmZ+fn7+/v9PT09fX19/f 38PDw/7+/uXl5ejo6Ofn5/f39////wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwb/QIBwSCwah6ukcslsOp+ro3RKrVqv2Kx2y+16v+Cw eNyFms9OslqKbqPX8Lh8Tq/b73W3/okP7/9LfYKDhIWGh3eAiohaioCMkJGSk5Ryjn+VbJd6mZ2e n6CRm5yhQqNupamqq6xbp22pr2+ttLW2sbJmqrm6t76/wIa8ULjDTcHIycpwxmnFaAGXy9PU1VYm UAHa29Kle9GL1uLj1dhm4CvomM/n6Y7k8PG/5tlL6qShetH3qPL+/6roPVHHDxa7egUNAlzIcJJA J+gSzsrXJuKjhhgzGnrYZJu2dwchKpHYS6PJk3M4MiEYjiI0jxdRypwpRqW9lTFd1ru5jqbP/59Y bI7E2RNUs2NAkyo9cpTJrqZKlkpdCjWqt6pRpmr9iTXr1apbw8rsGtKY2LMmyZYdhrYtQ7Vfn5xA Mcqt3X9oRJxCFuCu37t9NQb+S/js4IyHCytemphh48WQfT5eODmyZcEmK1/e7PikZs6g430WHbp0 w9GkTauWh5pc69Wwf70eN5spgCi4b+vOzXu3797AfcceLqV2NeNFuk4kzhwAcmrPkSgv2Xx4dGXX b08nVp159mTZt3PvHvt7sPDinZEv79lPeqTrV5sHhv59oPiw59N3b98qftP6+VLfSx+xdIkJ/8nX HhgV2QMONwd6lSBoAd4y4E48JUESGghOWP9ahXMEJ+JvJPamQIkoAtdORxkqgo2HoUWT4owj1kjj bybkqOOOPPboo48YYPDjkD2esaE7B8IYI5FMNunkk9o1lUEGUB15pBkvKrnZlf0pN2WV0GzSoZaX cdlllEd92ZSVYkpI5mJmdlmVmmuyOFSSb1oWp31oNkNnnXcG6qKbeRK2p5xpUonoJoVGdmh6fRrz 56ItNWoopbLwc+SkmOJj6aUDefSoLJFiuAennfbzqWHaELGhRanidCiqsVK36laiDvFqi9OVKtKh ESww5bDEFmvsscgmq+yyxWoggXPQ9iVttNROa2212F6rbbbcbuttt+B+K2645I5rbrnonqv/brrs eivqRytqWOtQ9xw5AQMU5Kvvvvz2m28DDgQs8MAEF2zwwQg78IAA7zbs8MMQRyzxxBRXbPHFGGes 8cYcd+wxvBjWm86onDQor4abKsrorY3m6pyRMI0EMqKwnmwGrZ6yTKZHrhrZIsmYVBSzzVDgnLPO Sja2a4ZADyMy0U8YrRDSqy4daNMl+8w0GlJPTXXLWhONNaVdn/H1rWODNafK3ZwN9rzTlW2r22+m DZWvucg9N91Jwx0325XyvbPfSeAti97jCa6l3U2ZcqONwVVQAeQzKl7345hTrrlud4BoeYKe0xL6 5/iN3orppHeHuiqrp95c66nA7jp7mM2u/7jsoeBuO4CZ7S647p8A7ztnwmdS/PBlLog81cdT0vzy cCoPPcvPS1L99H9dH4n22LvFPSLfd49W+IeQLz6uvZ9ftfTq52k+Ie+3zxj78i+efv3u04+/h/EL 0v/+NPlfHwQIQP0BhIAFvB9iEpg0BTIQdAZ8oOocKMH4INAOF6zgPzI4Bw5qkDUR/KB1KCjC14Ww hAqqHQonSMIV5qeFLkyhCmM4whnSkHY2vKFqPBgHHuoQPCf8oZ5gKMQtBbGI0cshEol3xCUaiohO TKISowgZH67BilQ8XROz6D0octEvWFRDGL+YOy+SsYtmPKNh0qhGsYxxDG9sYyXiCAY6yv9xEnb8 Qh7vyIg9csGPfCzfFgOpFEBqwZCEHAQis7DIRHaOjY4ESiOvMMlIdhCSlgzgIDMpk0pSwZOcvOIm Q4nJ45DSjaM8JUZAWRxVoq+UruzMFGOpSVjScoO2vKU/WNlKXUoyl76EBy+PMMxgWqGYrjLmT5CZ TGXOhJlCgKYzjSBNaE1TDZvLJubCIM1qTm9R3EzlNZmCqHDOcpyuKGcdxYlOIoBznedsJxbeqUd2 ytNwvYLnAu/5BXp6oZreXJ4/u9BNfn5BKA4qkMyANqZ/2lOeCBXbgwT1h4YSFJj3jKimxOYIi/4x IABAkEhDStKRmrSkKDXpBjaQ0paedKT/hDImQgtC046GYQAjcKlOX7rTnvL0pFhBnHquOVN92BQM BCAB4fB5CqEO1ZlFNZmLwpBUwgUVcDmZZlTDNlWkKtVvTB2FU+Gj1XiZqqtfqKpVoTLW+4xTo3ZC kpio+lW4hXUTbXVrWblaM7lWlK5rZStWizLNgXJBrXZdWxNSQFhlGnYLiA2sWfXwpxRwoAB7aOdj tRDZhEKIV40zKiDUZNkCzMxrjlVnWusqEqjFah+jzUBph4ba1MoJsKZiXNbCNCsLmPZjwA2ucIdL 3OIa97jITS5wDVACs+rWaX51x2mXkAEMeOAAogqBdrfL3e6G4APy7AAAxEve8Zq3vOg9/69608te 84oBAayN69OwEtaafTZqVFKBBxhw39oaNBWdXQltp9ulvqZsCSDgb2b/W4sA/wy0R6nvgLmGVRA0 lsGlcDBF+yqn+R54ZRhmhYahxuHQclWuHwZxiAEcX6JwVLI3G+yCV6yKEVPqrpfIq39oHAobwzjH Mj4ajz3h43Iqti5D7nGLf9zUIKsqyZ8o8m2PrGIoZyIBS+7UI61sDYBy2ZTx/LKFHirmThS0zMvw MpqBGOY1s0LNbt5Pm+McOzLTGRJnvrOA7KxnQc65z56AM6C1+OdBz5HPhvYfRhNdCEEzuhR5fnSd Fy1pPES60qBwNKbNTOlN10HTnnZep+JDLQdQk3p7oz61KFOtajiyutViMDWsDXHpWfcR0bbW5ypz bT1c8/qihf51qX0t7EO+utiMJDayKXnsZR9T2c7+ZLOjPQVZU7uH0742NaGt7SLUutvDzja4rbnP cdPB2uY2Z7nTjW1xg/vb7Ha1u7sN73ire932lje+8x1rbpu73vwGdrADXu1509vf4wY4wY1t8Gsr fOFYQDfEnz3wiXsb4e9uuMMxfvCKW1xXHNf2wz9ecI1He+QkJ2bIN+5xkks85dtu+cdfDvNm7rvm VaA5zsm9651HfOXURrnPde7zUgQBADs= ------=_Part_73937_21421163.1186036464172-- --===============0171685056== 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 --===============0171685056==-- From dime-bounces@ietf.org Thu Aug 02 06:11: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 1IGXeG-0000AY-Tu; Thu, 02 Aug 2007 06:11:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGXeF-00008y-SE for dime@ietf.org; Thu, 02 Aug 2007 06:11:15 -0400 Received: from mail2.telenet-ag.de ([213.188.99.163] helo=proxy2.ip3k.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGXeD-0005KK-R8 for dime@ietf.org; Thu, 02 Aug 2007 06:11:14 -0400 Received: from [193.96.234.249] ([193.96.234.249]) (authenticated bits=0) by proxy2.ip3k.de (8.12.8/8.12.8) with ESMTP id l72AB6pP015574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2007 12:11:11 +0200 Message-ID: <46B1ADBA.5070503@telenet-ag.de> Date: Thu, 02 Aug 2007 12:11:06 +0200 From: Michael Hillier User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: dime@ietf.org Content-Type: multipart/mixed; boundary="------------080909080204000600080408" X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Subject: [Dime] Encoding of Address Format for E.164 MSISDNs 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 This is a multi-part message in MIME format. --------------080909080204000600080408 Content-Type: multipart/alternative; boundary="------------010308060305060508070608" --------------010308060305060508070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have been trying to establish how an E.164 number (Address) is encoded into the Diameter Base Address format. For IPv4 addresses everything seems quite clear (IPv4 = Address Family 1), i.e. the IPv4 address 10.11.12.128 is encoded as an octet string 0x0001*0A0B0C80*. *The question is how does an E.164 number get encoded, this being Address Family 8: *(E.164 = Mobile telephone number = MSISDN, roughly speaking)* * Let us take the E.164 number 491715454121. I see several possibilities: either (A) as UTF8 0x0008*343931373135343534313231* or (B) as Binary Coded Decimal (BCD) 0x0008*491715454121* or (C) a binary number/integer 0x0008*727C8664A9* Does any body know either the theoretically correct answer or have inter-op practical experience? Depending on the answer, it might be worth adding a note to RFC 3588bis. Many thanks in advance Mike References: Diameter Base defines the derived format "address" in section 4.3 "The Address format is derived from the OctetString AVP Base Format. It is a discriminated union, representing, for example a 32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most significant octet first. The first two octets of the Address AVP represents the AddressType, which contains an Address Family defined in [IANAADFAM]. The AddressType is used to discriminate the content and format of the remaining octets." The reference is the IANA Address Family Numbers, I quote: ADDRESS FAMILY NUMBERS (last updated 2007-02-08) Several protocols deal with multiple address families. The 16-bit assignments are listed here. Number Description Reference ------ ---------------------------------------------------- --------- 0 Reserved *1 IP (IP version 4)* 2 IP6 (IP version 6) ... 7 E.163* 8 E.164 (SMDS, Frame Relay, ATM)* -- Telenet AG Rhein-Main m.hillier@telenet-ag.de --------------010308060305060508070608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I have been trying to establish how an E.164 number (Address) is encoded into the Diameter Base Address format.
For IPv4 addresses everything seems quite clear (IPv4 = Address Family 1), i.e. the IPv4 address 10.11.12.128 is
encoded as an octet string 0x00010A0B0C80.

The question is how does an E.164 number get encoded,  this being Address Family 8:
(E.164 = Mobile telephone  number = MSISDN, roughly speaking)

Let us take the E.164 number 491715454121.  I see several possibilities: 
either (A) as UTF8
    0x0008343931373135343534313231 
or (B) as Binary Coded Decimal (BCD)
    0x0008491715454121
or (C) a binary number/integer
    0x0008727C8664A9

Does any body know either the theoretically correct answer or have inter-op practical experience?
Depending on the answer, it might be worth adding a note to RFC 3588bis.

Many thanks in advance

Mike



References:

Diameter Base defines the derived format "address" in section 4.3
"The Address format is derived from the OctetString AVP Base
Format. It is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
significant octet first. The first two octets of the Address
AVP represents the AddressType, which contains an Address Family
defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets."

The reference is the IANA Address Family Numbers, I quote:
ADDRESS FAMILY NUMBERS
(last updated 2007-02-08)
Several protocols deal with multiple address families.  The 16-bit
assignments are listed here.

Number    Description                                          Reference
------    ---------------------------------------------------- ---------
     0    Reserved
     1    IP (IP version 4)
     2    IP6 (IP version 6)
     ...
     7    E.163
     8    E.164 (SMDS, Frame Relay, ATM)


-- 

Telenet AG Rhein-Main
m.hillier@telenet-ag.de
--------------010308060305060508070608-- --------------080909080204000600080408 Content-Type: text/x-vcard; charset=utf-8; name="m.hillier.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="m.hillier.vcf" begin:vcard fn:Michael Hillier n:Hillier;Michael email;internet:m.hillier@telenet-ag.de tel;work:+49 6151 733 333 tel;home:+49 6155 77456 tel;cell:+49 170 5454 121 x-mozilla-html:TRUE url:Michael.Hillier@web.de version:2.1 end:vcard --------------080909080204000600080408 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 --------------080909080204000600080408-- From dime-bounces@ietf.org Thu Aug 02 08:31: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 1IGZpj-0000iX-49; Thu, 02 Aug 2007 08:31:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGZpi-0000iS-7B for dime@ietf.org; Thu, 02 Aug 2007 08:31:14 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGZph-0006qY-Qk for dime@ietf.org; Thu, 02 Aug 2007 08:31:14 -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 l72CV98K025751; Thu, 2 Aug 2007 08:31:09 -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 Subject: RE: [Dime] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 08:31:09 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> In-Reply-To: <005501c7d4b3$7691ce50$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4A References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com> From: "Asveren, Tolga" To: "Tina TSOU" , X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Tina, IMHO, this could be classified as a different "service". For example = right now people check a website or a paper document (or sometimes they = listen to an announcement) where prices are listed (maybe not for = different QoS levels but for different destinations, but conceptually it = is similar). Thanks, Tolga ________________________________________ From: Tina TSOU [mailto:tena@huawei.com]=20 Sent: Wednesday, August 01, 2007 11:16 PM To: dime@ietf.org Subject: [Dime] One scenario related to QoS Appl. Hi all, One scenario to be discussed is as below. =A0 One user is going to make a call with his friend. He estimates it will = take about 20 minutes to complete the call. Prices for calls at = different QoS levels are different, good quality calls will cost more = than low quality ones do. So he gotta know the QoS level at which his = account balance can provide 20 minutes quotas or more for him. =A0 Is it supported by the current QoS Appl.? B. R. Tina +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) Messengers:=20 MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU=A0=A0=A0 Jabber: tina@jabber.org=A0=A0=A0 Google talk: = tinatsou6@gmail.com =A0 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 08:33: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 1IGZsH-0002UR-6A; Thu, 02 Aug 2007 08:33:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGZsE-0002St-Lu for dime@ietf.org; Thu, 02 Aug 2007 08:33:51 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGZsE-0000BD-8j for dime@ietf.org; Thu, 02 Aug 2007 08:33:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Aug 2007 08:33:49 -0400 X-IronPort-AV: i="4.19,212,1183348800"; d="scan'208"; a="43904043:sNHT8973798" 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] Vendor-Specific Commands Date: Thu, 2 Aug 2007 14:33:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Vendor-Specific Commands Thread-Index: AcfUbHXV95QsKxiUSFC4gvARAzlQogAlBwqQ References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com><46B0B088.307@tari.toshiba.com> From: "Romascanu, Dan (Dan)" To: "Mark Jones" , "Victor Fajardo" , 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 =20 =20 > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 > Sent: Wednesday, August 01, 2007 9:47 PM > To: Victor Fajardo; john.loughney@nokia.com > Cc: dime@ietf.org > Subject: RE: [Dime] Vendor-Specific Commands >=20 > > > - Non-SDO Vendor: Reference is email of vendor contact person. > > > =20 > >=20 > > I'm not sure if we should start distinguishing between=20 > non-IETF SDOs=20 > > and vendors. It maybe better if they fall in the same=20 > category as the=20 > > 'Non-IETF' above. Besides, 'vendor contact person' does not seem=20 > > helpful if we want publicly available specification. > >=20 >=20 > I agree that a reference to a publicly available spec SHOULD=20 > be included when requesting a new app/command code. However,=20 > tightening the 'SHOULD' > to a 'MUST' would result in IANA refusing to assign an id for=20 > apps that are unpublished because they are company=20 > confidential and I think that is unnecessarily restrictive. >=20 > Regards > Mark >=20 Yes, but in this case the policy to be used for IANA cannot be labeled as 'Specification Required', which according to RFC 2434 implies:=20 Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. You need to be clear what to ask from IANA.=20 Dan _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 09:17: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 1IGaYH-0002oL-Km; Thu, 02 Aug 2007 09:17:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaYG-0002oF-Qv for dime@ietf.org; Thu, 02 Aug 2007 09:17:16 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGaY9-0007kD-LA for dime@ietf.org; Thu, 02 Aug 2007 09:17:16 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM500J9FE8JY5@usaga01-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 06:17:08 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM500BPJE8IKA@usaga01-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 06:17:07 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.70.145.77]) by szxmc04-in.huawei.com (mshttpd); Thu, 02 Aug 2007 21:17:03 +0800 Date: Thu, 02 Aug 2007 21:17:03 +0800 From: HarshaM 71438 Subject: Re: Fwd: [Dime] Clarification regarding the election process In-reply-to: To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg)" Content-language: en X-Accept-Language: en Priority: normal References: <66E8AEE9980BB44CA5FCAD39EBA56AC601F7CF9D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 1.7 (+) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 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 This is a multi-part message in MIME format. --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi All, I am confused about Peer State Machine in RFC 3588. This is my understanding 1) The peer state machine actually combines two state machines,Initiator (client) state machine and Responder (server) state machine. 2) States and events with "I" are possible only in initiator. 3) States and events with "R" are possible only in responder. 4) States and events without any prefix can come in both. But I also see some initiator states like "WAIT-I-CEA" that can receive events from responder like "R-Conn-CER", how is this possible? If I am wrong somewhere please correct me. Regards, Harsha --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg) Content-type: multipart/related; boundary="Boundary_(ID_ALSro3hW1sl4/rFk2gkcdA)" --Boundary_(ID_ALSro3hW1sl4/rFk2gkcdA) Content-type: multipart/alternative; boundary="Boundary_(ID_m81lFyGy+pWDyp28o5iAdw)" --Boundary_(ID_m81lFyGy+pWDyp28o5iAdw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Bala, I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node. 1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.) 2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side). Hope this helps. cheers, Harish ---------- Forwarded message ---------- From: Balamurugan T, TLS-Chennai Date: Aug 1, 2007 7:39 PM Subject: [Dime] Clarification regarding the election process To: dime@ietf.org Hi All, I need some clarification regarding the election process in peer state machine. According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, The election process is described as below +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.1.2. Election This test case refers to Section 5.6.4 of [RFC3588]. Responders must be able to resolve contention with initiator peers. o Positive test for establishment of connection with responder having higher identity than initiator. Vendor A initiates connection followed by B doing the same a few milliseconds later. *Vendor A having a higher identity should close B's connection* * attempt.* +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ But, in RFC 3588, section 5.6. Peer State Machine, 5th paragraph explains ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down*. The* * responder connection will survive if the Origin-Host of the local* * Diameter entity is higher than that of the peer;* the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ These are contradicting. I guess the test draft should be corrected. As per RFC3588, If A and B are two Peers, Ai is the initiator of the connection C1; Br is the responder for the connection C1 Bi is the initiator of the connection C2; Ar is the responder for the connection C2 Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process. But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txtexplains differently. Please confirm that this draft needs to be corrected. Thanks, Bala DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_m81lFyGy+pWDyp28o5iAdw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Bala,

I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node.

1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.)

2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side).

Hope this helps.

cheers,
Harish

---------- Forwarded message ----------
From: Balamurugan T, TLS-Chennai < tbalamurugan@hcl.in>
Date: Aug 1, 2007 7:39 PM
Subject: [Dime] Clarification regarding the election process
To: dime@ietf.org

 

Hi All,

 

     I need some clarification regarding the election process in peer state machine.

 

   According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, 

 
The election process is described as below 
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3.1.1.2.  Election

 
   This test case refers to Section 5.6.4 of [RFC3588].  Responders must

   be able to resolve contention with initiator peers.

 
   o  Positive test for establishment of connection with responder

      having higher identity than initiator.  Vendor A initiates
      connection followed by B doing the same a few milliseconds later.

      Vendor A having a higher identity should close B's connection

      attempt.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

 

But, in RFC 3588, section  5.6.  Peer State Machine, 5th paragraph explains

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   A CER message is always sent on the initiating connection immediately

   after the connection request is successfully completed.  In the case

   of an election, one of the two connections will shut down.  The

   responder connection will survive if the Origin-Host of the local

   Diameter entity is higher than that of the peer; the initiator

   connection will survive if the peer's Origin-Host is higher.  All

   subsequent messages are sent on the surviving connection.  Note that

   the results of an election on one peer are guaranteed to be the

   inverse of the results on the other.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

These are contradicting. I guess the test draft should be corrected. As per RFC3588,

 

If A and B are two Peers,

 

 

Ai is the initiator of the connection C1; Br is the responder for the connection C1

Bi is the initiator of the connection C2; Ar is the responder for the connection C2

 

Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process.

 

But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt explains differently. Please confirm that this draft needs to be corrected.

 

 

Thanks,

Bala

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_m81lFyGy+pWDyp28o5iAdw)-- --Boundary_(ID_ALSro3hW1sl4/rFk2gkcdA)-- --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg) Content-type: text/x-vcard; name=h71438.vcf; charset=windows-1252 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=h71438.vcf Content-description: Card for HarshaM 71438 begin:vcard n:Matadhikari ;Harsha fn:Harsha M tel;home:64510566 tel;work:1405 org:Huawei Technologies India Pvt Ltd.;Embedded BU adr:;;#875, 2nd Floor, 3rd Main, Hosakerehalli;Banashankari III Stage, Bangalore;Karnataka;560085;India version:2.1 email;internet:harsham@huawei.com title:TPL end:vcard --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg) 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 --Boundary_(ID_nJzOJ2Fh4FtefS0OxY+1hg)-- From dime-bounces@ietf.org Thu Aug 02 09:23: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 1IGaeB-0006xJ-Lm; Thu, 02 Aug 2007 09:23:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGaeA-0006xA-7b for dime@ietf.org; Thu, 02 Aug 2007 09:23:22 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGae8-0001BA-Of for dime@ietf.org; Thu, 02 Aug 2007 09:23:22 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM500J2FEIVY5@usaga01-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 06:23:20 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM500B9PEIUKA@usaga01-in.huawei.com> for dime@ietf.org; Thu, 02 Aug 2007 06:23:19 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.70.145.77]) by szxmc04-in.huawei.com (mshttpd); Thu, 02 Aug 2007 21:23:16 +0800 Date: Thu, 02 Aug 2007 21:23:16 +0800 From: HarshaM 71438 In-reply-to: To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q)" Content-language: en X-Accept-Language: en Priority: normal References: <66E8AEE9980BB44CA5FCAD39EBA56AC601F7CF9D@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-Spam-Score: 1.7 (+) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 Subject: [Dime] Query on PSM 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 This is a multi-part message in MIME format. --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi All, I am confused about Peer State Machine in RFC 3588. This is my understanding 1) The peer state machine actually combines two state machines,Initiator (client) state machine and Responder (server) state machine. 2) States and events with "I" are possible only in initiator. 3) States and events with "R" are possible only in responder. 4) States and events without any prefix can come in both. But I also see some initiator states like "WAIT-I-CEA" that can receive events from responder like "R-Conn-CER", how is this possible? If I am wrong somewhere please correct me. Regards, Harsha PS: Sorry for following a wrong thread in the last mail. --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) Content-type: multipart/related; boundary="Boundary_(ID_TkOjNkNhI1vr4wKL8kAqOw)" --Boundary_(ID_TkOjNkNhI1vr4wKL8kAqOw) Content-type: multipart/alternative; boundary="Boundary_(ID_rYAHGHlLP51b7YFNU50nIg)" --Boundary_(ID_rYAHGHlLP51b7YFNU50nIg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Bala, I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node. 1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.) 2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side). Hope this helps. cheers, Harish ---------- Forwarded message ---------- From: Balamurugan T, TLS-Chennai Date: Aug 1, 2007 7:39 PM Subject: [Dime] Clarification regarding the election process To: dime@ietf.org Hi All, I need some clarification regarding the election process in peer state machine. According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, The election process is described as below +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 3.1.1.2. Election This test case refers to Section 5.6.4 of [RFC3588]. Responders must be able to resolve contention with initiator peers. o Positive test for establishment of connection with responder having higher identity than initiator. Vendor A initiates connection followed by B doing the same a few milliseconds later. *Vendor A having a higher identity should close B's connection* * attempt.* +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ But, in RFC 3588, section 5.6. Peer State Machine, 5th paragraph explains ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A CER message is always sent on the initiating connection immediately after the connection request is successfully completed. In the case of an election, one of the two connections will shut down*. The* * responder connection will survive if the Origin-Host of the local* * Diameter entity is higher than that of the peer;* the initiator connection will survive if the peer's Origin-Host is higher. All subsequent messages are sent on the surviving connection. Note that the results of an election on one peer are guaranteed to be the inverse of the results on the other. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ These are contradicting. I guess the test draft should be corrected. As per RFC3588, If A and B are two Peers, Ai is the initiator of the connection C1; Br is the responder for the connection C1 Bi is the initiator of the connection C2; Ar is the responder for the connection C2 Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process. But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txtexplains differently. Please confirm that this draft needs to be corrected. Thanks, Bala DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_rYAHGHlLP51b7YFNU50nIg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Hi Bala,

I think the bis- draft/RFC is correct in this regard. Please note that election has to be held at the responder (listening) end. The statements are w.r.t that node.

1. The responder connection will survice if the Origin-Host of the local Diameter entity is higher than that of the peer (This is correct. The election will result in Win-Election result at the responder in this case - in case listening end too had iniated a transport connection.)

2. The initiator connection will survive if the peer's Origin-Host is higher (This means, the node that does the connect has a higher Origin-Host and will win the election. So the 'responder' node has to close the connection initated from its side).

Hope this helps.

cheers,
Harish

---------- Forwarded message ----------
From: Balamurugan T, TLS-Chennai < tbalamurugan@hcl.in>
Date: Aug 1, 2007 7:39 PM
Subject: [Dime] Clarification regarding the election process
To: dime@ietf.org

 

Hi All,

 

     I need some clarification regarding the election process in peer state machine.

 

   According to http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt, 

 
The election process is described as below 
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3.1.1.2.  Election

 
   This test case refers to Section 5.6.4 of [RFC3588].  Responders must

   be able to resolve contention with initiator peers.

 
   o  Positive test for establishment of connection with responder

      having higher identity than initiator.  Vendor A initiates
      connection followed by B doing the same a few milliseconds later.

      Vendor A having a higher identity should close B's connection

      attempt.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

 

 

But, in RFC 3588, section  5.6.  Peer State Machine, 5th paragraph explains

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   A CER message is always sent on the initiating connection immediately

   after the connection request is successfully completed.  In the case

   of an election, one of the two connections will shut down.  The

   responder connection will survive if the Origin-Host of the local

   Diameter entity is higher than that of the peer; the initiator

   connection will survive if the peer's Origin-Host is higher.  All

   subsequent messages are sent on the surviving connection.  Note that

   the results of an election on one peer are guaranteed to be the

   inverse of the results on the other.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

These are contradicting. I guess the test draft should be corrected. As per RFC3588,

 

If A and B are two Peers,

 

 

Ai is the initiator of the connection C1; Br is the responder for the connection C1

Bi is the initiator of the connection C2; Ar is the responder for the connection C2

 

Now, during the election process, if Host IP address of A is greater than that of B, C1 is closed and C2 is kept open for further process. Similarly if the Host IP address of B is greater than that of A, then C2 is closed and C1 is kept open for the further process.

 

But the test draft, http://www.opendiameter.org/public/draft-fajardo-dime-interop-test-suite-04.txt explains differently. Please confirm that this draft needs to be corrected.

 

 

Thanks,

Bala

 

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
--Boundary_(ID_rYAHGHlLP51b7YFNU50nIg)-- --Boundary_(ID_TkOjNkNhI1vr4wKL8kAqOw)-- --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) Content-type: text/x-vcard; name=h71438.vcf; charset=windows-1252 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=h71438.vcf Content-description: Card for HarshaM 71438 begin:vcard n:Matadhikari ;Harsha fn:Harsha M tel;home:64510566 tel;work:1405 org:Huawei Technologies India Pvt Ltd.;Embedded BU adr:;;#875, 2nd Floor, 3rd Main, Hosakerehalli;Banashankari III Stage, Bangalore;Karnataka;560085;India version:2.1 email;internet:harsham@huawei.com title:TPL end:vcard --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q) 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 --Boundary_(ID_OCD2CWHJEZUEw5BKbwaX5Q)-- From dime-bounces@ietf.org Thu Aug 02 11:16: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 1IGcQ4-0005Kn-LV; Thu, 02 Aug 2007 11:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcQ2-0005KZ-Vn for dime@ietf.org; Thu, 02 Aug 2007 11:16:54 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGcQ1-0002Z5-D1 for dime@ietf.org; Thu, 02 Aug 2007 11:16:54 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1186067811!1189442!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31589 invoked from network); 2 Aug 2007 15:16:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 2 Aug 2007 15:16:52 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l72FGplU022044 for ; Thu, 2 Aug 2007 08:16:51 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l72FGpkJ010813 for ; Thu, 2 Aug 2007 10:16:51 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l72FGoQP010801 for ; Thu, 2 Aug 2007 10:16:50 -0500 (CDT) 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 11:16:49 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFA= References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , "Tina TSOU" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 I agree with Tolga. The user must consult with his home provider for the per-minute charges. The price paid by the home provider for all the NEs along the path will be the wholesale price, and the home provider likely has a contract with the end user for a different price. The Diameter QoS application only deals with the wholesale price. -Pete Asveren, Tolga wrote: > Hi Tina, >=20 > IMHO, this could be classified as a different "service". For example > right now people check a website or a paper document (or sometimes > they listen to an announcement) where prices are listed (maybe not > for different QoS levels but for different destinations, but > conceptually it is similar). =20 >=20 > Thanks, > Tolga >=20 > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, August 01, 2007 11:16 PM > To: dime@ietf.org > Subject: [Dime] One scenario related to QoS Appl. >=20 > Hi all, > One scenario to be discussed is as below. >=20 > One user is going to make a call with his friend. He estimates it > will take about 20 minutes to complete the call. Prices for calls at > different QoS levels are different, good quality calls will cost more > than low quality ones do. So he gotta know the QoS level at which his > account balance can provide 20 minutes quotas or more for him. =20 >=20 > Is it supported by the current QoS Appl.? > B. R. > Tina > +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > Messengers: > MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU=A0=A0=A0 > Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com=20 >=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 Aug 02 11:19:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcSZ-0007v3-I8; Thu, 02 Aug 2007 11:19:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGcSY-0007rP-KL for dime@ietf.org; Thu, 02 Aug 2007 11:19:30 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGcSY-0004Hf-4Z for dime@ietf.org; Thu, 02 Aug 2007 11:19:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Vendor-Specific Commands Date: Thu, 2 Aug 2007 11:19:18 -0400 Message-ID: In-Reply-To: References: <19EBBEC503C3B5469070E0A6674A533A59D37A@daebe104.NOE.Nokia.com><46B0B088.307@tari.toshiba.com> From: "Mark Jones" To: "Romascanu, Dan (Dan)" 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 Dan, > You need to be clear what to ask from IANA.=20 I think we've concluded that "First Come First Served" is the most appropriate policy for assignment of Vendor-Specific Command Codes.=20 In IETF, "Vendor-Specific" does not distinguish between SDO and equipment vendor. A single IANA assignment policy for these two groups is not ideal: The "Specification Required" policy is preferable for SDOs but it simply does not work for proprietary commands. The "First Come First Served" assignment policy requires "a brief description of what the value would be used for" [RFC2434]. I suggest that RFC3588bis clarifies this in the context of Vendor-Specific Command Codes with the following text in section 11.2.1 (following Glen's proposed text): "The request for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification which documents the command in sufficient detail for interoperability between independent implementations. If the specification is not publicly available, the request for a Vendor-Specific Command Code MUST include a point of contact for the proposed command." The Vendor-Specific Application IDs already assigned by IANA follow these rules so there should not be any issues with extending them to Vendor-Specific Command Codes. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 12:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdFk-0004Mu-Qy; Thu, 02 Aug 2007 12:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdFi-0004JD-QY for dime@ietf.org; Thu, 02 Aug 2007 12:10:18 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGdFh-0003nP-G3 for dime@ietf.org; Thu, 02 Aug 2007 12:10:18 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l72G9vL4001725; Thu, 2 Aug 2007 11:10:08 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:10:07 -0500 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 11:10:07 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUA== References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Asveren, Tolga" , "Tina TSOU" , X-OriginalArrivalTime: 02 Aug 2007 16:10:07.0738 (UTC) FILETIME=[9830B5A0:01C7D51F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Pete, I agree the wholesale model should be supported for sure, but it might = be possible to have another model, in the roaming scenario, the visited = network, based on the agreement (or negotiate) with home network on = Price/QoS for a particular service, may perform QoS handling on = individual session/request basis. Maybe I misunderstood the wholesale = price/model you refer to. Regards, Dong =20 -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, August 02, 2007 11:17 AM To: Asveren, Tolga; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. I agree with Tolga. The user must consult with his home provider for = the per-minute charges. The price paid by the home provider for all the = NEs along the path will be the wholesale price, and the home provider = likely has a contract with the end user for a different price. The = Diameter QoS application only deals with the wholesale price. -Pete Asveren, Tolga wrote: > Hi Tina, >=20 > IMHO, this could be classified as a different "service". For example=20 > right now people check a website or a paper document (or sometimes=20 > they listen to an announcement) where prices are listed (maybe not for = > different QoS levels but for different destinations, but > conceptually it is similar). =20 >=20 > Thanks, > Tolga >=20 > ________________________________________ > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Wednesday, August 01, 2007 11:16 PM > To: dime@ietf.org > Subject: [Dime] One scenario related to QoS Appl. >=20 > Hi all, > One scenario to be discussed is as below. >=20 > One user is going to make a call with his friend. He estimates it will = > take about 20 minutes to complete the call. Prices for calls at=20 > different QoS levels are different, good quality calls will cost more=20 > than low quality ones do. So he gotta know the QoS level at which his > account balance can provide 20 minutes quotas or more for him. =20 >=20 > Is it supported by the current QoS Appl.? > B. R. > Tina > +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > Messengers: > MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU > Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com >=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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 12:18: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 1IGdNq-0000vt-AI; Thu, 02 Aug 2007 12:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdNo-0000vo-H1 for dime@ietf.org; Thu, 02 Aug 2007 12:18:40 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGdNo-0004Dg-4O for dime@ietf.org; Thu, 02 Aug 2007 12:18:40 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1186071515!25208197!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17176 invoked from network); 2 Aug 2007 16:18:35 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-119.messagelabs.com with SMTP; 2 Aug 2007 16:18:35 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l72GIYmB024047 for ; Thu, 2 Aug 2007 09:18:34 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l72GIXCG005694 for ; Thu, 2 Aug 2007 11:18:34 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l72GIWeO005678 for ; Thu, 2 Aug 2007 11:18:33 -0500 (CDT) 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 12:18:30 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2A References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , "Asveren, Tolga" , "Tina TSOU" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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, Dong, I don't quite understand the new model you are proposing - I think you are saying that individual Network Elements might have a negotiated price with the home network. I think that's fine and can be accommodated; the QAR message should contain the price that the NE is going to charge for its service. The NE might take into account contracts that may exist with the home network, since we assume that the NE knows the Destination Realm. -Pete Sun, Dong (Dong) wrote: > Hi Pete, > I agree the wholesale model should be supported for sure, but it > might be possible to have another model, in the roaming scenario, the > visited network, based on the agreement (or negotiate) with home > network on Price/QoS for a particular service, may perform QoS > handling on individual session/request basis. Maybe I misunderstood > the wholesale price/model you refer to. =20 >=20 > Regards, > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 11:17 AM > To: Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > I agree with Tolga. The user must consult with his home provider for > the per-minute charges. The price paid by the home provider for all > the NEs along the path will be the wholesale price, and the home > provider likely has a contract with the end user for a different > price. The Diameter QoS application only deals with the wholesale > price. =20 >=20 > -Pete >=20 > Asveren, Tolga wrote: >> Hi Tina, >>=20 >> IMHO, this could be classified as a different "service". For example >> right now people check a website or a paper document (or sometimes >> they listen to an announcement) where prices are listed (maybe not >> for different QoS levels but for different destinations, but >> conceptually it is similar). >>=20 >> Thanks, >> Tolga >>=20 >> ________________________________________ >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Wednesday, August 01, 2007 11:16 PM >> To: dime@ietf.org >> Subject: [Dime] One scenario related to QoS Appl. >>=20 >> Hi all, >> One scenario to be discussed is as below. >>=20 >> One user is going to make a call with his friend. He estimates it >> will take about 20 minutes to complete the call. Prices for calls at >> different QoS levels are different, good quality calls will cost more >> than low quality ones do. So he gotta know the QoS level at which his >> account balance can provide 20 minutes quotas or more for him. >>=20 >> Is it supported by the current QoS Appl.? >> B. R. >> Tina >> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) >> Messengers: >> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU >> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 12:27: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 1IGdWY-0003Wg-1i; Thu, 02 Aug 2007 12:27:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdWW-0003Wa-Us for dime@ietf.org; Thu, 02 Aug 2007 12:27:40 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGdWW-0005li-6X for dime@ietf.org; Thu, 02 Aug 2007 12:27:40 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l72GRE6V015965; Thu, 2 Aug 2007 11:27:26 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:27:19 -0500 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 11:27:18 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteA= References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Asveren, Tolga" , "Tina TSOU" , X-OriginalArrivalTime: 02 Aug 2007 16:27:19.0250 (UTC) FILETIME=[FF04F320:01C7D521] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 I also think the QoS application should be able to support this new = model, may be named as retail scenario. It seems to me there might be more common in practice to have one local = PDF (authorizing entity) residing in the visited network domain to talk = to the authorizing entity in the home network rather than asking each NE = for this kind of negotiation/decision. Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, August 02, 2007 12:19 PM To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. Hi, Dong, I don't quite understand the new model you are proposing - I think you = are saying that individual Network Elements might have a negotiated = price with the home network. I think that's fine and can be = accommodated; the QAR message should contain the price that the NE is = going to charge for its service. The NE might take into account = contracts that may exist with the home network, since we assume that the = NE knows the Destination Realm. -Pete Sun, Dong (Dong) wrote: > Hi Pete, > I agree the wholesale model should be supported for sure, but it might = > be possible to have another model, in the roaming scenario, the=20 > visited network, based on the agreement (or negotiate) with home=20 > network on Price/QoS for a particular service, may perform QoS=20 > handling on individual session/request basis. Maybe I misunderstood > the wholesale price/model you refer to. =20 >=20 > Regards, > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 11:17 AM > To: Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > I agree with Tolga. The user must consult with his home provider for=20 > the per-minute charges. The price paid by the home provider for all=20 > the NEs along the path will be the wholesale price, and the home=20 > provider likely has a contract with the end user for a different=20 > price. The Diameter QoS application only deals with the wholesale > price. =20 >=20 > -Pete >=20 > Asveren, Tolga wrote: >> Hi Tina, >>=20 >> IMHO, this could be classified as a different "service". For example=20 >> right now people check a website or a paper document (or sometimes=20 >> they listen to an announcement) where prices are listed (maybe not=20 >> for different QoS levels but for different destinations, but=20 >> conceptually it is similar). >>=20 >> Thanks, >> Tolga >>=20 >> ________________________________________ >> From: Tina TSOU [mailto:tena@huawei.com] >> Sent: Wednesday, August 01, 2007 11:16 PM >> To: dime@ietf.org >> Subject: [Dime] One scenario related to QoS Appl. >>=20 >> Hi all, >> One scenario to be discussed is as below. >>=20 >> One user is going to make a call with his friend. He estimates it=20 >> will take about 20 minutes to complete the call. Prices for calls at=20 >> different QoS levels are different, good quality calls will cost more = >> than low quality ones do. So he gotta know the QoS level at which his = >> account balance can provide 20 minutes quotas or more for him. >>=20 >> Is it supported by the current QoS Appl.? >> B. R. >> Tina >> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) >> Messengers: >> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU >> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 12:43: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 1IGdlW-00016W-NS; Thu, 02 Aug 2007 12:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdlW-00016O-8B for dime@ietf.org; Thu, 02 Aug 2007 12:43:10 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IGdlV-0004tv-2C for dime@ietf.org; Thu, 02 Aug 2007 12:43:10 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1186072986!18026299!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30409 invoked from network); 2 Aug 2007 16:43:06 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 2 Aug 2007 16:43:06 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l72Gh5xN019255 for ; Thu, 2 Aug 2007 09:43:05 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l72Gh46Y026098 for ; Thu, 2 Aug 2007 11:43:04 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l72Gh2FY026081 for ; Thu, 2 Aug 2007 11:43:03 -0500 (CDT) 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 12:43:01 -0400 Message-ID: In-Reply-To: <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMA== References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> From: "McCann Peter-A001034" To: "Sun, Dong (Dong)" , "Asveren, Tolga" , "Tina TSOU" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Sun, Dong (Dong) wrote: > I also think the QoS application should be able to support this new > model, may be named as retail scenario.=20 Can you give a more detailed description of the scenario you have in mind? Is it the same as Tina's? > It seems to me there might be more common in practice to have one > local PDF (authorizing entity) residing in the visited network domain > to talk to the authorizing entity in the home network rather than > asking each NE for this kind of negotiation/decision. =20 Sure, I think we should allow a PDF to add the price information to a QAR that is on its way toward the home network. -Pete > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 12:19 PM > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > Hi, Dong, >=20 > I don't quite understand the new model you are proposing - I think > you are saying that individual Network Elements might have a > negotiated price with the home network. I think that's fine and can > be accommodated; the QAR message should contain the price that the NE > is going to charge for its service. The NE might take into account > contracts that may exist with the home network, since we assume that > the NE knows the Destination Realm. =20 >=20 > -Pete >=20 > Sun, Dong (Dong) wrote: >> Hi Pete, >> I agree the wholesale model should be supported for sure, but it >> might be possible to have another model, in the roaming scenario, the >> visited network, based on the agreement (or negotiate) with home >> network on Price/QoS for a particular service, may perform QoS >> handling on individual session/request basis. Maybe I misunderstood >> the wholesale price/model you refer to. >>=20 >> Regards, >> Dong >>=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Thursday, August 02, 2007 11:17 AM >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org >> Subject: RE: [Dime] One scenario related to QoS Appl. >>=20 >> I agree with Tolga. The user must consult with his home provider for >> the per-minute charges. The price paid by the home provider for all >> the NEs along the path will be the wholesale price, and the home >> provider likely has a contract with the end user for a different >> price. The Diameter QoS application only deals with the wholesale >> price.=20 >>=20 >> -Pete >>=20 >> Asveren, Tolga wrote: >>> Hi Tina, >>>=20 >>> IMHO, this could be classified as a different "service". For example >>> right now people check a website or a paper document (or sometimes >>> they listen to an announcement) where prices are listed (maybe not >>> for different QoS levels but for different destinations, but >>> conceptually it is similar).=20 >>>=20 >>> Thanks, >>> Tolga >>>=20 >>> ________________________________________ >>> From: Tina TSOU [mailto:tena@huawei.com] >>> Sent: Wednesday, August 01, 2007 11:16 PM >>> To: dime@ietf.org >>> Subject: [Dime] One scenario related to QoS Appl. >>>=20 >>> Hi all, >>> One scenario to be discussed is as below. >>>=20 >>> One user is going to make a call with his friend. He estimates it >>> will take about 20 minutes to complete the call. Prices for calls at >>> different QoS levels are different, good quality calls will cost >>> more than low quality ones do. So he gotta know the QoS level at >>> which his account balance can provide 20 minutes quotas or more for >>> him.=20 >>>=20 >>> Is it supported by the current QoS Appl.? >>> B. R. >>> Tina >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) >>> Messengers: >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com >=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 Aug 02 12:57: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 1IGdzD-0005jQ-0z; Thu, 02 Aug 2007 12:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdzB-0005jF-Ql for dime@ietf.org; Thu, 02 Aug 2007 12:57:17 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGdzA-0005Fu-Ef for dime@ietf.org; Thu, 02 Aug 2007 12:57:17 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l72GvBRm007591; Thu, 2 Aug 2007 11:57:11 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 11:57:11 -0500 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 11:57:10 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMAAAHcKQ References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> From: "Sun, Dong \(Dong\)" To: "McCann Peter-A001034" , "Asveren, Tolga" , "Tina TSOU" , X-OriginalArrivalTime: 02 Aug 2007 16:57:11.0109 (UTC) FILETIME=[2B0CEF50:01C7D526] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 The retail scenario in my mind is: When UE is roaming in visited network and requests a service, the home = network will determine the price/QoS based on subscription and resource = availability (if multiple price/QoS options are allowed), and the = agreement with that visited network, it is also possible that home = network and visited network talk to each other on the fly to identify = the right price/QoS based on real resource status when the request = occurs (either push or pull mode can be used for the interaction = depending on the network/UE capability).=20 Dong -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Thursday, August 02, 2007 12:43 PM To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. Sun, Dong (Dong) wrote: > I also think the QoS application should be able to support this new=20 > model, may be named as retail scenario. Can you give a more detailed description of the scenario you have in = mind? Is it the same as Tina's? > It seems to me there might be more common in practice to have one=20 > local PDF (authorizing entity) residing in the visited network domain=20 > to talk to the authorizing entity in the home network rather than > asking each NE for this kind of negotiation/decision. =20 Sure, I think we should allow a PDF to add the price information to a = QAR that is on its way toward the home network. -Pete > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 12:19 PM > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > Hi, Dong, >=20 > I don't quite understand the new model you are proposing - I think you = > are saying that individual Network Elements might have a negotiated=20 > price with the home network. I think that's fine and can be=20 > accommodated; the QAR message should contain the price that the NE is=20 > going to charge for its service. The NE might take into account=20 > contracts that may exist with the home network, since we assume that > the NE knows the Destination Realm. =20 >=20 > -Pete >=20 > Sun, Dong (Dong) wrote: >> Hi Pete, >> I agree the wholesale model should be supported for sure, but it=20 >> might be possible to have another model, in the roaming scenario, the = >> visited network, based on the agreement (or negotiate) with home=20 >> network on Price/QoS for a particular service, may perform QoS=20 >> handling on individual session/request basis. Maybe I misunderstood=20 >> the wholesale price/model you refer to. >>=20 >> Regards, >> Dong >>=20 >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Thursday, August 02, 2007 11:17 AM >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org >> Subject: RE: [Dime] One scenario related to QoS Appl. >>=20 >> I agree with Tolga. The user must consult with his home provider for = >> the per-minute charges. The price paid by the home provider for all=20 >> the NEs along the path will be the wholesale price, and the home=20 >> provider likely has a contract with the end user for a different=20 >> price. The Diameter QoS application only deals with the wholesale=20 >> price. >>=20 >> -Pete >>=20 >> Asveren, Tolga wrote: >>> Hi Tina, >>>=20 >>> IMHO, this could be classified as a different "service". For example = >>> right now people check a website or a paper document (or sometimes=20 >>> they listen to an announcement) where prices are listed (maybe not=20 >>> for different QoS levels but for different destinations, but=20 >>> conceptually it is similar). >>>=20 >>> Thanks, >>> Tolga >>>=20 >>> ________________________________________ >>> From: Tina TSOU [mailto:tena@huawei.com] >>> Sent: Wednesday, August 01, 2007 11:16 PM >>> To: dime@ietf.org >>> Subject: [Dime] One scenario related to QoS Appl. >>>=20 >>> Hi all, >>> One scenario to be discussed is as below. >>>=20 >>> One user is going to make a call with his friend. He estimates it=20 >>> will take about 20 minutes to complete the call. Prices for calls at = >>> different QoS levels are different, good quality calls will cost=20 >>> more than low quality ones do. So he gotta know the QoS level at=20 >>> which his account balance can provide 20 minutes quotas or more for=20 >>> him. >>>=20 >>> Is it supported by the current QoS Appl.? >>> B. R. >>> Tina >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) >>> Messengers: >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com >=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 Aug 02 16:33: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 1IGhMf-0004zz-Fi; Thu, 02 Aug 2007 16:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhMd-0004zo-Uq for dime@ietf.org; Thu, 02 Aug 2007 16:33:43 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGhMc-0001rm-Nh for dime@ietf.org; Thu, 02 Aug 2007 16:33:43 -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 l72KXVZp005492; Thu, 2 Aug 2007 16:33:31 -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 Subject: RE: [Dime] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 16:33:31 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMAAAHcKQAAfQZJA= References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" , "McCann Peter-A001034" , "Tina TSOU" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 That organizations can dynamically negotiate the price for QoS is = interesting but a bit too complex as a first step IMHO. I think, it is = better to address it in an extension document. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, August 02, 2007 12:57 PM > To: McCann Peter-A001034; Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > The retail scenario in my mind is: > When UE is roaming in visited network and requests a service, the home > network will determine the price/QoS based on subscription and = resource > availability (if multiple price/QoS options are allowed), and the > agreement with that visited network, it is also possible that home = network > and visited network talk to each other on the fly to identify the = right > price/QoS based on real resource status when the request occurs = (either > push or pull mode can be used for the interaction depending on the > network/UE capability). >=20 > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 12:43 PM > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > Sun, Dong (Dong) wrote: > > I also think the QoS application should be able to support this new > > model, may be named as retail scenario. >=20 > Can you give a more detailed description of the scenario you have in = mind? > Is it the same as Tina's? >=20 > > It seems to me there might be more common in practice to have one > > local PDF (authorizing entity) residing in the visited network = domain > > to talk to the authorizing entity in the home network rather than > > asking each NE for this kind of negotiation/decision. >=20 > Sure, I think we should allow a PDF to add the price information to a = QAR > that is on its way toward the home network. >=20 > -Pete >=20 > > Dong > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Thursday, August 02, 2007 12:19 PM > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > Hi, Dong, > > > > I don't quite understand the new model you are proposing - I think = you > > are saying that individual Network Elements might have a negotiated > > price with the home network. I think that's fine and can be > > accommodated; the QAR message should contain the price that the NE = is > > going to charge for its service. The NE might take into account > > contracts that may exist with the home network, since we assume that > > the NE knows the Destination Realm. > > > > -Pete > > > > Sun, Dong (Dong) wrote: > >> Hi Pete, > >> I agree the wholesale model should be supported for sure, but it > >> might be possible to have another model, in the roaming scenario, = the > >> visited network, based on the agreement (or negotiate) with home > >> network on Price/QoS for a particular service, may perform QoS > >> handling on individual session/request basis. Maybe I misunderstood > >> the wholesale price/model you refer to. > >> > >> Regards, > >> Dong > >> > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Thursday, August 02, 2007 11:17 AM > >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org > >> Subject: RE: [Dime] One scenario related to QoS Appl. > >> > >> I agree with Tolga. The user must consult with his home provider = for > >> the per-minute charges. The price paid by the home provider for = all > >> the NEs along the path will be the wholesale price, and the home > >> provider likely has a contract with the end user for a different > >> price. The Diameter QoS application only deals with the wholesale > >> price. > >> > >> -Pete > >> > >> Asveren, Tolga wrote: > >>> Hi Tina, > >>> > >>> IMHO, this could be classified as a different "service". For = example > >>> right now people check a website or a paper document (or sometimes > >>> they listen to an announcement) where prices are listed (maybe not > >>> for different QoS levels but for different destinations, but > >>> conceptually it is similar). > >>> > >>> Thanks, > >>> Tolga > >>> > >>> ________________________________________ > >>> From: Tina TSOU [mailto:tena@huawei.com] > >>> Sent: Wednesday, August 01, 2007 11:16 PM > >>> To: dime@ietf.org > >>> Subject: [Dime] One scenario related to QoS Appl. > >>> > >>> Hi all, > >>> One scenario to be discussed is as below. > >>> > >>> One user is going to make a call with his friend. He estimates it > >>> will take about 20 minutes to complete the call. Prices for calls = at > >>> different QoS levels are different, good quality calls will cost > >>> more than low quality ones do. So he gotta know the QoS level at > >>> which his account balance can provide 20 minutes quotas or more = for > >>> him. > >>> > >>> Is it supported by the current QoS Appl.? > >>> B. R. > >>> Tina > >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > >>> Messengers: > >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU > >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com > > > > _______________________________________________ > > 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 Aug 02 16:36: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 1IGhOt-0006nO-Cl; Thu, 02 Aug 2007 16:36:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhOs-0006nI-7g for dime@ietf.org; Thu, 02 Aug 2007 16:36:02 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGhOr-0002qf-RY for dime@ietf.org; Thu, 02 Aug 2007 16:36:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: Vendor-Specific Commands Date: Thu, 2 Aug 2007 16:36:00 -0400 Message-ID: In-Reply-To: References: From: "Mark Jones" To: "Daily William" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > It seems to me that the command code is already in a namespace, this > being defined by the application id. =20 My understanding is the Command Codes are taken from a single global namespace in order to allow Command re-use. Commands from one Diameter application can be re-used in another and are still required to conform to the original ABNF. However, the Command header in this case would contain the Application ID of the 'using application' and not the 'defining application'. This is required because the Application ID in the Command Header is used as a secondary key field in routing table lookups. I don't think this case was covered in the original 3588 but it is clarified in section 5.3 of the Application Design Guidelines draft.=20 Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 02 16:45:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhXf-0001it-9N; Thu, 02 Aug 2007 16:45:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhXd-0001io-LM for dime@ietf.org; Thu, 02 Aug 2007 16:45:05 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGhXc-00028R-Bw for dime@ietf.org; Thu, 02 Aug 2007 16:45:05 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l72KilV6021320; Thu, 2 Aug 2007 15:44:56 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 15:44:51 -0500 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 15:44:50 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520A0D@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMAAAHcKQAAfQZJAAAFWIIA== References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" , "McCann Peter-A001034" , "Tina TSOU" , X-OriginalArrivalTime: 02 Aug 2007 20:44:51.0462 (UTC) FILETIME=[F9416260:01C7D545] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 The basic retail could be dynamically negotiate the QoS and decide the = proper price based on static SLA (or vice versa). I thought it can be = supported by current QAR, QIR with some add-on parameters (if those = parameters have not yet defined).=20 The negotiation of SLA on the fly might be a bit complex if that is what = you are concerned, which I can see. -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Thursday, August 02, 2007 4:34 PM To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. That organizations can dynamically negotiate the price for QoS is = interesting but a bit too complex as a first step IMHO. I think, it is = better to address it in an extension document. Thanks, Tolga > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, August 02, 2007 12:57 PM > To: McCann Peter-A001034; Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > The retail scenario in my mind is: > When UE is roaming in visited network and requests a service, the home = > network will determine the price/QoS based on subscription and=20 > resource availability (if multiple price/QoS options are allowed), and = > the agreement with that visited network, it is also possible that home = > network and visited network talk to each other on the fly to identify=20 > the right price/QoS based on real resource status when the request=20 > occurs (either push or pull mode can be used for the interaction=20 > depending on the network/UE capability). >=20 > Dong >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Thursday, August 02, 2007 12:43 PM > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > Sun, Dong (Dong) wrote: > > I also think the QoS application should be able to support this new=20 > > model, may be named as retail scenario. >=20 > Can you give a more detailed description of the scenario you have in = mind? > Is it the same as Tina's? >=20 > > It seems to me there might be more common in practice to have one=20 > > local PDF (authorizing entity) residing in the visited network=20 > > domain to talk to the authorizing entity in the home network rather=20 > > than asking each NE for this kind of negotiation/decision. >=20 > Sure, I think we should allow a PDF to add the price information to a=20 > QAR that is on its way toward the home network. >=20 > -Pete >=20 > > Dong > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Thursday, August 02, 2007 12:19 PM > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > Hi, Dong, > > > > I don't quite understand the new model you are proposing - I think=20 > > you are saying that individual Network Elements might have a=20 > > negotiated price with the home network. I think that's fine and can = > > be accommodated; the QAR message should contain the price that the=20 > > NE is going to charge for its service. The NE might take into=20 > > account contracts that may exist with the home network, since we=20 > > assume that the NE knows the Destination Realm. > > > > -Pete > > > > Sun, Dong (Dong) wrote: > >> Hi Pete, > >> I agree the wholesale model should be supported for sure, but it=20 > >> might be possible to have another model, in the roaming scenario,=20 > >> the visited network, based on the agreement (or negotiate) with=20 > >> home network on Price/QoS for a particular service, may perform QoS = > >> handling on individual session/request basis. Maybe I misunderstood = > >> the wholesale price/model you refer to. > >> > >> Regards, > >> Dong > >> > >> -----Original Message----- > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > >> Sent: Thursday, August 02, 2007 11:17 AM > >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org > >> Subject: RE: [Dime] One scenario related to QoS Appl. > >> > >> I agree with Tolga. The user must consult with his home provider=20 > >> for the per-minute charges. The price paid by the home provider=20 > >> for all the NEs along the path will be the wholesale price, and the = > >> home provider likely has a contract with the end user for a=20 > >> different price. The Diameter QoS application only deals with the=20 > >> wholesale price. > >> > >> -Pete > >> > >> Asveren, Tolga wrote: > >>> Hi Tina, > >>> > >>> IMHO, this could be classified as a different "service". For=20 > >>> example right now people check a website or a paper document (or=20 > >>> sometimes they listen to an announcement) where prices are listed=20 > >>> (maybe not for different QoS levels but for different=20 > >>> destinations, but conceptually it is similar). > >>> > >>> Thanks, > >>> Tolga > >>> > >>> ________________________________________ > >>> From: Tina TSOU [mailto:tena@huawei.com] > >>> Sent: Wednesday, August 01, 2007 11:16 PM > >>> To: dime@ietf.org > >>> Subject: [Dime] One scenario related to QoS Appl. > >>> > >>> Hi all, > >>> One scenario to be discussed is as below. > >>> > >>> One user is going to make a call with his friend. He estimates it=20 > >>> will take about 20 minutes to complete the call. Prices for calls=20 > >>> at different QoS levels are different, good quality calls will=20 > >>> cost more than low quality ones do. So he gotta know the QoS level = > >>> at which his account balance can provide 20 minutes quotas or more = > >>> for him. > >>> > >>> Is it supported by the current QoS Appl.? > >>> B. R. > >>> Tina > >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > >>> Messengers: > >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 Skype: = tinaTSOU > >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: tinatsou6@gmail.com > > > > _______________________________________________ > > 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 Aug 02 17:09: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 1IGhvO-0006Us-44; Thu, 02 Aug 2007 17:09:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGhvL-0006MU-4j for dime@ietf.org; Thu, 02 Aug 2007 17:09:36 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGhvK-0003Oa-8A for dime@ietf.org; Thu, 02 Aug 2007 17:09:35 -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 l72L9H6k031034; Thu, 2 Aug 2007 17:09:17 -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 Subject: RE: [Dime] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 17:09:17 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E71880F0@sonusmail04.sonusnet.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D520A0D@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMAAAHcKQAAfQZJAAAFWIIAAAaA3Q References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A0D@ILEXC2U01.ndc.lucent.com> From: "Asveren, Tolga" To: "Sun, Dong (Dong)" , "McCann Peter-A001034" , "Tina TSOU" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Dong, > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, August 02, 2007 4:45 PM > To: Asveren, Tolga; McCann Peter-A001034; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > The basic retail could be dynamically negotiate the QoS and decide the > proper price based on static SLA (or vice versa). I thought it can be > supported by current QAR, QIR with some add-on parameters (if those > parameters have not yet defined). [TOLGA]It may/may not be doable purely from technical perspective. IMHO = it is not an immediate need in practice though. Just to make sure that I = understood this model correctly: I have a device/phone/softclient etc... to make voice/video calls. I can = select the quality of this communication by pressing/selecting a button. = I put the destination address/number, push the dial-button (or whatever = is its equivalent) and see some price-tag for different levels of = quality. Then I select a quality level. IMHO, use of resources associated with QoS could be dynamic enough to = make this model impractical. For example, it is not guaranteed that = during the time between the network issued the price info and hit the = button to select a service level, overall resource allocation in the = network stays the same. My understanding of Tina's message was that she is asking to convey some = information about static pricing. >=20 > The negotiation of SLA on the fly might be a bit complex if that is = what > you are concerned, which I can see. >=20 > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, August 02, 2007 4:34 PM > To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > That organizations can dynamically negotiate the price for QoS is > interesting but a bit too complex as a first step IMHO. I think, it is > better to address it in an extension document. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, August 02, 2007 12:57 PM > > To: McCann Peter-A001034; Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > The retail scenario in my mind is: > > When UE is roaming in visited network and requests a service, the = home > > network will determine the price/QoS based on subscription and > > resource availability (if multiple price/QoS options are allowed), = and > > the agreement with that visited network, it is also possible that = home > > network and visited network talk to each other on the fly to = identify > > the right price/QoS based on real resource status when the request > > occurs (either push or pull mode can be used for the interaction > > depending on the network/UE capability). > > > > Dong > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Thursday, August 02, 2007 12:43 PM > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > Sun, Dong (Dong) wrote: > > > I also think the QoS application should be able to support this = new > > > model, may be named as retail scenario. > > > > Can you give a more detailed description of the scenario you have in > mind? > > Is it the same as Tina's? > > > > > It seems to me there might be more common in practice to have one > > > local PDF (authorizing entity) residing in the visited network > > > domain to talk to the authorizing entity in the home network = rather > > > than asking each NE for this kind of negotiation/decision. > > > > Sure, I think we should allow a PDF to add the price information to = a > > QAR that is on its way toward the home network. > > > > -Pete > > > > > Dong > > > > > > -----Original Message----- > > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > > Sent: Thursday, August 02, 2007 12:19 PM > > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > > > Hi, Dong, > > > > > > I don't quite understand the new model you are proposing - I think > > > you are saying that individual Network Elements might have a > > > negotiated price with the home network. I think that's fine and = can > > > be accommodated; the QAR message should contain the price that the > > > NE is going to charge for its service. The NE might take into > > > account contracts that may exist with the home network, since we > > > assume that the NE knows the Destination Realm. > > > > > > -Pete > > > > > > Sun, Dong (Dong) wrote: > > >> Hi Pete, > > >> I agree the wholesale model should be supported for sure, but it > > >> might be possible to have another model, in the roaming scenario, > > >> the visited network, based on the agreement (or negotiate) with > > >> home network on Price/QoS for a particular service, may perform = QoS > > >> handling on individual session/request basis. Maybe I = misunderstood > > >> the wholesale price/model you refer to. > > >> > > >> Regards, > > >> Dong > > >> > > >> -----Original Message----- > > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >> Sent: Thursday, August 02, 2007 11:17 AM > > >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org > > >> Subject: RE: [Dime] One scenario related to QoS Appl. > > >> > > >> I agree with Tolga. The user must consult with his home provider > > >> for the per-minute charges. The price paid by the home provider > > >> for all the NEs along the path will be the wholesale price, and = the > > >> home provider likely has a contract with the end user for a > > >> different price. The Diameter QoS application only deals with = the > > >> wholesale price. > > >> > > >> -Pete > > >> > > >> Asveren, Tolga wrote: > > >>> Hi Tina, > > >>> > > >>> IMHO, this could be classified as a different "service". For > > >>> example right now people check a website or a paper document (or > > >>> sometimes they listen to an announcement) where prices are = listed > > >>> (maybe not for different QoS levels but for different > > >>> destinations, but conceptually it is similar). > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> ________________________________________ > > >>> From: Tina TSOU [mailto:tena@huawei.com] > > >>> Sent: Wednesday, August 01, 2007 11:16 PM > > >>> To: dime@ietf.org > > >>> Subject: [Dime] One scenario related to QoS Appl. > > >>> > > >>> Hi all, > > >>> One scenario to be discussed is as below. > > >>> > > >>> One user is going to make a call with his friend. He estimates = it > > >>> will take about 20 minutes to complete the call. Prices for = calls > > >>> at different QoS levels are different, good quality calls will > > >>> cost more than low quality ones do. So he gotta know the QoS = level > > >>> at which his account balance can provide 20 minutes quotas or = more > > >>> for him. > > >>> > > >>> Is it supported by the current QoS Appl.? > > >>> B. R. > > >>> Tina > > >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > > >>> Messengers: > > >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 = Skype: tinaTSOU > > >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: = tinatsou6@gmail.com > > > > > > _______________________________________________ > > > 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 Aug 02 17:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiKU-0003bH-VY; Thu, 02 Aug 2007 17:35:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiKU-0003bB-3U for dime@ietf.org; Thu, 02 Aug 2007 17:35:34 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGiKS-0002zW-Q8 for dime@ietf.org; Thu, 02 Aug 2007 17:35:34 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l72LZMwH022890; Thu, 2 Aug 2007 16:35:22 -0500 (CDT) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 16:35:22 -0500 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] One scenario related to QoS Appl. Date: Thu, 2 Aug 2007 16:35:21 -0500 Message-ID: <09C9068466B79E4C938DC7737562404D520A0F@ILEXC2U01.ndc.lucent.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880F0@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] One scenario related to QoS Appl. Thread-Index: AcfUs8U0hxRYQmhAQZyx2RpcnzPg1gATKd4AAAXNpFAAAaYvUAAAdU2AAABRteAAAKkiMAAAHcKQAAfQZJAAAFWIIAAAaA3QAAEKvqA= References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A0D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880F0@sonusmail04.sonusnet.com> From: "Sun, Dong \(Dong\)" To: "Asveren, Tolga" , "McCann Peter-A001034" , "Tina TSOU" , X-OriginalArrivalTime: 02 Aug 2007 21:35:22.0024 (UTC) FILETIME=[079C7280:01C7D54D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 Tolga, The model you described is not exact as I am thinking. The key point in = the retail model is that visited network could provide some QoS info on = per call level to facilitate the decision in addition to home network = policy (against the pure wholesale model). This interaction might be = transparent to end user totally.=20 If the carrier likes to offer the different options of QoS/price to end = user directly, the mechanism should be helpful. I don't see real issue = from a purely technical perspective :-) although this scenario is not = what I am concerned and addressed sofar. In your example, when UE = selects a price/qos plan, it would send a message e.g. SIP to request = the authorization from its home SP, before getting back the confirmation = to UE, the SP will check and allocate the resources along the path. Certainly, the options of the price on the list would be very limited = typically, may not be more than what you can see in the gas station, I = guess :-).=20 Regards, Dong=20 -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Thursday, August 02, 2007 5:09 PM To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. Hi Dong, > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, August 02, 2007 4:45 PM > To: Asveren, Tolga; McCann Peter-A001034; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > The basic retail could be dynamically negotiate the QoS and decide the = > proper price based on static SLA (or vice versa). I thought it can be=20 > supported by current QAR, QIR with some add-on parameters (if those=20 > parameters have not yet defined). [TOLGA]It may/may not be doable purely from technical perspective. IMHO = it is not an immediate need in practice though. Just to make sure that I = understood this model correctly: I have a device/phone/softclient etc... to make voice/video calls. I can = select the quality of this communication by pressing/selecting a button. = I put the destination address/number, push the dial-button (or whatever = is its equivalent) and see some price-tag for different levels of = quality. Then I select a quality level. IMHO, use of resources associated with QoS could be dynamic enough to = make this model impractical. For example, it is not guaranteed that = during the time between the network issued the price info and hit the = button to select a service level, overall resource allocation in the = network stays the same. My understanding of Tina's message was that she is asking to convey some = information about static pricing. >=20 > The negotiation of SLA on the fly might be a bit complex if that is=20 > what you are concerned, which I can see. >=20 > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, August 02, 2007 4:34 PM > To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. >=20 > That organizations can dynamically negotiate the price for QoS is=20 > interesting but a bit too complex as a first step IMHO. I think, it is = > better to address it in an extension document. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, August 02, 2007 12:57 PM > > To: McCann Peter-A001034; Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > The retail scenario in my mind is: > > When UE is roaming in visited network and requests a service, the=20 > > home network will determine the price/QoS based on subscription and=20 > > resource availability (if multiple price/QoS options are allowed),=20 > > and the agreement with that visited network, it is also possible=20 > > that home network and visited network talk to each other on the fly=20 > > to identify the right price/QoS based on real resource status when=20 > > the request occurs (either push or pull mode can be used for the=20 > > interaction depending on the network/UE capability). > > > > Dong > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Thursday, August 02, 2007 12:43 PM > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > Sun, Dong (Dong) wrote: > > > I also think the QoS application should be able to support this=20 > > > new model, may be named as retail scenario. > > > > Can you give a more detailed description of the scenario you have in > mind? > > Is it the same as Tina's? > > > > > It seems to me there might be more common in practice to have one=20 > > > local PDF (authorizing entity) residing in the visited network=20 > > > domain to talk to the authorizing entity in the home network=20 > > > rather than asking each NE for this kind of negotiation/decision. > > > > Sure, I think we should allow a PDF to add the price information to=20 > > a QAR that is on its way toward the home network. > > > > -Pete > > > > > Dong > > > > > > -----Original Message----- > > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > > Sent: Thursday, August 02, 2007 12:19 PM > > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > > > Hi, Dong, > > > > > > I don't quite understand the new model you are proposing - I think = > > > you are saying that individual Network Elements might have a=20 > > > negotiated price with the home network. I think that's fine and=20 > > > can be accommodated; the QAR message should contain the price that = > > > the NE is going to charge for its service. The NE might take into = > > > account contracts that may exist with the home network, since we=20 > > > assume that the NE knows the Destination Realm. > > > > > > -Pete > > > > > > Sun, Dong (Dong) wrote: > > >> Hi Pete, > > >> I agree the wholesale model should be supported for sure, but it=20 > > >> might be possible to have another model, in the roaming scenario, = > > >> the visited network, based on the agreement (or negotiate) with=20 > > >> home network on Price/QoS for a particular service, may perform=20 > > >> QoS handling on individual session/request basis. Maybe I=20 > > >> misunderstood the wholesale price/model you refer to. > > >> > > >> Regards, > > >> Dong > > >> > > >> -----Original Message----- > > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >> Sent: Thursday, August 02, 2007 11:17 AM > > >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org > > >> Subject: RE: [Dime] One scenario related to QoS Appl. > > >> > > >> I agree with Tolga. The user must consult with his home provider = > > >> for the per-minute charges. The price paid by the home provider=20 > > >> for all the NEs along the path will be the wholesale price, and=20 > > >> the home provider likely has a contract with the end user for a=20 > > >> different price. The Diameter QoS application only deals with=20 > > >> the wholesale price. > > >> > > >> -Pete > > >> > > >> Asveren, Tolga wrote: > > >>> Hi Tina, > > >>> > > >>> IMHO, this could be classified as a different "service". For=20 > > >>> example right now people check a website or a paper document (or = > > >>> sometimes they listen to an announcement) where prices are=20 > > >>> listed (maybe not for different QoS levels but for different=20 > > >>> destinations, but conceptually it is similar). > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> ________________________________________ > > >>> From: Tina TSOU [mailto:tena@huawei.com] > > >>> Sent: Wednesday, August 01, 2007 11:16 PM > > >>> To: dime@ietf.org > > >>> Subject: [Dime] One scenario related to QoS Appl. > > >>> > > >>> Hi all, > > >>> One scenario to be discussed is as below. > > >>> > > >>> One user is going to make a call with his friend. He estimates=20 > > >>> it will take about 20 minutes to complete the call. Prices for=20 > > >>> calls at different QoS levels are different, good quality calls=20 > > >>> will cost more than low quality ones do. So he gotta know the=20 > > >>> QoS level at which his account balance can provide 20 minutes=20 > > >>> quotas or more for him. > > >>> > > >>> Is it supported by the current QoS Appl.? > > >>> B. R. > > >>> Tina > > >>> +86-755-28972912 (Office)=A0=A0=A0 +86-13922884380 (Mobile) > > >>> Messengers: > > >>> MSN: tinatsou6@hotmail.com=A0=A0 Yahoo: tina_tsou=A0=A0=A0 = Skype: tinaTSOU > > >>> Jabber: tina@jabber.org=A0=A0=A0 Google talk: = tinatsou6@gmail.com > > > > > > _______________________________________________ > > > 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 Aug 02 17:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiaD-0002Bq-Eo; Thu, 02 Aug 2007 17:51:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiaC-0002Bl-NS for dime@ietf.org; Thu, 02 Aug 2007 17:51:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IGiaC-00040z-17 for dime@ietf.org; Thu, 02 Aug 2007 17:51:48 -0400 Received: (qmail 13853 invoked by uid 0); 2 Aug 2007 21:45:07 -0000 Received: from 90.186.116.146 by www095.gmx.net with HTTP; Thu, 02 Aug 2007 23:45:07 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Aug 2007 23:45:07 +0200 From: "Hannes Tschofenig" In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> Message-ID: <20070802214507.245620@gmx.net> MIME-Version: 1.0 References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com><033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com><09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> To: dime@ietf.org, keyprov@ietf.org, ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX192AsBf3rF2Vr5WT3/c0rTUYGa5P1YTBozyrxJSZF qHrTO39i46zdmejPySNWUlzSPSRcAnlNUccg== Content-Transfer-Encoding: 7bit X-GMX-UID: UWaHd4c3bUk7LMVQ8Gkn5npsZ2hlN4rX X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Dime] Vacation 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 Folks, I am on vacation and (almost) out of email reach until August 13th. If you need something really urgent then put "URGENT" into the subject header of your mail to Hannes.Tschofenig@gmx.net. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 03 04:25: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 1IGsT8-0006Iz-BH; Fri, 03 Aug 2007 04:25:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGsT7-0006Iu-71 for dime@ietf.org; Fri, 03 Aug 2007 04:25:09 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGsT5-00022a-5N for dime@ietf.org; Fri, 03 Aug 2007 04:25:09 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM600FDQUSM4Z@szxga03-in.huawei.com> for dime@ietf.org; Fri, 03 Aug 2007 16:12:22 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM6001BRUSJC0@szxga03-in.huawei.com> for dime@ietf.org; Fri, 03 Aug 2007 16:12:22 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM6002DXUSIV3@szxml03-in.huawei.com> for dime@ietf.org; Fri, 03 Aug 2007 16:12:19 +0800 (CST) Date: Fri, 03 Aug 2007 16:12:18 +0800 From: Tina TSOU Subject: Re: [Dime] One scenario related to QoS Appl. To: dime@ietf.org, McCann Peter-A001034 , "Asveren, Tolga" , "Sun, Dong (Dong)" Message-id: <018701c7d5a6$02970e90$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=original; charset=utf-8; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <005501c7d4b3$7691ce50$864c460a@china.huawei.com> <033458F56EC2A64E8D2D7B759FA3E7E71880E3@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A08@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A09@ILEXC2U01.ndc.lucent.com> <09C9068466B79E4C938DC7737562404D520A0A@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880EF@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A0D@ILEXC2U01.ndc.lucent.com> <033458F56EC2A64E8D2D7B759FA3E7E71880F0@sonusmail04.sonusnet.com> <09C9068466B79E4C938DC7737562404D520A0F@ILEXC2U01.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 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 all, Tks for all your reply. I did not sleep well yesterday night, due to = the jet=20 lag, or I knew you guys were posting a lot during my sleep;-) I think Tolga understood my original meaning more precisely. The detailed scenario is below. The user has a device/phone/soft client etc... to make voice/video ca= lls. He=20 (I would say she :) can select multiple QoS levels of this communicat= ion by=20 pressing/selecting a button. Then he puts the destination address/number, the quota he needs (for= =20 example, 20 minutes), push the dial-button. (1)One is: The Authorizing Entity calculates different quotas accordi= ng to=20 the user's account balance and different QoS levels, and then returns= the=20 result to user's device=E3=80=82 The user selects a quality level whose matching quota is equal to the= =20 required quota or more than it. Maybe the user will select the best q= uality=20 meeting his need on quota. (2)The other is: The Authorizing Entity calculates different quotas= =20 according to the account balance and different QoS levels, and then s= elects=20 the best quality level meeting the user's need on quota on its own. T= hen the=20 Authorizing Entity returns the best quality level to network elements= in=20 order to reserve resources. B. R. Tina ----- Original Message -----=20 =46rom: "Sun, Dong (Dong)" To: "Asveren, Tolga" ; "McCann Peter-A001034"= =20 ; "Tina TSOU" ; Sent: Friday, August 03, 2007 5:35 AM Subject: RE: [Dime] One scenario related to QoS Appl. Hi Tolga, The model you described is not exact as I am thinking. The key point = in the=20 retail model is that visited network could provide some QoS info on p= er call=20 level to facilitate the decision in addition to home network policy (= against=20 the pure wholesale model). This interaction might be transparent to e= nd user=20 totally. If the carrier likes to offer the different options of QoS/price to e= nd user=20 directly, the mechanism should be helpful. I don't see real issue fro= m a=20 purely technical perspective :-) although this scenario is not what I= am=20 concerned and addressed sofar. In your example, when UE selects a pri= ce/qos=20 plan, it would send a message e.g. SIP to request the authorization f= rom its=20 home SP, before getting back the confirmation to UE, the SP will chec= k and=20 allocate the resources along the path. Certainly, the options of the price on the list would be very limited= =20 typically, may not be more than what you can see in the gas station, = I guess=20 :-). Regards, Dong -----Original Message----- =46rom: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Thursday, August 02, 2007 5:09 PM To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.org Subject: RE: [Dime] One scenario related to QoS Appl. Hi Dong, > -----Original Message----- > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > Sent: Thursday, August 02, 2007 4:45 PM > To: Asveren, Tolga; McCann Peter-A001034; Tina TSOU; dime@ietf.org > Subject: RE: [Dime] One scenario related to QoS Appl. > > The basic retail could be dynamically negotiate the QoS and decide = the > proper price based on static SLA (or vice versa). I thought it can = be > supported by current QAR, QIR with some add-on parameters (if those > parameters have not yet defined). [TOLGA]It may/may not be doable purely from technical perspective. IM= HO it=20 is not an immediate need in practice though. Just to make sure that I= =20 understood this model correctly: I have a device/phone/softclient etc... to make voice/video calls. I = can=20 select the quality of this communication by pressing/selecting a butt= on. I=20 put the destination address/number, push the dial-button (or whatever= is its=20 equivalent) and see some price-tag for different levels of quality. T= hen I=20 select a quality level. IMHO, use of resources associated with QoS could be dynamic enough to= make=20 this model impractical. For example, it is not guaranteed that during= the=20 time between the network issued the price info and hit the button to = select=20 a service level, overall resource allocation in the network stays the= same. My understanding of Tina's message was that she is asking to convey s= ome=20 information about static pricing. > > The negotiation of SLA on the fly might be a bit complex if that is > what you are concerned, which I can see. > > -----Original Message----- > From: Asveren, Tolga [mailto:tasveren@sonusnet.com] > Sent: Thursday, August 02, 2007 4:34 PM > To: Sun, Dong (Dong); McCann Peter-A001034; Tina TSOU; dime@ietf.or= g > Subject: RE: [Dime] One scenario related to QoS Appl. > > That organizations can dynamically negotiate the price for QoS is > interesting but a bit too complex as a first step IMHO. I think, it= is > better to address it in an extension document. > > Thanks, > Tolga > > > -----Original Message----- > > From: Sun, Dong (Dong) [mailto:dongsun@alcatel-lucent.com] > > Sent: Thursday, August 02, 2007 12:57 PM > > To: McCann Peter-A001034; Asveren, Tolga; Tina TSOU; dime@ietf.or= g > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > The retail scenario in my mind is: > > When UE is roaming in visited network and requests a service, the > > home network will determine the price/QoS based on subscription a= nd > > resource availability (if multiple price/QoS options are allowed)= , > > and the agreement with that visited network, it is also possible > > that home network and visited network talk to each other on the f= ly > > to identify the right price/QoS based on real resource status whe= n > > the request occurs (either push or pull mode can be used for the > > interaction depending on the network/UE capability). > > > > Dong > > > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Thursday, August 02, 2007 12:43 PM > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > Sun, Dong (Dong) wrote: > > > I also think the QoS application should be able to support this > > > new model, may be named as retail scenario. > > > > Can you give a more detailed description of the scenario you have= in > mind? > > Is it the same as Tina's? > > > > > It seems to me there might be more common in practice to have o= ne > > > local PDF (authorizing entity) residing in the visited network > > > domain to talk to the authorizing entity in the home network > > > rather than asking each NE for this kind of negotiation/decisio= n. > > > > Sure, I think we should allow a PDF to add the price information = to > > a QAR that is on its way toward the home network. > > > > -Pete > > > > > Dong > > > > > > -----Original Message----- > > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > > Sent: Thursday, August 02, 2007 12:19 PM > > > To: Sun, Dong (Dong); Asveren, Tolga; Tina TSOU; dime@ietf.org > > > Subject: RE: [Dime] One scenario related to QoS Appl. > > > > > > Hi, Dong, > > > > > > I don't quite understand the new model you are proposing - I th= ink > > > you are saying that individual Network Elements might have a > > > negotiated price with the home network. I think that's fine an= d > > > can be accommodated; the QAR message should contain the price t= hat > > > the NE is going to charge for its service. The NE might take i= nto > > > account contracts that may exist with the home network, since w= e > > > assume that the NE knows the Destination Realm. > > > > > > -Pete > > > > > > Sun, Dong (Dong) wrote: > > >> Hi Pete, > > >> I agree the wholesale model should be supported for sure, but = it > > >> might be possible to have another model, in the roaming scenar= io, > > >> the visited network, based on the agreement (or negotiate) wit= h > > >> home network on Price/QoS for a particular service, may perfor= m > > >> QoS handling on individual session/request basis. Maybe I > > >> misunderstood the wholesale price/model you refer to. > > >> > > >> Regards, > > >> Dong > > >> > > >> -----Original Message----- > > >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > >> Sent: Thursday, August 02, 2007 11:17 AM > > >> To: Asveren, Tolga; Tina TSOU; dime@ietf.org > > >> Subject: RE: [Dime] One scenario related to QoS Appl. > > >> > > >> I agree with Tolga. The user must consult with his home provi= der > > >> for the per-minute charges. The price paid by the home provid= er > > >> for all the NEs along the path will be the wholesale price, an= d > > >> the home provider likely has a contract with the end user for = a > > >> different price. The Diameter QoS application only deals with > > >> the wholesale price. > > >> > > >> -Pete > > >> > > >> Asveren, Tolga wrote: > > >>> Hi Tina, > > >>> > > >>> IMHO, this could be classified as a different "service". For > > >>> example right now people check a website or a paper document = (or > > >>> sometimes they listen to an announcement) where prices are > > >>> listed (maybe not for different QoS levels but for different > > >>> destinations, but conceptually it is similar). > > >>> > > >>> Thanks, > > >>> Tolga > > >>> > > >>> ________________________________________ > > >>> From: Tina TSOU [mailto:tena@huawei.com] > > >>> Sent: Wednesday, August 01, 2007 11:16 PM > > >>> To: dime@ietf.org > > >>> Subject: [Dime] One scenario related to QoS Appl. > > >>> > > >>> Hi all, > > >>> One scenario to be discussed is as below. > > >>> > > >>> One user is going to make a call with his friend. He estimate= s > > >>> it will take about 20 minutes to complete the call. Prices fo= r > > >>> calls at different QoS levels are different, good quality cal= ls > > >>> will cost more than low quality ones do. So he gotta know the > > >>> QoS level at which his account balance can provide 20 minutes > > >>> quotas or more for him. > > >>> > > >>> Is it supported by the current QoS Appl.? > > >>> B. R. > > >>> Tina > > >>> +86-755-28972912 (Office) +86-13922884380 (Mobile) > > >>> Messengers: > > >>> MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU > > >>> Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > > > > > > _______________________________________________ > > > 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 Aug 03 15:10:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH2XB-0001iD-Ho; Fri, 03 Aug 2007 15:10:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH2X9-0001hf-Rc; Fri, 03 Aug 2007 15:09:59 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH2X9-0004n8-2w; Fri, 03 Aug 2007 15:09:59 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JM7003QRP7MSM@szxga01-in.huawei.com>; Sat, 04 Aug 2007 03:09:22 +0800 (CST) Received: from ny3104051930 ([10.124.12.88]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JM700FB5P7H7D@szxga01-in.huawei.com>; Sat, 04 Aug 2007 03:09:22 +0800 (CST) Date: Fri, 03 Aug 2007 14:11:32 -0500 From: Frank Xia To: dime@ietf.org, netlmm@ietf.org Message-id: <005401c7d602$1bfa0fc0$580c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.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: , Content-Type: multipart/mixed; boundary="===============0539695088==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0539695088== Content-type: multipart/alternative; boundary="Boundary_(ID_MpWix+SmhqGBLh9b5v8Ttw)" This is a multi-part message in MIME format. --Boundary_(ID_MpWix+SmhqGBLh9b5v8Ttw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi all I have some comments in the DIME WG when the draft is presented in Chicago. I would like to summarize my comments here. The main idea of the draft is based on that " The access authentication procedure into the Proxy Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario bootstrapping" I would like to highlight some differences and their influence on AAA interface. 1)The security association is between MAG and LMA, not MN and LMA 2)PMIPv6 now only deals with the P-t-P link model, in which case it is very probable that the LMA has no any idea about the MN's IP addess 3)In the PMIPv6 ,there is another important function, that is, the all MAGs should run consistently to emulate the MN's home link characteritics The following is the detailed comments: 1)Adding information exchange between LMA and AAA server to convey key material when LMA<->MAG SA is established using EAP authentication. 2)Clarifying the meaning FQDN, and enabling dynamical LMA discovery 3)DNS update. It is possible for MAG to initate DNS update 4)the usage of PMIP6-MAG-Address. 5)Adding address configuration mode attribute to emulate the link. BR Frank --Boundary_(ID_MpWix+SmhqGBLh9b5v8Ttw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi all
 
I have some comments in the DIME WG when the draft is presented in Chicago.
I would like to summarize my comments here.
 
The main idea of the draft is based on that "
The access authentication procedure into the Proxy
Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario
bootstrapping"
 
I would like to highlight some differences and their influence on AAA interface.
1)The security association is between MAG and LMA, not MN and LMA
2)PMIPv6 now only deals with the P-t-P link model, in which case
  it is very probable that the LMA has no any idea about the MN's IP addess
3)In the PMIPv6 ,there is another important function, that is,
  the all MAGs should run consistently to emulate the MN's home link characteritics
 
The following is the detailed comments:
1)Adding information exchange between LMA and AAA server to convey
  key material when LMA<->MAG SA is established using EAP authentication.
2)Clarifying the meaning FQDN, and enabling dynamical LMA discovery
3)DNS update. It is possible for MAG to initate DNS update
4)the usage of PMIP6-MAG-Address.
5)Adding address configuration mode attribute to emulate the link.
 
BR
Frank

--Boundary_(ID_MpWix+SmhqGBLh9b5v8Ttw)-- --===============0539695088== 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 --===============0539695088==-- From dime-bounces@ietf.org Sun Aug 05 19:39: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 1IHph3-0001LF-Au; Sun, 05 Aug 2007 19:39:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHph2-0001LA-7D for dime@ietf.org; Sun, 05 Aug 2007 19:39:28 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHph1-0006ZE-DF for dime@ietf.org; Sun, 05 Aug 2007 19:39:28 -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 l75NdQ28013312 for ; Sun, 5 Aug 2007 19:39: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 5 Aug 2007 19:39:26 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E702DF26@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QoS Application Review Thread-Index: AcfXudwqxDV2fHsnR1qRYHut1cL9Kg== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Dime] QoS Application Review 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 Please find below my comments after an initial review of QoS application = draft. I tried to list first the generic comments/questions and then the = ones which are corresponding to specific sections. Thanks, Tolga 1- As indicated during IETF69 Dime sessions as well, more explanation is = necessary for push mode operation; particularly state machines and = explanation of the procedures at each step of the operation. IMHO, push = and pull modes seem different enough to justify two different = applications. 2- An explanation of how failure scenarios need to be handled could be = useful. 3- I feel like Credit Control Application (CCA) is what we need for pull = mode. Functionality currently defined in the document is quite similar = to it. Is the reason, why CCA is not used, addition of new AVPs with = M-bit set to CCA commands? I guess, even in this case, one approach is = referencing CCA and just defining new commands (with new command codes = and the new AVPs) and linking them to CCA commands in terms of semantics = (with semantics of the new AVPs explained in QoS document). If not all = flexibility provided by CCA is necessary, this could be indicated as = well. I will start a new thread about this (what to do if one wants to = reuse an existing application -because the semantics provided by that = application are a good match- but wants to add a few new AVPs with M-bit = set) regarding its impact on Application Design Guideline work. 4- I think for push mode, the direction in the draft is the right one, = i.e. using new messages to install QoS reservation. 5- I guess we should cover how emergency sessions are to be handled. I = didn't check whether there is an already suitable AVP for this but some = AVP identifying the priority of the QoS request could be useful (and = semantics about its use should be defined as well) 6- Especially for push mode, there should be a way for NE to signal loss = of an existing reservation. This mechanism should allow signaling of = loss of a single flow in a session with multiple flows. 7- Some section about different use cases could be a good idea, e.g = interaction between different organizations in different scenarios, NAT = traversal issues etc.. It could be an idea to have this as a separate = document. 8-=20 1. Introduction "However, when bandwidth is scarce and must be carefully managed, such as in cellular networks, or when applications and transport protocols lack the capability to perform end-to-end congestion control, explicit reservation techniques are required." Why is end-to-end mechanisms not suitable for the first case ("when = bandwidth resources are scarce")? 9- 2. Terminology "Application Server An application server is a network entity that exchanges signaling messages with an application endpoint. It may be a source of authorization for QoS-enhanced application flows. For example, a SIP server is one kind of application server." I don't think SIP server is the right terminology for that type of = functionality. SIP Application Server or SIP proxy seems to be a better = example. 10-=20 2. Terminology "Application Endpoint An application endpoint is an entity in an end user device that exchanges signaling messages with application servers or directly with other application endpoints. Based on the result of this signaling, the endpoint may make a request for QoS from the network. For example, a SIP User Agent is one kind of application endpoint." Is it mandatory for Application Endpoint to initiate application = signaling before asking for QoS in an end-to-end fashion? 11- 2. Terminology Network Element Could be an entity different than a QoS aware router as well, e.g. a = cable modem termination system. 12- 2. Terminology Network Element "For almost all scenarios this entity triggers the protocol interaction described in this document." This sentence ignores push model; "for almost all scenarios" is too = strong. 13- 2. Terminology "Push Mode In this mode, the QoS authorization process is invoked by the request from Application Server or local policies in the Authorizing Entity." What does "local policies" refer to? What is a real life example for = this? Does it refer to something like installing filters statically? 14- 3. Framework Should cover push model as well. 15- 3. Framework "If defined properly, the interface between the routers and AAA cloud would be identical in both cases." Does this refer to using the same interface for push and pull modes? If = so, I guess it is not true, we use different messages.=20 16- 3.2.2 When listing what mode is suitable for which type of network, discussing = the reasons rather than just listing the names could be better (or just = deleting that part completely). 17- 3.3.1 "With the 'Two party scheme' the QoS resource requesting entity is authenticated by the Network Element and the authorization decision is made either locally at the Network Element itself or offloaded to a trusted entity (most likely within the same administrative domain). In the former case no Diameter QoS protocol interaction is required." Why is QoS protocol interaction necessary for the latter case? I thought = this would be completely independent of QoS reservation itself. 18- Figure 4 I would think that an explicit "Authorization Token Request" is optional = and such a token could be included in application signaling based on = configuration/policy. It could be a good idea to clarify this in the = text or in the figure. 19- 3.3.2 The distinction between "endpoint initiated" and "network initiated" = seems a bit artificial to me. At the end, it is *something* signaled by = endpoint (or is the idea application server reserving QoS out of the = blue?), which triggers the QoS reservation. The level of explicitness of = QoS information in that signal doesn't really matter much from QoS = application perspective.=20 20- 4.1 Parties Involved "Note that the QoS resource requesting entity is only indirectly involved in the message exchange. This entity provides the trigger to initiate the Diameter QoS protocol interaction by transmitting QoS signaling messages." I guess this part is ignoring push mode. The trigger could be = application signaling from which corresponding QoS parameters can be = extracted. 21- 4.2 Diameter QoS Authorization Session Establishment "A Signaling-session-Id (if present) SHOULD be used together with the generated Acc-Multi- Session-Id AVP (see Section 7.3) for binding the authorization and the accounting session information in case of end host mobility (i.e., to correlate the Diameter sessions that are initiated for the same signaling session from different QoS NE)." I think we first need to define the semantics how mobility is going to = work in such a case. For example, if the new NE is controlled by another = organization, how would be the interaction with the initial NE? 22- IMHO, DIAMETER_SUCCESS instead of DIAMETER_LIMITED_SUCCESS could be = used. The expected message flow/behavior is already defined as parts of = the procedures. Upon receipt of DIAMETER_SUCCESS, the requesting entity = would know what it needs to do next. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 06 08:04: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 1II1K9-0001NZ-Nc; Mon, 06 Aug 2007 08:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II1K8-0001NT-P0 for dime@ietf.org; Mon, 06 Aug 2007 08:04:36 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II1K7-0004fw-1e for dime@ietf.org; Mon, 06 Aug 2007 08:04:36 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l76C4RHd082530 for ; Mon, 6 Aug 2007 14:04:27 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Update on Diameter Auditing Date: Mon, 6 Aug 2007 14:04:41 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAXncRVA= References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Mon, 06 Aug 2007 14:04:27 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3877/Mon Aug 6 12:18:31 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Replies below ([Ulf1:..]).=20 BR Ulf=20 -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: den 30 juli 2007 01:33 To: Ulf Bodin Cc: dime@ietf.org Subject: RE: [Dime] Update on Diameter Auditing=20 Ulf Bodin allegedly scribbled on Sunday, July 29, 2007 1:22 AM: > All, >=20 > As requested I'm giving a brief update on the Diameter Auditing work=20 > at the list (basically the update I gave verbally on Friday's WG > meeting): =20 >=20 >=20 > There are two individual drafts on the topic; the Diameter Auditing=20 > requirements draft, AR (draft-bodin-dime-auditing-reqs-02) and the=20 > State recovery draft, SR (draft-asveren-dime-state-recovery-01). AR=20 > gives high level requirements for Diameter auditing and contains=20 > previous work done by Pat Calhoun on defining commads and AVPs for=20 > auditing. This draft is largely indecipherable. Although there may be requirements in there, I can't find them and there seems to be no actual description of the problem it's trying to solve. My _guess_ is that for some unknown reason you are trying to use the network as a state repository so that it can recover state after a failure. Is that right? If so, why is this scheme better than, say, NVRAM? [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is to capture needs for auditing in a wider sense the usage that triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, which is an entity keeping track of resource reservations for IP-based networks. The states kept in such entity is mot necesserily present in any network device. At failover from active to standby NVRAM does not help. I.e. non-volatile local storage does not help when failing over between physically separted entities. draft-asveren-dime-state-recovery-01 explores the problem of state recovery further and may do a better job in actually defining requirements for state recovery/auditing.]=20 > SR provides an analyze of what protocol assisted mechanisms > can be helfull in performing state recovery. =20 >=20 > Some mails have been exchanged in June studying which commands and=20 > AVPs either defined in Calhouns original work or that exists in other=20 > Dimeter specificaitons that could be used or enhanced for protocol=20 > assisted state recovery (i.e. auditing). Maybe part of the problem is the (mis)use of the word auditing. Thinking that I was ignorant I made a rather extensive search of dictionaries and was unable to find a definition of the word "auditing" that remotely resembled "protocol assisted (sic) state recovery". [Ulf1: I can agree that the word auditing can be misleading. State recovery may indeed better indicate what this is all about.] > My intention is to proceed > that work and before the next IETF meeting collect what then have been > done on the mailing list into a draft presenting desired extensions to > Dimaeter for protocol assisted state recovery. Based on that work it'd > in my view make sence considering taking on Diameter > protocol assisted state recovery as a WG work item. =20 Why? [Ulf1: Earlier this year we debated this very valid question on the mailing list. My and some others oppinion are that mechanisms for state recovery (I'll use that term instead of auditing) should be defined by the IETF for usage by various Diameter applications e.g. such as those defined by ETSI TISPAN, ITU-T, 3GPP, etc. instead of relying on these SDOs defining separate mechanisms potentially for each individual application. By that we can avoid different mechanisms being used for basically the same thing, which I fear easily can result in less than optimal solutions.] =20 >=20 > BR Ulf >=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 Mon Aug 06 12:54: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 1II5qu-0002gq-8H; Mon, 06 Aug 2007 12:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5qt-0002gk-Eu for dime@ietf.org; Mon, 06 Aug 2007 12:54:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II5qs-0002YM-S2 for dime@ietf.org; Mon, 06 Aug 2007 12:54:43 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Aug 2007 09:54:42 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAbvtkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,225,1183359600"; d="scan'208"; a="195194013:sNHT39028410" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l76GsgSv011310; Mon, 6 Aug 2007 09:54:42 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l76GsfVp000344; Mon, 6 Aug 2007 16:54:42 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 09:54:41 -0700 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] Update on Diameter Auditing Date: Mon, 6 Aug 2007 09:53:58 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> In-Reply-To: <33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAXncRVAACqc/gA== References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com> From: "Glen Zorn \(gwz\)" To: "Ulf Bodin" X-OriginalArrivalTime: 06 Aug 2007 16:54:41.0645 (UTC) FILETIME=[7B9D89D0:01C7D84A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1203; t=1186419282; x=1187283282; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Update=20on=20Diameter=20Auditing=20 |Sender:=20; bh=uh/CBMs62nWpF51CJt1h293jV+QCRvTL29p4jyWe668=; b=tuW3Y4Ph3G+mFo6KhTN6ikKrRNauoMts6HtT6LkZd9RX51+rYPLM75p8HnS1Kwdo2q/Z4JsO oOIK6KdoTE1Yshf53oDjQnzg5krT+2akNl54DSbXq+wG78Iuw9T9q/C+; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Ulf Bodin allegedly scribbled on Monday, August 06, 2007 5:05 AM: ... >=20 > [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is > to capture needs for auditing in a wider sense the usage that > triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, Where can I get a copy of the document defining this entity? > which is an entity keeping track of resource reservations for > IP-based networks. The states kept in such entity is mot necessarily > present in any network device. At failover from active to standby > NVRAM does not help. I.e. non-volatile local storage does not help > when failing over between physically separted entities. > draft-asveren-dime-state-recovery-01 explores the problem of state > recovery further and may do a better job in actually defining > requirements for state recovery/auditing.] =20 I'd actually prefer to see a document saying why this is actually needed in a real network, rather than one that assumes its necessity as a starting point. BTW, it was the lack of that clear necessity that led to the demise of the original resource management work, IIRC. =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 07:17: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 1IIN3j-0007uI-8N; Tue, 07 Aug 2007 07:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIN3i-0007u9-GQ for dime@ietf.org; Tue, 07 Aug 2007 07:17:06 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIN3h-0004bM-K6 for dime@ietf.org; Tue, 07 Aug 2007 07:17:06 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l77BGwpS092828 for ; Tue, 7 Aug 2007 13:16:58 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 13:16:49 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAXncRVAACqc/gAAlidCw References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Tue, 07 Aug 2007 13:16:58 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3879/Tue Aug 7 02:27:49 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: den 6 augusti 2007 18:54 To: Ulf Bodin Cc: dime@ietf.org Subject: RE: [Dime] Update on Diameter Auditing=20 Ulf Bodin allegedly scribbled on Monday, August 06, 2007 5:05 AM: ... >=20 > [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is=20 > to capture needs for auditing in a wider sense the usage that=20 > triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, Where can I get a copy of the document defining this entity? [Ulf2: Unfortunately access to specifications published by ETSI and ITU requires membership or purchase of each particular publication. The documents can most likely be shared using a liason statement issued by ETSI and/or ITU in case we need those specifciations for reference (in particular for them working for an organization not being member of those SDOs). However, the MSF (Multi-Service Forum) has published a document giving an overview of this kind of entity that I believe could be sufficient (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] > which is an entity keeping track of resource reservations for IP-based > networks. The states kept in such entity is mot necessarily present in > any network device. At failover from active to standby NVRAM does not=20 > help. I.e. non-volatile local storage does not help when failing over=20 > between physically separted entities. > draft-asveren-dime-state-recovery-01 explores the problem of state=20 > recovery further and may do a better job in actually defining=20 > requirements for state recovery/auditing.] I'd actually prefer to see a document saying why this is actually needed in a real network, rather than one that assumes its necessity as a starting point. BTW, it was the lack of that clear necessity that led to the demise of the original resource management work, IIRC. [Ulf2: Yes, that's my understanding as well for why the work was demised a couple of years back. However, given the appearance of RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter in 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for state recovery is actually needed for products now being developed for usage in real networks.=20 And, in TISPAN, H.248 was back in 2005 actually considered as an alternative to Diameter to be used for one of the interfaces to RACS partly due to its auditing capabilities that also can be used for state recovery (H.248 is used in the published architecture, but for a different interface).]=20 =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 07:40: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 1IINQX-00054G-TX; Tue, 07 Aug 2007 07:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINQW-000531-Pt for dime@ietf.org; Tue, 07 Aug 2007 07:40:40 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IINQU-00059y-Bx for dime@ietf.org; Tue, 07 Aug 2007 07:40:40 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JME00JXQJ2FRP@szxga02-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:39:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JME00J28J2EKJ@szxga02-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:39:51 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JME000KEJ2E4O@szxml03-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:39:50 +0800 (CST) Date: Tue, 07 Aug 2007 19:39:50 +0800 From: Tina TSOU Subject: Re: [Dime] Update on Diameter Auditing To: dime@ietf.org, Ulf Bodin Message-id: <008401c7d8e7$aa378a00$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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, In ITU-T, it is free with your TIES account now. Cisco is the sector member of ITU-T, so Glen can apply a TIES account. Architecture: Y.2111 Resource and admission control functions in Next Generation Networks Procedure and Protocol: Q.3301.1 Resource control protocol - Protocol at the Rs interface (with simple audit inside, to check whether the session indicated by the Session-Id in the RAR message is active, not including the state recovery) Q.3302.1 Resource control protocol - Protocol at the Rp interface In ETSI, it is also free with your ETSI account. Cisco is the member of ETSI, so Glen can apply a ETSI account. Architecture: http://pda.etsi.org/pda/home.asp?wki_id=m5ClL_vIFdCECIEF7HHwR B. R. Tina ----- Original Message ----- From: "Ulf Bodin" To: Sent: Tuesday, August 07, 2007 7:16 PM Subject: RE: [Dime] Update on Diameter Auditing -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com] Sent: den 6 augusti 2007 18:54 To: Ulf Bodin Cc: dime@ietf.org Subject: RE: [Dime] Update on Diameter Auditing Ulf Bodin allegedly scribbled on Monday, August 06, 2007 5:05 AM: ... > > [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is > to capture needs for auditing in a wider sense the usage that > triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, Where can I get a copy of the document defining this entity? [Ulf2: Unfortunately access to specifications published by ETSI and ITU requires membership or purchase of each particular publication. The documents can most likely be shared using a liason statement issued by ETSI and/or ITU in case we need those specifciations for reference (in particular for them working for an organization not being member of those SDOs). However, the MSF (Multi-Service Forum) has published a document giving an overview of this kind of entity that I believe could be sufficient (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] > which is an entity keeping track of resource reservations for IP-based > networks. The states kept in such entity is mot necessarily present in > any network device. At failover from active to standby NVRAM does not > help. I.e. non-volatile local storage does not help when failing over > between physically separted entities. > draft-asveren-dime-state-recovery-01 explores the problem of state > recovery further and may do a better job in actually defining > requirements for state recovery/auditing.] I'd actually prefer to see a document saying why this is actually needed in a real network, rather than one that assumes its necessity as a starting point. BTW, it was the lack of that clear necessity that led to the demise of the original resource management work, IIRC. [Ulf2: Yes, that's my understanding as well for why the work was demised a couple of years back. However, given the appearance of RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter in 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for state recovery is actually needed for products now being developed for usage in real networks. And, in TISPAN, H.248 was back in 2005 actually considered as an alternative to Diameter to be used for one of the interfaces to RACS partly due to its auditing capabilities that also can be used for state recovery (H.248 is used in the published architecture, but for a different interface).] ... _______________________________________________ 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 Aug 07 07:44: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 1IINUf-0007JU-93; Tue, 07 Aug 2007 07:44:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINUd-0007JL-Ry for dime@ietf.org; Tue, 07 Aug 2007 07:44:55 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IINUc-000180-Ku for dime@ietf.org; Tue, 07 Aug 2007 07:44:55 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JME00BK7J9OA3@szxga01-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:44:13 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JME00L0VJ9NP7@szxga01-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:44:12 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JME002BRJ9N73@szxml04-in.huawei.com> for dime@ietf.org; Tue, 07 Aug 2007 19:44:11 +0800 (CST) Date: Tue, 07 Aug 2007 19:44:11 +0800 From: Tina TSOU Subject: Re: [Dime] Update on Diameter Auditing To: Ulf Bodin , dime@ietf.org Message-id: <008901c7d8e8$45cdb570$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 2.2 (++) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Just in case the link was missing, I provide the link explicitly again adding below. ----- Original Message ----- From: "Tina TSOU" To: ; "Ulf Bodin" Sent: Tuesday, August 07, 2007 7:39 PM Subject: Re: [Dime] Update on Diameter Auditing > Hi, > In ITU-T, it is free with your TIES account now. Cisco is the sector > member of ITU-T, so Glen can apply a TIES account. > Architecture: > Y.2111 > Resource and admission control functions in Next Generation Networks http://www.itu.int/rec/T-REC-Y.2111-200609-I/en > Procedure and Protocol: > Q.3301.1 > Resource control protocol - Protocol at the Rs interface (with > simple audit inside, to check whether the session indicated by the > Session-Id in the RAR message is active, not including the state recovery) http://www.itu.int/rec/T-REC-Q.3301.1/en http://www.itu.int/rec/T-REC-Q.3301.1-200703-P/en > > Q.3302.1 > Resource control protocol - Protocol at the Rp interface http://www.itu.int/rec/T-REC-Q.3302.1/en http://www.itu.int/rec/T-REC-Q.3302.1-200703-P/en > > > > In ETSI, it is also free with your ETSI account. Cisco is the member of > ETSI, so Glen can apply a ETSI account. > Architecture: > http://pda.etsi.org/pda/home.asp?wki_id=m5ClL_vIFdCECIEF7HHwR > > B. R. > Tina > > ----- Original Message ----- > From: "Ulf Bodin" > To: > Sent: Tuesday, August 07, 2007 7:16 PM > Subject: RE: [Dime] Update on Diameter Auditing > > > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: den 6 augusti 2007 18:54 > To: Ulf Bodin > Cc: dime@ietf.org > Subject: RE: [Dime] Update on Diameter Auditing > > Ulf Bodin allegedly scribbled on Monday, > August 06, 2007 5:05 AM: > > ... > >> >> [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is >> to capture needs for auditing in a wider sense the usage that >> triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, > > Where can I get a copy of the document defining this entity? > > [Ulf2: Unfortunately access to specifications published by ETSI and ITU > requires membership or purchase of each particular publication. The > documents can most likely be shared using a liason statement issued by > ETSI and/or ITU in case we need those specifciations for reference (in > particular for them working for an organization not being member of > those SDOs). However, the MSF (Multi-Service Forum) has published a > document giving an overview of this kind of entity that I believe could > be sufficient > (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] > >> which is an entity keeping track of resource reservations for IP-based > >> networks. The states kept in such entity is mot necessarily present in > >> any network device. At failover from active to standby NVRAM does not >> help. I.e. non-volatile local storage does not help when failing over >> between physically separted entities. >> draft-asveren-dime-state-recovery-01 explores the problem of state >> recovery further and may do a better job in actually defining >> requirements for state recovery/auditing.] > > I'd actually prefer to see a document saying why this is actually needed > in a real network, rather than one that assumes its necessity as a > starting point. BTW, it was the lack of that clear necessity that led > to the demise of the original resource management work, IIRC. > > [Ulf2: Yes, that's my understanding as well for why the work was demised > a couple of years back. However, given the appearance of RACS/RACF in > ETSI TISPAN/ITU-T and the widespread usage of Diameter in 3GPP/3GPP2/MSF > etc. I think this shows that that mechanisms for state recovery is > actually needed for products now being developed for usage in real > networks. > > And, in TISPAN, H.248 was back in 2005 actually considered as an > alternative to Diameter to be used for one of the interfaces to RACS > partly due to its auditing capabilities that also can be used for state > recovery (H.248 is used in the published architecture, but for a > different interface).] > > > > > > ... > > _______________________________________________ > 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 Aug 07 08:00: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 1IINjg-0007sH-8R; Tue, 07 Aug 2007 08:00:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IINjf-0007sB-C7 for dime@ietf.org; Tue, 07 Aug 2007 08:00:27 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IINje-0001Vz-9N for dime@ietf.org; Tue, 07 Aug 2007 08:00:27 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Aug 2007 08:00:25 -0400 X-IronPort-AV: i="4.19,229,1183348800"; d="scan'208"; a="45355898:sNHT9231150" 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 13:59:44 +0200 Message-ID: In-Reply-To: <008401c7d8e7$aa378a00$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfY5+MO4Tgj7riGQxOLIel6OEiECwAAlr1Q References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Tina TSOU" , , "Ulf Bodin" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 Actually one does not even need a TIES account. ITU-T is making its specifications available for free on experimental basis for now as I understand at http://www.itu.int/rec/T-REC/e.=20 Dan =20 =20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com]=20 > Sent: Tuesday, August 07, 2007 2:40 PM > To: dime@ietf.org; Ulf Bodin > Subject: Re: [Dime] Update on Diameter Auditing >=20 > Hi, > In ITU-T, it is free with your TIES account now. Cisco is the=20 > sector member of ITU-T, so Glen can apply a TIES account. > Architecture: > Y.2111 > Resource and admission control functions in Next=20 > Generation Networks >=20 > Procedure and Protocol: >=20 >=20 > Q.3301.1 > Resource control protocol - Protocol at the Rs interface=20 > (with simple=20 > audit inside, to check whether the session indicated by the=20 > Session-Id in the RAR message is active, not including the=20 > state recovery) >=20 > Q.3302.1 > Resource control protocol - Protocol at the Rp interface >=20 >=20 >=20 > In ETSI, it is also free with your ETSI account. Cisco is the=20 > member of ETSI, so Glen can apply a ETSI account. > Architecture: > http://pda.etsi.org/pda/home.asp?wki_id=3Dm5ClL_vIFdCECIEF7HHwR >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: "Ulf Bodin" > To: > Sent: Tuesday, August 07, 2007 7:16 PM > Subject: RE: [Dime] Update on Diameter Auditing >=20 >=20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: den 6 augusti 2007 18:54 > To: Ulf Bodin > Cc: dime@ietf.org > Subject: RE: [Dime] Update on Diameter Auditing >=20 > Ulf Bodin allegedly scribbled on Monday, > August 06, 2007 5:05 AM: >=20 > ... >=20 > > > > [Ulf1: Although the intention of=20 > draft-bodin-dime-auditing-reqs-02 is > > to capture needs for auditing in a wider sense the usage that > > triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, >=20 > Where can I get a copy of the document defining this entity? >=20 > [Ulf2: Unfortunately access to specifications published by=20 > ETSI and ITU > requires membership or purchase of each particular publication. The > documents can most likely be shared using a liason statement issued by > ETSI and/or ITU in case we need those specifciations for reference (in > particular for them working for an organization not being member of > those SDOs). However, the MSF (Multi-Service Forum) has published a > document giving an overview of this kind of entity that I=20 > believe could > be sufficient > (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] >=20 > > which is an entity keeping track of resource reservations=20 > for IP-based >=20 > > networks. The states kept in such entity is mot necessarily=20 > present in >=20 > > any network device. At failover from active to standby=20 > NVRAM does not > > help. I.e. non-volatile local storage does not help when=20 > failing over > > between physically separted entities. > > draft-asveren-dime-state-recovery-01 explores the problem of state > > recovery further and may do a better job in actually defining > > requirements for state recovery/auditing.] >=20 > I'd actually prefer to see a document saying why this is=20 > actually needed > in a real network, rather than one that assumes its necessity as a > starting point. BTW, it was the lack of that clear necessity that led > to the demise of the original resource management work, IIRC. >=20 > [Ulf2: Yes, that's my understanding as well for why the work=20 > was demised > a couple of years back. However, given the appearance of RACS/RACF in > ETSI TISPAN/ITU-T and the widespread usage of Diameter in=20 > 3GPP/3GPP2/MSF > etc. I think this shows that that mechanisms for state recovery is > actually needed for products now being developed for usage in real > networks. >=20 > And, in TISPAN, H.248 was back in 2005 actually considered as an > alternative to Diameter to be used for one of the interfaces to RACS > partly due to its auditing capabilities that also can be used=20 > for state > recovery (H.248 is used in the published architecture, but for a > different interface).] >=20 >=20 >=20 >=20 >=20 > ... >=20 > _______________________________________________ > 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 Tue Aug 07 08:29: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 1IIOBe-0000kV-Hw; Tue, 07 Aug 2007 08:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIOBd-0000kJ-1u for dime@ietf.org; Tue, 07 Aug 2007 08:29:21 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIOBb-0006ND-4d for dime@ietf.org; Tue, 07 Aug 2007 08:29:21 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l77CTBWn093404 for ; Tue, 7 Aug 2007 14:29:11 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 14:29:13 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401950C5F@lulex02.ad.operax.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfY5+MO4Tgj7riGQxOLIel6OEiECwAAlr1QAAEAruA= References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Tue, 07 Aug 2007 14:29:11 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3880/Tue Aug 7 12:49:57 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Great. Thank you Tina and Dan for pointing this out. IMO having open access is to the benefit of everyone including ETSI and ITU. To be honest I've never understood completely why restricting access (i.e. must be another way to have organizations pay to run an SDO).=20 Rgs Ulf =20 -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: den 7 augusti 2007 14:00 To: Tina TSOU; dime@ietf.org; Ulf Bodin Subject: RE: [Dime] Update on Diameter Auditing Actually one does not even need a TIES account. ITU-T is making its specifications available for free on experimental basis for now as I understand at http://www.itu.int/rec/T-REC/e.=20 Dan =20 =20 > -----Original Message----- > From: Tina TSOU [mailto:tena@huawei.com] > Sent: Tuesday, August 07, 2007 2:40 PM > To: dime@ietf.org; Ulf Bodin > Subject: Re: [Dime] Update on Diameter Auditing >=20 > Hi, > In ITU-T, it is free with your TIES account now. Cisco is the sector=20 > member of ITU-T, so Glen can apply a TIES account. > Architecture: > Y.2111 > Resource and admission control functions in Next Generation=20 > Networks >=20 > Procedure and Protocol: >=20 >=20 > Q.3301.1 > Resource control protocol - Protocol at the Rs interface=20 > (with simple > audit inside, to check whether the session indicated by the Session-Id > in the RAR message is active, not including the state recovery) >=20 > Q.3302.1 > Resource control protocol - Protocol at the Rp interface >=20 >=20 >=20 > In ETSI, it is also free with your ETSI account. Cisco is the member=20 > of ETSI, so Glen can apply a ETSI account. > Architecture: > http://pda.etsi.org/pda/home.asp?wki_id=3Dm5ClL_vIFdCECIEF7HHwR >=20 > B. R. > Tina >=20 > ----- Original Message ----- > From: "Ulf Bodin" > To: > Sent: Tuesday, August 07, 2007 7:16 PM > Subject: RE: [Dime] Update on Diameter Auditing >=20 >=20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: den 6 augusti 2007 18:54 > To: Ulf Bodin > Cc: dime@ietf.org > Subject: RE: [Dime] Update on Diameter Auditing >=20 > Ulf Bodin allegedly scribbled on Monday, > August 06, 2007 5:05 AM: >=20 > ... >=20 > > > > [Ulf1: Although the intention of > draft-bodin-dime-auditing-reqs-02 is > > to capture needs for auditing in a wider sense the usage that=20 > > triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, >=20 > Where can I get a copy of the document defining this entity? >=20 > [Ulf2: Unfortunately access to specifications published by ETSI and=20 > ITU requires membership or purchase of each particular publication.=20 > The documents can most likely be shared using a liason statement=20 > issued by ETSI and/or ITU in case we need those specifciations for=20 > reference (in particular for them working for an organization not=20 > being member of those SDOs). However, the MSF (Multi-Service Forum)=20 > has published a document giving an overview of this kind of entity=20 > that I believe could be sufficient=20 > (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] >=20 > > which is an entity keeping track of resource reservations > for IP-based >=20 > > networks. The states kept in such entity is mot necessarily > present in >=20 > > any network device. At failover from active to standby > NVRAM does not > > help. I.e. non-volatile local storage does not help when > failing over > > between physically separted entities. > > draft-asveren-dime-state-recovery-01 explores the problem of state=20 > > recovery further and may do a better job in actually defining=20 > > requirements for state recovery/auditing.] >=20 > I'd actually prefer to see a document saying why this is actually=20 > needed in a real network, rather than one that assumes its necessity=20 > as a starting point. BTW, it was the lack of that clear necessity=20 > that led to the demise of the original resource management work, IIRC. >=20 > [Ulf2: Yes, that's my understanding as well for why the work was=20 > demised a couple of years back. However, given the appearance of=20 > RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter in > 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for state=20 > recovery is actually needed for products now being developed for usage > in real networks. >=20 > And, in TISPAN, H.248 was back in 2005 actually considered as an=20 > alternative to Diameter to be used for one of the interfaces to RACS=20 > partly due to its auditing capabilities that also can be used for=20 > state recovery (H.248 is used in the published architecture, but for a > different interface).] >=20 >=20 >=20 >=20 >=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 Tue Aug 07 11:34: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 1IIR4a-0002oT-JO; Tue, 07 Aug 2007 11:34:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR4Z-0002nM-F8; Tue, 07 Aug 2007 11:34:15 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIR4Z-0004IG-3F; Tue, 07 Aug 2007 11:34:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l77FYCq14350; Tue, 7 Aug 2007 15:34:12 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 Date: Tue, 7 Aug 2007 10:34:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711601FED4@zrc2hxm2.corp.nortel.com> In-Reply-To: <46B04CEB.5010407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 1: Field Data supporting the use case per: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0A References: <46B04CEB.5010407@gmx.net> From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org Subject: [Dime] Issue 1: Field Data supporting the use case per: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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 DIME meeting at IETF-69, there was a question raised if there is any field data which support the case that it may takes the MN more than one second to receive the initial RRP message and the MN had to retransmit the initial RRQ. First of all, IMO, I would like to say that it is very possible and realistic to assume that under certain conditions the initial MIPv4 RRP message may take more than one second to arrive at the Mobile Node. As far as getting the field data, I will continue to try to find some real data on this. On the other hand, I really appreciate it if any of the handset, AAA vendors or any of the operators can share or comment on this field data record. =20 Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, August 01, 2007 4:06 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: MIPv4 Authentication Performance Using RADIUS and=20 > Diameter MIPv4 >=20 > Hi Ahmad, >=20 > you raised some interesting discussions during the DIME=20 > working group meeting. Unfortunately, there was not enough=20 > time to address all questions. >=20 > I would be great if you could > * summarize your presentation, and > * address some of the raised questions > on the mailing list. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 11:38: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 1IIR98-0007EG-7k; Tue, 07 Aug 2007 11:38:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR96-00070Q-FK; Tue, 07 Aug 2007 11:38:56 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIR96-0004SW-4G; Tue, 07 Aug 2007 11:38:56 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l77Fcrq15003; Tue, 7 Aug 2007 15:38:53 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 Date: Tue, 7 Aug 2007 10:38:52 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eA= From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Dime] Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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 =20 All, During DIME meeting at IETF-69, Pete raised the point that when RADIUS relay the re-transmitted RRQ without going to AAA, Pete thinks that there possibly a security concern. I would like to start this thread but I would like to let Pete summarize his concern and we then can discuss it. Hi Pete, Could you please summarize the security concern that you raised during DIME meeting? Many thanks in advance. =20 Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, August 01, 2007 4:06 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: MIPv4 Authentication Performance Using RADIUS and Diameter=20 > MIPv4 >=20 > Hi Ahmad, >=20 > you raised some interesting discussions during the DIME working group=20 > meeting. Unfortunately, there was not enough time to address all=20 > questions. >=20 > I would be great if you could > * summarize your presentation, and > * address some of the raised questions on the mailing list. >=20 > Ciao > Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 14:36: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 1IITup-0003Ub-EQ; Tue, 07 Aug 2007 14:36:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITun-0003Tf-6I for dime@ietf.org; Tue, 07 Aug 2007 14:36:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IITul-0006ar-NS for dime@ietf.org; Tue, 07 Aug 2007 14:36:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2007 11:36:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgnXAOZYuEarR7PD/2dsb2JhbACICgOjYgE X-IronPort-AV: i="4.19,230,1183359600"; d="scan'208"; a="511127634:sNHT2416611024" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l77Ia6Pm029072; Tue, 7 Aug 2007 11:36:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l77IZmFW017711; Tue, 7 Aug 2007 18:36:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 11:36:06 -0700 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 11:35:50 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6A9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAXncRVAACqc/gAAlidCwAA+0HJA= References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> From: "Glen Zorn \(gwz\)" To: "Ulf Bodin" X-OriginalArrivalTime: 07 Aug 2007 18:36:06.0121 (UTC) FILETIME=[D0A8A590:01C7D921] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2040; t=1186511766; x=1187375766; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Update=20on=20Diameter=20Auditing=20 |Sender:=20; bh=FEnx93X7uoU8JRRJVgoTUCE6d3m4I3wTI7gQsz4wb4I=; b=kS2Y8xGnIqpSy1g9gEMVzsR0IpjoSL43vLHASHgLRBpeH9ubT1+x3J7Y3sOxAAN5pF6S7sjq d+rxruZJCreuMPLhHFVElKxjnB0XInhEM9no7y282DfbyOcWj0feawmI; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Ulf Bodin allegedly scribbled on Tuesday, August 07, 2007 4:17 AM: ... >>=20 >> [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is >> to capture needs for auditing in a wider sense the usage that >> triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, >=20 > Where can I get a copy of the document defining this entity? >=20 > [Ulf2: Unfortunately access to specifications published by ETSI and > ITU requires membership or purchase of each particular publication. > The documents can most likely be shared using a liason statement > issued by ETSI and/or ITU in case we need those specifciations for > reference (in particular for them working for an organization not > being member of those SDOs). However, the MSF (Multi-Service Forum) > has published a document giving an overview of this kind of entity > that I believe could be sufficient > (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] >=20 ... >=20 > I'd actually prefer to see a document saying why this is actually > needed in a real network, rather than one that assumes its necessity > as a starting point. BTW, it was the lack of that clear necessity > that led to the demise of the original resource management work, > IIRC. =20 >=20 > [Ulf2: Yes, that's my understanding as well for why the work was > demised a couple of years back. However, given the appearance of > RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter > in 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for > state recovery is actually needed for products now being developed > for usage in real networks. =20 Except that a) it seems not possible for us to evaluate the basis of this work (let alone the work itself) and b) I, at least, hold a somewhat less sanguine opinion of standards bodies: just because some (professional or amateur) standards folks have invented something doesn't mean that it's necessary or even useful. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 14:36: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 1IITup-0003Uf-KM; Tue, 07 Aug 2007 14:36:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITun-0003Tk-Oz for dime@ietf.org; Tue, 07 Aug 2007 14:36:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IITun-0003T7-C7 for dime@ietf.org; Tue, 07 Aug 2007 14:36:21 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2007 11:36:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgnXAOZYuEarR7PD/2dsb2JhbACICgOjYgE X-IronPort-AV: i="4.19,230,1183359600"; d="scan'208"; a="511127636:sNHT3413583444" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l77Ia6k1029078; Tue, 7 Aug 2007 11:36:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l77IZmFY017711; Tue, 7 Aug 2007 18:36:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 11:36:06 -0700 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 11:35:51 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6AA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <008401c7d8e7$aa378a00$864c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfY59PgFwq74pNDTN2lwhvGaiT6DQAN7dsw References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> From: "Glen Zorn \(gwz\)" To: "Tina TSOU" X-OriginalArrivalTime: 07 Aug 2007 18:36:06.0230 (UTC) FILETIME=[D0B94760:01C7D921] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1243; t=1186511766; x=1187375766; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Update=20on=20Diameter=20Auditing |Sender:=20; bh=KkegQPWsw5AG/RMycDmTAFppiuybi9yyKQSOa9CJejM=; b=OFU5LsBZjDnPXgkNdhSSzfyYPV8+eeG3ejpk+IzOR4jEdQbgP7HqVbo8eMIDgkO7Zc+PTt76 AysBC+gy3u5farTw4sSpGv4BhtFJl0qOi3SdvUTgi7JNPnOjWcTAeWJ7; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Ulf Bodin , 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 Tina TSOU allegedly scribbled on Tuesday, August 07, 2007 4:40 AM: > Hi, > In ITU-T, it is free with your TIES account now. Cisco is the sector > member of ITU-T, so Glen can apply a TIES account.=20 > Architecture: > Y.2111 > Resource and admission control functions in Next Generation > Networks=20 >=20 > Procedure and Protocol: >=20 >=20 > Q.3301.1 > Resource control protocol - Protocol at the Rs interface (with > simple=20 > audit inside, to check whether the session indicated by the > Session-Id in the RAR message is active, not including the state > recovery) =20 >=20 > Q.3302.1 > Resource control protocol - Protocol at the Rp interface >=20 >=20 >=20 > In ETSI, it is also free with your ETSI account. Cisco is the member > of ETSI, so Glen can apply a ETSI account.=20 > Architecture: > http://pda.etsi.org/pda/home.asp?wki_id=3Dm5ClL_vIFdCECIEF7HHwR >=20 Thanks for the data, Tina, but the issue isn't really whether I or other Cisco employees are able to access the documents but whether the IETF Community at large has such access. We can't be expected to standardize something based upon documents we can't see. ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 15: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 1IIUZY-0006rm-1O; Tue, 07 Aug 2007 15:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUZW-0006rg-RZ for dime@ietf.org; Tue, 07 Aug 2007 15:18: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 1IIUZV-0007hQ-MI for dime@ietf.org; Tue, 07 Aug 2007 15:18: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 l77JHuGi079483; Tue, 7 Aug 2007 15:17:56 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46B8C55E.8010507@tari.toshiba.com> Date: Tue, 07 Aug 2007 15:17:50 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org Subject: [Dime] Re-Visiting Vendor-Specific Commands 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 had proposed a text for rfc3588bis with regards to the rules on Vendor-Specific command code allocation. The result would look like: 11.2.1. Command Codes The Command Code namespace is used to identify Diameter commands. The values 0-255 (0x00-0xff) are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for permanent, standard commands, allocated by Expert Review [RFC2434]. This document defines the Command Codes 257, 258, 271, 274-275, 280 and 282. See Section 3.1 for the assignment of the namespace in this specification. The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific command codes, to be allocated on a First Come, First Served basis by IANA [RFC2434]. The request to IANA for a Vendor-Specific Command Code SHOULD include a reference to a publicly available specification which documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific command code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command. The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [IANA-EXP]. I would like to poll the WG to see if there are still concerns about this proposal or if there are any other comments. It would be great if we can get some conclusion regarding this topic. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 15:29:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUjt-0005CD-1b; Tue, 07 Aug 2007 15:29:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIUjr-0005C3-EQ for dime@ietf.org; Tue, 07 Aug 2007 15:29:07 -0400 Received: from smtp104.rog.mail.re2.yahoo.com ([206.190.36.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIUjq-00088C-8p for dime@ietf.org; Tue, 07 Aug 2007 15:29:07 -0400 Received: (qmail 52446 invoked from network); 7 Aug 2007 19:29:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bx6fSjVehqEFUr7KDvKwPfYuOyIJYUed09OsIIf6WvpCbt8JHTXB2D190xj7VUlij4iGBGazmXlOF46+TKE5u7Bn+Gzc+AqruNQ7yAebWmWpKGLqPa3moO9lINF7THWyLDdV7jBJMLa74O4pTNoiu2mKEkvpmCBcXBN7ESL7gWw= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 7 Aug 2007 19:29:06 -0000 X-YMail-OSG: AxQjgc8VM1lzS2bWsg8PP1.alKTVgtZRtRNrZhyBbge9Qg_VLDgT29OizC7EBcAACA-- Message-ID: <46B8C82F.1020401@rogers.com> Date: Tue, 07 Aug 2007 15:29:51 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Glen Zorn (gwz)" Subject: Re: [Dime] Update on Diameter Auditing References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6AA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6AA@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Ulf Bodin , 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 OK, let's say this one more time. ITU-T documents are available for free to everyone, not just Cisco, at http://www.itu.int/ITU-T/publications/recs.html. ETSI published specifications are available for free to everyone, not just Cisco, at http://pda.etsi.org/pda/queryform.asp. ETSI work in progress is available free to everyone, not just Cisco, at http://portal.etsi.org/docbox/TISPAN/Open/NGN_LATEST_DRAFTS/ I can dig out the relevant ETSI publication numbers, but people who are working with this stuff regularly may have them readily to hand. Glen Zorn (gwz) wrote: > Tina TSOU allegedly scribbled on Tuesday, > August 07, 2007 4:40 AM: > >> Hi, >> In ITU-T, it is free with your TIES account now. Cisco is the sector >> member of ITU-T, so Glen can apply a TIES account. >> Architecture: >> Y.2111 >> Resource and admission control functions in Next Generation >> Networks >> >> Procedure and Protocol: >> >> >> Q.3301.1 >> Resource control protocol - Protocol at the Rs interface (with >> simple >> audit inside, to check whether the session indicated by the >> Session-Id in the RAR message is active, not including the state >> recovery) >> >> Q.3302.1 >> Resource control protocol - Protocol at the Rp interface >> >> >> >> In ETSI, it is also free with your ETSI account. Cisco is the member >> of ETSI, so Glen can apply a ETSI account. >> Architecture: >> http://pda.etsi.org/pda/home.asp?wki_id=m5ClL_vIFdCECIEF7HHwR >> > > Thanks for the data, Tina, but the issue isn't really whether I or other > Cisco employees are able to access the documents but whether the IETF > Community at large has such access. We can't be expected to standardize > something based upon documents we can't see. > > ... > > _______________________________________________ > 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 Aug 07 16:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVrF-0005cJ-IC; Tue, 07 Aug 2007 16:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVrD-0005cE-Qb for dime@ietf.org; Tue, 07 Aug 2007 16:40:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIVrC-0002Zg-Hx for dime@ietf.org; Tue, 07 Aug 2007 16:40:47 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2007 13:40:45 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAd1uEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.19,231,1183359600"; d="scan'208"; a="12493328:sNHT14482842" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l77Keja2019174; Tue, 7 Aug 2007 13:40:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l77KeaW1029115; Tue, 7 Aug 2007 20:40:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 13:40:41 -0700 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] Update on Diameter Auditing Date: Tue, 7 Aug 2007 13:40:00 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B77C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <46B8C82F.1020401@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfZKTi5ll/Om0MTQtqpUMRh7hf/NQACRfHg References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6AA@xmb-sjc-215.amer.cisco.com> <46B8C82F.1020401@rogers.com> From: "Glen Zorn \(gwz\)" To: "Tom Taylor" X-OriginalArrivalTime: 07 Aug 2007 20:40:41.0555 (UTC) FILETIME=[385D5A30:01C7D933] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=987; t=1186519245; x=1187383245; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:=20RE=3A=20[Dime]=20Update=20on=20Diameter=20Auditing |Sender:=20; bh=90mE/+p8U21k+QanRvPm9OwC8Etw/fg1m1Be1uP1Qi4=; b=o3+EEoqeKN1kWXtSymj5Al/JnRcF4780BCv44d2WaI7aLn81O6xJuRkeEkD572rIBlwsD/x+ Ga3VdPVIetekUJtS/Gs/AwTJMSdvXjWpXaFGx3iQsREAXLLYW0w8RYvA; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Ulf Bodin , 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 Tom Taylor allegedly scribbled on Tuesday, August 07, 2007 12:30 PM: > OK, let's say this one more time. ITU-T documents are available for > free to everyone, not just Cisco, at > http://www.itu.int/ITU-T/publications/recs.html. =20 >=20 > ETSI published specifications are available for free to everyone, not > just Cisco, at http://pda.etsi.org/pda/queryform.asp. ETSI work in > progress is available free to everyone, not just Cisco, at > http://portal.etsi.org/docbox/TISPAN/Open/NGN_LATEST_DRAFTS/ =20 OK, let's say _this_ one more time: this is neither ETSI nor ITU-T. I don't think that a simple I-D cogently describing the problem to be solved is too much to ask; if it is, then maybe there _is_ no problem. Not that I'm opposed to full employment for protocol designers but it seems to me that the above referenced organizations (among many others) provide ample opportunity: we don't need to help them out here. =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 16:45: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 1IIVwD-0008JF-I7; Tue, 07 Aug 2007 16:45:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVwB-0008IT-Q0; Tue, 07 Aug 2007 16:45:55 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIVwB-0008Kr-9J; Tue, 07 Aug 2007 16:45:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1186519553!3901118!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25976 invoked from network); 7 Aug 2007 20:45:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 7 Aug 2007 20:45:53 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l77Kjpri026363; Tue, 7 Aug 2007 13:45:53 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l77Kjovc020691; Tue, 7 Aug 2007 15:45:51 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l77KjneP020672; Tue, 7 Aug 2007 15:45:50 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2007 16:45:48 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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, Ahmad, Maybe this is not so big an issue, but one thing that might happen is that the MN can use a different HA address in the re-transmitted RRQ. If there is network policy in place that only allows registering on specific HAs, this policy might be skirted by the retransmission unless the HA address is sent to the RADIUS/Diameter server with every RRQ. I am also concerned about increasing the overall registration time by going from one round-trip to two round-trips. The nice thing about the existing Diameter application is that it can do both authentication/authorization and MIP registration in one round-trip to the home network. One question: why couldn't we fix the problem by adjusting the retransmission timers upwards? If we know that AAA adds some additional delay, we could wait a bit longer before retransmitting the request. This seems to fix the problem.=20 -Pete Ahmad Muhanna wrote: > All, > During DIME meeting at IETF-69, Pete raised the point that when > RADIUS relay the re-transmitted RRQ without going to AAA, Pete thinks > that there possibly a security concern. =20 >=20 > I would like to start this thread but I would like to let Pete > summarize his concern and we then can discuss it.=20 >=20 > Hi Pete, >=20 > Could you please summarize the security concern that you raised > during DIME meeting?=20 > Many thanks in advance. >=20 > Regards, > Ahmad >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, August 01, 2007 4:06 AM >> To: dime@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: MIPv4 Authentication Performance Using RADIUS and Diameter >> MIPv4=20 >>=20 >> Hi Ahmad, >>=20 >> you raised some interesting discussions during the DIME working group >> meeting. Unfortunately, there was not enough time to address all >> questions.=20 >>=20 >> I would be great if you could >> * summarize your presentation, and >> * address some of the raised questions on the mailing list. >>=20 >> Ciao >> Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 07 18:02: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 1IIX80-00028y-Fz; Tue, 07 Aug 2007 18:02:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX7z-00028Y-45; Tue, 07 Aug 2007 18:02:11 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIX7y-0001jX-Ia; Tue, 07 Aug 2007 18:02:11 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l77M0Dd29510; Tue, 7 Aug 2007 22:00:13 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 Date: Tue, 7 Aug 2007 17:02:04 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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 Pete, Please see response inline. Regards, Ahmad =20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 > Sent: Tuesday, August 07, 2007 3:46 PM > To: Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > Cc: mip4@ietf.org; Hannes Tschofenig > Subject: RE: Issue 2: Security Concern in RADIUS Mode: MIPv4=20 > Auth Performance Using RADIUS and Diameter MIPv4 Application draft >=20 > Hi, Ahmad, >=20 > Maybe this is not so big an issue, but one thing that might=20 > happen is that the MN can use a different HA address in the=20 > re-transmitted RRQ. If there is network policy in place that=20 > only allows registering on specific HAs, this policy might be=20 > skirted by the retransmission unless the HA address is sent=20 > to the RADIUS/Diameter server with every RRQ. [Ahmad] We can look at this special case later, but for the sake of this simple analysis, we need to address the most common simple scenario first. With the following in mind: "What would the impact be when using Diameter MIPv4 Application in place of RADIUS model." Also, usually the MN does not try to register with another HA until the registration process is timeout. In our case, we are focusing on the first retransmitted RRQ which usually done after one second. >=20 > I am also concerned about increasing the overall registration=20 > time by going from one round-trip to two round-trips. The=20 > nice thing about the existing Diameter application is that it=20 > can do both authentication/authorization and MIP registration=20 > in one round-trip to the home network. [Ahmad] I am sorry I missed this point here. Could you please elaborate a little further. >=20 > One question: why couldn't we fix the problem by adjusting=20 > the retransmission timers upwards? If we know that AAA adds=20 > some additional delay, we could wait a bit longer before=20 > retransmitting the request. This seems to fix the problem.=20 [Ahmad] I agree with you here. It is anticipated that Diameter MIPv4 Application will take a longer time to complete MIPv4 initial registration. Two questions:=20 1. Why the MN and possibly the network configurations need to change just for using Diameter MIPv4 Application in place of RADIUS. 2. On the other hand, even if we increase the initial timer a little, we still do not solve the issue, all what we do is delaying it.=20 >=20 > -Pete >=20 > Ahmad Muhanna wrote: > > All, > > During DIME meeting at IETF-69, Pete raised the point that=20 > when RADIUS=20 > > relay the re-transmitted RRQ without going to AAA, Pete thinks that=20 > > there possibly a security concern. > >=20 > > I would like to start this thread but I would like to let Pete=20 > > summarize his concern and we then can discuss it. > >=20 > > Hi Pete, > >=20 > > Could you please summarize the security concern that you=20 > raised during=20 > > DIME meeting? > > Many thanks in advance. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Wednesday, August 01, 2007 4:06 AM > >> To: dime@ietf.org > >> Cc: Muhanna, Ahmad (RICH1:2H10) > >> Subject: MIPv4 Authentication Performance Using RADIUS and Diameter > >> MIPv4 > >>=20 > >> Hi Ahmad, > >>=20 > >> you raised some interesting discussions during the DIME=20 > working group=20 > >> meeting. Unfortunately, there was not enough time to address all=20 > >> questions. > >>=20 > >> I would be great if you could > >> * summarize your presentation, and > >> * address some of the raised questions on the mailing list. > >>=20 > >> Ciao > >> Hannes >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 02:10: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 1IIekE-00020K-7t; Wed, 08 Aug 2007 02:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIekB-0001v2-BC for dime@ietf.org; Wed, 08 Aug 2007 02:10:07 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIek9-0006aQ-OX for dime@ietf.org; Wed, 08 Aug 2007 02:10:07 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l7869vBM002246 for ; Wed, 8 Aug 2007 08:09:57 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Update on Diameter Auditing Date: Wed, 8 Aug 2007 08:09:56 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401950CC8@lulex02.ad.operax.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6A9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfRuXdbrFxxz74fTsuROEtjOuBXwAAfd8hAAXncRVAACqc/gAAlidCwAA+0HJAAGIesMA== References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com> <33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6A9@xmb-sjc-215.amer.cisco.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 08 Aug 2007 08:09:58 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3891/Wed Aug 8 02:11:58 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: den 7 augusti 2007 20:36 To: Ulf Bodin Cc: dime@ietf.org Subject: RE: [Dime] Update on Diameter Auditing=20 Ulf Bodin allegedly scribbled on Tuesday, August 07, 2007 4:17 AM: ... >>=20 >> [Ulf1: Although the intention of draft-bodin-dime-auditing-reqs-02 is >> to capture needs for auditing in a wider sense the usage that=20 >> triggered us writing the draft is the ETSI TISPAN RACS/ITU-T RACF, >=20 > Where can I get a copy of the document defining this entity? >=20 > [Ulf2: Unfortunately access to specifications published by ETSI and=20 > ITU requires membership or purchase of each particular publication. > The documents can most likely be shared using a liason statement=20 > issued by ETSI and/or ITU in case we need those specifciations for=20 > reference (in particular for them working for an organization not=20 > being member of those SDOs). However, the MSF (Multi-Service Forum)=20 > has published a document giving an overview of this kind of entity=20 > that I believe could be sufficient=20 > (http://www.msforum.org/techinfo/reports/MSF-TR-ARCH-005-FINAL.pdf).] >=20 ... >=20 > I'd actually prefer to see a document saying why this is actually=20 > needed in a real network, rather than one that assumes its necessity=20 > as a starting point. BTW, it was the lack of that clear necessity=20 > that led to the demise of the original resource management work, > IIRC. =20 >=20 > [Ulf2: Yes, that's my understanding as well for why the work was=20 > demised a couple of years back. However, given the appearance of=20 > RACS/RACF in ETSI TISPAN/ITU-T and the widespread usage of Diameter in > 3GPP/3GPP2/MSF etc. I think this shows that that mechanisms for state=20 > recovery is actually needed for products now being developed > for usage in real networks. =20 Except that a) it seems not possible for us to evaluate the basis of this work (let alone the work itself) and b) I, at least, hold a somewhat less sanguine opinion of standards bodies: just because some (professional or amateur) standards folks have invented something doesn't mean that it's necessary or even useful. [Ulf3: Skipping a) to reply to it in a separate mail I must say b) makes me somewhat confused. I can agree to that standards not always become widely used in reality depending on market needs, kind of solution preferred by ccustomer etc. However, IMHO standards should at least be seen as potetially useful and part of the game in evolving businesses including vendors and operators/network providers/ISPs/etc. Waiting for things to be used in real networks before starting standardizing may in my view be beneficial to larger vendors having the power to get new solutions and protocol mechanisms in operation with customers, while smaller vendors and operators better rely on standards (in progress and published). Maybe I'm missing the point here (e.g. that the IETF only aims at standardizing things alrady in use and thereby proved useful).]=20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 04:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIgg9-0008NA-HC; Wed, 08 Aug 2007 04:14:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIgg8-0008N4-9x for dime@ietf.org; Wed, 08 Aug 2007 04:14:04 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIgg7-0008HL-Mg for dime@ietf.org; Wed, 08 Aug 2007 04:14:04 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l788Dtk3003090 for ; Wed, 8 Aug 2007 10:13:55 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Update on Diameter Auditing Date: Wed, 8 Aug 2007 10:13:54 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401950CF1@lulex02.ad.operax.com> In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB262504C3B77C@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Update on Diameter Auditing Thread-Index: AcfZKTi5ll/Om0MTQtqpUMRh7hf/NQACRfHgABglUIA= References: <33656995C5C5094A983DE84DA649A924017F8F14@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504B63A8A@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950B37@lulex02.ad.operax.com><4C0FAAC489C8B74F96BEAD85EAEB262504BC8994@xmb-sjc-215.amer.cisco.com><33656995C5C5094A983DE84DA649A92401950C38@lulex02.ad.operax.com> <008401c7d8e7$aa378a00$864c460a@china.huawei.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C3B6AA@xmb-sjc-215.amer.cisco.com> <46B8C82F.1020401@rogers.com> <4C0FAAC489C8B74F96BEAD85EAEB262504C3B77C@xmb-sjc-215.amer.cisco.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Wed, 08 Aug 2007 10:13:55 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3891/Wed Aug 8 02:11:58 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 -----Original Message----- From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 Sent: den 7 augusti 2007 22:40 To: Tom Taylor Cc: Tina TSOU; Ulf Bodin; dime@ietf.org Subject: RE: [Dime] Update on Diameter Auditing Tom Taylor allegedly scribbled on Tuesday, August 07, 2007 12:30 PM: > OK, let's say this one more time. ITU-T documents are available for=20 > free to everyone, not just Cisco, at=20 > http://www.itu.int/ITU-T/publications/recs.html. >=20 > ETSI published specifications are available for free to everyone, not=20 > just Cisco, at http://pda.etsi.org/pda/queryform.asp. ETSI work in=20 > progress is available free to everyone, not just Cisco, at > http://portal.etsi.org/docbox/TISPAN/Open/NGN_LATEST_DRAFTS/ =20 OK, let's say _this_ one more time: this is neither ETSI nor ITU-T. I don't think that a simple I-D cogently describing the problem to be solved is too much to ask; if it is, then maybe there _is_ no problem. Not that I'm opposed to full employment for protocol designers but it seems to me that the above referenced organizations (among many others) provide ample opportunity: we don't need to help them out here. [Ulf: What we have are two drafts; draft-bodin-dime-auditing-reqs-02 and draft-asveren-dime-state-recovery-01. While the first draft provides a somewhat more general description of requirements that I agree may not be sufficient to derive protocol mechanisms from, the seconds draft come in my view closer to providing a base for such work.] =20 ... _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 10:18: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 1IImMh-0006KO-KK; Wed, 08 Aug 2007 10:18:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImMf-0006Jx-C8; Wed, 08 Aug 2007 10:18:21 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IImMe-0000Gr-Pe; Wed, 08 Aug 2007 10:18:21 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1186582699!18498677!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17605 invoked from network); 8 Aug 2007 14:18:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 8 Aug 2007 14:18:19 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l78EIJd4029219; Wed, 8 Aug 2007 07:18:19 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l78EIIeP018439; Wed, 8 Aug 2007 09:18:18 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l78EIItZ018427; Wed, 8 Aug 2007 09:18:18 -0500 (CDT) 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, 8 Aug 2007 10:18:16 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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, Ahmad, Ahmad Muhanna wrote: >> Maybe this is not so big an issue, but one thing that might happen is >> that the MN can use a different HA address in the re-transmitted RRQ. >> If there is network policy in place that only allows registering on >> specific HAs, this policy might be skirted by the retransmission >> unless the HA address is sent to the RADIUS/Diameter server with >> every RRQ. >=20 > [Ahmad] > We can look at this special case later, but for the sake of this > simple analysis, we need to address the most common simple scenario > first. With the following in mind: "What would the impact be when > using Diameter MIPv4 Application in place of RADIUS model." =20 I think the main impact would be a shorter overall registration time, because the AMR/AMA can carry the registration along with the authentication credentials, which means only one round-trip to the home network instead of 2. =20 > Also, usually the MN does not try to register with another HA until > the registration process is timeout. In our case, we are focusing on > the first retransmitted RRQ which usually done after one second. =20 Why can't we just increase the recommended timeout value? >> I am also concerned about increasing the overall registration time by >> going from one round-trip to two round-trips. The nice thing about >> the existing Diameter application is that it can do both >> authentication/authorization and MIP registration in one round-trip >> to the home network. >=20 > [Ahmad] > I am sorry I missed this point here. Could you please elaborate a > little further.=20 The Diameter MIP4 application was designed to minimize the number of round-trips needed to complete the authentication and registration process. Because the RRQ is carried inside the AMR, there is only one round trip to carry out the two operations: authentication and registration. >> One question: why couldn't we fix the problem by adjusting the >> retransmission timers upwards? If we know that AAA adds some >> additional delay, we could wait a bit longer before retransmitting >> the request. This seems to fix the problem. >=20 > [Ahmad] > I agree with you here. It is anticipated that Diameter MIPv4 > Application will take a longer time to complete MIPv4 initial > registration.=20 On the contrary, I think it will be faster. > Two =20 > questions: >=20 > 1. Why the MN and possibly the network configurations need to change > just for using Diameter MIPv4 Application in place of RADIUS. If we have encountered deployment situations in which a 1 second retransmission is too fast, then we should adjust the recommended minimum value of the timer. =20 > 2. On the other hand, even if we increase the initial timer a little, > we still do not solve the issue, all what we do is delaying it.=20 If we can increase the timer so that 99% of the time the registration completes (or fails) within the new timeout value, then we will have the initial RRP back to the MN before it retransmits (or, in the case of failure, the retransmission will be really necessary). This seems to solve the issue. I don't think we should go re-architecting the MIP4 Diameter application because of a mismatched timeout value. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 10:32: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 1IImaB-0007v2-DM; Wed, 08 Aug 2007 10:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIma6-0007uE-AJ; Wed, 08 Aug 2007 10:32:14 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIma5-0001n9-1Y; Wed, 08 Aug 2007 10:32:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l78EWA612400; Wed, 8 Aug 2007 14:32:10 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 Date: Wed, 8 Aug 2007 09:31:49 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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 Pete, >From this discussion, it is apparent that there is no security issue that you are concerned with. Please confirm? If that is true, then we can change the subject of this thread to the performance issue and continue discussion. Is that acceptable? Regards, Ahmad =20 >=20 > Hi, Ahmad, >=20 > Ahmad Muhanna wrote: > >> Maybe this is not so big an issue, but one thing that=20 > might happen is=20 > >> that the MN can use a different HA address in the=20 > re-transmitted RRQ. > >> If there is network policy in place that only allows=20 > registering on=20 > >> specific HAs, this policy might be skirted by the retransmission=20 > >> unless the HA address is sent to the RADIUS/Diameter server with=20 > >> every RRQ. > >=20 > > [Ahmad] > > We can look at this special case later, but for the sake of this=20 > > simple analysis, we need to address the most common simple scenario=20 > > first. With the following in mind: "What would the impact be when=20 > > using Diameter MIPv4 Application in place of RADIUS model." >=20 > I think the main impact would be a shorter overall=20 > registration time, because the AMR/AMA can carry the=20 > registration along with the authentication credentials, which=20 > means only one round-trip to the home network instead of 2. > =20 > > Also, usually the MN does not try to register with another HA until=20 > > the registration process is timeout. In our case, we are=20 > focusing on=20 > > the first retransmitted RRQ which usually done after one second. >=20 > Why can't we just increase the recommended timeout value? >=20 > >> I am also concerned about increasing the overall=20 > registration time by=20 > >> going from one round-trip to two round-trips. The nice=20 > thing about=20 > >> the existing Diameter application is that it can do both=20 > >> authentication/authorization and MIP registration in one=20 > round-trip=20 > >> to the home network. > >=20 > > [Ahmad] > > I am sorry I missed this point here. Could you please elaborate a=20 > > little further. >=20 > The Diameter MIP4 application was designed to minimize the=20 > number of round-trips needed to complete the authentication=20 > and registration process. Because the RRQ is carried inside=20 > the AMR, there is only one round trip to carry out the two=20 > operations: authentication and registration. >=20 > >> One question: why couldn't we fix the problem by adjusting the=20 > >> retransmission timers upwards? If we know that AAA adds some=20 > >> additional delay, we could wait a bit longer before retransmitting=20 > >> the request. This seems to fix the problem. > >=20 > > [Ahmad] > > I agree with you here. It is anticipated that Diameter MIPv4=20 > > Application will take a longer time to complete MIPv4 initial=20 > > registration. >=20 > On the contrary, I think it will be faster. >=20 > > Two > > questions: > >=20 > > 1. Why the MN and possibly the network configurations need=20 > to change=20 > > just for using Diameter MIPv4 Application in place of RADIUS. >=20 > If we have encountered deployment situations in which a 1=20 > second retransmission is too fast, then we should adjust the=20 > recommended minimum value of the timer. > =20 > > 2. On the other hand, even if we increase the initial timer=20 > a little,=20 > > we still do not solve the issue, all what we do is delaying it. >=20 > If we can increase the timer so that 99% of the time the=20 > registration completes (or fails) within the new timeout=20 > value, then we will have the initial RRP back to the MN=20 > before it retransmits (or, in the case of failure, the=20 > retransmission will be really necessary). This seems to=20 > solve the issue. I don't think we should go re-architecting=20 > the MIP4 Diameter application because of a mismatched timeout value. >=20 > -Pete >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 11:08: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 1IIn9E-0003Lw-TU; Wed, 08 Aug 2007 11:08:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIn9E-0003Lq-1v for dime@ietf.org; Wed, 08 Aug 2007 11:08:32 -0400 Received: from us-wkf-fwmain.comverse.com ([63.64.185.250] helo=us-wkf-interscan1.comverse.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIn9D-0001ae-Ki for dime@ietf.org; Wed, 08 Aug 2007 11:08:31 -0400 Received: from us-nj-mail1.comverse.com (localhost.localdomain [127.0.0.1]) by us-wkf-interscan1.comverse.com (8.13.1/8.13.1) with ESMTP id l78F8SN7007068; Wed, 8 Aug 2007 11:08:29 -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] RE: Vendor-Specific Commands Date: Wed, 8 Aug 2007 11:08:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Vendor-Specific Commands thread-index: AcfVRPUYVR1Fmh02SRSTUeGdpAoWWQEfbacA References: From: "Daily William" To: "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Mark, Thanks for this information. I now have a better understanding of the objective in command code definitions. However this brings to light another interesting question. If a command is reused within the scope of an application ID that it was not originally defined in then it seems that the semantics of the Command can being defined by the 'using application'. An example of this is in the proposed use of ACR/ACA in the draft-ietf-dime-diameter-qos-01.txt. The ABNF for ACR/ACA is inconsistent with the ABNF of Base Diameter (App Id 3). All this is ok and reflects the semantics of the two applications however the ABNF for the same message in both applications is ambiguous and contradictory. Base diameter defines the command header ABNF syntax as: header =3D "<" Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] [application-id]">" IMHO, perhaps in the definition of new applications (or anything other then base diameter (0)) best practice should dictate that the application-id be used in the ABNF for all messages in the new application. This is especially important for reused commands to remove ambiguity. Considering that the base ABNF syntax supports this capability this should be relatively easy. Regards, Bill Comverse, Inc. -----Original Message----- From: Mark Jones [mailto:mark.jones@bridgewatersystems.com]=20 Sent: Thursday, August 02, 2007 4:36 PM To: Daily William Cc: dime@ietf.org Subject: RE: [Dime] RE: Vendor-Specific Commands > It seems to me that the command code is already in a namespace, this > being defined by the application id. =20 My understanding is the Command Codes are taken from a single global namespace in order to allow Command re-use. Commands from one Diameter application can be re-used in another and are still required to conform to the original ABNF. However, the Command header in this case would contain the Application ID of the 'using application' and not the 'defining application'. This is required because the Application ID in the Command Header is used as a secondary key field in routing table lookups. I don't think this case was covered in the original 3588 but it is clarified in section 5.3 of the Application Design Guidelines draft.=20 Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 11:24: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 1IInOZ-0006Yu-RZ; Wed, 08 Aug 2007 11:24:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInOY-0006YX-K2; Wed, 08 Aug 2007 11:24:22 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IInOX-0001xz-H1; Wed, 08 Aug 2007 11:24:22 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1186586659!3192170!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19537 invoked from network); 8 Aug 2007 15:24:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 8 Aug 2007 15:24:19 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l78FOJkD022880; Wed, 8 Aug 2007 08:24:19 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l78FOHFf015111; Wed, 8 Aug 2007 10:24:18 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l78FOGkH015087; Wed, 8 Aug 2007 10:24:17 -0500 (CDT) 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, 8 Aug 2007 11:24:15 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAAACBbmA References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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, Ahmad, I would say there is a minor security issue that may or may not be important in some deployments. It is fine with me if you want to change the subject line. -Pete Ahmad Muhanna wrote: > Hi Pete, >=20 > From this discussion, it is apparent that there is no security issue > that you are concerned with. Please confirm? If that is true, then we > can change the subject of this thread to the performance issue and > continue discussion. =20 >=20 > Is that acceptable? >=20 > Regards, > Ahmad >=20 >>=20 >> Hi, Ahmad, >>=20 >> Ahmad Muhanna wrote: >>>> Maybe this is not so big an issue, but one thing that might happen >>>> is that the MN can use a different HA address in the >>>> re-transmitted RRQ. If there is network policy in place that only >>>> allows registering on specific HAs, this policy might be skirted >>>> by the retransmission unless the HA address is sent to the >>>> RADIUS/Diameter server with every RRQ. >>>=20 >>> [Ahmad] >>> We can look at this special case later, but for the sake of this >>> simple analysis, we need to address the most common simple scenario >>> first. With the following in mind: "What would the impact be when >>> using Diameter MIPv4 Application in place of RADIUS model." >>=20 >> I think the main impact would be a shorter overall registration time, >> because the AMR/AMA can carry the registration along with the >> authentication credentials, which means only one round-trip to the >> home network instead of 2. >=20 >>=20 >>> Also, usually the MN does not try to register with another HA until >>> the registration process is timeout. In our case, we are focusing on >>> the first retransmitted RRQ which usually done after one second. >>=20 >> Why can't we just increase the recommended timeout value? >>=20 >>>> I am also concerned about increasing the overall registration time >>>> by going from one round-trip to two round-trips. The nice thing >>>> about the existing Diameter application is that it can do both >>>> authentication/authorization and MIP registration in one round-trip >>>> to the home network. >>>=20 >>> [Ahmad] >>> I am sorry I missed this point here. Could you please elaborate a >>> little further. >>=20 >> The Diameter MIP4 application was designed to minimize the number of >> round-trips needed to complete the authentication and registration >> process. Because the RRQ is carried inside the AMR, there is only >> one round trip to carry out the two >> operations: authentication and registration. >>=20 >>>> One question: why couldn't we fix the problem by adjusting the >>>> retransmission timers upwards? If we know that AAA adds some >>>> additional delay, we could wait a bit longer before retransmitting >>>> the request. This seems to fix the problem. >>>=20 >>> [Ahmad] >>> I agree with you here. It is anticipated that Diameter MIPv4 >>> Application will take a longer time to complete MIPv4 initial >>> registration. >>=20 >> On the contrary, I think it will be faster. >>=20 >>> Two >>> questions: >>>=20 >>> 1. Why the MN and possibly the network configurations need to change >>> just for using Diameter MIPv4 Application in place of RADIUS. >>=20 >> If we have encountered deployment situations in which a 1 second >> retransmission is too fast, then we should adjust the recommended >> minimum value of the timer.=20 >>=20 >>> 2. On the other hand, even if we increase the initial timer a >>> little, we still do not solve the issue, all what we do is delaying >>> it.=20 >>=20 >> If we can increase the timer so that 99% of the time the registration >> completes (or fails) within the new timeout value, then we will have >> the initial RRP back to the MN before it retransmits (or, in the case >> of failure, the retransmission will be really necessary). This seems >> to solve the issue. I don't think we should go re-architecting the >> MIP4 Diameter application because of a mismatched timeout value. >>=20 >> -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 08 11: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 1IInTI-0001yr-MX; Wed, 08 Aug 2007 11:29:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInTG-0001yR-1E; Wed, 08 Aug 2007 11:29:14 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IInTE-00038c-QD; Wed, 08 Aug 2007 11:29:14 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l78FRFk02653; Wed, 8 Aug 2007 15:27:15 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 Date: Wed, 8 Aug 2007 10:29:05 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711607078E@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAAACBbmAAAALInA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft 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 Thanks Pete. Just a minor note; I have not been able to see what was the minor security issue you are referring to but as you said, we can go ahead and start the new thread. Will follow Performance discussion on the new thread. Regards, Ahmad =20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 > Sent: Wednesday, August 08, 2007 10:24 AM > To: Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > Cc: mip4@ietf.org; Hannes Tschofenig > Subject: RE: Issue 2: Security Concern in RADIUS Mode: MIPv4=20 > Auth Performance Using RADIUS and Diameter MIPv4 Application draft >=20 > Hi, Ahmad, >=20 > I would say there is a minor security issue that may or may=20 > not be important in some deployments. >=20 > It is fine with me if you want to change the subject line. >=20 > -Pete >=20 > Ahmad Muhanna wrote: > > Hi Pete, > >=20 > > From this discussion, it is apparent that there is no=20 > security issue=20 > > that you are concerned with. Please confirm? If that is=20 > true, then we=20 > > can change the subject of this thread to the performance issue and=20 > > continue discussion. > >=20 > > Is that acceptable? > >=20 > > Regards, > > Ahmad > >=20 > >>=20 > >> Hi, Ahmad, > >>=20 > >> Ahmad Muhanna wrote: > >>>> Maybe this is not so big an issue, but one thing that=20 > might happen=20 > >>>> is that the MN can use a different HA address in the=20 > re-transmitted=20 > >>>> RRQ. If there is network policy in place that only allows=20 > >>>> registering on specific HAs, this policy might be skirted by the=20 > >>>> retransmission unless the HA address is sent to the=20 > RADIUS/Diameter=20 > >>>> server with every RRQ. > >>>=20 > >>> [Ahmad] > >>> We can look at this special case later, but for the sake of this=20 > >>> simple analysis, we need to address the most common=20 > simple scenario=20 > >>> first. With the following in mind: "What would the impact be when=20 > >>> using Diameter MIPv4 Application in place of RADIUS model." > >>=20 > >> I think the main impact would be a shorter overall=20 > registration time,=20 > >> because the AMR/AMA can carry the registration along with the=20 > >> authentication credentials, which means only one round-trip to the=20 > >> home network instead of 2. > >=20 > >>=20 > >>> Also, usually the MN does not try to register with=20 > another HA until=20 > >>> the registration process is timeout. In our case, we are=20 > focusing on=20 > >>> the first retransmitted RRQ which usually done after one second. > >>=20 > >> Why can't we just increase the recommended timeout value? > >>=20 > >>>> I am also concerned about increasing the overall=20 > registration time=20 > >>>> by going from one round-trip to two round-trips. The nice thing=20 > >>>> about the existing Diameter application is that it can do both=20 > >>>> authentication/authorization and MIP registration in one=20 > round-trip=20 > >>>> to the home network. > >>>=20 > >>> [Ahmad] > >>> I am sorry I missed this point here. Could you please elaborate a=20 > >>> little further. > >>=20 > >> The Diameter MIP4 application was designed to minimize the=20 > number of=20 > >> round-trips needed to complete the authentication and registration=20 > >> process. Because the RRQ is carried inside the AMR, there is only=20 > >> one round trip to carry out the two > >> operations: authentication and registration. > >>=20 > >>>> One question: why couldn't we fix the problem by adjusting the=20 > >>>> retransmission timers upwards? If we know that AAA adds some=20 > >>>> additional delay, we could wait a bit longer before=20 > retransmitting=20 > >>>> the request. This seems to fix the problem. > >>>=20 > >>> [Ahmad] > >>> I agree with you here. It is anticipated that Diameter MIPv4=20 > >>> Application will take a longer time to complete MIPv4 initial=20 > >>> registration. > >>=20 > >> On the contrary, I think it will be faster. > >>=20 > >>> Two > >>> questions: > >>>=20 > >>> 1. Why the MN and possibly the network configurations=20 > need to change=20 > >>> just for using Diameter MIPv4 Application in place of RADIUS. > >>=20 > >> If we have encountered deployment situations in which a 1 second=20 > >> retransmission is too fast, then we should adjust the recommended=20 > >> minimum value of the timer. > >>=20 > >>> 2. On the other hand, even if we increase the initial timer a=20 > >>> little, we still do not solve the issue, all what we do=20 > is delaying=20 > >>> it. > >>=20 > >> If we can increase the timer so that 99% of the time the=20 > registration=20 > >> completes (or fails) within the new timeout value, then we=20 > will have=20 > >> the initial RRP back to the MN before it retransmits (or,=20 > in the case=20 > >> of failure, the retransmission will be really necessary). =20 > This seems=20 > >> to solve the issue. I don't think we should go re-architecting the > >> MIP4 Diameter application because of a mismatched timeout value. > >>=20 > >> -Pete >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 08:18:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6yP-000516-FA; Thu, 09 Aug 2007 08:18:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ6yN-00050w-TJ for dime@ietf.org; Thu, 09 Aug 2007 08:18:39 -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 1IJ6yN-0001yN-Kh for dime@ietf.org; Thu, 09 Aug 2007 08:18:39 -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 l79CISV7089375; Thu, 9 Aug 2007 08:18:28 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46BB0614.2060507@tari.toshiba.com> Date: Thu, 09 Aug 2007 08:18:28 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Daily William Subject: Re: [Dime] RE: Vendor-Specific Commands 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Daily, > IMHO, perhaps in the definition of new applications (or anything other > then base diameter (0)) best practice should dictate that the > application-id be used in the ABNF for all messages in the new > application. This is especially important for reused commands to remove > ambiguity. Considering that the base ABNF syntax supports this > capability this should be relatively easy. > The diameter "best practices" document (http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt) does explicitly state what you mentioned. Unfortunately, older document had followed an older scheme and recent drafts had yet to conform. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 09:35: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 1IJ8Ax-0004Dz-W6; Thu, 09 Aug 2007 09:35:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8Ax-0004De-Dc for dime@ietf.org; Thu, 09 Aug 2007 09:35:43 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ8Av-0001uC-Mv for dime@ietf.org; Thu, 09 Aug 2007 09:35:43 -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 l79DZbv7012453; Thu, 9 Aug 2007 09:35:37 -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] Re-Visiting Vendor-Specific Commands Date: Thu, 9 Aug 2007 09:35:37 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718811D@sonusmail04.sonusnet.com> In-Reply-To: <46B8C55E.8010507@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Re-Visiting Vendor-Specific Commands Thread-Index: AcfZJ8MZhMiauwkQTSW/bJgHAld2tQBYJ3kA References: <46B8C55E.8010507@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" , "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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, I agree with this text. Considering also "Application Design Guidelines" document, we probably will end-up lots of new commands/applications, e.g. any operator which wants to add a new AVP with M-bit set (pretty much all AVPs) will require a new command code and this further will require a new application. OTOH, I still think this is the direction to follow to guarantee proper routing of messages to endpoints, which actually can process them. Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Tuesday, August 07, 2007 3:18 PM > To: Mark Jones > Cc: dime@ietf.org > Subject: [Dime] Re-Visiting Vendor-Specific Commands >=20 > Hi, >=20 > Mark had proposed a text for rfc3588bis with regards to the rules on > Vendor-Specific command code allocation. The result would look like: >=20 > 11.2.1. Command Codes >=20 > The Command Code namespace is used to identify Diameter commands. > The values 0-255 (0x00-0xff) are reserved for RADIUS backward > compatibility, and are defined as "RADIUS Packet Type Codes" in > [RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for > permanent, standard commands, allocated by Expert Review [RFC2434]. > This document defines the Command Codes 257, 258, 271, 274-275, > 280 and 282. See Section 3.1 for the assignment of the namespace > in this specification. >=20 > The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are > reserved for vendor-specific command codes, to be allocated on a > First Come, First Served basis by IANA [RFC2434]. The request to > IANA for a Vendor-Specific Command Code SHOULD include a reference > to a publicly available specification which documents the command > in sufficient detail to aid in interoperability between independent > implementations. If the specification cannot be made publicly > available, the request for a vendor-specific command code MUST > include the contact information of persons and/or entities responsible > for authoring and maintaining the command. >=20 > The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - > 0xffffff) are reserved for experimental commands. As these codes are > only for experimental and testing purposes, no guarantee is made for > interoperability between Diameter peers using experimental commands, > as outlined in [IANA-EXP]. >=20 >=20 > I would like to poll the WG to see if there are still concerns about > this proposal or if there are any other comments. It would be great if > we can get some conclusion regarding this topic. >=20 > 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 Aug 09 13:15: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 1IJBc3-00049I-8p; Thu, 09 Aug 2007 13:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBc1-00047D-L5; Thu, 09 Aug 2007 13:15:53 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBc0-000771-85; Thu, 09 Aug 2007 13:15:53 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l79HFlS27027; Thu, 9 Aug 2007 17:15:48 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 Date: Thu, 9 Aug 2007 12:15:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0A== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org Subject: [Dime] Issue 3: Diameter MIP4 Application vs. RADIUS Architecture 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 Pete, My apologies, I almost forgot about opening this thread. However, May I focus on one portion of your reply, specifically your proposals to address the issue. > =20 >=20 > > Two > > questions: > >=20 > > 1. Why the MN and possibly the network configurations need=20 > to change=20 > > just for using Diameter MIPv4 Application in place of RADIUS. >=20 > If we have encountered deployment situations in which a 1=20 > second retransmission is too fast, then we should adjust the=20 > recommended minimum value of the timer. [Ahmad] This is a proposal for increasing the initial RRQ retransmission timer. Please see below. > =20 > > 2. On the other hand, even if we increase the initial timer=20 > a little,=20 > > we still do not solve the issue, all what we do is delaying it. >=20 > If we can increase the timer so that 99% of the time the=20 > registration completes (or fails) within the new timeout=20 > value, then we will have the initial RRP back to the MN=20 > before it retransmits (or, in the case of failure, the=20 > retransmission will be really necessary). This seems to=20 > solve the issue. I don't think we should go re-architecting=20 > the MIP4 Diameter application because of a mismatched timeout value. [Ahmad] Ok, I think this is an important step. I think what you are trying to say is that you agree with the analysis that the draft presented and you are trying to propose solutions for the issue without any change to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair statement? >=20 > -Pete >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 13:51: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 1IJCAu-0000Ay-W3; Thu, 09 Aug 2007 13:51:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCAt-00009a-Fc; Thu, 09 Aug 2007 13:51:55 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJCAr-0007yQ-DA; Thu, 09 Aug 2007 13:51:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1186681910!18461861!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30941 invoked from network); 9 Aug 2007 17:51:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 9 Aug 2007 17:51:50 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l79HpoVS024134; Thu, 9 Aug 2007 10:51:50 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l79HpnLU021873; Thu, 9 Aug 2007 12:51:49 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l79Hpn9a021860; Thu, 9 Aug 2007 12:51:49 -0500 (CDT) 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, 9 Aug 2007 13:51:48 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7Gw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture 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, Ahmad, Ahmad Muhanna wrote: >> If we can increase the timer so that 99% of the time the registration >> completes (or fails) within the new timeout value, then we will have >> the initial RRP back to the MN before it retransmits (or, in the case >> of failure, the retransmission will be really necessary). This seems >> to solve the issue. I don't think we should go re-architecting the >> MIP4 Diameter application because of a mismatched timeout value. >=20 > [Ahmad] > Ok, I think this is an important step. I think what you are trying to > say is that you agree with the analysis that the draft presented and > you are trying to propose solutions for the issue without any change > to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair > statement? =20 I agree that if the Diameter infrastructure takes too long to respond to the MN before it retransmits, this would potentially put a second, uneccessary AMR into the network, causing more traffic. The registration process itself would be delayed a bit because the MN would be waiting for a response to its most recently transmitted RRQ. However, RFC3344 specifies an exponentially increasing timeout value so eventually the MN would get registered. I think that summarizes the problem you raised; it could have been sent to the list in that form rather than writing an entire draft with call flows comparing RADIUS to Diameter. I agree that a Diameter (or RADIUS, for that matter) infrastructure might take more than 1 second to respond to an AMR or an Access-Request. It seems that the solution is to recommend a longer timeout value for the initial retransmission. Another solution would be to allow the MN to complete its registration successfully by receiving an RRP matching a previous RRQ (not just the most recently retransmitted one). I don't think we should turn the MIP4 Diameter application into a 2-round-trips protocol. The goal of RFC4004 is to provide MIP registration in one round-trip. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 14:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCz6-0005YO-VT; Thu, 09 Aug 2007 14:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCyk-0004x9-9A; Thu, 09 Aug 2007 14:43:27 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJCyi-0001Ti-PU; Thu, 09 Aug 2007 14:43:26 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l79IhLS19061; Thu, 9 Aug 2007 18:43:21 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 Date: Thu, 9 Aug 2007 13:43:16 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture 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 Pete, >=20 > Hi, Ahmad, >=20 > Ahmad Muhanna wrote: > >> If we can increase the timer so that 99% of the time the=20 > registration=20 > >> completes (or fails) within the new timeout value, then we=20 > will have=20 > >> the initial RRP back to the MN before it retransmits (or,=20 > in the case=20 > >> of failure, the retransmission will be really necessary). =20 > This seems=20 > >> to solve the issue. I don't think we should go re-architecting the > >> MIP4 Diameter application because of a mismatched timeout value. > >=20 > > [Ahmad] > > Ok, I think this is an important step. I think what you are=20 > trying to=20 > > say is that you agree with the analysis that the draft=20 > presented and=20 > > you are trying to propose solutions for the issue without=20 > any change=20 > > to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair > > statement? =20 >=20 > I agree that if the Diameter infrastructure takes too long to=20 > respond to the MN before it retransmits, this would=20 > potentially put a second, uneccessary AMR into the network,=20 > causing more traffic. The registration process itself would=20 > be delayed a bit because the MN would be waiting for a=20 > response to its most recently transmitted RRQ. However,=20 > RFC3344 specifies an exponentially increasing timeout value=20 > so eventually the MN would get registered. >=20 > I think that summarizes the problem you raised; it could have=20 > been sent to the list in that form rather than writing an=20 > entire draft with call flows comparing RADIUS to Diameter. [Ahmad] I assume you are talking here with MIPv4 chair hat-off, there is no restrictions about writing drafts in IETF and getting two wg to agree to present the idea and generate discussion inside the meeting and on the mailing lists or you are suggesting a new IETF rule here? Having said that, I guess the least which can be said about what you just mentioned is over simplification of what the draft is trying to present. The idea the draft was to highlight and present, IMO and many others, a valid weakness about D-MIPv4 architecture. The draft is trying to compare the performance of the current RADIUS deployment to what to be Diameter Mobile IPv4 Application deployment. Let me try to explain what the draft is trying to highlight one more time: 1. Currently there are certain deployment configuration parameters and the operator probably would like to get better performance in case Diameter is used in place of RADIUS without further studies and analysis to how to tweak the network in order to optimize the expected D-MIP4 performance issue. 2. The point here is not about Diameter as an AAA protocol, however, it is about the concept of coupling the MIPv4 control signaling to AAA signaling. Which many people do not think it is a good idea and believe that it is a deviation from RFC3344 initial MIPv4 registration procedure. Do not you agree? 3. Of course, RFC3344 have a retransmission mechanism, which in most cases should get the MN eventually registered. On the other hand, RFC4004 proposes a Diameter Application and impeded MIPv4 control signaling inside AAA control signaling and the draft never assumed that there could be an impact on the MIPv4 signaling retransmission mechanism or performance. Not to mention coupling of MIPv4 signaling retransmission with AAA signaling retransmission. 4. If the AAA infrastructure have the same load in case of RADIUS and D-MIP4 and the MN had to retransmit the initial MIPv4 RRQ, there is a much much greater chance that D-MIPv4 will cause another round of UNNECESSARY AAA signaling that does not happen in the case of RADIUS. 5. If the AAA infrastructure is slightly loaded and cause a MN to retransmit its MIPv4 initial RRQ, D-MIPv4 as per RFC4004 makes the situation much WORSE by injecting, at least, DOUBLE the number of AAA (Diameter) signaling messages. In the case of RADIUS this is not there. 6. Actually, we are going to publish a new revision of this draft and address the scenario of allocating a HA in the visited network. Have you looked into the difference between the RADIUS and D-MIP4 performance in this scenario and what will happen if the MN happened to retransmit? 7. Finally, I guess all of the above worth writing a draft in order to provide heads up for the industry of what to expect in case D-MIPv4, RFC4004, is deployed in place of RADIUS. >=20 > I agree that a Diameter (or RADIUS, for that matter)=20 > infrastructure might take more than 1 second to respond to an=20 > AMR or an Access-Request. > It seems that the solution is to recommend a longer timeout=20 > value for the initial retransmission. Another solution would=20 > be to allow the MN to complete its registration successfully=20 > by receiving an RRP matching a previous RRQ (not just the=20 > most recently retransmitted one). >=20 > I don't think we should turn the MIP4 Diameter application=20 > into a 2-round-trips protocol. The goal of RFC4004 is to=20 > provide MIP registration in one round-trip. >=20 > -Pete >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 15:02: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 1IJDH4-0002AO-C5; Thu, 09 Aug 2007 15:02:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDGz-00028k-Ms; Thu, 09 Aug 2007 15:02:19 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJDGy-000284-Ee; Thu, 09 Aug 2007 15:02:17 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1186686135!20222747!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6588 invoked from network); 9 Aug 2007 19:02:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 9 Aug 2007 19:02:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l79J2E4L018319; Thu, 9 Aug 2007 12:02:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l79J2E3I008959; Thu, 9 Aug 2007 14:02:14 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l79J2D8s008950; Thu, 9 Aug 2007 14:02:13 -0500 (CDT) 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, 9 Aug 2007 15:02:12 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip4@ietf.org Subject: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture 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, Ahmad, Ahmad Muhanna wrote: > 2. The point here is not about Diameter as an AAA protocol, however, > it is about the concept of coupling the MIPv4 control signaling to > AAA signaling. Which many people do not think it is a good idea and > believe that it is a deviation from RFC3344 initial MIPv4 > registration procedure. Do not you agree? =20 No, I don't. Putting the Registration Request in the AMR is a feature. It allows the registration to happen in one round-trip. =20 > 6. Actually, we are going to publish a new revision of this draft and > address the scenario of allocating a HA in the visited network. Have > you looked into the difference between the RADIUS and D-MIP4 > performance in this scenario and what will happen if the MN happened > to retransmit? =20 Obviously this scenario takes longer to process the RRQ and so the chance of hitting a retransmission is greater. =20 >> I agree that a Diameter (or RADIUS, for that matter) infrastructure >> might take more than 1 second to respond to an AMR or an >> Access-Request. It seems that the solution is to recommend a longer >> timeout value for the initial retransmission. Another solution >> would be to allow the MN to complete its registration successfully >> by receiving an RRP matching a previous RRQ (not just the most >> recently retransmitted one).=20 >>=20 >> I don't think we should turn the MIP4 Diameter application into a >> 2-round-trips protocol. The goal of RFC4004 is to provide MIP >> registration in one round-trip. >>=20 -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 15:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDis-0002ET-LZ; Thu, 09 Aug 2007 15:31:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDim-000226-UB; Thu, 09 Aug 2007 15:31:02 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJDim-0005hv-Gn; Thu, 09 Aug 2007 15:31:00 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l79JT1D02239; Thu, 9 Aug 2007 19:29:02 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 Date: Thu, 9 Aug 2007 14:30:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAAAlpMQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mip4@ietf.org Subject: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture 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 Pete, >=20 > Ahmad Muhanna wrote: > > 2. The point here is not about Diameter as an AAA protocol,=20 > however,=20 > > it is about the concept of coupling the MIPv4 control=20 > signaling to AAA=20 > > signaling. Which many people do not think it is a good idea and=20 > > believe that it is a deviation from RFC3344 initial MIPv4 > > registration procedure. Do not you agree? =20 >=20 > No, I don't. Putting the Registration Request in the AMR is=20 > a feature. > It allows the registration to happen in one round-trip. [Ahmad] Well, I do not understand what you mean by a feature. Initial RRQ/RRP is coupled with AMR/AMA, as a matter of fact they are carried in attributes. In other words, we can not relay initial RRQ/RRP outside AMR/AMA as per RFC3344. Even if you want to call it a feature, that feature makes D-MIP4 architecture different from RADIUS and at the same time makes AAA infrastructure more vulnerable. > =20 > > 6. Actually, we are going to publish a new revision of this=20 > draft and=20 > > address the scenario of allocating a HA in the visited=20 > network. Have=20 > > you looked into the difference between the RADIUS and D-MIP4=20 > > performance in this scenario and what will happen if the MN happened > > to retransmit? =20 >=20 > Obviously this scenario takes longer to process the RRQ and=20 > so the chance of hitting a retransmission is greater. [Ahmad] Okay.. Then that is bad and has bad consequences on the AAA infrastructure and on the current MIPv4 deployment. Operators, expects the current network infrastructure to work, at least, better when upgrading AAA to Diameter not to degrade their network performance and start spending moneys on studies and tweaking mechanisms here and there to compromise for the D-MIPv4 feature. IMO, that is not a bad feature and we need to fix it. > =20 > >> I agree that a Diameter (or RADIUS, for that matter)=20 > infrastructure=20 > >> might take more than 1 second to respond to an AMR or an=20 > >> Access-Request. It seems that the solution is to recommend=20 > a longer=20 > >> timeout value for the initial retransmission. Another=20 > solution would=20 > >> be to allow the MN to complete its registration successfully by=20 > >> receiving an RRP matching a previous RRQ (not just the=20 > most recently=20 > >> retransmitted one). > >>=20 > >> I don't think we should turn the MIP4 Diameter application into a=20 > >> 2-round-trips protocol. The goal of RFC4004 is to provide MIP=20 > >> registration in one round-trip. > >>=20 >=20 > -Pete >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 09 15:34: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 1IJDmQ-0005vl-QP; Thu, 09 Aug 2007 15:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDmL-0005uy-FJ; Thu, 09 Aug 2007 15:34:42 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJDmI-0002yr-EA; Thu, 09 Aug 2007 15:34:40 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l79JYYS05283; Thu, 9 Aug 2007 19:34:34 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] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Date: Thu, 9 Aug 2007 14:34:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711611499F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAAAlpMQAACZeRA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mip4@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 Sorry one correction:) > compromise for the D-MIPv4 feature. IMO, that is **not** a bad=20 > feature and we need to fix it. I meant to say: IMO, that is a bad feature and we need to fix it. Regards, Ahmad =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 10 07:03: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 1IJSHb-0005Wc-KI; Fri, 10 Aug 2007 07:03:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJSHa-0005WU-OV; Fri, 10 Aug 2007 07:03:54 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJSHZ-0002Of-99; Fri, 10 Aug 2007 07:03:54 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 13:03:49 +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] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. Date: Fri, 10 Aug 2007 13:03:48 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F274E4@SEHAN021MB.tcad.telia.se> In-Reply-To: <005401c7d602$1bfa0fc0$580c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. Thread-Index: AcfWAex2iPusDUJMSHiQ0TeCWSKLGgCIecRw References: <005401c7d602$1bfa0fc0$580c7c0a@china.huawei.com> From: To: , , X-OriginalArrivalTime: 10 Aug 2007 11:03:49.0368 (UTC) FILETIME=[2121FF80:01C7DB3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Frank, =20 Thanks for the review. This is good discussion start for subsequent revisions of the I-D. Sorry for the slow reply.. I am still on summer vacation mode ;-) Please see some of my random thoughts inline. =20 Cheers, Jouni =20 ________________________________ From: Frank Xia [mailto:xiayangsong@huawei.com]=20 Sent: Friday, August 03, 2007 10:12 PM To: dime@ietf.org; netlmm@ietf.org Subject: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. =09 =09 Hi all =20 I have some comments in the DIME WG when the draft is presented in Chicago. I would like to summarize my comments here. =20 The main idea of the draft is based on that "=20 The access authentication procedure into the Proxy Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario bootstrapping" =20 I would like to highlight some differences and their influence on AAA interface. 1)The security association is between MAG and LMA, not MN and LMA [JiK] Yes.. how does this affect the authentication procedure between the NAS(MAG) and the AAA? At the end you still authenticate a MN.. 2)PMIPv6 now only deals with the P-t-P link model, in which case it is very probable that the LMA has no any idea about the MN's IP addess [JiK] Yes.. there is currently no assumption that LMA would know the MN-HoA.. It can learn it though. 3)In the PMIPv6 ,there is another important function, that is, the all MAGs should run consistently to emulate the MN's home link characteritics [JiK] Yes.. How does this affect to the said AAA interface? I am a bit confused about the three above points and their relation to the MAG-AAA=20 interface when it comes to MN attaching & authenticating to a PMIP6 domain.. =20 The following is the detailed comments: 1)Adding information exchange between LMA and AAA server to convey key material when LMA<->MAG SA is established using EAP authentication. [JiK] Hmm.. a MN attaching to a MAG may trigger a dynamic establishment of the MAG-LMA SA, if it does not exist at that point. What information do you think will be PMIP6 specific betweem LMA and AAA during the IKEv2 IPSec SA setup? By the way, we should not restrict ourselves to EAP only. 2)Clarifying the meaning FQDN, and enabling dynamical LMA discovery [JiK] Meaning of the FQDN? Would stating that it is the FQDN of the LMA be enough? Dynamic discovery of LMA is alrady in the I-D. Using both DNS and AAA options. 3)DNS update. It is possible for MAG to initate DNS update [JiK] Yes. This is missing. 4)the usage of PMIP6-MAG-Address. [JiK] Right.. the original intention of this was to support deployment an option where a NAS/authenticator is not co-located with a MAG rather looking after a pool of MAGs. There the AAA might want to know which MAG the authentication concerns as PBUs and AAA messages originate from different IPs. 5)Adding address configuration mode attribute to emulate the link. [JiK] Originally we thought to handle this with the feature vector AVP we have in the I-D. =20 BR Frank _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 10 15:27: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 1IJa8V-0007d9-8V; Fri, 10 Aug 2007 15:27:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJa8U-0007d0-J2; Fri, 10 Aug 2007 15:27:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJa8T-0003pX-O8; Fri, 10 Aug 2007 15:27:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMK00AUCOO1YD@szxga01-in.huawei.com>; Sat, 11 Aug 2007 03:26:25 +0800 (CST) Received: from ny3104051930 ([10.124.12.88]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMK00DL5ONWE0@szxga01-in.huawei.com>; Sat, 11 Aug 2007 03:26:25 +0800 (CST) Date: Fri, 10 Aug 2007 14:28:37 -0500 From: Frank Xia Subject: Re: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. To: jouni.korhonen@teliasonera.com, dime@ietf.org, netlmm@ietf.org Message-id: <005501c7db84$a79a6cf0$580c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <005401c7d602$1bfa0fc0$580c7c0a@china.huawei.com> <59D7431DE2527D4CB0F1EFEDA5683ED301F274E4@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 Please see my inlines comments... BR Frank ----- Original Message ----- From: To: ; ; Sent: Friday, August 10, 2007 6:03 AM Subject: RE: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. Hi Frank, Thanks for the review. This is good discussion start for subsequent revisions of the I-D. Sorry for the slow reply.. I am still on summer vacation mode ;-) Frank=> I will benefit from the discussion too. Please see some of my random thoughts inline. Cheers, Jouni ________________________________ From: Frank Xia [mailto:xiayangsong@huawei.com] Sent: Friday, August 03, 2007 10:12 PM To: dime@ietf.org; netlmm@ietf.org Subject: [Dime] follow-up of Chicago meeting: comments on draft-korhonen-dime-pmip6-00.txt. Hi all I have some comments in the DIME WG when the draft is presented in Chicago. I would like to summarize my comments here. The main idea of the draft is based on that " The access authentication procedure into the Proxy Mobile IPv6 Domain resembles the Mobile IPv6 integrated scenario bootstrapping" I would like to highlight some differences and their influence on AAA interface. 1)The security association is between MAG and LMA, not MN and LMA [JiK] Yes.. how does this affect the authentication procedure between the NAS(MAG) and the AAA? At the end you still authenticate a MN.. Frank=>My point is how to build SA between MAG and LMA. For example, after authentication of the first MN named first@italia.com, there is a SA establishment process between MAG and LMA. As to second MN named second@italia.com it is not necessary for MAG to initate the SA estbalishment because the second MN can share existing SA. The SA establishment needs the support of AAA infrastructure. 2)PMIPv6 now only deals with the P-t-P link model, in which case it is very probable that the LMA has no any idea about the MN's IP addess [JiK] Yes.. there is currently no assumption that LMA would know the MN-HoA. It can learn it though. 3)In the PMIPv6 ,there is another important function, that is, the all MAGs should run consistently to emulate the MN's home link characteritics [JiK] Yes.. How does this affect to the said AAA interface? I am a bit confused about the three above points and their relation to the MAG-AAA interface when it comes to MN attaching & authenticating to a PMIP6 domain.. Frank=> The above are general comments to highlight the differences. The following are the specific comments. The following is the detailed comments: 1)Adding information exchange between LMA and AAA server to convey key material when LMA<->MAG SA is established using EAP authentication. [JiK] Hmm.. a MN attaching to a MAG may trigger a dynamic establishment of the MAG-LMA SA, if it does not exist at that point. What information do you think will be PMIP6 specific betweem LMA and AAA during the IKEv2 IPSec SA setup? By the way, we should not restrict ourselves to EAP only. Frank=>New attribute PMIP6-LMA-MAG-Pair-Keys is necessary. It is true we should not restrict to EAP, but we should support EAP. 2)Clarifying the meaning FQDN, and enabling dynamical LMA discovery [JiK] Meaning of the FQDN? Would stating that it is the FQDN of the LMA be enough? Dynamic discovery of LMA is alrady in the I-D. Using both DNS and AAA options. Frank=>Could you give me the text about Dynamic discovery of LMA in the I-D? 3)DNS update. It is possible for MAG to initate DNS update [JiK] Yes. This is missing. 4)the usage of PMIP6-MAG-Address. [JiK] Right.. the original intention of this was to support deployment an option where a NAS/authenticator is not co-located with a MAG rather looking after a pool of MAGs. There the AAA might want to know which MAG the authentication concerns as PBUs and AAA messages originate from different IPs. Frank=>Even though NAS/authenticator is not co-located with MAG, AAA should be agnostic with the relationship between NAS/authenticator and MAG. Any way, could you give a more specific scenario? 5)Adding address configuration mode attribute to emulate the link. [JiK] Originally we thought to handle this with the feature vector AVP we have in the I-D. Frank=>I can't find related description till now. BR Frank _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 10 16:29: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 1IJb6c-0003nP-H9; Fri, 10 Aug 2007 16:29:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJb6b-0003nK-45 for dime@ietf.org; Fri, 10 Aug 2007 16:29:09 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJb6a-0005I7-Kp for dime@ietf.org; Fri, 10 Aug 2007 16:29: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 l7AKT8SH007929 for ; Fri, 10 Aug 2007 16:29:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2007 16:29:07 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments for draft-ietf-dime-app-design-guide-02.txt Thread-Index: AcfbjRnjKaOMFrSzTEaP67/my6asJQ== From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Dime] Comments for draft-ietf-dime-app-design-guide-02.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 Victor, Please find below my comments for draft-dime-app-design-guide-02.txt. I think this draft is in very good shape and almost all of my comments are editorial. Thanks, Tolga 1) 4.1.2 Deleting a command In general, it is unusual to delete an existing command from an existing application for ^^^^^^^^^^^ ADD This design decision would normally be an indication of a flawed designed.=20 =3D=3D> This normally would be an indication of a flawed design. 2) 4.2 Reusing existing commands In some cases, there are a lot of ambiguity. =3D=3D> In some cases there is a lot of ambiguity. So design considerations have been outlined to ease process. ^ ADD 3) 4.2.1 Adding AVPs to a command A mandatory AVP cannot be added ^^^ ADD 4) 4.2.2 Deleting AVPs from a command Instead of deleting AVPs from a command, a better alternative ^^^^^^^^^^^^^^^^^^^ ADD 5) 6.3 Updating an existing application "Optional AVPs can also be used to indicate version differences." I think, using an *optional* AVP for this purpose could be problematic. I can think of two different cases here: a) An application has a mandatory AVP from very beginning on to indicate version. In such a case, a new version can be safely signaled to entities running an older version of the application. Because semantics associated with the Version-AVP are defined by the initial release of the application, all nodes would be able to interpret it successfully. An older version implementation can reject a request containing a Version-AVP with a newer value. b) The new release of the application uses a new and mandatory AVP. This would mean that a new command needs to be defined as well. New command would not be recognized by the old implementation and would be rejected. This is really an ugly solution but would make sure that sender is aware of any possibly incompatibility due to version differences. I guess, due to lack of elegance in b), we should add a recommendation that new applications should use an AVP to indicate the version used by a node. Actually, I even think that there should be a generic AVP defined for this purpose. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 10 19:00: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 1IJdT1-0008S8-NI; Fri, 10 Aug 2007 19:00:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJdSy-0008Rq-Pu; Fri, 10 Aug 2007 19:00:24 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJdSx-0001KT-Fm; Fri, 10 Aug 2007 19:00:24 -0400 Received: from [88.233.199.213] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IJdSp3z3s-0006TB; Fri, 10 Aug 2007 19:00:21 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Subject: RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Sat, 11 Aug 2007 02:00:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-ID: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/OnfAUvYY9K9xYl0rnh5GqSvkj/NgRYMI09xX ZjhG7mCIydbhyPw4dAKp4c97TCuZBbMZsFTQHxJL4US2FwbBs3 xuElbvzgt5+Zk7xanM0IA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip4@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 Pete, > > 2. The point here is not about Diameter as an AAA protocol, however, > > it is about the concept of coupling the MIPv4 control signaling to > > AAA signaling. Which many people do not think it is a good idea and > > believe that it is a deviation from RFC3344 initial MIPv4 > > registration procedure. Do not you agree? > > No, I don't. Putting the Registration Request in the AMR is a feature. > It allows the registration to happen in one round-trip. Obviously it is a feature. But don't you think it is a bit of a hack? I mean, tunneling one protocol inside another for the sake of saving round-trips? For example, we could further reduce the round-trips by tunneling MIP4 inside EAP of network access authentication. I also understand that having to go to HAAA twice for each MIP RegReq is bothersome. But then, maybe we should re-consider the necessity of MN-FA authentication. Given that HA is going to authenticate the MN, does FA also need to do the same? Alper _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 12 10:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKEVk-00007L-OK; Sun, 12 Aug 2007 10:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKEVj-0008UG-8L for dime@ietf.org; Sun, 12 Aug 2007 10:33:43 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKEVi-0004Lx-Od for dime@ietf.org; Sun, 12 Aug 2007 10:33:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Aug 2007 10:34:55 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Dime] Comments on section 1.2 of draft-ietf-dime-rfc3588bis-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 Please find below my comments on the extensibility section in 3588bis: * Section 1.2: Bulleted list is missing "Creating new commands". * Section 1.2: Suggested rewording of last paragraph and removing command code comments (new section proposed below for commands): Reuse of existing AVP values, AVPs, commands and Diameter applications are strongly recommended. Reuse simplifies=20 standardization and implementation and avoids potential=20 interoperability issues. =20 * Section 1.2.1: Second paragraph is incorrect for vendor-specific AVP values. Suggest rewording to: In order to allocate a new value for a standards track AVP, a request MUST be sent to IANA [RFC2434], along with an explanation of the=20 new AVP value. IANA considerations for AVP values are discussed in Section 11.4. * Section 1.2.2: Suggest rewording the first paragraph to include a recommendation on derived data type usage:=20 When no existing AVP can be reused, a new AVP MUST be created. =20 The new AVP MUST be defined using one of the data types listed in Section 4.2 or 4.3. If an appropriate derived data type is already defined, it SHOULD be used instead of the base data type. I considered tightening this last sentence to a MUST but realized RADIUS/Diameter Translation Nodes could not be compliant. The Design Guidelines draft should probably explain this exception to the rule. * Section 1.2.2: Suggest rewording the second paragraph to use a requirement key word: In the event that a logical grouping of AVPs is necessary, and multiple "groups" are possible in a given command, a Grouped AVP=20 SHOULD be used (see Section 4.4). * Section 1.2.2: Second paragraph is incorrect for vendor-specific AVPs. Suggest rewording to: In order to create a new standards track AVP, a request MUST be sent=20 to IANA with a reference to the specification that defines the AVP. =20 IANA considerations for AVPs are discussed in Section 11.1.1. * Section 1.2.2: I suggest removing the sentence requiring that the IANA request include the commands that make use of the AVP. For me, this implies that the IANA AVP entry must be updated every time an AVP is reused. * Section 1.2.x: Add new section on the creation of new commands: 1.2.x Creating new Commands A new command should only be created when no suitable command can=20 be reused from an existing application. In order to create a new command,=20 a request MUST be sent to IANA. The IANA considerations for commands=20 are discussed in Section 11.2.1. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 08:10: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 1IKYkp-0008BT-6k; Mon, 13 Aug 2007 08:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYkn-0008BM-LC for dime@ietf.org; Mon, 13 Aug 2007 08:10:37 -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 1IKYkn-0002sS-98 for dime@ietf.org; Mon, 13 Aug 2007 08:10:37 -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 l7DCAC13002645; Mon, 13 Aug 2007 08:10:12 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C04A24.6040502@tari.toshiba.com> Date: Mon, 13 Aug 2007 08:10:12 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Comments on section 1.2 of draft-ietf-dime-rfc3588bis-05 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: 92df29fa99cf13e554b84c8374345c17 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 for the comments. > * Section 1.2: Bulleted list is missing "Creating new commands". > Ok. > * Section 1.2: Suggested rewording of last paragraph and removing > command code comments (new section proposed below for commands): > > Reuse of existing AVP values, AVPs, commands and Diameter > applications are strongly recommended. Reuse simplifies > standardization and implementation and avoids potential > interoperability issues. > Ok. > * Section 1.2.1: Second paragraph is incorrect for vendor-specific AVP > values. Suggest rewording to: > > In order to allocate a new value for a standards track AVP, a request > MUST be sent to IANA [RFC2434], along with an explanation of the > new AVP value. IANA considerations for AVP values are discussed in > Section 11.4. > > Sure. > * Section 1.2.2: Suggest rewording the first paragraph to include a > recommendation on derived data type usage: > > When no existing AVP can be reused, a new AVP MUST be created. > The new AVP MUST be defined using one of the data types listed in > Section 4.2 or 4.3. If an appropriate derived data type is already > defined, it SHOULD be used instead of the base data type. > Ok. > > * Section 1.2.2: Second paragraph is incorrect for vendor-specific AVPs. > Suggest rewording to: > > In order to create a new standards track AVP, a request MUST be sent > to IANA with a reference to the specification that defines the AVP. > IANA considerations for AVPs are discussed in Section 11.1.1. > Ok. > * Section 1.2.x: Add new section on the creation of new commands: > > 1.2.x Creating new Commands > > A new command should only be created when no suitable command can > be reused from an existing application. In order to create a new > command, > a request MUST be sent to IANA. The IANA considerations for commands > are discussed in Section 11.2.1. > Sure. Though this maybe to terse. We can re-hash a little bit. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 08:18:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYrw-0007yE-8F; Mon, 13 Aug 2007 08:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKYrv-0007y8-CX for dime@ietf.org; Mon, 13 Aug 2007 08:17:59 -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 1IKYrv-00039h-05 for dime@ietf.org; Mon, 13 Aug 2007 08:17:59 -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 l7DCHa5e002716; Mon, 13 Aug 2007 08:17:36 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C04BDF.3070803@tari.toshiba.com> Date: Mon, 13 Aug 2007 08:17:35 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Tolga, Thanks for the comments. I'll incorporate editorial comments 1 through 4 below. > > 1) > 4.1.2 Deleting a command > In general, it is unusual to delete an existing command from an existing > application for > ^^^^^^^^^^^ > ADD > > This design decision would normally be an indication of a flawed > designed. > ==> This normally would be an indication of a flawed design. > > 2) > 4.2 Reusing existing commands > In some cases, there are a lot of ambiguity. > ==> In some cases there is a lot of ambiguity. > > So design considerations have been outlined to ease process. > ^ > ADD > > 3) > 4.2.1 Adding AVPs to a command > A mandatory AVP cannot be added > ^^^ > ADD > > 4) > 4.2.2 Deleting AVPs from a command > Instead of deleting AVPs from a command, a better alternative > ^^^^^^^^^^^^^^^^^^^ > ADD > > 5) > 6.3 Updating an existing application > "Optional AVPs can also be used to indicate version differences." > I think, using an *optional* AVP for this purpose could be problematic. > I can think of two different cases here: > a) An application has a mandatory AVP from very beginning on to indicate > version. In such a case, a new version can be safely signaled to > entities running an older version of the application. Because semantics > associated with the Version-AVP are defined by the initial release of > the application, all nodes would be able to interpret it successfully. > An older version implementation can reject a request containing a > Version-AVP with a newer value. > b) The new release of the application uses a new and mandatory AVP. This > would mean that a new command needs to be defined as well. New command > would not be recognized by the old implementation and would be rejected. > This is really an ugly solution but would make sure that sender is aware > of any possibly incompatibility due to version differences. > > I guess, due to lack of elegance in b), we should add a recommendation > that new applications should use an AVP to indicate the version used by > a node. Actually, I even think that there should be a generic AVP > defined for this purpose. > Sure. We may also consider the case where the initial version does not have a "version-avp" but the new version introduces it. In which case, the *optional* avp method maybe applicable to the "vesion-avp" to make the application inter operate with the old version. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 09:25: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 1IKZuw-0008Rk-Ob; Mon, 13 Aug 2007 09:25:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKZuv-0008Rc-Q9 for dime@ietf.org; Mon, 13 Aug 2007 09:25:09 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKZuv-00056U-Co for dime@ietf.org; Mon, 13 Aug 2007 09:25:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Date: Mon, 13 Aug 2007 09:27:22 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" , "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Tolga, Victor, Regarding the application version, I think there is more than optional/ mandatory AVPs involved. By adding application versions, we are effectively saying that the peer capability wrt a specific application is now defined by the Application ID AND Application Version. This implies that the Application Version needs to be exchanged in CER/CEA messages.=20 Since Application ID is a secondary key field for routing table lookups, the version also needs to be considered in routing decisions. Command routing performance will be impacted if peers must scan messages for Application Version AVPs. Ideally, the Application Version needs to be in the Diameter header but I don't see any way to add it while maintaining backwards compatibility. Given these challenges, maybe it is simpler to state that designers MUST request a new Application ID when they revise their application. Apart from using up additional IDs, do you see any downsides with this approach? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 09:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaKj-0001Bq-Pr; Mon, 13 Aug 2007 09:51:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKaKi-00018s-MJ for dime@ietf.org; Mon, 13 Aug 2007 09:51: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 1IKaKi-0005wr-9R for dime@ietf.org; Mon, 13 Aug 2007 09:51:48 -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 l7DDpkKv002955; Mon, 13 Aug 2007 09:51:46 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C061F2.8050706@tari.toshiba.com> Date: Mon, 13 Aug 2007 09:51:46 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.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: b19722fc8d3865b147c75ae2495625f2 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, > By adding application versions, we are effectively saying that the peer > capability wrt a specific application is now defined by the Application > ID AND Application Version. This implies that the Application Version > needs to be exchanged in CER/CEA messages. > Mmm... not sure if this is necessary. The context of the versioning scheme in discussion is a corner case scenario that is confined within the application and hence the application id is not necessarily required to change. > Since Application ID is a secondary key field for routing table lookups, > the version also needs to be considered in routing decisions. Command > routing performance will be impacted if peers must scan messages for > Application Version AVPs. Ideally, the Application Version needs to be > in the Diameter header but I don't see any way to add it while > maintaining backwards compatibility. > Again, the knowledge of versioning is confined within an application; there should be no routing states or changes involved. Just to give a background, this section on versioning is present in the app guide to shed light on how one can do versioning within a specific application if the change is not significant enough to warrant defining a new application. Other SDOs have defined very ad-hoc ways of going from one version of the same application to the next without formally defining a scheme and this is intended to show the bad consequence of those decisions. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 10:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKalN-00040V-9j; Mon, 13 Aug 2007 10:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKalL-00040Q-FG for dime@ietf.org; Mon, 13 Aug 2007 10:19:19 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKalK-0006Iv-5n for dime@ietf.org; Mon, 13 Aug 2007 10:19:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Date: Mon, 13 Aug 2007 10:21:31 -0400 Message-ID: In-Reply-To: <46C061F2.8050706@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> <46C061F2.8050706@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > Mmm... not sure if this is necessary. The context of the versioning=20 > scheme in discussion is a corner case scenario that is=20 > confined within=20 > the application and hence the application id is not=20 > necessarily required=20 > to change. >=20 Thanks Victor. I re-read section 5.5 and I understand this scenario better.=20 If I understand correctly, the application has changed but the enhancements are 'optional to understand', i.e. the new application version is backwards compatible. The version/capability AVP is used to communicate support of these enhancements between end-points and so intermediate relays are not impacted. Is that correct? Regards Mark=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 10:46: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 1IKbBE-0007eF-Bu; Mon, 13 Aug 2007 10:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbBD-0007eA-5N for dime@ietf.org; Mon, 13 Aug 2007 10:46:03 -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 1IKbBC-00076T-TE for dime@ietf.org; Mon, 13 Aug 2007 10:46:03 -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 l7DEjZjw003160; Mon, 13 Aug 2007 10:45:35 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C06E8F.4040504@tari.toshiba.com> Date: Mon, 13 Aug 2007 10:45:35 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> <46C061F2.8050706@tari.toshiba.com> 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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, > If I understand correctly, the application has changed but the > enhancements are 'optional to understand', i.e. the new application > version is backwards compatible. The version/capability AVP is used to > communicate support of these enhancements between end-points and so > intermediate relays are not impacted. Is that correct? > Yup. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 11:15:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbdM-0002u5-EV; Mon, 13 Aug 2007 11:15:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbdJ-0002tg-0H; Mon, 13 Aug 2007 11:15:06 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKbdI-0000QO-Hk; Mon, 13 Aug 2007 11:15:04 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1187018098!4657528!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 19560 invoked from network); 13 Aug 2007 15:14:58 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-15.tower-153.messagelabs.com with SMTP; 13 Aug 2007 15:14:58 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7DFEs3q005519; Mon, 13 Aug 2007 08:14:58 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7DFEqGE028910; Mon, 13 Aug 2007 10:14:53 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7DFEpET028877; Mon, 13 Aug 2007 10:14:52 -0500 (CDT) 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] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Mon, 13 Aug 2007 11:14:50 -0400 Message-ID: In-Reply-To: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkA= References: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip4@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 Alper Yegin wrote: > Pete, >> No, I don't. Putting the Registration Request in the AMR is a >> feature. It allows the registration to happen in one round-trip. >=20 > Obviously it is a feature. But don't you think it is a bit of a hack? > I mean, tunneling one protocol inside another for the sake of saving > round-trips? For example, we could further reduce the round-trips by > tunneling MIP4 inside EAP of network access authentication. =20 I don't think it's a hack. When we have Mobile IP being used for access authentication I think it makes sense to carry the RRQ in a Diameter application. EAP is a different case because then we have a separate protocol doing access authentication. > I also understand that having to go to HAAA twice for each MIP RegReq > is bothersome. But then, maybe we should re-consider the necessity of > MN-FA authentication. Given that HA is going to authenticate the MN, > does FA also need to do the same? =20 The FA and HA might be part of different administrative domains. I think the FA has just as much reason to authenticate the MN as the HA. > Alper -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 11:27: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 1IKbpN-0003XV-W8; Mon, 13 Aug 2007 11:27:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbpN-0003XP-08 for dime@ietf.org; Mon, 13 Aug 2007 11:27:33 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbpL-0008NZ-8C for dime@ietf.org; Mon, 13 Aug 2007 11:27:32 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l7DFRNp9061193 for ; Mon, 13 Aug 2007 17:27:23 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Comments for draft-ietf-dime-app-design-guide-02.txt Date: Mon, 13 Aug 2007 17:27:22 +0200 Message-ID: <33656995C5C5094A983DE84DA649A9240195112D@lulex02.ad.operax.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Thread-Index: AcfbjRnjKaOMFrSzTEaP67/my6asJQB9UiKA References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Mon, 13 Aug 2007 17:27:23 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3944/Mon Aug 13 08:12:09 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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, As the comments made by Tolga my comments on draft-dime-app-design-guide-02.txt are mostly editorial. I've got a few comments on what's actually recommended as well though as well as commenst on where I believe the text is somewhat unclear. Anyway, pls find my comments below. Best regards, Ulf Section 1 First bullet item: is the word "updated" really needed. Isn't the obejective to clearify exensibility rules of 2588 in general and not only those being updated in 2588bis? Second bullet intem: Stike out "which are" First paragraph after bullet list: The allusion with "These" is unclear (doesn't ally to any text above this paragraph). I would rather say: "The design gudelines given herein are necessary ...". First paragraph after bullet list, second sentence: A typical example would be deciding between item one(1) and two(2) above when an application designer requires a new application functionality which has many things in common with an existing application. -- change to --> A typical example would be deciding between item one(1) and two(2) above when new application functionality is required that has many things in common with functionality offered by an existing application. First paragraph after bullet list, third sentence: replace "the existing extensibility rules;" with "the original extensibility rules of RFC3588;" First paragraph after bullet list, last sentence: Does not make good sence, should be rephrased. The allusion for "this example" is weak. What does "it" refer to? The existing/original extensibility rules? What did then the existing/original rules say they are now changed/updated. Are the original rules based on collective experiences, or the statement of that creating a new application is now seen as the cleanest approach? A lot of questions - no suggestion unfortunately (since I'm not sure what should be said). Second paragraph after bullet list, second sentence: remove "times", replace "foreseen as" with "considered" Second paragraph after bullet list, last sentence: "(See ..)" -> "(see ..)" Third paragraph after bullet list: The text mention examples and implicitly talks about derived applications are no longer interoperable. In case such examples exist (which I'm sure they do), it may be useful to refernce them for clarity. Section 3 Last sentence: I'm not sure what this sentence is actually saying (or what informaiton it gives). A "Diameter node" is not mentioned before in the paragraph, still it's said that "This document also treats ..." I.e. the word "also" is somewhat ambiguous. Anyway, the meaning and purpose of the sentence is unclear at least to me. Section 4 First paragraph, second sentence: "applications" -> "application", or remove "an" before existing. Second paragraph, first sentence: "application's" -> "applications" Second paragraph, second sentence: ".. much of the existing application ..." -> ".. much of an existing application ..." Section 4.1.1 Fourth bullet item, first sentence: remove space before "?" and introduce space in "maybe" -> "may be" Section 4.2.1 First paragraph after second bullet list, first sentence: "consider" -> "considered" Section 4.2.2 First paragraph, first sentence: ".. is significant when trying to extend an existing application" -> ".. constitutes a significant change when extending and existent application." Second paragraph, second sentence: "..mandatory would.." -> "..mantatory AVPs would.." Third paragraph, first sentence: "..command that would represent.." -> "..command representing.." Fourth paragraph, second sentence: delete "optional" Fourth paragraph, fourth sentence: delete "to begin with" Fifth paragraph: This may be a stupid question, but I wonder if any gudence is needed for how to ignore an optional AVP because it's not used by the application being in use (and instead only has a purpose for the application from which the command in inhereted). That is, is silently ignoring anything ok from an compatibility standpoint ok. Maybe it, I'm just not enough of a Diameter expert to know for sure. Section 4.3 First paragraph, first and second sentence: Delete "deals with even more granularity than Section 4.1 and Section 4.2. Specifically, it" Section 5=20 Second paragraph, first sentence: Are we referring to new _mandatory_ AVPs and AVP values that _changes_ the behaviour of the applicatio, or any new AVP and AVP value? If I understand the rules correctly it's the former only and in case that's correct I suggest clearifying this. E.g. by saying "..new commands, mandatory AVPS and/or AVP values that changes the behaviour of the application for ..." Second paragraph, last sentence: Could the givenm examples be clearified beyond just giving the references? For example, by adding after the last reference ", where ...." Third paragraph, first sentence: "newly defined commands." -> "new commands." Section 5.3 First paragraph, last sentence:=20 Change=20 "However, this scheme is followed to avoid possible routing problems for these messages." to=20 "However, this scheme should be followed to avoid possible routing problems." Section 5.4 Third sentence:=20 Change=20 "The existing session statemachines defined by [1] is not intended for general use beyond AAA services therefore any behavior not covered by that category would not fit well." to=20 "The existing session statemachines defined by [1] is not intended for general use beyond AAA services therefore any behavior not covered by that category may not fit well for the new application." Section 6.1 Second last paragraph, first sentence: delete "obviously" Last paragraph, first sentence: "Additionally," does not seem to apply to anything said before e.g. in the previous paragraph. Henece another start of that sentence may be good to have.=20 -----Original Message----- From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: den 10 augusti 2007 22:29 To: dime@ietf.org Subject: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Hi Victor, Please find below my comments for draft-dime-app-design-guide-02.txt. I think this draft is in very good shape and almost all of my comments are editorial. Thanks, Tolga 1) 4.1.2 Deleting a command In general, it is unusual to delete an existing command from an existing application for ^^^^^^^^^^^ ADD This design decision would normally be an indication of a flawed designed. =3D=3D> This normally would be an indication of a flawed design. 2) 4.2 Reusing existing commands In some cases, there are a lot of ambiguity. =3D=3D> In some cases there is a lot of ambiguity. So design considerations have been outlined to ease process. ^ ADD 3) 4.2.1 Adding AVPs to a command A mandatory AVP cannot be added ^^^ ADD 4) 4.2.2 Deleting AVPs from a command Instead of deleting AVPs from a command, a better alternative ^^^^^^^^^^^^^^^^^^^ ADD 5) 6.3 Updating an existing application "Optional AVPs can also be used to indicate version differences." I think, using an *optional* AVP for this purpose could be problematic. I can think of two different cases here: a) An application has a mandatory AVP from very beginning on to indicate version. In such a case, a new version can be safely signaled to entities running an older version of the application. Because semantics associated with the Version-AVP are defined by the initial release of the application, all nodes would be able to interpret it successfully. An older version implementation can reject a request containing a Version-AVP with a newer value. b) The new release of the application uses a new and mandatory AVP. This would mean that a new command needs to be defined as well. New command would not be recognized by the old implementation and would be rejected. This is really an ugly solution but would make sure that sender is aware of any possibly incompatibility due to version differences. I guess, due to lack of elegance in b), we should add a recommendation that new applications should use an AVP to indicate the version used by a node. Actually, I even think that there should be a generic AVP defined for this purpose. _______________________________________________ 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 Aug 13 12:34: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 1IKcrx-00027l-7K; Mon, 13 Aug 2007 12:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcrv-00027U-RZ for dime@ietf.org; Mon, 13 Aug 2007 12:34:15 -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 1IKcrv-0002E1-2P for dime@ietf.org; Mon, 13 Aug 2007 12:34:15 -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 l7DGXkk7003649; Mon, 13 Aug 2007 12:33:46 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C087EA.4040705@tari.toshiba.com> Date: Mon, 13 Aug 2007 12:33:46 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Ulf Bodin Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> <33656995C5C5094A983DE84DA649A9240195112D@lulex02.ad.operax.com> In-Reply-To: <33656995C5C5094A983DE84DA649A9240195112D@lulex02.ad.operax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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 Ulf, Thanks for the review. > Section 1 > > First bullet item: is the word "updated" really needed. Isn't the > obejective to clearify exensibility rules of 2588 in general and not > only those being updated in 2588bis? > > Second bullet intem: Stike out "which are" > > First paragraph after bullet list: The allusion with "These" is unclear > (doesn't ally to any text above this paragraph). I would rather say: > "The design gudelines given herein are necessary ...". > > First paragraph after bullet list, second sentence: > A typical example would be deciding between item one(1) and two(2) above > when an application designer requires a new application functionality > which has many things in common with an existing application. > -- change to --> > A typical example would be deciding between item one(1) and two(2) above > when new application functionality is required that has many things in > common with functionality offered by an existing application. > > First paragraph after bullet list, third sentence: replace "the existing > extensibility rules;" with "the original extensibility rules of > RFC3588;" > Ok. I'll incorporate all of your suggestions above. > First paragraph after bullet list, last sentence: Does not make good > sence, should be rephrased. The allusion for "this example" is weak. > What does "it" refer to? The existing/original extensibility rules? What > did then the existing/original rules say they are now changed/updated. > Are the original rules based on collective experiences, or the statement > of that creating a new application is now seen as the cleanest approach? > A lot of questions - no suggestion unfortunately (since I'm not sure > what should be said). > > Ok. Maybe we can re-phrase to: "Certain design patterns did emerge from the experiences of application designers. For example, in the case of using optional AVPs to indicate new functionality, it is now generally viewed that the creation of a new application (item two(2)) is a better design approach. " > Second paragraph after bullet list, second sentence: remove "times", > replace "foreseen as" with "considered" > > Second paragraph after bullet list, last sentence: "(See ..)" -> "(see > ..)" > > Ok > Third paragraph after bullet list: The text mention examples and > implicitly talks about derived applications are no longer interoperable. > In case such examples exist (which I'm sure they do), it may be useful > to refernce them for clarity. > Good point. > Section 3 > > Last sentence: I'm not sure what this sentence is actually saying (or > what informaiton it gives). A "Diameter node" is not mentioned before in > the paragraph, still it's said that "This document also treats ..." I.e. > the word "also" is somewhat ambiguous. Anyway, the meaning and purpose > of the sentence is unclear at least to me. > Ok. I think it is safe to remove that sentence since it does not seem to provide any value. > Section 4 > > First paragraph, second sentence: "applications" -> "application", or > remove "an" before existing. > > Second paragraph, first sentence: "application's" -> "applications" > > Second paragraph, second sentence: ".. much of the existing application > ..." -> ".. much of an existing application ..." > > Section 4.1.1 > > Fourth bullet item, first sentence: remove space before "?" and > introduce space in "maybe" -> "may be" > > Section 4.2.1 > > First paragraph after second bullet list, first sentence: "consider" -> > "considered" > > Section 4.2.2 > > First paragraph, first sentence: ".. is significant when trying to > extend an existing application" -> ".. constitutes a significant change > when extending and existent application." > > Second paragraph, second sentence: "..mandatory would.." -> "..mantatory > AVPs would.." > > Third paragraph, first sentence: "..command that would represent.." -> > "..command representing.." > > Fourth paragraph, second sentence: delete "optional" > > Fourth paragraph, fourth sentence: delete "to begin with" > I'm ok with the editorials. > Fifth paragraph: This may be a stupid question, but I wonder if any > gudence is needed for how to ignore an optional AVP because it's not > used by the application being in use (and instead only has a purpose for > the application from which the command in inhereted). That is, is > silently ignoring anything ok from an compatibility standpoint ok. Maybe > it, I'm just not enough of a Diameter expert to know for sure. > In some sense, ignoring optional AVPs are an implied behavior in general. Though, for the application itself, not explicitly stating such behavior may have implications. For example, maybe apps should explicitly differentiate when ignoring an optional avp by choice or because it does not understand the avp. Anyway, maybe some additional text is needed. > Section 4.3 > > First paragraph, first and second sentence: Delete "deals with even more > granularity than Section 4.1 and Section 4.2. Specifically, it" > > Section 5 > > Second paragraph, first sentence: Are we referring to new _mandatory_ > AVPs and AVP values that _changes_ the behaviour of the applicatio, or > any new AVP and AVP value? If I understand the rules correctly it's the > former only and in case that's correct I suggest clearifying this. E.g. > by saying "..new commands, mandatory AVPS and/or AVP values that changes > the behaviour of the application for ..." > Good point. we can clarify that. > Second paragraph, last sentence: Could the givenm examples be clearified > beyond just giving the references? For example, by adding after the last > reference ", where ...." > Ok sure. we can further clarify the text. > Third paragraph, first sentence: "newly defined commands." -> "new > commands." > > Section 5.3 > > First paragraph, last sentence: > Change > "However, this scheme is followed to avoid possible routing problems for > these messages." to > "However, this scheme should be followed to avoid possible routing > problems." > > Section 5.4 > > Third sentence: > Change > "The existing session statemachines defined by [1] is not intended for > general use beyond AAA services therefore any behavior not covered by > that category would not fit well." to > "The existing session statemachines defined by [1] is not intended for > general use beyond AAA services therefore any behavior not covered by > that category may not fit well for the new application." > > Section 6.1 > > Second last paragraph, first sentence: delete "obviously" > > Last paragraph, first sentence: "Additionally," does not seem to apply > to anything said before e.g. in the previous paragraph. Henece another > start of that sentence may be good to have. > Ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 14:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeGr-00007Y-TM; Mon, 13 Aug 2007 14:04:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeGr-00007T-1S for dime@ietf.org; Mon, 13 Aug 2007 14:04:05 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKeGp-0007KK-Nb for dime@ietf.org; Mon, 13 Aug 2007 14:04:04 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1187028237!14235829!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9519 invoked from network); 13 Aug 2007 18:03:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 13 Aug 2007 18:03:57 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7DI3vu6006289 for ; Mon, 13 Aug 2007 11:03:57 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7DI3uDY008132 for ; Mon, 13 Aug 2007 13:03:56 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7DI3sTK008120 for ; Mon, 13 Aug 2007 13:03:55 -0500 (CDT) 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] QoS Application Review Date: Mon, 13 Aug 2007 14:03:53 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E702DF26@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] QoS Application Review Thread-Index: AcfXudwqxDV2fHsnR1qRYHut1cL9KgBenZEQ References: <033458F56EC2A64E8D2D7B759FA3E7E702DF26@sonusmail04.sonusnet.com> From: "McCann Peter-A001034" To: "Asveren, Tolga" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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, Tolga, Thanks for the detailed review. Sorry for taking this long to respond. See some comments from me below. Asveren, Tolga wrote: > Please find below my comments after an initial review of QoS > application draft. I tried to list first the generic > comments/questions and then the ones which are corresponding to > specific sections. =20 >=20 > Thanks, > Tolga >=20 > 1- As indicated during IETF69 Dime sessions as well, more explanation > is necessary for push mode operation; particularly state machines and > explanation of the procedures at each step of the operation. IMHO, > push and pull modes seem different enough to justify two different > applications. =20 That might be a good idea; however, as was mentioned during the WG meeting it may be possible to use both modes during a single session, where some NEs use push mode and some NEs use pull mode. If we allow that, it might make more sense to keep a single application. > 2- An explanation of how failure scenarios need to be handled could > be useful.=20 Ok. > 3- I feel like Credit Control Application (CCA) is what we need for > pull mode. Functionality currently defined in the document is quite > similar to it. Is the reason, why CCA is not used, addition of new > AVPs with M-bit set to CCA commands?=20 We didn't see the need to include CCA commands; all the credit-control information is contained in the QAR/QAA. The approach in the draft is much simpler than the CCA and IMHO in contains all the needed functionality. > I guess, even in this case, one > approach is referencing CCA and just defining new commands (with new > command codes and the new AVPs) and linking them to CCA commands in > terms of semantics (with semantics of the new AVPs explained in QoS > document).=20 That's essentially what we did; we re-used the Cost-Information, Cost-Unit, Tariff-Time-Change, and CC-Time AVPs within the Diameter QoS commands but provided a much simpler framework in which to work. > If not all flexibility provided by CCA is necessary, this > could be indicated as well. I will start a new thread about this > (what to do if one wants to reuse an existing application -because > the semantics provided by that application are a good match- but > wants to add a few new AVPs with M-bit set) regarding its impact on > Application Design Guideline work. =20 Ok let's talk about this. IMHO the commands in the Diameter QoS application are the ones we want to use. > 4- I think for push mode, the direction in the draft is the right > one, i.e. using new messages to install QoS reservation.=20 Ok. > 5- I guess we should cover how emergency sessions are to be handled. > I didn't check whether there is an already suitable AVP for this but > some AVP identifying the priority of the QoS request could be useful > (and semantics about its use should be defined as well) =20 I suppose we might need such an AVP either in QAA or QIR, in the case where the Authorizing Entity knows about the emergency status; Alternatively, such a field could be added to NSIS if only the AE knows about the emergency status. I am not sure whether=20 such a field exists in NSIS - maybe experts could speak up? > 6- Especially for push mode, there should be a way for NE to signal > loss of an existing reservation. This mechanism should allow > signaling of loss of a single flow in a session with multiple flows. =20 Are you thinking that the NE might be monitoring the flow for active traffic, and then timeout when it detects no packets for a certain period of time? We need to watch out for confusing loss of bearer with silence suppression. Maybe you have in mind that some specific link-layer trigger that tears-down the flow. In general, we also may want to react to NSIS signaling that "politely" tears down a flow. If we keep every flow as a different Diameter QoS session, it should be possible to terminate them independently. Hopefully we can just use STR / ASR for termination. > 7- Some section about different use cases could be a good idea, e.g > interaction between different organizations in different scenarios, > NAT traversal issues etc.. It could be an idea to have this as a > separate document. =20 Ok let's think about this. > 8- > 1. Introduction > "However, when bandwidth is scarce and must be carefully managed, > such as in cellular networks, or when applications and transport > protocols lack the capability to perform end-to-end congestion > control, explicit reservation techniques are required." =20 > Why is end-to-end mechanisms not suitable for the first case ("when > bandwidth resources are scarce")?=20 I see your point - maybe we can remove that clause. > 9- > 2. Terminology > "Application Server >=20 > An application server is a network entity that exchanges signaling > messages with an application endpoint. It may be a source of > authorization for QoS-enhanced application flows. For example, a SIP > server is one kind of application server." =20 > I don't think SIP server is the right terminology for that type of > functionality. SIP Application Server or SIP proxy seems to be a > better example. =20 I am ok with "SIP Application Server." > 10- > 2. Terminology > "Application Endpoint >=20 > An application endpoint is an entity in an end user device that > exchanges signaling messages with application servers or directly > with other application endpoints. Based on the result of this > signaling, the endpoint may make a request for QoS from the network.=20 > For example, a SIP User Agent is one kind of application endpoint." =20 > Is it mandatory for Application Endpoint to initiate application > signaling before asking for QoS in an end-to-end fashion?=20 I think the application negotiation (what codec to use etc.) needs to complete before a properly formed NSIS reservation is made. So at least, the signaling must have started before a request=20 can be made. If you look at the SIP Preconditions RFC that's where RSVP signaling is traditionally integrated. > 11- > 2. Terminology > Network Element > Could be an entity different than a QoS aware router as well, e.g. a > cable modem termination system.=20 If a given NE is not an IP-addressable entity then it can't participate in path-coupled signaling. My preference would=20 be to keep the notion of a NE =3D Router. > 12- > 2. Terminology > Network Element > "For almost all scenarios this entity triggers the protocol > interaction described in this document."=20 > This sentence ignores push model; "for almost all scenarios" is too > strong.=20 Ok, we can take this out. > 13- > 2. Terminology > "Push Mode > In this mode, the QoS authorization process is invoked by the request > from Application Server or local policies in the Authorizing Entity."=20 > What does "local policies" refer to? What is a real life example for > this? Does it refer to something like installing filters statically?=20 I think this has to do with some confusion about the role of the Authorizing Entity. In my mind the Authorizing Entity equals either a home subscriber database or an Application Server. In some people's mind the AE is a local PDF which communicates over a separate entity to an Application Server. I'd be ok with removing "Application Server or local policies in" from the sentence. > 14- > 3. Framework > Should cover push model as well. Ok. > 15- > 3. Framework > "If defined properly, the interface between the routers and AAA cloud > would be identical in both cases."=20 > Does this refer to using the same interface for push and pull modes? > If so, I guess it is not true, we use different messages.=20 It refers to using the same interface whether the AE is a static subscriber database or an active Application Server. We should=20 clarify. > 16- > 3.2.2 > When listing what mode is suitable for which type of network, > discussing the reasons rather than just listing the names could be > better (or just deleting that part completely). =20 I'd be ok with deleting it. Dong may have a different opinion. > 17- > 3.3.1 > "With the 'Two party scheme' the QoS > resource requesting entity is authenticated by the Network Element > and the authorization decision is made either locally at the Network > Element itself or offloaded to a trusted entity (most likely within > the same administrative domain). In the former case no Diameter QoS > protocol interaction is required." =20 > Why is QoS protocol interaction necessary for the latter case? I > thought this would be completely independent of QoS reservation > itself. =20 In the latter case there is a protocol needed between the NE and the "trusted entity". In the draft that is assumed to be the Diameter QoS Application. However, this is not really two-party scheme anymore... I'd be ok with removing that part. > 18- > Figure 4 > I would think that an explicit "Authorization Token Request" is > optional and such a token could be included in application signaling > based on configuration/policy. It could be a good idea to clarify > this in the text or in the figure. =20 It is necessary for the NE to be able to fill in the Destination-Realm field for proper routing of the QAR (pull mode) or for the Application Server to fill in the Destination-Realm of the QIR (push mode). Thus something needs to be exchanged in the application signaling; a "token" is an ok name for that, IMHO. Maybe we can improve the wording a bit here. > 19- > 3.3.2 > The distinction between "endpoint initiated" and "network initiated" > seems a bit artificial to me. At the end, it is *something* signaled > by endpoint (or is the idea application server reserving QoS out of > the blue?), which triggers the QoS reservation. The level of > explicitness of QoS information in that signal doesn't really matter > much from QoS application perspective. =20 I agree. > 20- > 4.1 > Parties Involved > "Note that the QoS resource requesting entity is only indirectly > involved in the message exchange. This entity provides the trigger > to initiate the Diameter QoS protocol interaction by transmitting QoS > signaling messages." =20 > I guess this part is ignoring push mode. The trigger could be > application signaling from which corresponding QoS parameters can be > extracted. =20 Agreed. We should re-word. > 21- > 4.2 > Diameter QoS Authorization Session Establishment "A > Signaling-session-Id (if=20 > present) SHOULD be used together with the generated Acc-Multi- > Session-Id AVP (see Section 7.3) for binding the authorization and > the accounting session information in case of end host mobility > (i.e., to correlate the Diameter sessions that are initiated for the > same signaling session from different QoS NE)." =20 > I think we first need to define the semantics how mobility is going > to work in such a case. For example, if the new NE is controlled by > another organization, how would be the interaction with the initial > NE? =20 Need to think about this one some more. > 22- > IMHO, DIAMETER_SUCCESS instead of DIAMETER_LIMITED_SUCCESS could be > used. The expected message flow/behavior is already defined as parts > of the procedures. Upon receipt of DIAMETER_SUCCESS, the requesting > entity would know what it needs to do next. =20 Ok with me. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 16:09: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 1IKgEL-0002De-5l; Mon, 13 Aug 2007 16:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgEJ-0002DN-LO; Mon, 13 Aug 2007 16:09:35 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgEI-0003v3-Cp; Mon, 13 Aug 2007 16:09:35 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IKgE83oi3-0006T1; Mon, 13 Aug 2007 16:09:31 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Subject: RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Mon, 13 Aug 2007 23:09:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwA== Message-ID: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19fC2x2NKL72qVIdu4/WvhQ2zOcOyYIt7qmcO1 4NBusH9iDo/IaWbxr7pi7854sFkaeZWDmKdk0bHotxxucHT2OK KGwxAG9vneq5FFaVvx8XQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip4@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 Pete, > >> No, I don't. Putting the Registration Request in the AMR is a > >> feature. It allows the registration to happen in one round-trip. > > > > Obviously it is a feature. But don't you think it is a bit of a hack? > > I mean, tunneling one protocol inside another for the sake of saving > > round-trips? For example, we could further reduce the round-trips by > > tunneling MIP4 inside EAP of network access authentication. > > I don't think it's a hack. When we have Mobile IP being used > for access authentication I think it makes sense to carry the > RRQ in a Diameter application. EAP is a different case because > then we have a separate protocol doing access authentication. Using a mobility protocol's AAA for network access AAA is another hack, IMHO. These are two separate services. That may explain why one protocol is tunneled inside another, but it does not justify. I understand these are all driven by performance improvements. > > I also understand that having to go to HAAA twice for each MIP RegReq > > is bothersome. But then, maybe we should re-consider the necessity of > > MN-FA authentication. Given that HA is going to authenticate the MN, > > does FA also need to do the same? > > The FA and HA might be part of different administrative domains. > I think the FA has just as much reason to authenticate the MN as > the HA. MN is authenticated by the same entity (HAAA) whether requested by the FA or the HA. If HA and FA has some trust relationship (e.g., using FA-HA AE, or IPsec), then I believe letting the HA authenticate the MN is sufficient. Alper > > > Alper > > -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 16:32: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 1IKgaV-00035l-UU; Mon, 13 Aug 2007 16:32:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgaS-00034c-Hq; Mon, 13 Aug 2007 16:32:28 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKgaS-0005qk-0y; Mon, 13 Aug 2007 16:32:28 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1187037146!5492512!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1640 invoked from network); 13 Aug 2007 20:32:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 13 Aug 2007 20:32:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7DKWQMG027167; Mon, 13 Aug 2007 13:32:26 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l7DKWPJl019990; Mon, 13 Aug 2007 15:32:25 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7DKWOrL019969; Mon, 13 Aug 2007 15:32:25 -0500 (CDT) 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] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Mon, 13 Aug 2007 16:32:23 -0400 Message-ID: In-Reply-To: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQA References: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip4@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 Alper Yegin wrote: > Pete, >> >> I don't think it's a hack. When we have Mobile IP being used for >> access authentication I think it makes sense to carry the RRQ in a >> Diameter application. EAP is a different case because then we have a >> separate protocol doing access authentication. >=20 > Using a mobility protocol's AAA for network access AAA is another > hack, IMHO. These are two separate services. That may explain why one > protocol is tunneled inside another, but it does not justify. =20 Well, this is the road we went down back in 1998. There is at least one SDO that is heavily dependent on the MN-NAI and MN-AAA extensions. =20 > I understand these are all driven by performance improvements. Yes. =20 >> The FA and HA might be part of different administrative domains. >> I think the FA has just as much reason to authenticate the MN as the >> HA. >=20 > MN is authenticated by the same entity (HAAA) whether requested by > the FA or the HA. If HA and FA has some trust relationship (e.g., > using FA-HA AE, or IPsec), then I believe letting the HA authenticate > the MN is sufficient. =20 There is no scalable way to maintain trust relationships between all pairs of (FA, HA). One of the main purposes of the Diameter MIPv4 application is to distribute keys for those (FA, HA) relationships that are necessary based on the MNs that are roaming to a given FA. The FA needs to make sure that the visited resources will be paid for, which is why it needs=20 authorization from the AAA infrastructure. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 13 18:58: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 1IKis9-0006j1-Dc; Mon, 13 Aug 2007 18:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKis8-0006ic-4B; Mon, 13 Aug 2007 18:58:52 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKis6-0002Bx-QK; Mon, 13 Aug 2007 18:58:52 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IKirz3qBP-0006SO; Mon, 13 Aug 2007 18:58:49 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Subject: RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Tue, 14 Aug 2007 01:58:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAA= Message-ID: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/Gw/cVkVE31tMl447aVzQOIsrP/vexHOJ1iIy 6h4zxh+wD86hEAf5LrJ+xAh/ams981D/G8RzP4m4FSCcNf8JYk XTnR2cKd42sBHr8Sc0aVQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@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 > > MN is authenticated by the same entity (HAAA) whether requested by > > the FA or the HA. If HA and FA has some trust relationship (e.g., > > using FA-HA AE, or IPsec), then I believe letting the HA authenticate > > the MN is sufficient. > > There is no scalable way to maintain trust relationships between > all pairs of (FA, HA). One of the main purposes of the Diameter > MIPv4 application is to distribute keys for those (FA, HA) > relationships that are necessary based on the MNs that are > roaming to a given FA. The FA needs to make sure that the > visited resources will be paid for, which is why it needs > authorization from the AAA infrastructure. FA-HA security association can also be dynamically created during the network access authentication procedure. Alper _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 14 02:41:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKq68-0003I5-ER; Tue, 14 Aug 2007 02:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKq67-0003Dm-D5 for dime@ietf.org; Tue, 14 Aug 2007 02:41:47 -0400 Received: from smtp.operax.com ([213.50.74.226] helo=smtp-dmz.operax.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKq65-0006Dh-LK for dime@ietf.org; Tue, 14 Aug 2007 02:41:47 -0400 Received: from lulex02.ad.operax.com (ad.operax.com [192.168.2.13]) by smtp-dmz.operax.com (8.13.1/8.13.1) with ESMTP id l7E6fc0l068415 for ; Tue, 14 Aug 2007 08:41:38 +0200 (CEST) (envelope-from Ulf.Bodin@operax.com) 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] Comments for draft-ietf-dime-app-design-guide-02.txt Date: Tue, 14 Aug 2007 08:41:37 +0200 Message-ID: <33656995C5C5094A983DE84DA649A92401951165@lulex02.ad.operax.com> In-Reply-To: <46C087EA.4040705@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Thread-Index: Acfdx9C3orRDDYImTAeLyyoOyFExdwAdQaPQ References: <033458F56EC2A64E8D2D7B759FA3E7E7188125@sonusmail04.sonusnet.com> <33656995C5C5094A983DE84DA649A9240195112D@lulex02.ad.operax.com> <46C087EA.4040705@tari.toshiba.com> From: "Ulf Bodin" To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp-dmz.operax.com [172.16.1.4]); Tue, 14 Aug 2007 08:41:38 +0200 (CEST) X-Spam-Status: No, score=-152.6 required=4.7 tests=ALL_TRUSTED,BAYES_00, USER_IN_BLACKLIST,USER_IN_WHITELIST autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on smtp-dmz.operax.com X-Virus-Scanned: ClamAV 0.88.7/3956/Tue Aug 14 06:52:09 2007 on smtp-dmz.operax.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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,=20 Pls find by replies below.=20 BR Ulf=20 -----Original Message----- From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 Sent: den 13 augusti 2007 18:34 To: Ulf Bodin Cc: dime@ietf.org Subject: Re: [Dime] Comments for draft-ietf-dime-app-design-guide-02.txt Hi Ulf, Thanks for the review. > Section 1 > > First bullet item: is the word "updated" really needed. Isn't the=20 > obejective to clearify exensibility rules of 2588 in general and not=20 > only those being updated in 2588bis? > > Second bullet intem: Stike out "which are" > > First paragraph after bullet list: The allusion with "These" is=20 > unclear (doesn't ally to any text above this paragraph). I would rather say: > "The design gudelines given herein are necessary ...". > > First paragraph after bullet list, second sentence: > A typical example would be deciding between item one(1) and two(2)=20 > above when an application designer requires a new application=20 > functionality which has many things in common with an existing application. > -- change to --> > A typical example would be deciding between item one(1) and two(2)=20 > above when new application functionality is required that has many=20 > things in common with functionality offered by an existing application. > > First paragraph after bullet list, third sentence: replace "the=20 > existing extensibility rules;" with "the original extensibility rules=20 > of RFC3588;" > =20 Ok. I'll incorporate all of your suggestions above. > First paragraph after bullet list, last sentence: Does not make good=20 > sence, should be rephrased. The allusion for "this example" is weak. > What does "it" refer to? The existing/original extensibility rules?=20 > What did then the existing/original rules say they are now changed/updated. > Are the original rules based on collective experiences, or the=20 > statement of that creating a new application is now seen as the cleanest approach? > A lot of questions - no suggestion unfortunately (since I'm not sure=20 > what should be said). > > =20 Ok. Maybe we can re-phrase to: "Certain design patterns did emerge from the experiences of application designers. For example, in the case of using optional AVPs to indicate new functionality, it is now generally viewed that the creation of a new application (item two(2)) is a better design approach. " [Ulf1: Yes.] > Second paragraph after bullet list, second sentence: remove "times",=20 > replace "foreseen as" with "considered" > > Second paragraph after bullet list, last sentence: "(See ..)" -> "(see > ..)" > > =20 Ok > Third paragraph after bullet list: The text mention examples and=20 > implicitly talks about derived applications are no longer interoperable. > In case such examples exist (which I'm sure they do), it may be useful > to refernce them for clarity. > =20 Good point. > Section 3 > > Last sentence: I'm not sure what this sentence is actually saying (or=20 > what informaiton it gives). A "Diameter node" is not mentioned before=20 > in the paragraph, still it's said that "This document also treats ..." I.e. > the word "also" is somewhat ambiguous. Anyway, the meaning and purpose > of the sentence is unclear at least to me. > =20 Ok. I think it is safe to remove that sentence since it does not seem to provide any value. > Section 4 > > First paragraph, second sentence: "applications" -> "application", or=20 > remove "an" before existing. > > Second paragraph, first sentence: "application's" -> "applications" > > Second paragraph, second sentence: ".. much of the existing=20 > application ..." -> ".. much of an existing application ..." > > Section 4.1.1 > > Fourth bullet item, first sentence: remove space before "?" and=20 > introduce space in "maybe" -> "may be" > > Section 4.2.1 > > First paragraph after second bullet list, first sentence: "consider"=20 > -> "considered" > > Section 4.2.2 > > First paragraph, first sentence: ".. is significant when trying to=20 > extend an existing application" -> ".. constitutes a significant=20 > change when extending and existent application." > > Second paragraph, second sentence: "..mandatory would.." ->=20 > "..mantatory AVPs would.." > > Third paragraph, first sentence: "..command that would represent.." -> > "..command representing.." > > Fourth paragraph, second sentence: delete "optional" > > Fourth paragraph, fourth sentence: delete "to begin with" > =20 I'm ok with the editorials. > Fifth paragraph: This may be a stupid question, but I wonder if any=20 > gudence is needed for how to ignore an optional AVP because it's not=20 > used by the application being in use (and instead only has a purpose=20 > for the application from which the command in inhereted). That is, is=20 > silently ignoring anything ok from an compatibility standpoint ok.=20 > Maybe it, I'm just not enough of a Diameter expert to know for sure. > =20 In some sense, ignoring optional AVPs are an implied behavior in general. Though, for the application itself, not explicitly stating such behavior may have implications. For example, maybe apps should explicitly differentiate when ignoring an optional avp by choice or because it does not understand the avp. Anyway, maybe some additional text is needed. [Ulf1: Yes, I think such text would actually be useful. Especially if an application is to differentiate between ignoring an optional AVP by choice or because it does not understand the AVP (e.g. in reporting this back to a requester).] > Section 4.3 > > First paragraph, first and second sentence: Delete "deals with even=20 > more granularity than Section 4.1 and Section 4.2. Specifically, it" > > Section 5 > > Second paragraph, first sentence: Are we referring to new _mandatory_=20 > AVPs and AVP values that _changes_ the behaviour of the applicatio, or > any new AVP and AVP value? If I understand the rules correctly it's=20 > the former only and in case that's correct I suggest clearifying this. E.g. > by saying "..new commands, mandatory AVPS and/or AVP values that=20 > changes the behaviour of the application for ..." > =20 Good point. we can clarify that. > Second paragraph, last sentence: Could the givenm examples be=20 > clearified beyond just giving the references? For example, by adding=20 > after the last reference ", where ...." > =20 Ok sure. we can further clarify the text. > Third paragraph, first sentence: "newly defined commands." -> "new=20 > commands." > > Section 5.3 > > First paragraph, last sentence:=20 > Change > "However, this scheme is followed to avoid possible routing problems=20 > for these messages." to "However, this scheme should be followed to=20 > avoid possible routing problems." > > Section 5.4 > > Third sentence:=20 > Change > "The existing session statemachines defined by [1] is not intended for > general use beyond AAA services therefore any behavior not covered by=20 > that category would not fit well." to "The existing session=20 > statemachines defined by [1] is not intended for general use beyond=20 > AAA services therefore any behavior not covered by that category may=20 > not fit well for the new application." > > Section 6.1 > > Second last paragraph, first sentence: delete "obviously" > > Last paragraph, first sentence: "Additionally," does not seem to apply > to anything said before e.g. in the previous paragraph. Henece another > start of that sentence may be good to have. > =20 Ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 14 08:07: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 1IKvAt-0000VU-O8; Tue, 14 Aug 2007 08:07:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvAs-0000VI-J3 for dime@ietf.org; Tue, 14 Aug 2007 08:07:02 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKvAp-0007Lg-RL for dime@ietf.org; Tue, 14 Aug 2007 08:07:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMR00KBYIYEYW@szxga01-in.huawei.com> for dime@ietf.org; Tue, 14 Aug 2007 20:06:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMR00C29IYBKV@szxga01-in.huawei.com> for dime@ietf.org; Tue, 14 Aug 2007 20:06:13 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JMR00EDPIYBKM@szxml04-in.huawei.com> for dime@ietf.org; Tue, 14 Aug 2007 20:06:11 +0800 (CST) Date: Tue, 14 Aug 2007 20:06:11 +0800 From: Tina TSOU Subject: Re: [Dime] QoS Application Review To: dime@ietf.org, "Asveren, Tolga" , McCann Peter-A001034 Message-id: <00ec01c7de6b$815c5f50$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <033458F56EC2A64E8D2D7B759FA3E7E702DF26@sonusmail04.sonusnet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 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 all, Basically, are we saying we are going to use Credit Control Appl. for PULL mode, and QoS Appl. for PUSH mode? B. R. Tina ----- Original Message ----- From: "McCann Peter-A001034" To: "Asveren, Tolga" ; Sent: Tuesday, August 14, 2007 2:03 AM Subject: RE: [Dime] QoS Application Review Hi, Tolga, Thanks for the detailed review. Sorry for taking this long to respond. See some comments from me below. Asveren, Tolga wrote: > Please find below my comments after an initial review of QoS > application draft. I tried to list first the generic > comments/questions and then the ones which are corresponding to > specific sections. > > Thanks, > Tolga > > 1- As indicated during IETF69 Dime sessions as well, more explanation > is necessary for push mode operation; particularly state machines and > explanation of the procedures at each step of the operation. IMHO, > push and pull modes seem different enough to justify two different > applications. That might be a good idea; however, as was mentioned during the WG meeting it may be possible to use both modes during a single session, where some NEs use push mode and some NEs use pull mode. If we allow that, it might make more sense to keep a single application. > 2- An explanation of how failure scenarios need to be handled could > be useful. Ok. > 3- I feel like Credit Control Application (CCA) is what we need for > pull mode. Functionality currently defined in the document is quite > similar to it. Is the reason, why CCA is not used, addition of new > AVPs with M-bit set to CCA commands? We didn't see the need to include CCA commands; all the credit-control information is contained in the QAR/QAA. The approach in the draft is much simpler than the CCA and IMHO in contains all the needed functionality. > I guess, even in this case, one > approach is referencing CCA and just defining new commands (with new > command codes and the new AVPs) and linking them to CCA commands in > terms of semantics (with semantics of the new AVPs explained in QoS > document). That's essentially what we did; we re-used the Cost-Information, Cost-Unit, Tariff-Time-Change, and CC-Time AVPs within the Diameter QoS commands but provided a much simpler framework in which to work. > If not all flexibility provided by CCA is necessary, this > could be indicated as well. I will start a new thread about this > (what to do if one wants to reuse an existing application -because > the semantics provided by that application are a good match- but > wants to add a few new AVPs with M-bit set) regarding its impact on > Application Design Guideline work. Ok let's talk about this. IMHO the commands in the Diameter QoS application are the ones we want to use. > 4- I think for push mode, the direction in the draft is the right > one, i.e. using new messages to install QoS reservation. Ok. > 5- I guess we should cover how emergency sessions are to be handled. > I didn't check whether there is an already suitable AVP for this but > some AVP identifying the priority of the QoS request could be useful > (and semantics about its use should be defined as well) I suppose we might need such an AVP either in QAA or QIR, in the case where the Authorizing Entity knows about the emergency status; Alternatively, such a field could be added to NSIS if only the AE knows about the emergency status. I am not sure whether such a field exists in NSIS - maybe experts could speak up? > 6- Especially for push mode, there should be a way for NE to signal > loss of an existing reservation. This mechanism should allow > signaling of loss of a single flow in a session with multiple flows. Are you thinking that the NE might be monitoring the flow for active traffic, and then timeout when it detects no packets for a certain period of time? We need to watch out for confusing loss of bearer with silence suppression. Maybe you have in mind that some specific link-layer trigger that tears-down the flow. In general, we also may want to react to NSIS signaling that "politely" tears down a flow. If we keep every flow as a different Diameter QoS session, it should be possible to terminate them independently. Hopefully we can just use STR / ASR for termination. > 7- Some section about different use cases could be a good idea, e.g > interaction between different organizations in different scenarios, > NAT traversal issues etc.. It could be an idea to have this as a > separate document. Ok let's think about this. > 8- > 1. Introduction > "However, when bandwidth is scarce and must be carefully managed, > such as in cellular networks, or when applications and transport > protocols lack the capability to perform end-to-end congestion > control, explicit reservation techniques are required." > Why is end-to-end mechanisms not suitable for the first case ("when > bandwidth resources are scarce")? I see your point - maybe we can remove that clause. > 9- > 2. Terminology > "Application Server > > An application server is a network entity that exchanges signaling > messages with an application endpoint. It may be a source of > authorization for QoS-enhanced application flows. For example, a SIP > server is one kind of application server." > I don't think SIP server is the right terminology for that type of > functionality. SIP Application Server or SIP proxy seems to be a > better example. I am ok with "SIP Application Server." > 10- > 2. Terminology > "Application Endpoint > > An application endpoint is an entity in an end user device that > exchanges signaling messages with application servers or directly > with other application endpoints. Based on the result of this > signaling, the endpoint may make a request for QoS from the network. > For example, a SIP User Agent is one kind of application endpoint." > Is it mandatory for Application Endpoint to initiate application > signaling before asking for QoS in an end-to-end fashion? I think the application negotiation (what codec to use etc.) needs to complete before a properly formed NSIS reservation is made. So at least, the signaling must have started before a request can be made. If you look at the SIP Preconditions RFC that's where RSVP signaling is traditionally integrated. > 11- > 2. Terminology > Network Element > Could be an entity different than a QoS aware router as well, e.g. a > cable modem termination system. If a given NE is not an IP-addressable entity then it can't participate in path-coupled signaling. My preference would be to keep the notion of a NE = Router. > 12- > 2. Terminology > Network Element > "For almost all scenarios this entity triggers the protocol > interaction described in this document." > This sentence ignores push model; "for almost all scenarios" is too > strong. Ok, we can take this out. > 13- > 2. Terminology > "Push Mode > In this mode, the QoS authorization process is invoked by the request > from Application Server or local policies in the Authorizing Entity." > What does "local policies" refer to? What is a real life example for > this? Does it refer to something like installing filters statically? I think this has to do with some confusion about the role of the Authorizing Entity. In my mind the Authorizing Entity equals either a home subscriber database or an Application Server. In some people's mind the AE is a local PDF which communicates over a separate entity to an Application Server. I'd be ok with removing "Application Server or local policies in" from the sentence. > 14- > 3. Framework > Should cover push model as well. Ok. > 15- > 3. Framework > "If defined properly, the interface between the routers and AAA cloud > would be identical in both cases." > Does this refer to using the same interface for push and pull modes? > If so, I guess it is not true, we use different messages. It refers to using the same interface whether the AE is a static subscriber database or an active Application Server. We should clarify. > 16- > 3.2.2 > When listing what mode is suitable for which type of network, > discussing the reasons rather than just listing the names could be > better (or just deleting that part completely). I'd be ok with deleting it. Dong may have a different opinion. > 17- > 3.3.1 > "With the 'Two party scheme' the QoS > resource requesting entity is authenticated by the Network Element > and the authorization decision is made either locally at the Network > Element itself or offloaded to a trusted entity (most likely within > the same administrative domain). In the former case no Diameter QoS > protocol interaction is required." > Why is QoS protocol interaction necessary for the latter case? I > thought this would be completely independent of QoS reservation > itself. In the latter case there is a protocol needed between the NE and the "trusted entity". In the draft that is assumed to be the Diameter QoS Application. However, this is not really two-party scheme anymore... I'd be ok with removing that part. > 18- > Figure 4 > I would think that an explicit "Authorization Token Request" is > optional and such a token could be included in application signaling > based on configuration/policy. It could be a good idea to clarify > this in the text or in the figure. It is necessary for the NE to be able to fill in the Destination-Realm field for proper routing of the QAR (pull mode) or for the Application Server to fill in the Destination-Realm of the QIR (push mode). Thus something needs to be exchanged in the application signaling; a "token" is an ok name for that, IMHO. Maybe we can improve the wording a bit here. > 19- > 3.3.2 > The distinction between "endpoint initiated" and "network initiated" > seems a bit artificial to me. At the end, it is *something* signaled > by endpoint (or is the idea application server reserving QoS out of > the blue?), which triggers the QoS reservation. The level of > explicitness of QoS information in that signal doesn't really matter > much from QoS application perspective. I agree. > 20- > 4.1 > Parties Involved > "Note that the QoS resource requesting entity is only indirectly > involved in the message exchange. This entity provides the trigger > to initiate the Diameter QoS protocol interaction by transmitting QoS > signaling messages." > I guess this part is ignoring push mode. The trigger could be > application signaling from which corresponding QoS parameters can be > extracted. Agreed. We should re-word. > 21- > 4.2 > Diameter QoS Authorization Session Establishment "A > Signaling-session-Id (if > present) SHOULD be used together with the generated Acc-Multi- > Session-Id AVP (see Section 7.3) for binding the authorization and > the accounting session information in case of end host mobility > (i.e., to correlate the Diameter sessions that are initiated for the > same signaling session from different QoS NE)." > I think we first need to define the semantics how mobility is going > to work in such a case. For example, if the new NE is controlled by > another organization, how would be the interaction with the initial > NE? Need to think about this one some more. > 22- > IMHO, DIAMETER_SUCCESS instead of DIAMETER_LIMITED_SUCCESS could be > used. The expected message flow/behavior is already defined as parts > of the procedures. Upon receipt of DIAMETER_SUCCESS, the requesting > entity would know what it needs to do next. Ok with me. -Pete _______________________________________________ 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 Aug 14 08:12: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 1IKvGH-0002dC-7y; Tue, 14 Aug 2007 08:12:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuiP-0005or-Mo for dime@ietf.org; Tue, 14 Aug 2007 07:37:37 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKuiL-0008RN-Jh for dime@ietf.org; Tue, 14 Aug 2007 07:37:37 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 14 Aug 2007 13:36:48 +0200 Received: from S4DE9JSAANL.ost.t-com.de ([10.125.177.226]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Aug 2007 13:36:47 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7DE67.6545B8C2" Date: Tue, 14 Aug 2007 13:36:43 +0200 Message-Id: <75404C7727619C4E81A6DABE442E42DD0255DD4F@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <46B04B7E.4040404@gmx.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Diameter Design Guidelines Draft Reviewers Thread-Index: AcfUGlEBvSPnLj5jSqi5x2t5ggsHoAKTHjbw References: <46B04B7E.4040404@gmx.net> From: Steigerwaldw To: X-OriginalArrivalTime: 14 Aug 2007 11:36:47.0334 (UTC) FILETIME=[65BEA860:01C7DE67] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8506cd99a2b34fd8177504aff14605e X-Mailman-Approved-At: Tue, 14 Aug 2007 08:12:33 -0400 Cc: dime@ietf.org Subject: [Dime] AW: Diameter Design Guidelines Draft Reviewers 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DE67.6545B8C2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Hannes, I have reviewed the application design guideline document. I have found = only some editorial issues and marked them with "WS!" Regards=20 Wolfgang =20 T-Systems Enterprise Services GmbH Systems Integration Project & Design, Business Unit Telco Line of Business Products & Services Goslarer Ufer 35, 10589 Berlin=20 Tel. +49 30 -3497 2058=20 Fax +49 391 53475396=20 Mobil +49 171 5664350=20 E-Mail: wolfgang.steigerwald@t-systems.com=20 T-Systems Business Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder*, Albert Henn*, Olaf Heyden, Katrin = Horstmann, Ulrich Kemp*, Wilfried Peters*,=20 Dr. Herbert Schaaff, Zvezdana Seeger Handelsregister: Amtsgericht Bonn HRB 6787 Sitz der Gesellschaft: Bonn WEEE-Reg.-Nr. DE50335567 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you.=20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Mittwoch, 1. August 2007 11:00 > An: dime@ietf.org > Cc: Steigerwald, Wolfgang; Ulf Bodin; aland@nitros9.org > Betreff: Diameter Design Guidelines Draft Reviewers >=20 > I would like to thank >=20 > * Wolfgang Steigerwald > * Ulf Bodin > * Alan DeKok >=20 > for their willingness to review the Diameter Design=20 > Guidelines draft within the next 2 weeks. >=20 > Ciao > Hannes >=20 >=20 >=20 ------_=_NextPart_001_01C7DE67.6545B8C2 Content-Type: text/plain; name="draft-ietf-dime-app-design-guide-02-WS.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-dime-app-design-guide-02-WS.txt Content-Disposition: attachment; filename="draft-ietf-dime-app-design-guide-02-WS.txt" DQoNCkRpYW1ldGVyIE1haW50YW5lbmNlIGFuZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFYuIEZhamFyZG8sIEVkLg0KRXh0ZW5zaW9ucyAoRElNRSkgICAgICAgICAgICAgICAgICAg ICAgICAgIFRvc2hpYmEgQW1lcmljYSBSZXNlYXJjaCBJbmMuDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIEFzdmVyZW4NCklu dGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg U29udXMgTmV0d29yaw0KRXhwaXJlczogSmFudWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBUc2Nob2ZlbmlnDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5va2lhIFNpZW1lbnMgTmV0d29ya3MNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBN Y0dyZWdvcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFsY2F0ZWwtTHVjZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gTG91Z2huZXkNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIENlbnRl cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSnVseSA2LCAyMDA3DQoNCg0KICAgICAgICAgICAgICAgIERpYW1ldGVyIEFwcGxpY2F0 aW9ucyBEZXNpZ24gR3VpZGVsaW5lcw0KICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZGltZS1h cHAtZGVzaWduLWd1aWRlLTAyLnR4dA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIEJ5IHN1 Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0 IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBo ZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5k IGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9z ZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu Zw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw cy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFm dCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJl IG9uIEphbnVhcnkgNywgMjAwOC4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQg KEMpIFRoZSBJRVRGIFRydXN0ICgyMDA3KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhlIERpYW1ldGVy IEJhc2UgcHJvdG9jb2wgcHJvdmlkZXMgdXBkYXRlZCBydWxlcyBvbiBob3cgdG8gZXh0ZW5kDQoN Cg0KDQpGYWphcmRvLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDcsIDIwMDggICAg ICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgRGlhbWV0ZXIgQXBwbGlj YXRpb25zIERlc2lnbiBHdWlkZWxpbmVzICAgICAgIEp1bHkgMjAwNw0KDQoNCiAgIERpYW1ldGVy IGJ5IG1vZGlmeWluZyBhbmQvb3IgZGVyaXZpbmcgZnJvbSBleGlzdGluZyBhcHBsaWNhdGlvbnMg b3INCiAgIGNyZWF0aW5nIGVudGlyZWx5IG5ldyBhcHBsaWNhdGlvbnMuICBUaGlzIGlzIGEgY29t cGFuaW9uIGRvY3VtZW50IHRvDQogICB0aGUgRGlhbWV0ZXIgQmFzZSBwcm90b2NvbCB3aGljaCBm dXJ0aGVyIGV4cGxhaW5zIGFuZC9vciBjbGFyaWZ5DQogICB0aGVzZSBydWxlcy4gIEl0IGlzIG1l YW50IGFzIGEgZ3VpZGVsaW5lcyBkb2N1bWVudCBhbmQgdGhlcmVmb3JlIGl0DQogICBkb2VzIG5v dCBhZGQsIHJlbW92ZSBvciBjaGFuZ2UgZXhpc3RpbmcgcnVsZXMuDQoNCg0KVGFibGUgb2YgQ29u dGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgVGVybWlub2xvZ3kgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMuICBCcmllZiBP dmVydmlldyBvZiB0aGUgRGlhbWV0ZXIgQXBwbGljYXRpb24gTW9kZWwgLiAuIC4gLiAuIC4gLiAg NA0KICAgNC4gIFJ1bGVzIG9uIEV4dGVuZGluZyBEaWFtZXRlciAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDQuMS4gIFJldXNpbmcgRXhpc3RpbmcgQXBwbGljYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgICA0LjEuMS4gIEFkZGlu ZyBhIG5ldyBjb21tYW5kIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAg ICAgIDQuMS4yLiAgRGVsZXRpbmcgYSBjb21tYW5kIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA3DQogICAgIDQuMi4gIFJldXNpbmcgRXhpc3RpbmcgQ29tbWFuZHMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgICA0LjIuMS4gIEFkZGluZyBBVlBz IHRvIGEgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAgIDQu Mi4yLiAgRGVsZXRpbmcgQVZQcyBmcm9tIGEgY29tbWFuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA5DQogICAgIDQuMy4gIFJldXNpbmcgRXhpc3RpbmcgQVZQcyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgIDUuICBSdWxlcyBmb3IgbmV3IEFwcGxpY2F0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA1LjEuICBSdWxl cyBpbiBBbGxvY2F0aW5nIG5ldyBDb21tYW5kIENvZGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDEw DQogICAgIDUuMi4gIEp1c3RpZnlpbmcgdGhlIEFsbG9jYXRpb24gb2YgQXBwbGljYXRpb24tSWQg IC4gLiAuIC4gLiAuIC4gMTENCiAgICAgNS4zLiAgVXNlIG9mIEFwcGxpY2F0aW9uLUlkIGluIGEg TWVzc2FnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgICA1LjQuICBBcHBsaWNhdGlv biBTcGVjaWZpYyBTZXNzaW9uIFN0YXRlbWFjaGluZSAgLiAuIC4gLiAuIC4gLiAuIDExDQogICAg IDUuNS4gIEVuZC10by1FbmQgQXBwbGljYXRpb25zIENhcGFiaWxpdGllcyBFeGNoYW5nZSAgLiAu IC4gLiAuIC4gMTINCiAgIDYuICBPdGhlciBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgICA2LjEuICBEaWFtZXRlciBBY2NvdW50 aW5nIFN1cHBvcnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICAgIDYuMi4g IEdlbmVyaWMgRGlhbWV0ZXIgRXh0ZW5zaW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTQNCiAgICAgNi4zLiAgVXBkYXRpbmcgYW4gZXhpc3RpbmcgQXBwbGljYXRpb24gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNQ0KICAgICA2LjQuICBTeXN0ZW0gQXJjaGl0ZWN0dXJlIGFu ZCBEZXBsb3ltZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICA3LiAgSUFOQSBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYN CiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNg0KICAgOS4gIEFja25vd2xlZGdtZW50cyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQogICAxMC4gUmVmZXJlbmNlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgICAg MTAuMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNw0KICAgICAxMC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgIEludGVsbGVj dHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4g LiAxOQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgIERpYW1ldGVyIEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBK dWx5IDIwMDcNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBEaWFtZXRlciBCYXNlIHBy b3RvY29sIGRvY3VtZW50IGRlZmluZXMgcnVsZXMgb24gaG93IG9uZSB3b3VsZA0KICAgZXh0ZW5k IERpYW1ldGVyIChzZWUgU2VjdGlvbiAxLjIgb2YgWzFdKS4gIEluIHRoZSBjb250ZXh0IG9mIHRo aXMNCiAgIGRvY3VtZW50LCBleHRlbmRpbmcgRGlhbWV0ZXIgbWVhbnMgb25lIG9mIHRoZSBmb2xs b3dpbmc6DQoNCiAgIDEuICBBIG5ldyBmdW5jdGlvbmFsaXR5IGlzIGJlaW5nIGFkZGVkIHRvIGFu IGV4aXN0aW5nIERpYW1ldGVyDQogICAgICAgYXBwbGljYXRpb24gd2l0aG91dCBkZWZpbmluZyBh IG5ldyBhcHBsaWNhdGlvbi4NCg0KICAgMi4gIEEgbmV3IERpYW1ldGVyIGFwcGxpY2F0aW9uIGlz IGJlaW5nIGRlZmluZWQgYnkgcmV1c2luZyBhbg0KICAgICAgIGV4aXN0aW5nIGFwcGxpY2F0aW9u Lg0KDQogICAzLiAgQSBjb21wbGV0ZWx5IG5ldyBhcHBsaWNhdGlvbiBpcyBiZWluZyBkZWZpbmVk IHRoYXQgaGFzIG5vDQogICAgICAgZGVwZW5kZW5jaWVzIHRvIGFueSBleGlzdGluZyBhcHBsaWNh dGlvbnMuDQoNCiAgIDQuICBBIG5ldyBnZW5lcmljIGZ1bmN0aW9uYWxpdHkgaXMgYmVpbmcgZGVm aW5lZCB0aGF0IGNhbiBiZSByZXVzZWQNCiAgICAgICBhY3Jvc3MgZGlmZmVyZW50IGFwcGxpY2F0 aW9ucy4NCg0KICAgQWxsIG9mIHRoZXNlIGNob2ljZXMgYXJlIGRlc2lnbiBkZWNpc2lvbnMgdGhh dCBjYW4gZG9uZSBieSBhbnkNCiAgIGNvbWJpbmF0aW9uIG9mIHJldXNpbmcgZXhpc3Rpbmcgb3Ig ZGVmaW5pbmcgbmV3IGNvbW1hbmRzLCBBVlBzIG9yIEFWUA0KICAgdmFsdWVzLiAgVGhlIG9iamVj dGl2ZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIENsYXJpZnkg dXBkYXRlZCBEaWFtZXRlciBleHRlbnNpYmlsaXR5IHJ1bGVzIGluIHRoZSBEaWFtZXRlciBCYXNl DQogICAgICBQcm90b2NvbC4NCg0KICAgbyAgQ2xhcmlmeSB1c2FnZSBvZiBjZXJ0YWluIERpYW1l dGVyIGZ1bmN0aW9uYWxpdHkgd2hpY2ggYXJlIG5vdA0KICAgICAgZXhwbGljaXRseSBkZXNjcmli ZWQgaW4gdGhlIERpYW1ldGVyIEJhc2Ugc3BlY2lmaWNhdGlvbi4NCg0KICAgbyAgRGlzY3VzcyBk ZXNpZ24gY2hvaWNlcyBhbmQgcHJvdmlkZSBndWlkZWxpbmVzIHdoZW4gZGVmaW5pbmcNCiAgICAg IGFwcGxpY2F0aW9ucy4NCg0KICAgbyAgUHJlc2VudCB0cmFkZW9mZnMgb2YgZGVzaWduIGNob2lj ZXMuDQoNCiAgIFRoZXNlIGd1aWRlbGluZXMgYXJlIG5lY2Vzc2FyeSBzaW5jZSB0aGUgZXhpc3Rp bmcgcnVsZXMgZG8gbm90IGNvdmVyDQogICB0aGUgYW1iaWd1aXR5IHRoYXQgZXhpc3Qgd2hlbiBz b21lIG9mIHRoZSBkZXNpZ24gY2hvaWNlcyBvdmVybGFwLiAgQQ0KICAgdHlwaWNhbCBleGFtcGxl IHdvdWxkIGJlIGRlY2lkaW5nIGJldHdlZW4gaXRlbSBvbmUoMSkgYW5kIHR3bygyKQ0KICAgYWJv dmUgd2hlbiBhbiBhcHBsaWNhdGlvbiBkZXNpZ25lciByZXF1aXJlcyBhIG5ldyBhcHBsaWNhdGlv bg0KICAgZnVuY3Rpb25hbGl0eSB3aGljaCBoYXMgbWFueSB0aGluZ3MgaW4gY29tbW9uIHdpdGgg YW4gZXhpc3RpbmcNCiAgIGFwcGxpY2F0aW9uLiAgQ2VydGFpbiBhbWJpZ3VvdXMgYXNwZWN0cyBv ZiBzdWNoIGNhc2VzIHdhcyBub3QNCiAgIGZvcmVzZWVuIGluIHRoZSBleGlzdGluZyBleHRlbnNp YmlsaXR5IHJ1bGVzOyBpLmUuLCB1c2Ugb2Ygb3B0aW9uYWwNCiAgIEFWUHMgdG8gZGlmZmVyZW50 aWF0ZSBuZXcgZnVuY3Rpb25hbGl0eSBpbiB0aGUgb2xkIGFwcGxpY2F0aW9uIHZlcnN1cw0KICAg ZGVmaW5pbmcgYSBuZXcgYXBwbGljYXRpb24gYW5kIGltcG9ydGluZyB0aGUgZXhpc3Rpbmcgc2V0 IG9mDQogICBjb21tYW5kcy4gIEluIHRoaXMgZXhhbXBsZSwgaXQgd2FzIG9ubHkgYmFzZWQgb24g Y29sbGVjdGl2ZQ0KICAgZXhwZXJpZW5jZXMgb2YgYXBwbGljYXRpb24gZGVzaWduZXJzIHRoYXQg dGhlIGRlY2lzaW9uIHRvIGNyZWF0ZSBhDQogICBuZXcgYXBwbGljYXRpb24gKGl0ZW0gdHdvKDIp KSBpcyBub3cgc2VlbiBhcyB0aGUgY2xlYW5lc3QgYXBwcm9hY2guDQoNCiAgIEFsb25nIHdpdGgg dGhlIGdhaW5lZCBleHBlcmllbmNlIGhvd2V2ZXIsIGFkZGl0aW9uYWwgYmFkIHByYWN0aWNlcw0K ICAgaGF2ZSBkZXZlbG9wZWQgYXMgd2VsbC4gIENvbnRpbnVpbmcgdGhlIGV4YW1wbGUgYWJvdmUs IHRoZSBkZWNpc2lvbg0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAg IERpYW1ldGVyIEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBKdWx5IDIwMDcN Cg0KDQogICB0byBjcmVhdGUgYSBuZXcgYXBwbGljYXRpb24gd291bGQgcmVzdWx0IGluIHRoZSBh bGxvY2F0aW9uIG9mIGEgbmV3DQogICBhcHBsaWNhdGlvbiBJRCB3aGljaCBvZnRlbiB0aW1lcyBp cyBmb3Jlc2VlbiBhcyBjdW1iZXJzb21lIGJ5DQogICBhcHBsaWNhdGlvbiBkZXNpZ25lcnMgYmVj YXVzZSBvZiB0aGUgbGVuZ3RoeSBwcm9jZXNzLiAgRGVzaWduZXJzDQogICB0aGVyZWZvcmUgdGVu ZCB0byBjaXJjdW12ZW50IHRoZSBiZXR0ZXIgYXBwcm9hY2ggbGVhZGluZyB0byBtYW55DQogICBj b21wcm9taXNlcyBpbiB0aGUgZGVzaWduIHRoYXQgZXZlbnR1YWxseSBsZWFkIHRvIGludGVyb3Bl cmFiaWxpdHkNCiAgIGlzc3VlcyAoU2VlIFNlY3Rpb24gNS4xKS4NCg0KICAgVGhlIGJhc2ljIGlz c3VlIGlzIHRoYXQgdGhlIHJ1bGVzIGRlZmluZWQgaW4gdGhlIERpYW1ldGVyIEJhc2UNCiAgIHBy b3RvY29sIGFyZSBub3QgY29tcHJlaGVuc2l2ZSBlbm91Z2ggdGhhdCBvbmUgY2FuIGVhc2lseSBk ZXJpdmUgZ29vZA0KICAgZGVzaWduIGRlY2lzaW9ucyBmcm9tIHRoZW0uICBUaGUgZWZmZWN0IG9m IHRoaXMgY2FuIGJlIHNlZW4gaW4NCiAgIHZhcmlvdXMgYXR0ZW1wdHMgdG8gZXh0ZW5kIERpYW1l dGVyIGFwcGxpY2F0aW9ucyB3aGVyZSBkZXNpZ25lcnMgaGF2ZQ0KICAgbm8gY2xlYXIgYW5zd2Vy IG9uIHdoZXRoZXIgdG8gZXZlbiBkZWZpbmUgYSBuZXcgYXBwbGljYXRpb24gb3Igbm90Lg0KICAg QXQgd29yc3QsIHNvbWUgZXhpc3RpbmcgRGlhbWV0ZXIgYXBwbGljYXRpb25zIHRoYXQgaGFkIHB1 cnBvc2VseSBiZWVuDQogICBkZXJpdmVkIGZyb20gYW5vdGhlciBleGlzdGluZyBhcHBsaWNhdGlv biByZXN1bHRlZCBpbiBzb21lIGluLQ0KICAgYXBwcm9wcmlhdGUgZGVzaWduIGRlY2lzaW9uIHdo ZXJlIGJvdGggdGhlIGV4aXN0aW5nIGFwcGxpY2F0aW9uIGFuZA0KICAgdGhlIGRlcml2ZWQgYXBw bGljYXRpb25zIGFyZSBubyBsb25nZXIgaW50ZXJvcGVyYWJsZSB1bmRlciBjZXJ0YWluDQogICBj b25kaXRpb25zLiAgTm90ZSB0aGF0IGl0IGlzIG5vdCBhbHdheXMgcG9zc2libGUgdG8gb2ZmZXIg YSBjb21wbGV0ZQ0KICAgYW5kIGNvbmNpc2UgYW5zd2VyIHRvIGNlcnRhaW4gZGVzaWduIGNob2lj ZXMgYnV0IGF0IHRoZSBsZWFzdCwgdGhpcw0KICAgZG9jdW1lbnQgY2FuIGJlIHVzZWQgYXMgYSBn dWlkZSB0byBEaWFtZXRlciBleHRlbnNpYmlsaXR5Lg0KDQoNCjIuICBUZXJtaW5vbG9neQ0KDQog ICBUaGlzIGRvY3VtZW50IHJldXNlcyB0aGUgdGVybWlub2xvZ3kgdXNlZCBpbiBbMV0uDQogICBX UyEgVGVybWlub2xvZ3kgaXMgaW4gc2VjdGlvbiAxLjMNCg0KMy4gIEJyaWVmIE92ZXJ2aWV3IG9m IHRoZSBEaWFtZXRlciBBcHBsaWNhdGlvbiBNb2RlbA0KDQogICBBcyBpdCBpcyBjdXJyZW50bHkg aW50ZXJwcmV0ZWQgYW5kIHByYWN0aWNlZCwgdGhlIERpYW1ldGVyIEJhc2UNCiAgIHByb3RvY29s IGlzIGEgdHdvLWxheWVyIHByb3RvY29sLiAgVGhlIGxvd2VyIGxheWVyIGlzIG1haW5seQ0KICAg cmVzcG9uc2libGUgZm9yIG1hbmFnaW5nIGNvbm5lY3Rpb25zIGJldHdlZW4gbmVpZ2hib3Jpbmcg cGVlcnMgYW5kDQogICBmb3IgbWVzc2FnZSByb3V0aW5nLiAgVGhlIHVwcGVyIGxheWVyIGlzIHdo ZXJlIHRoZSBEaWFtZXRlcg0KICAgYXBwbGljYXRpb25zIHJlc2lkZS4gIFRoaXMgbW9kZWwgaXMg aW5saW5lIHdpdGggYSBEaWFtZXRlciBub2RlDQogICBoYXZpbmcgYW4gYXBwbGljYXRpb24gbGF5 ZXIgYW5kIGEgcGVlci10by1wZWVyIGRlbGl2ZXJ5IGxheWVyLiAgVGhlDQogICBEaWFtZXRlciBC YXNlIHByb3RvY29sIGRvY3VtZW50IGNvbXBsZXRlbHkgZGVmaW5lcyB0aGUgYXJjaGl0ZWN0dXJl DQogICBhbmQgYmVoYXZpb3Igb2YgdGhlIG1lc3NhZ2UgZGVsaXZlcnkgbGF5ZXIgYW5kIHRoZW4g cHJvdmlkZXMgdGhlDQogICBmcmFtZXdvcmsgZm9yIGRlc2lnbmluZyBEaWFtZXRlciBhcHBsaWNh dGlvbnMgb24gdGhlIGFwcGxpY2F0aW9uDQogICBsYXllci4gIFRoaXMgZnJhbWV3b3JrIGluY2x1 ZGVzIGRlZmluaXRpb25zIG9mIGFwcGxpY2F0aW9uIHNlc3Npb25zDQogICBhbmQgYWNjb3VudGlu ZyBzdXBwb3J0IChzZWUgU2VjdGlvbiA4IGFuZCA5IG9mIFsxXSkuICBUaGUgcmVtYWluZGVyDQog ICBvZiB0aGlzIGRvY3VtZW50IGFsc28gdHJlYXRzIGEgRGlhbWV0ZXIgbm9kZSBhcyBhIHNpbmds ZSBpbnN0YW5jZSBvZg0KICAgYSBEaWFtZXRlciBtZXNzYWdlIGRlbGl2ZXJ5IGxheWVyIGFuZCBv bmUgb3IgbW9yZSBEaWFtZXRlcg0KICAgYXBwbGljYXRpb25zIHVzaW5nIGl0Lg0KDQoNCjQuICBS dWxlcyBvbiBFeHRlbmRpbmcgRGlhbWV0ZXINCg0KICAgRXh0ZW5kaW5nIERpYW1ldGVyIGNhbiBt ZWFuIHRoZSByZXVzZSBvZiBjb21tYW5kcywgQVZQcyBhbmQgQVZQDQogICB2YWx1ZXMgaW4gYW55 IGNvbWJpbmF0aW9uIGZvciB0aGUgcHVycG9zZSBvZiBpbmhlcml0aW5nIHRoZSBmZWF0dXJlcw0K DQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA3LCAyMDA4ICAg ICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgIERpYW1ldGVyIEFwcGxp Y2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBKdWx5IDIwMDcNCg0KDQogICBvZiBhbiBl eGlzdGluZyBEaWFtZXRlciBhcHBsaWNhdGlvbiAocykuICBUaGlzIHNlY3Rpb24gZGlzY3Vzc2Vz IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdTIV5eDQogICBydWxl cyBvbiBob3cgc3VjaCByZXVzZSBjYW4gYmUgZG9uZS4NCg0KICAgV2hlbiByZXVzaW5nIGV4aXN0 aW5nIGFwcGxpY2F0aW9ucywgdGhlIHJlcXVpcmVtZW50cyBvZiB0aGUgbmV3DQogICBhcHBsaWNh dGlvbnMgYXJlIHR5cGljYWxseSBub3QgY29tcGxldGVseSB1bmlxdWUgYW5kIHRoZXJlIGFyZQ0K ICAgZXhpc3RpbmcgYXBwbGljYXRpb24ncyB0aGF0IGNhbiBiZSByZXVzZWQgdG8gc29sdmUgc29t ZSBvciBhbGwgb2YgdGhlDQogICBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMuICBUaGVyZWZvcmUs IHRoZXJlIGlzIGEgZ3JlYXRlciBsaWtlbGlob29kDQogICBvZiBhbWJpZ3VpdHkgb24gaG93IG11 Y2ggb2YgdGhlIGV4aXN0aW5nIGFwcGxpY2F0aW9uIGNhbiBiZSByZXVzZWQsDQogICB0byB3aGF0 IGV4dGVudCBhbmQgd2hhdCB0aGUgaW1wbGljYXRpb25zIGZvciBib3RoIHRoZSBuZXcgYW5kDQog ICBleGlzdGluZyBhcHBsaWNhdGlvbi4gIFRvIGJyb2FkbHkgY2F0ZWdvcml6ZSwgdGhlIHJ1bGVz IGZvciByZXVzaW5nDQogICBleGlzdGluZyBhcHBsaWNhdGlvbnMgY2FuIGJlIGVpdGhlcjoNCg0K ICAgMS4gIE1pbmltYWwgLSB3aGljaCB0eXBpY2FsbHkgbWVhbnMgYWRkaW5nIG9wdGlvbmFsIEFW UHMgdG8gZXhpc3RpbmcNCiAgICAgICBjb21tYW5kcy4NCg0KICAgMi4gIEludmFzaXZlIC0gd2hl cmUgYWRkaXRpb24gb3IgZGVsZXRpb24gb2YgY29tbWFuZHMgYW5kL29yIEFWUHMsDQogICAgICAg YW5kL29yIEFWUCB2YWx1ZXMgKGlzIGRvbmUpLg0KICAgICAgICAgICAgICAgICAgICAgV1MhIF5e Xl5eXl5eDQoNCg0KICAgQmVjYXVzZSBpdCBjYW4gZnVuZGFtZW50YWxseSBjaGFuZ2UgdGhlIGFw cGxpY2F0aW9uLCB0aGUgbGF0dGVyDQogICBhcHByb2FjaCBoYXMgc3RyaWN0IHJlcGVyY3Vzc2lv bnMuICBTcGVjaWZpY2FsbHksIGl0IHdvdWxkIHJlc3VsdCBpbg0KICAgdGhlIGRlZmluaXRpb24g b2YgYSBuZXcgYXBwbGljYXRpb24gYW5kIHRoZXJlZm9yZSBhbGxvY2F0aW9uIG9mIGEgbmV3DQog ICBhcHBsaWNhdGlvbiBJRCBpcyByZXF1aXJlZC4gIERpc2N1c3Npb24gYWJvdXQgdGhlIHNwZWNp ZmljIERpYW1ldGVyDQogICBCYXNlIHByb3RvY29sIHJ1bGVzIGFzc29jaWF0ZWQgd2l0aCB0aGlz IGFwcHJvYWNoIGFyZSBjb3ZlcmVkIChpbikNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV1MhIF5eXl4NCiAgIHN1YnNlcXVlbnQg c2VjdGlvbnMuDQoNCiAgIFRoZSBmb3JtZXIgYXBwcm9hY2gsIGFsdGhvdWdoIHNpbXBsZSwgaGFz IHBpdGZhbGxzLiAgVGhlIHByb2JsZW1zDQogICBhcmlzZSB3aGVuIHRoZXJlIGlzIGEgdGVuZGVu Y3kgYnkgYXBwbGljYXRpb25zIGRlc2lnbmVycyB0byBrZWVwDQogICBhZGRpbmcgb3B0aW9uYWwg QVZQcyB0byBleGlzdGluZyBjb21tYW5kIHNvIHRoZXkgY2FuIGNpcmN1bXZlbnQgdGhlDQogICBy dWxlcyBhc3NvY2lhdGVkIHdpdGggdGhlIGxhdHRlciBhcHByb2FjaC4gIFNwZWNpZmljYWxseSwg c29tZQ0KICAgZGVzaWduZXJzIHdhbnQgdG8gY2lyY3VtdmVudCB0aGUgc3RhbmRhcmRpemF0aW9u IHByb2Nlc3MgYXNzb2NpYXRlZA0KICAgd2l0aCB0aGVzZSBydWxlcyBhbmQgbm90IG5lY2Vzc2Fy aWx5IHRoZSBydWxlcyB0aGVtc2VsdmVzLiAgVGhlDQogICBwaXRmYWxscyBhc3NvY2lhdGVkIHdp dGggdGhpcyBhcHByb2FjaCBpcyBkZXNjcmliZWQgZnVydGhlciBpbg0KICAgU2VjdGlvbiA0LjIu MS4gIEFkZGl0aW9uYWxseSwgaWYgZGVzaWduZXJzIGNob29zZSB0aGlzIGFwcHJvYWNoLCBhbGwN CiAgIG9mIHRoZSBmdW5jdGlvbmFsaXR5IG9mIHRoZSBleGlzdGluZyBhcHBsaWNhdGlvbiB3aWxs IGJlIGluaGVyaXRlZA0KICAgZXZlbiBpZiB0aGUgbmV3IHVzYWdlIGhhcyBubyBpbnRlbnQgb2Yg dXNpbmcgc29tZSBvZiB0aGUgZXhpc3RpbmcNCiAgIGZlYXR1cmVzLg0KDQo0LjEuICBSZXVzaW5n IEV4aXN0aW5nIEFwcGxpY2F0aW9ucw0KDQogICBUaGlzIHNlY3Rpb24gZGlzY3Vzc2VzIHRoZSBy ZXVzZSBvZiBleGlzdGluZyBhcHBsaWNhdGlvbnMgYnkgYWRkaW5nDQogICBhbmQvb3IgZGVsZXRp bmcgY29tbWFuZHMgZnJvbSB0aGUgYXBwbGljYXRpb24uICBUaGlzIHNjZW5hcmlvIGlzDQogICBj YXRlZ29yaXplIGFzICJJbnZhc2l2ZSIgaW4gU2VjdGlvbiA0IGFuZCB3b3VsZCBhbHdheXMgcmVz dWx0IGluIHRoZQ0KICAgY3JlYXRpb24gb2YgbmV3IGFwcGxpY2F0aW9ucyB3aGVuIHRoZSBydWxl cyBhcmUgYXBwbGllZC4NCg0KDQoNCg0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5l dC1EcmFmdCAgIERpYW1ldGVyIEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBK dWx5IDIwMDcNCg0KDQo0LjEuMS4gIEFkZGluZyBhIG5ldyBjb21tYW5kDQoNCiAgIFRoZSBydWxl cyBhcmUgc3RyaWN0IGluIHRoaXMgY2FzZS4gIEFkZGluZyBhIGNvbW1hbmQgdG8gYW4NCiAgIGFw cGxpY2F0aW9uIGlzIG5vdCBhbGxvd2VkIGFuZCBkb2luZyBzbyB3aWxsIGZvcmNlIGEgZGVmaW5p dGlvbiBvZiBhDQogICBuZXcgYXBwbGljYXRpb24uICBIb3dldmVyLCBpZiB0aGlzIGlzIHRoZSBp bnRlbnQsIHRoZW4gdGhlIG5ldw0KICAgYXBwbGljYXRpb24gY2FuIGJlIGNyZWF0ZWQgYnkgZGVm aW5pbmcgIFdTISAoZm9yIHJlYWRhYmlsaXR5IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRv IHdyaXRlIGl0IGxpa2UpDQogICAgLSBhIG5ldyBjb21tYW5kIGZvciBhbiBleGlzdGluZyBhcHBs aWNhdGlvbiANCiAgICBvciANCiAgICAtIGltcG9ydGluZyBhbiBleGlzdGluZyBjb21tYW5kIGZy b20gYW5vdGhlciBhcHBsaWNhdGlvbiBzbyBhcyB0byBpbmhlcml0IA0KICAgICAgc29tZSBvciBh bGwgb2YgdGhlIGZ1bmN0aW9uYWxpdHkgb2YgdGhhdGFwcGxpY2F0aW9uDQogICAgICANCiAgIElu IHRoZSBmb3JtZXIgY2FzZSwgdGhlIGRlY2lzaW9uIGlzIHN0cmFpZ2h0IGZvcndhcmQNCiAgIHNp bmNlIHRoaXMgaXMgdHlwaWNhbGx5IGEgcmVzdWx0IG9mIGFkZGluZyBuZXcgZnVuY3Rpb25hbGl0 eSB0aGF0DQogICBkb2VzIG5vdCB5ZXQgZXhpc3QuICBTZWUgU2VjdGlvbiA1LjEgZm9yIHJ1bGVz IG9uIGhvdyB0byBhbGxvY2F0ZSBuZXcNCiAgIGNvbW1hbmQgY29kZXMgZm9yIG5ldyBhcHBsaWNh dGlvbnMuICBUaGUgbGF0dGVyIGNhc2Ugd291bGQgcmVzdWx0IGluDQogICBhIG5ldyBhcHBsaWNh dGlvbiBidXQgaXQgaGFzIGEgbW9yZSBzdWJ0bGUgaXNzdWUgc3VjaCBhcyBkZWNpZGluZw0KICAg d2hldGhlciBpbXBvcnRpbmcgb2YgY29tbWFuZHMgYW5kIGZ1bmN0aW9uYWxpdHkgaXMgcmVhbGx5 IGJldHRlciB0aGFuDQogICBzaW1wbHkgdXNpbmcgdGhlIGV4aXN0aW5nIGFwcGxpY2F0aW9uIGFz IGl0IGlzIGluIGNvbmp1bmN0aW9uIHdpdGgNCiAgIGFueSBuZXcgYXBwbGljYXRpb24uDQoNCiAg IEEgdHlwaWNhbCBleGFtcGxlIHdvdWxkIGJlIHRoZSBEaWFtZXRlciBNSVB2NiBzcGxpdCBzY2Vu YXJpbyAoc2VlDQogICBbMl0pIGluIHdoaWNoIHNldmVyYWwgYXBwbGljYXRpb24gbW9kZWxzIHdv dWxkIGhhdmUgYmVlbiBwb3NzaWJsZQ0KICAgZHVyaW5nIHRoZSBkZXNpZ24gcGhhc2U7IG9uZSBt b2RlbCB3b3VsZCByZXVzZSBleGlzdGluZyBEaWFtZXRlciBFQVANCiAgIGFwcGxpY2F0aW9uIGNv bWJpbmVkIHdpdGggYSBuZXcgRGlhbWV0ZXIgTUlQdjYgYXBwbGljYXRpb24gdG8gZm9ybSBhDQog ICBjb21wbGV0ZSBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBzY2hlbWUgYW5kIGFu b3RoZXIgd291bGQgYmUNCiAgIHRvIHJldXNlIERpYW1ldGVyIEVBUCBsaWtlIGNvbW1hbmRzIHdp dGhpbiB0aGUgbmV3IERpYW1ldGVyIE1JUHY2DQogICBhcHBsaWNhdGlvbiB0byBhY2NvbXBsaXNo IHRoZSBzYW1lIHJlc3VsdC4gIEluIHRoaXMgY2FzZSwgdGhlIGxhdHRlcg0KICAgbW9kZWwgd2Fz IGNob3NlbiB3aGljaCB3b3VsZCBwZXJtaXQgdGhlIHJldXNlIG9mIGNvbW1hbmRzIGFuZC9vciBB VlBzDQogICBmcm9tIG9uZSBhcHBsaWNhdGlvbiB0byBhbm90aGVyLiAgT3RoZXIgYXBwbGljYXRp b25zIHN1Y2ggYXMgRGlhbWV0ZXINCiAgIFFvUyAoc2VlIFszXSkgd291bGQgbGlrZWx5IGZhY2Ug c2ltaWxhciBkZWNpc2lvbnMuDQoNCiAgIEluIGdlbmVyYWwsIGl0IGlzIGRpZmZpY3VsdCB0byBj b21lIHRvIGEgaGFyZCBhbmQgZmFzdCBndWlkZWxpbmUgc28gYQ0KICAgY2FzZSBieSBjYXNlIHN0 dWR5IG9mIGVhY2ggYXBwbGljYXRpb24gcmVxdWlyZW1lbnQgc2hvdWxkIGJlIGFwcGxpZWQuDQog ICBCZWZvcmUgYWRkaW5nIG9yIGltcG9ydGluZyBhIGNvbW1hbmQsIGFwcGxpY2F0aW9uIGRlc2ln bmVycyBzaG91bGQNCiAgIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIENhbiB0aGUg bmV3IGZ1bmN0aW9uYWxpdHkgYmUgZnVsZmlsbGVkIGJ5IGNyZWF0aW5nIGEgbmV3DQogICAgICBh cHBsaWNhdGlvbiBpbmRlcGVuZGVudCBmcm9tIHRoZSBleGlzdGluZyBhcHBsaWNhdGlvbnMgPyAg SW4gdGhpcw0KICAgICAgY2FzZSwgYSBkZXBsb3ltZW50IGFyY2hpdGVjdHVyZSBjb3VsZCBiZSBk ZXNpZ25lZCBzdWNoIHRoYXQgYm90aA0KICAgICAgb2xkIGFuZCBuZXcgYXBwbGljYXRpb24gY2Fu IHdvcmsgaW5kZXBlbmRlbnQgb2YgYnV0IGNvb3BlcmF0aW5nDQogICAgICB3aXRoIGVhY2ggb3Ro ZXIuDQoNCiAgIG8gIENhbiB0aGUgZXhpc3RpbmcgYXBwbGljYXRpb24gYmUgcmV1c2VkIGFzIGlz IHdpdGhvdXQgZnVuZGFtZW50YWwNCiAgICAgIGNoYW5nZXM7IGkuZS4gYSBub24tbWFuZGF0b3J5 IG9wdGlvbmFsIEFWUCBpcyBzdWZmaWNpZW50IHRvDQogICAgICBpbmRpY2F0ZSBzdXBwb3J0IGZv ciBuZXcgb3B0aW9uYWwgZnVuY3Rpb25hbGl0eSBpZiBhbnkuICBUaGVyZSBhcmUNCiAgICAgIHBp dGZhbGxzIHRvIHRoaXMgYXMgd2VsbC4gIFNlZSBTZWN0aW9uIDQuMi4xDQoNCiAgIG8gIFdTISBU byBiZSBpbiBsaW5lIHdpdGggdGhlICJjb25zaWRlciIgLS0+IFdpbGwgaW1wb3J0aW5nIG1hbnkg Y29tbWFuZHMgbGVhZCB0byBhIG1vbm9saXRoaS4uLg0KICAgICAgQ2FyZSBzaG91bGQgYmUgdGFr ZW4gdG8gYXZvaWQgYSBsaWJlcmFsIG1ldGhvZCBvZiBpbXBvcnRpbmcgbWFueQ0KICAgICAgY29t bWFuZHMgdGhhdCByZXN1bHRzIGluIGEgbW9ub2xpdGhpYyBhbmQgaGFyZCB0byBtYW5hZ2UNCiAg ICAgIGFwcGxpY2F0aW9uIHdoaWNoIHN1cHBvcnRzIG1hbnkgZGlmZmVyZW50IGZ1bmN0aW9uYWxp dHkuDQoNCg0KDQoNCkZhamFyZG8sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNywg MjAwOCAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICBEaWFtZXRl ciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRlbGluZXMgICAgICAgSnVseSAyMDA3DQoNCg0KICAg byAgV2lsbCB0aGUgbmV3IGZlYXR1cmUgb3IgZnVuY3Rpb25hbGl0eSByZWZlcnMgb25seSB0byBz ZW1hbnRpYyBvcg0KICAgICAgc3RhdGVtYWNoaW5lIGNoYW5nZXMgaW4gdGhlIGFwcGxpY2F0aW9u IHJlcXVpcmluZyBleHRyYSBtZXNzYWdlDQogICAgICByb3VuZC10cmlwcyA/ICBJbiBzdWNoIGNh c2VzLCBkZWZpbml0aW9uIG9mIG5ldyBjb21tYW5kcyBtYXkgbm90DQogICAgICBiZSBuZWNlc3Nh cnkgYW5kIHVzZSBvZiBleGlzdGluZyBjb21tYW5kcyBtYXliZSBzdWZmaWNpZW50Lg0KICAgbyAg UmV1c2Ugb2YgZXhpc3RpbmcgYXBwbGljYXRpb25zIHdvdWxkIHJlc3VsdCBpbiBhIGRpc3RyaWJ1 dGVkDQogICAgICBlbnZpcm9ubWVudCB3aGljaCBtYXkgbm90IGJlIGNvbmR1Y2l2ZSB0byBjZXJ0 YWluIHJlcXVpcmVtZW50cyBvZg0KICAgICAgdGhlIGFwcGxpY2F0aW9uczsgaS5lLiBzZWN1cml0 eSBhbmQgb3IgZGVwbG95bWVudCBkaWZmaWN1bHRpZXMgLQ0KICAgICAgYmVjYXVzZSBvZiBEaWFt ZXRlciByb3V0aW5nLCBtZXNzYWdlcyBmb3IgZGlmZmVyZW50IGFwcGxpY2F0aW9ucw0KICAgICAg cHJvdmlkaW5nIHNlcnZpY2UgdG8gdGhlIHNhbWUgdXNlciBtYXkgZW5kIHVwIGluIGRpZmZlcmVu dCBzZXJ2ZXJzDQogICAgICB3b3VsZCB0aGVuIG5lZWQgdG8gYmUgY28tcmVsYXRlZC4gIFRoaXMg Y291bGQgbWVhbiBleHRyYSBzaWduYWxpbmcNCiAgICAgIGJldHdlZW4gYXBwbGljYXRpb24gc2Vy dmVycy4gIEEgdHlwaWNhbCBleGFtcGxlIHdvdWxkIGJlIHRoZQ0KICAgICAgaW5pdGlhbCBwcm9w b3NhbCBmb3IgRGlhbWV0ZXIgTUlQdjYgc3BsaXQgc2NlbmFyaW8gKHNlZSBbMl0pIHdoZXJlDQog ICAgICBhdXRob3JpemF0aW9uIGFuZCBhdXRoZW50aWNhdGlvbiBpcyBzZXBhcmF0ZWQuDQoNCiAg IE5vdGUgdGhhdCBhY2NvdW50aW5nIGNvbW1hbmRzIG5vcm1hbGx5IHJlcXVpcmUgc3BlY2lhbCB0 cmVhdG1lbnQgYW5kDQogICB3b3VsZCBub3QgbmVjZXNzYXJpbHkgZmFsbCBpbnRvIHRoaXMgY2F0 ZWdvcnkuICBTZWUgU2VjdGlvbiA2LjEuDQoNCjQuMS4yLiAgRGVsZXRpbmcgYSBjb21tYW5kDQoN CiAgIEFsdGhvdWdoIHRoaXMgaXMgbm90IHR5cGljYWwsIGRlbGV0aW5nIGFuIGNvbW1hbmQgZnJv bSBhbiBleGlzdGluZw0KICAgYXBwbGljYXRpb24gaXMgZnVuZGFtZW50YWxseSBjaGFuZ2luZyB0 aGUgYXBwbGljYXRpb24uICBJbiBnZW5lcmFsLA0KICAgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGlz IGFwcHJvYWNoIGlzIHRoZSBzYW1lIGFzIFNlY3Rpb24gNC4xLjENCiAgIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBuZXcgY29tbWFuZHMgd2lsbCBhbHNvIGJlIGFkZGVkIHRvIHRoZQ0KICAgcmVzdWx0 aW5nIGFwcGxpY2F0aW9uLiAgSW4gZ2VuZXJhbCwgaXQgaXMgdW51c3VhbCB0byBkZWxldGUgYW4N CiAgIGV4aXN0aW5nIGNvbW1hbmQgZnJvbSBhbiBleGlzdGluZyBmb3IgdGhlIHNha2Ugb2YgZGVs ZXRpbmcgaXQgb3IgdGhlDQogICBmdW5jdGlvbmFsaXR5IGl0IHJlcHJlc2VudHMuICBUaGlzIGRl c2lnbiBkZWNpc2lvbiB3b3VsZCBub3JtYWxseSBiZQ0KICAgYW4gaW5kaWNhdGlvbiBvZiBhIGZs YXdlZCBkZXNpZ24gKGVkKSAuICBBbiBleGNlcHRpb24gbWlnaHQgYmUgaWYgdGhlDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgV1MhXl4NCiAgIGludGVudCBvZiB0aGUgZGVsZXRp b24gaXMgdG8gY3JlYXRlIGEgbmV3ZXIgdmVyc2lvbiBvZiB0aGUgc2FtZQ0KICAgYXBwbGljYXRp b24gd2hpY2ggaXMgc29tZWhvdyBzaW1wbGVyIHRoYW4gdGhlIHByZXZpb3VzIHZlcnNpb24uICBJ bg0KICAgdGhhdCBjYXNlLCB0aGUgY29uc2lkZXJhdGlvbnMgaW4gU2VjdGlvbiA2LjMgc2hvdWxk IGFwcGx5IGluc3RlYWQuDQoNCjQuMi4gIFJldXNpbmcgRXhpc3RpbmcgQ29tbWFuZHMNCg0KICAg VGhpcyBzZWN0aW9uIGRlYWxzIHdpdGggYSBsaXR0bGUgbW9yZSBncmFudWxhcml0eSB0aGFuIFNl Y3Rpb24gNC4xLg0KICAgU3BlY2lmaWNhbGx5LCBpdCBkaXNjdXNzZXMgcnVsZXMgaW4gYWRkaW5n IGFuZC9vciBkZWxldGluZyBBVlBzIGZyb20NCiAgIGFuIGV4aXN0aW5nIGNvbW1hbmQgb2YgYW4g ZXhpc3RpbmcgYXBwbGljYXRpb24uICBVbmxpa2UgU2VjdGlvbiA0LjEsDQogICB0aGUgY2FzZXMg aW4gdGhpcyBzZWN0aW9uIG1heSBub3QgbmVjZXNzYXJpbHkgcmVzdWx0IGluIHRoZSBjcmVhdGlv bg0KICAgb2YgbmV3IGFwcGxpY2F0aW9uKHMpLiAgSW4gc29tZSBjYXNlcywgdGhlcmUgYXJlIGEg bG90IG9mIGFtYmlndWl0eS4NCiAgIFNvIGRlc2lnbiBjb25zaWRlcmF0aW9ucyBoYXZlIGJlZW4g b3V0bGluZSB0byBlYXNlIHRoZSBkZWNpc2lvbg0KICAgbWFraW5nIHByb2Nlc3MuDQoNCjQuMi4x LiAgQWRkaW5nIEFWUHMgdG8gYSBjb21tYW5kDQoNCiAgIEJhc2VkIG9uIHRoZSBydWxlcyBpbiBb MV0sIEFWUHMgdGhhdCBhcmUgYWRkZWQgdG8gYW4gZXhpc3RpbmcgY29tbWFuZA0KICAgY2FuIGJl IGNhdGVnb3JpemVkIGludG86DQogICBvICBNYW5kYXRvcnkgdG8gdW5kZXJzdGFuZCBBVlBzLiAg QXMgZGVmaW5lZCBpbiBbMV0sIHRoZXNlIGFyZSBBVlBzDQogICAgICB3aGljaCBoYXMgdGhlaXIg TS1iaXQgZmxhZyBzZXQgd2hpY2ggbWVhbnMgRGlhbWV0ZXIgbm9kZXMgdGhhdA0KICAgICAgcmVj ZWl2ZXMgdGhlc2UgQVZQcyBoYXMgdG8gdW5kZXJzdGFuZCBub3Qgb25seSB0aGVpciB2YWx1ZXMg YnV0DQoNCg0KDQpGYWphcmRvLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDcsIDIw MDggICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgRGlhbWV0ZXIg QXBwbGljYXRpb25zIERlc2lnbiBHdWlkZWxpbmVzICAgICAgIEp1bHkgMjAwNw0KDQoNCiAgICAg IHRoZWlyIHNlbWFudGljcyBhbmQgdXNhZ2UgYXMgd2VsbC4gIFRoaXMgaXMgcmVnYXJkbGVzcyBv ZiB3aGV0aGVyDQogICAgICB0aGVzZSBBVlBzIGFyZSByZXF1aXJlZCBvciBvcHRpb25hbCB0byBh cHBlYXIgaW4gdGhlIGNvbW1hbmQ7IGFzDQogICAgICBzcGVjaWZpZWQgYnkgdGhlIGNvbW1hbmRz IEFCTkYuDQogICBvICBOb24tbWFuZGF0b3J5IEFWUHMgdGhhdCBhcmUgYWxzbyBvcHRpb25hbCBp biB0aGUgY29tbWFuZHMgQUJORi4NCg0KICAgVGhlIHJ1bGVzIGFyZSBzdHJpY3QgaW4gdGhlIGNh c2Ugd2hlcmUgdGhlIEFWUHMgdG8gYmUgYWRkZWQgaXMNCiAgIG1hbmRhdG9yeS4gIEEgbWFuZGF0 b3J5IGNhbm5vdCBiZSBhZGRlZCB0byBvciBkZWxldGVkIGZyb20gYW4NCiAgIGV4aXN0aW5nIGNv bW1hbmQuIFsxXSBzdGF0ZXMgdGhhdCBkb2luZyBzbyB3b3VsZCByZXF1aXJlIHRoZQ0KICAgZGVm aW5pdGlvbiBvZiBhIG5ldyBhcHBsaWNhdGlvbi4gIFRoaXMgZmFsbHMgaW50byB0aGUgIkludmFz aXZlIg0KICAgY2F0ZWdvcnkgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4gIERlc3BpdGUgdGhlIGNs YXJpdHkgb2YgdGhlIHJ1bGUsDQogICBhbWJpZ3VpdHkgc3RpbGwgYXJpc2VzIHdoZW4gdHJ5aW5n IHRvIGRlY2lkZSB3aGV0aGVyIGEgbmV3IEFWUCBiZWluZw0KICAgYWRkZWQgc2hvdWxkIGJlIG1h bmRhdG9yeSB0byBiZWdpbiB3aXRoLiAgVGhlcmUgYXJlIHNldmVyYWwgcXVlc3Rpb25zDQogICB0 aGF0IGFwcGxpY2F0aW9uIGRlc2lnbmVycyBzaG91bGQgY29udGVtcGxhdGUgd2hlbiB0cnlpbmcg dG8gZGVjaWRlOg0KDQogICBvICBEb2VzIHRoZSBBVlBzIGNoYW5nZSB0aGUgc3RhdGUgbWFjaGlu ZSBvZiB0aGUgYXBwbGljYXRpb24gPw0KDQogICBvICBXb3VsZCB0aGUgcHJlc2VuY2Ugb2YgdGhl IEFWUHMgY2F1c2UgYWRkaXRpb25hbCBtZXNzYWdlIHJvdW5kLQ0KICAgICAgdHJpcHM7IGVmZmVj dGl2ZWx5IGNoYW5naW5nIHRoZSBzdGF0ZSBtYWNoaW5lIG9mIHRoZSBhcHBsaWNhdGlvbiA/DQoN CiAgIG8gIFdpbGwgdGhlIEFWUCBiZSB1c2VkIHRvIGZ1bGZpbGwgbmV3IHJlcXVpcmVkIGZ1bmN0 aW9uYWxpdHkgPw0KDQogICBvICBXb3VsZCB0aGUgQVZQIGJlIHVzZWQgdG8gZGlmZmVyZW50aWF0 ZSBiZXR3ZWVuIG9sZCBhbmQgbmV3DQogICAgICB2ZXJzaW9ucyBvZiB0aGUgc2FtZSBhcHBsaWNh dGlvbiA/DQoNCiAgIG8gIFdpbGwgaXQgaGF2ZSBkdWFsaXR5IGluIG1lYW5pbmc7IGkuZS4sIGJl IHVzZWQgdG8gY2FycnkNCiAgICAgIGFwcGxpY2F0aW9uIHJlbGF0ZWQgaW5mb3JtYXRpb24gYXMg d2VsbCBhcyBiZSB1c2VkIHRvIGluZGljYXRlDQogICAgICB0aGF0IHRoZSBtZXNzYWdlIGlzIGZv ciBhIG5ldyBhcHBsaWNhdGlvbiA/DQoNCiAgIElmIG9uZSBvciBtb3JlIG9mIHRoZSBhYm92ZSBj b25kaXRpb25zIGFyZSB0cnVlLCB0aGUgQVZQIGlzIGNvbnNpZGVyDQogICBtYW5kYXRvcnkuICBU aGVzZSBxdWVzdGlvbnMgYXJlIG5vdCBjb21wcmVoZW5zaXZlIGluIGFueSB3YXkgYnV0IGluDQog ICBhbGwgY2FzZXMgdGhlIHNlbWFudGljcyBvZiB0aGUgYXBwbGljYXRpb24gbXVzdCBjaGFuZ2Ug dG8ganVzdGlmeSB0aGUNCiAgIHVzZSBvZiBtYW5kYXRvcnkgQVZQcy4NCg0KICAgVGhlIHJ1bGVz IGFyZSBsZXNzIHJlc3RyaWN0aXZlIHdoZW4gYWRkaW5nIE5vbi1tYW5kYXRvcnksIG9wdGlvbmFs DQogICBBVlBzLiAgVGhpcyBmYWxscyBpbnRvIHRoZSAiTWluaW1hbCIgY2F0ZWdvcnkgZGVzY3Jp YmVkIGluIFNlY3Rpb24gNC4NCiAgIEhvd2V2ZXIsIGNhcmUgc2hvdWxkIGFsc28gYmUgdGFrZW4g d2hlbiBvcHRpbmcgZm9yIG9wdGlvbmFsIEFWUHMNCiAgIGluc3RlYWQgb2YgbWFuZGF0b3J5IEFW UHMgc2ltcGx5IHRvIGF2b2lkIHRoZSBwcm9jZXNzIG9mIGNyZWF0aW5nIGENCiAgIG5ldyBhcHBs aWNhdGlvbiAocykuICBPcHRpb25hbCBBVlBzIHRoYXQgYW5zd2VycyBhbnkgb2YgdGhlIHF1ZXN0 aW9ucw0KICAgICAgICAgICAgICAgICBXUyFeXg0KICAgYWJvdmUgYWxzbyBoYXZlIGNvbnNlcXVl bmNlcy4gIFNvbWUgb2YgdGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGgNCiAgIHVzaW5nIG9wdGlv bmFsIEFWUHMgYXJlOg0KDQogICBvICBVc2Ugb2Ygb3B0aW9uYWwgQVZQcyB3aXRoIGludGVyc2Vj dGluZyBtZWFuaW5nOyBvbmUgQVZQIGhhcw0KICAgICAgcGFydGlhbGx5IHRoZSBzYW1lIHVzYWdl IGFuZC9vciBtZWFuaW5nIGFzIGFub3RoZXIgQVZQLiAgVGhlDQogICAgICBwcmVzZW5jZSBvZiBi b3RoIGNhbiBsZWFkIHRvIGNvbmZ1c2lvbi4NCg0KICAgbyAgQW4gb3B0aW9uYWwgQVZQcyB3aXRo IGR1YWwgcHVycG9zZTsgaS5lLjsgdG8gY2FycnkgYXBwbGljYXRpb25zDQogICAgICBkYXRhIGFz IHdlbGwgYXMgdG8gaW5kaWNhdGUgc3VwcG9ydCBmb3Igb25lIG9yIG1vcmUgZmVhdHVyZXMuDQog ICAgICBUaGlzIGhhcyBhIHRlbmRlbmN5IHRvIGludHJvZHVjZSBpbnRlcnByZXRhdGlvbiBpc3N1 ZXMuDQoNCg0KDQpGYWphcmRvLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDcsIDIw MDggICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgRGlhbWV0ZXIg QXBwbGljYXRpb25zIERlc2lnbiBHdWlkZWxpbmVzICAgICAgIEp1bHkgMjAwNw0KDQoNCiAgIG8g IFVzZSBvZiBvcHRpb25hbCBBVlBzIHdpdGggYSBtaW5pbXVtIG9jY3VycmVuY2Ugb2Ygb25lKDEp IGluIHRoZQ0KICAgICAgY29tbWFuZCBBQk5GLiAgVGhpcyBpcyBnZW5lcmFsbHkgY29udHJhZGlj dG9yeS4gIEFwcGxpY2F0aW9uDQogICAgICBkZXNpZ25lcnMgc2hvdWxkIG5vdCB1c2UgdGhpcyBz Y2hlbWUgdG8gY2lyY3VtdmVudCBkZWZpbml0aW9uIG9mDQogICAgICBtYW5kYXRvcnkgQVZQcy4N Cg0KICAgQWxsIG9mIHRoZXNlIHByYWN0aWNlcyBnZW5lcmFsbHkgcmVzdWx0IGluIGludGVyb3Bl cmFiaWxpdHkgcHJvYmxlbXMNCiAgIHNvIHRoZXkgc2hvdWxkIGJlIGF2b2lkZWQgYXMgbXVjaCBh cyBwb3NzaWJsZS4NCg0KNC4yLjIuICBEZWxldGluZyBBVlBzIGZyb20gYSBjb21tYW5kDQoNCiAg IEFsdGhvdWdoIHRoaXMgc2NlbmFyaW8gaXMgbm90IGFzIGNvbW1vbiwgdGhlIGRlbGV0aW9uIG9m IEFWUHMgZnJvbSBhDQogICBjb21tYW5kIEFCTkYgaXMgc2lnbmlmaWNhbnQgd2hlbiB0cnlpbmcg dG8gZXh0ZW5kIGFuIGV4aXN0aW5nDQogICBhcHBsaWNhdGlvbi4gIERlbGV0aW9uIGNhbiBhZ2Fp biBiZSBjYXRlZ29yaXplZCBiZXR3ZWVuIG1hbmRhdG9yeSBhbmQNCiAgIG5vbi1tYW5kYXRvcnkg b3B0aW9uYWwgQVZQcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjIuMS4NCg0KICAgSW4gdGhlIHVu bGlrZWx5IGV2ZW50IHRoYXQgYW4gYXBwbGljYXRpb24gZGVzaWduZXIgd291bGQgcmVxdWlyZSB0 aGF0DQogICBtYW5kYXRvcnkgQVZQcyBtdXN0IGJlIGRlbGV0ZWQgdGhlbiBpdCBjb25zdGl0dXRl cyBhIGZ1bmRhbWVudGFsDQogICBjaGFuZ2UgdG8gYW4gZXhpc3RpbmcgYXBwbGljYXRpb24uICBU aG91Z2ggbm90IHNwZWNpZmllZCBpbiBbMV0sDQogICBkZWxldGlvbiBvZiBtYW5kYXRvcnkgd291 bGQgcmVxdWlyZSB0aGUgZGVmaW5pdGlvbiBvZiBhIG5ldw0KICAgYXBwbGljYXRpb24gc2luY2Ug aXQgZGljdGF0ZXMgY2hhbmdlcyBpbiB0aGUgYmVoYXZpb3IgYW5kIHNlbWFudGljcw0KICAgb2Yg YW4gYXBwbGljYXRpb24uDQoNCiAgIEluc3RlYWQgb2YgZGVsZXRpbmcgY29tbWFuZHMsIGEgYmV0 dGVyIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGRlZmluZQ0KICAgYSBuZXcgY29tbWFuZCB0aGF0 IHdvdWxkIHJlcHJlc2VudCB0aGUgbmV3IGJlaGF2aW9yLiAgUmV1c2luZyB0aGUNCiAgIHNhbWUg Y29tbWFuZCBjb2RlIGZvciBkaWZmZXJlbnQgdXNlIGNhc2VzIGNhbiBsZWFkIHRvIG1vcmUgY29u ZnVzaW9uDQogICBzaW5jZSB0aGUgY29tbWFuZCB3aWxsIGhhdmUgZGlmZmVyZW50IHNlbWFudGlj cyBkZXBlbmRpbmcgb24gdXNhZ2UuDQogICBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB0byBiYXNl IHByb3RvY29sIGNvbW1hbmRzIChzZXNzaW9uIHJlbGF0ZWQNCiAgIGNvbW1hbmRzLCBBU1IvQVNB LCBTVFIvU1RBLCBSQVIvUkFBIGRlZmluZWQgaW4gWzFdKSB3aGVyZSB0aGV5IGFyZQ0KICAgYmVp bmcgdXNlZCBieSBtYW55IGRpZmZlcmVudCBhcHBsaWNhdGlvbnMuDQoNCiAgIFRoZSBkZWxldGlv biBvZiBhbiBvcHRpb25hbCBBVlAgbWF5IG5vdCBuZWNlc3NhcmlseSBpbmRpY2F0ZQ0KICAgYWxs b2NhdGlvbiBvZiBhIG5ldyBhcHBsaWNhdGlvbi4gIERlbGV0aW9uIG9mIG5vbi1tYW5kYXRvcnkg b3B0aW9uYWwNCiAgIEFWUHMgd2l0aCBhIHplcm8oMCkgbWluaW11bSBvY2N1cnJlbmNlIGluIHRo ZSBjb21tYW5kcyBBQk5GIHdvdWxkIG5vdA0KICAgcmVxdWlyZSBhIG5ldyBhcHBsaWNhdGlvbi4g IEluIHRoZSBjYXNlIHdoZXJlIGFuIG9wdGlvbmFsIEFWUCBoYXMgYQ0KICAgbWluaW11bSBvY2N1 cnJlbmNlIG9mIGF0IGxlYXN0IG9uZSgxKSBpbiB0aGUgY29tbWFuZHMgQUJORiwgdGhlbg0KICAg ZGVsZXRpb24gb2YgdGhlIEFWUCB3b3VsZCBlZmZlY3RpdmVseSBjaGFuZ2UgdGhlIGJlaGF2aW9y IG9mIHRoZQ0KICAgYXBwbGljYXRpb24uICBJdCB3b3VsZCBiZSBzaW1pbGFyIHRvIHRoZSBkZWxl dGlvbiBvZiBtYW5kYXRvcnkgQVZQcy4NCiAgIFN1Y2ggY2FzZXMgYXJlIGhpZ2hseSBkdWJpb3Vz IHRvIGJlZ2luIHdpdGggc2luY2UgdGhvc2UgQVZQcyBhbHJlYWR5DQogICBleGhpYml0cyBwcm9w ZXJ0aWVzIG9mIG1hbmRhdG9yeSBBVlBzLiAgRXh0cmEgY29uc2lkZXJhdGlvbiBzaG91bGQgYmUN CiAgIGdpdmVuIGFzIHRvIHdoeSBpdCB3YXMgbm90IGRlZmluZWQgYXMgbWFuZGF0b3J5IGluIHRo ZSBmaXJzdCBwbGFjZQ0KICAgYW5kIHRoYXQgZGVjaXNpb24gbWF5IGhhdmUgdG8gYmUgY29ycmVj dGVkIGFzIHdlbGwuDQoNCiAgIEluIG90aGVyIGNhc2VzLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0 IGFwcGxpY2F0aW9uIGRlc2lnbmVycyByZXVzZQ0KICAgdGhlIGNvbW1hbmQgQUJORiB3aXRob3V0 IG1vZGlmaWNhdGlvbiBhbmQgc2ltcGx5IGlnbm9yZSAoYnV0IG5vdA0KICAgZGVsZXRlKSBhbnkg b3B0aW9uYWwgQVZQIHRoYXQgd2lsbCBub3QgYmUgdXNlZC4gIFRoaXMgaXMgdG8gbWFpbnRhaW4N CiAgIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBhcHBsaWNhdGlvbnMgdGhhdCB3aWxsIG5v dCBrbm93IGFib3V0IHRoZQ0KICAgbmV3IGZ1bmN0aW9uYWxpdHkgYXMgd2VsbCBhcyBtYWludGFp biB0aGUgaW50ZWdyaXR5IG9mIGV4aXN0aW5nDQogICBkaWN0aW9uYXJpZXMuDQoNCg0KDQpGYWph cmRvLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDcsIDIwMDggICAgICAgICAgICAg ICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgRGlhbWV0ZXIgQXBwbGljYXRpb25zIERl c2lnbiBHdWlkZWxpbmVzICAgICAgIEp1bHkgMjAwNw0KDQoNCjQuMy4gIFJldXNpbmcgRXhpc3Rp bmcgQVZQcw0KDQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCBldmVuIG1vcmUgZ3JhbnVsYXJp dHkgdGhhbiBTZWN0aW9uIDQuMSBhbmQNCiAgIFNlY3Rpb24gNC4yLiAgU3BlY2lmaWNhbGx5LCBp dCBkaXNjdXNzZXMgcnVsZXMgaW4gYWRkaW5nLCBkZWxldGluZyBvcg0KICAgbW9kaWZ5aW5nIHRo ZSBzcGVjaWZpZWQgdmFsdWVzIG9mIGFuIEFWUC4gIFRoZSBydWxlcyBzdGF0ZSB0aGF0DQogICBt b2RpZnlpbmcgdGhlIHZhbHVlIG9mIGFuIEFWUCBpcyBhbGxvd2VkIG9ubHkgaWYgaXQgZG9lcyBu b3QgY2hhbmdlDQogICB0aGUgc2VtYW50aWNzIG9mIHRoZSBBVlAgYW5kIHRoZSBhcHBsaWNhdGlv biB1c2luZyBpdC4gIE90aGVyd2lzZSwNCiAgIHRoZSBjaGFuZ2UgY2FuIGJlIGNvbnNpZGVyICJJ bnZhc2l2ZSIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBhbmQNCiAgIHJlcXVpcmUgZGVmaW5p dGlvbiBvZiBhIG5ldyBhcHBsaWNhdGlvbi4gIE5vdGUgdGhhdCBkZXNpZ25lcnMgc2hvdWxkDQog ICBjb25zaWRlciBTZWN0aW9uIDUuMiB3aGVuIGNvbnRlbXBsYXRpbmcgb24gdGhlc2UgdHlwZXMg b2YgY2hhbmdlcy4NCg0KICAgVHlwaWNhbGx5LCB0aGUgZGF0YSB0eXBlcyBvZiB0aGUgQVZQcyBp biBxdWVzdGlvbiBhcmUgc2NhbGFyIGluDQogICBuYXR1cmUgYW5kIGVhY2ggb3JkaW5hbCB2YWx1 ZSByZXByZXNlbnQgYSBzcGVjaWZpYyBzZW1hbnRpYyBiZWhhdmlvcg0KICAgb2YgdGhlIGFwcGxp Y2F0aW9uLiAgQW4gZXhhbXBsZSBpcyBDQy1SZXF1ZXN0LVR5cGUgQVZQIG9mIFs0XS4NCiAgIEFk ZGluZywgZGVsZXRpbmcgb3IgbW9kaWZ5aW5nIGtub3duIHZhbHVlcyBvZiB0aGlzIEFWUCBjYW4g bW9kaWZ5IHRoZQ0KICAgYmVoYXZpb3Igb2YgdGhlIGFwcGxpY2F0aW9uIGl0c2VsZi4gIEFkZGl0 aW9uYWxseSwgdGhlIG1hbmRhdG9yeSBhbmQNCiAgIG9wdGlvbmFsIEFWUHMgcnVsZXMgYXJlIGlu aGVyaXRlZCBmcm9tIFNlY3Rpb24gNC4yLiAgU28gdGhpcyBhZmZlY3RzDQogICB0aGUgZGVjaXNp b24gZm9yIGRlZmluaW5nIG5ldyBhcHBsaWNhdGlvbnMgYXMgd2VsbC4NCg0KDQo1LiAgUnVsZXMg Zm9yIG5ldyBBcHBsaWNhdGlvbnMNCg0KICAgVGhlIGdlbmVyYWwgdGhlbWUgb2YgRGlhbWV0ZXIg ZXh0ZW5zaWJpbGl0eSBpcyB0byByZXVzZSBjb21tYW5kcywNCiAgIEFWUHMgYW5kIEFWUCB2YWx1 ZXMgYXMgbXVjaCBhcyBwb3NzaWJsZS4gIEhvd2V2ZXIsIHNvbWUgb2YgdGhlDQogICBleHRlbnNp YmlsaXR5IHJ1bGVzIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbiBhbHNvIGFwcGx5 IHRvDQogICBzY2VuYXJpb3Mgd2hlcmUgYSBkZXNpZ25lciBpcyB0cnlpbmcgdG8gZGVmaW5lIGEg Y29tcGxldGVseSBuZXcNCiAgIERpYW1ldGVyIGFwcGxpY2F0aW9uLg0KDQogICBUaGlzIHNlY3Rp b24gZGlzY3Vzc2VzIHRoZSBjYXNlIHdoZXJlIG5ldyBhcHBsaWNhdGlvbnMgaGF2ZQ0KICAgcmVx dWlyZW1lbnRzIHRoYXQgY2Fubm90IGJlIGZpbGxlZCBieSBleGlzdGluZyBhcHBsaWNhdGlvbnMg YW5kIHdvdWxkDQogICByZXF1aXJlIGRlZmluaXRpb24gb2YgY29tcGxldGVseSBuZXcgY29tbWFu ZHMsIEFWUHMgYW5kL29yIEFWUA0KICAgdmFsdWVzLiAgVHlwaWNhbGx5LCB0aGVyZSBpcyBsaXR0 bGUgYW1iaWd1aXR5IGFib3V0IHRoZSBkZWNpc2lvbiB0bw0KICAgY3JlYXRlIHRoZXNlIHR5cGVz IG9mIGFwcGxpY2F0aW9ucy4gIFNvbWUgZXhhbXBsZXMgYXJlIHRoZSBpbnRlcmZhY2VzDQogICBk ZWZpbmVkIGZvciB0aGUgSVAgTXVsdGltZWRpYSBTdWJzeXN0ZW0gb2YgM0dQUCwgaS5lLjsgQ3gv RHggKFs1XSBhbmQNCiAgIFs2XSksIFNoIChbN10gYW5kIFs4XSkgZXRjLg0KDQogICBBcHBsaWNh dGlvbiBkZXNpZ24gc2hvdWxkIGFsc28gZm9sbG93IHRoZSB0aGVtZSBvZiBEaWFtZXRlcg0KICAg ZXh0ZW5zaWJpbGl0eSB3aGljaCBpbiB0aGlzIGNhc2UgbWF5IG1lYW4gaW1wb3J0aW5nIG9mIGV4 aXN0aW5nIEFWUHMNCiAgIGFuZCBBVlAgdmFsdWVzIGZvciBhbnkgbmV3bHkgZGVmaW5lZCBjb21t YW5kcy4gIEluIGNlcnRhaW4gY2FzZXMNCiAgIHdoZXJlIGFjY291bnRpbmcgd2lsbCBiZSB1c2Vk LCB0aGUgbW9kZWxzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDYuMQ0KICAgc2hvdWxkIGFsc28gYmUg Y29uc2lkZXJlZC4gIFRob3VnaCBzb21lIGRlY2lzaW9ucyBtYXkgYmUgY2xlYXIsDQogICBkZXNp Z25lcnMgc2hvdWxkIGFsc28gY29uc2lkZXIgY2VydGFpbiBhc3BlY3RzIG9mIGRlZmluaW5nIGEg bmV3DQogICBhcHBsaWNhdGlvbi4gIFNvbWUgb2YgdGhlc2UgYXJlIGRlc2NyaWJlZCBpbiBmb2xs b3dpbmcgc2VjdGlvbnMuDQoNCjUuMS4gIFJ1bGVzIGluIEFsbG9jYXRpbmcgbmV3IENvbW1hbmQg Q29kZXMNCg0KICAgW0VkaXRvcidzIG5vdGU6IFRoZSBleHBlcnQgcmV2aWV3IHByb2Nlc3MgZm9y IGNvbW1hbmQgY29kZSBhbGxvY2F0aW9uDQogICBpcyBiZWluZyBpbnRyb2R1Y2VkIHRvIGhhc3Rl biB0aGUgYWxsb2NhdGlvbiBwcm9jZXNzIGl0c2VsZi4NCg0KDQoNCkZhamFyZG8sIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgNywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICBEaWFtZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRlbGlu ZXMgICAgICAgSnVseSAyMDA3DQoNCg0KICAgSG9wZWZ1bGx5IHRoaXMgd2lsbCBsZXNzZW4gdGhl IHRlbmRlbmN5IHRvIGNpcmN1bXZlbnQgdGhpcyBwcm9jZXNzLg0KICAgVGhlIGNvcmUgcnVsZXMg Zm9yIHRoaXMgcHJvY2VzcyB3aWxsIGJlIGludHJvZHVjZWQgaW4gcmZjMzU4OGJpcyBhbmQNCiAg IGZ1bGwgZGVzY3JpcHRpb24gd2lsbCBiZSBhZGRlZCBpbiB0aGlzIHNlY3Rpb24gaW4gdGhlIG5l eHQgcmV2IG9mDQogICB0aGlzIGRvY3VtZW50XQ0KDQo1LjIuICBKdXN0aWZ5aW5nIHRoZSBBbGxv Y2F0aW9uIG9mIEFwcGxpY2F0aW9uLUlkDQoNCiAgIEFwcGxpY2F0aW9uIGRlc2lnbmVycyBzaG91 bGQgYXZvaWQganVzdGlmeWluZyB0aGUgYWxsb2NhdGlvbiBvZiBhbg0KICAgYXBwbGljYXRpb24g SUQgZm9yIGVhY2ggbmV3IGZ1bmN0aW9uYWxpdHkgb3IgYW55IGNoYW5nZSB0aGF0IGlzIG1hZGUN CiAgIHRvIGFuIGV4aXN0aW5nIGFwcGxpY2F0aW9uLiAgUHJvbGlmZXJhdGlvbiBvZiBhcHBsaWNh dGlvbiBJRCBjYW4gbGVhZA0KICAgdG8gY29uZnVzaW9uIGFuZCBhbiBpbi1lZmZpY2llbnQgdXNl IG9mIHRoZSBhcHBsaWNhdGlvbiBJRA0KICAgbmFtZXNwYWNlcy4gIEFwcGxpY2F0aW9uIGRlc2ln bmVycyBzaG91bGQgYWx3YXlzIHVzZSBTZWN0aW9uIDQgYXMgYQ0KICAgYmFzaXMgZm9yIGp1c3Rp ZnlpbmcgYWxsb2NhdGlvbiBvZiBhIG5ldyBhcHBsaWNhdGlvbiBJRC4NCg0KNS4zLiAgVXNlIG9m IEFwcGxpY2F0aW9uLUlkIGluIGEgTWVzc2FnZQ0KDQogICBXaGVuIGRlc2lnbmluZyBuZXcgYXBw bGljYXRpb25zLCBkZXNpZ25lcnMgc2hvdWxkIHNwZWNpZnkgdGhhdCB0aGUNCiAgIGFwcGxpY2F0 aW9uIElEIGNhcnJpZWQgaW4gYWxsIHNlc3Npb24gbGV2ZWwgbWVzc2FnZXMgbXVzdCBiZSB0aGUN CiAgIGFwcGxpY2F0aW9uIElEIG9mIHRoZSBhcHBsaWNhdGlvbiB1c2luZyB0aG9zZSBtZXNzYWdl cy4gIFRoaXMNCiAgIGluY2x1ZGVzIHRoZSBzZXNzaW9uIGxldmVsIG1lc3NhZ2VzIGRlZmluZWQg aW4gYmFzZSBwcm90b2NvbCwgaS5lLiwNCiAgIFJBUi9SQUEsIFNUUi9TVEEsIEFTUi9BU0EgYW5k IHBvc3NpYmx5IEFDUi9BQ0EgaW4gdGhlIGNvdXBsZWQNCiAgIGFjY291bnRpbmcgbW9kZWwsIHNl ZSBTZWN0aW9uIDYuMS4gIEV4aXN0aW5nIHNwZWNpZmljYXRpb25zIG1heSBub3QNCiAgIGFkaGVy ZSB0byB0aGlzIHJ1bGUgZm9yIGhpc3RvcmljYWwgb3Igb3RoZXIgcmVhc29ucy4gIEhvd2V2ZXIs IHRoaXMNCiAgIHNjaGVtZSBpcyBmb2xsb3dlZCB0byBhdm9pZCBwb3NzaWJsZSByb3V0aW5nIHBy b2JsZW1zIGZvciB0aGVzZQ0KICAgbWVzc2FnZXMuDQoNCiAgIEFkZGl0aW9uYWxseSwgYXBwbGlj YXRpb24gZGVzaWduZXJzIHVzaW5nIHRoZSBWZW5kb3ItU3BlY2lmaWMtDQogICBBcHBsaWNhdGlv bi1JZCBBVlAgc2hvdWxkIG5vdGUgdGhhdCB0aGUgVmVuZG9yLUlkIEFWUCB3aWxsIG5vdCBiZQ0K ICAgdXNlZCBpbiBhbnkgd2F5IGJ5IHRoZSBEaWFtZXRlciBtZXNzYWdlIGRlbGl2ZXJ5IGxheWVy LiAgVGhlcmVmb3JlDQogICBpdHMgbWVhbmluZyBhbmQgdXNhZ2Ugc2hvdWxkIGJlIHNlZ3JlZ2F0 ZWQgb25seSB3aXRoaW4gdGhlDQogICBhcHBsaWNhdGlvbi4NCg0KNS40LiAgQXBwbGljYXRpb24g U3BlY2lmaWMgU2Vzc2lvbiBTdGF0ZW1hY2hpbmUNCg0KICAgU2VjdGlvbiA4IG9mIFsxXSBwcm92 aWRlcyBzZXNzaW9uIHN0YXRlbWFjaGluZXMgZm9yIGF1dGhlbnRpY2F0aW9uLA0KICAgYXV0aG9y aXphdGlvbiBhbmQgYWNjb3VudGluZyAoQUFBKSBzZXJ2aWNlcy4gIFdoZW4gYSBuZXcgYXBwbGlj YXRpb24NCiAgIGlzIGJlaW5nIGRlZmluZWQgdGhhdCBjYW5ub3QgY2xlYXJseSBiZSBjYXRlZ29y aXplZCBpbnRvIGFueSBvZiB0aGVzZQ0KICAgc2VydmljZXMgaXQgaXMgcmVjb21tZW5kZWQgdGhh dCB0aGUgYXBwbGljYXRpb24gaXRzZWxmIGRlZmluZXMgaXRzDQogICBvd24gc2Vzc2lvbiBzdGF0 ZW1hY2hpbmUuICBUaGUgZXhpc3Rpbmcgc2Vzc2lvbiBzdGF0ZW1hY2hpbmVzIGRlZmluZWQNCiAg IGJ5IFsxXSBpcyBub3QgaW50ZW5kZWQgZm9yIGdlbmVyYWwgdXNlIGJleW9uZCBBQUEgc2Vydmlj ZXMgdGhlcmVmb3JlDQogICBhbnkgYmVoYXZpb3Igbm90IGNvdmVyZWQgYnkgdGhhdCBjYXRlZ29y eSB3b3VsZCBub3QgZml0IHdlbGwuDQogICBTdXBwb3J0IGZvciBzZXJ2ZXIgaW5pdGlhdGVkIHJl cXVlc3QgaXMgYSBjbGVhciBleGFtcGxlIHdoZXJlIGFuDQogICBhcHBsaWNhdGlvbiBzcGVjaWZp YyBzZXNzaW9uIHN0YXRlbWFjaGluZSB3b3VsZCBiZSBuZWVkZWQ7IGkuZS4gIFJ3DQogICBpbnRl cmZhY2UgZm9yIElUVS1UIHB1c2ggbW9kZWwuDQoNCg0KDQoNCg0KDQoNCkZhamFyZG8sIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDEx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICBEaWFtZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRl bGluZXMgICAgICAgSnVseSAyMDA3DQoNCg0KNS41LiAgRW5kLXRvLUVuZCBBcHBsaWNhdGlvbnMg Q2FwYWJpbGl0aWVzIEV4Y2hhbmdlDQoNCiAgIEl0IGlzIGFsc28gcG9zc2libGUgdGhhdCBhcHBs aWNhdGlvbnMgY2FuIHVzZSBhIHR5cGUgb2Ygb3B0aW9uYWwNCiAgIGNhcGFiaWxpdGllcyBleGNo YW5nZSBBVlBzIGFzIGEgd2F5IHRvIGNvbnZleSBzdXBwb3J0IGZvciBzcGVjaWZpYw0KICAgYXBw bGljYXRpb24gZmVhdHVyZXMuICBUaGVzZSBBVlBzIGFyZSBleGNoYW5nZWQgb24gYW4gZW5kLXRv LWVuZA0KICAgYmFzaXMgYW5kIGtub3duIG9ubHkgYnkgdGhlIGFwcGxpY2F0aW9uIHN1cHBvcnRp bmcgdGhlbS4gIFRoZSB1c2Ugb2YNCiAgIHN1Y2ggQVZQcyBtdXN0IG9idmlvdXNseSBiZSBsaW1p dGVkIHRvIGNvbnZleSBmdW5jdGlvbmFsaXR5IG9mIHRoZQ0KICAgYXBwbGljYXRpb25zIGl0c2Vs Zi4gIEV4YW1wbGVzIG9mIHRoaXMgY2FuIGJlIGZvdW5kIGluIFsyXSBhbmQgWzNdLg0KDQogICBU aGlzIG1ldGhvZCBjYW4gYmUgdXNlZCB0byByZXNvbHZlIHNvbWUgb2YgdGhlIHByb2JsZW1zIGRl c2NyaWJlZCBpbg0KICAgU2VjdGlvbiA2LjMgYW5kIFNlY3Rpb24gNi4yLiAgSXQgaXMgYWxzbyB1 c2VmdWwgaW4gcHJvdmlkaW5nIHNvbWUNCiAgIHJlc3RyaWN0aW9ucyBhbmQvb3IgZ3VpZGVsaW5l cyAob24gdGhlKSBob3cgdGhlIG90aGVyIGZ1bmN0aW9uYWxpdHkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBXUyFeXl5eXl5eXg0KICAgcmVsYXRlZCBBVlBzIGNhbiBiZSBpbmNsdWRl IGluIGEgY29tbWFuZCB0byBhdm9pZCBpc3N1ZXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDQu Mi4xLiAgU3VjaCBlbmQtdG8tZW5kIGNhcGFiaWxpdGllcyBBVlBzIGNhbiBhaWQgaW4gdGhlDQog ICBmb2xsb3dpbmcgY2FzZXM6DQoNCiAgIG8gIEZvcm1hbGl6aW5nIHRoZSB3YXkgbmV3IGZ1bmN0 aW9uYWxpdHkgaXMgYWRkZWQgdG8gZXhpc3RpbmcNCiAgICAgIGFwcGxpY2F0aW9ucyBieSBhbm5v dW5jaW5nIHN1cHBvcnQgZm9yIGl0LiAgVGhpcyBtYWtlcyBkZXRlcm1pbmluZw0KICAgICAgc3Vw cG9ydCBmb3Igb25lIG9yIG1vcmUgc3BlY2lmaWMgZnVuY3Rpb25hbGl0eSBsZXNzIGFtYmlndW91 cy4NCg0KICAgbyAgUHJvdmlkZSBhIHdheSB0byBmdXJ0aGVyIG5lZ290aWF0ZSBjYXBhYmlsaXRp ZXMgaWYgYWxsb3dlZCBieSB0aGUNCiAgICAgIGFwcGxpY2F0aW9ucy4NCg0KICAgbyAgQXBwbGlj YXRpb25zIHRoYXQgZG8gbm90IHVuZGVyc3RhbmQgdGhlIGNhcGFiaWxpdGllcyBBVlAgY2FuDQog ICAgICBzYWZlbHkgaWdub3JlIGl0IHVwb24gcmVjZWlwdC4gIEluIHN1Y2ggY2FzZSwgc2VuZGVy cyBvZiB0aGUgQVZQDQogICAgICBjYW4gYWxzbyBzYWZlbHkgYXNzdW1lIHRoZSByZWNlaXZpbmcg ZW5kLXBvaW50IGRvZXMgbm90IHN1cHBvcnQNCiAgICAgIGFueSBmdW5jdGlvbmFsaXR5IGNhcnJp ZWQgYnkgdGhlIEFWUCBpZiBpdCBpcyBub3QgcHJlc2VudCBpbg0KICAgICAgc3Vic2VxdWVudCBy ZXNwb25zZXMuDQoNCiAgIE5vdGUgdGhhdCB0aGlzIGxpc3QgaXMgbm90IG1lYW50IHRvIGJlIGNv bXByZWhlbnNpdmUuDQoNCg0KNi4gIE90aGVyIERlc2lnbiBDb25zaWRlcmF0aW9ucw0KDQogICBU aGUgZm9sbG93aW5nIGFyZSBzb21lIG9mIHRoZSBkZXNpZ24gY29uc2lkZXJhdGlvbnMgdGhhdCBh cHBseSB0byBhDQogICBEaWFtZXRlciBhcHBsaWNhdGlvbi4NCg0KNi4xLiAgRGlhbWV0ZXIgQWNj b3VudGluZyBTdXBwb3J0DQoNCiAgIEFjY291bnRpbmcgY2FuIGJlIHRyZWF0ZWQgYXMgYW4gYXV4 aWxpYXJ5IGFwcGxpY2F0aW9uIHdoaWNoIGlzIHVzZWQNCiAgIGluIHN1cHBvcnQgb2Ygb3RoZXIg YXBwbGljYXRpb25zLiAgSW4gbW9zdCBjYXNlcywgYWNjb3VudGluZyBzdXBwb3J0DQogICBpcyBy ZXF1aXJlZCB3aGVuIGRlZmluaW5nIG5ldyBhcHBsaWNhdGlvbnMuICBIb3dldmVyLCB0aGUgbGFj ayBvZg0KICAgY2xhcml0eSBpbiB0aGUgYmFzZSBwcm90b2NvbCBkb2N1bWVudCBoYXMgcHJldmVu dGVkIGVhc3kgdXNlIHRoZSBiYXNlDQogICBhY2NvdW50aW5nIG1lc3NhZ2VzIChBQ1IvQUNBKS4g IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdHdvKDIpDQogICBwb3NzaWJsZSBtb2RlbHMgZm9yIHVz aW5nIGFjY291bnRpbmc6DQoNCg0KDQoNCg0KDQpGYWphcmRvLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDcsIDIwMDggICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgRGlhbWV0ZXIgQXBwbGljYXRpb25zIERlc2lnbiBHdWlkZWxpbmVzICAgICAgIEp1 bHkgMjAwNw0KDQoNCiAgIFNwbGl0IEFjY291bnRpbmcgTW9kZWwNCg0KICAgICAgSW4gdGhpcyBt b2RlbCwgdGhlIGFjY291bnRpbmcgbWVzc2FnZXMgd2lsbCB1c2UgdGhlIERpYW1ldGVyIGJhc2UN CiAgICAgIGFjY291bnRpbmcgYXBwbGljYXRpb24gSUQgKHZhbHVlIG9mIDMpLiAgVGhlIGRlc2ln biBpbXBsaWNhdGlvbg0KICAgICAgZm9yIHRoaXMgaXMgdGhhdCB0aGUgYWNjb3VudGluZyBpcyB0 cmVhdGVkIGFzIGFuIGluZGVwZW5kZW50DQogICAgICBhcHBsaWNhdGlvbiwgZXNwZWNpYWxseSBk dXJpbmcgcm91dGluZy4gIFRoaXMgbWVhbnMgdGhhdA0KICAgICAgYWNjb3VudGluZyBjb21tYW5k cyBlbWFuYXRpbmcgZnJvbSBhbiBhcHBsaWNhdGlvbiBtYXkgYmUgcm91dGVkDQogICAgICBzZXBh cmF0ZWx5IGZyb20gdGhlIHJlc3Qgb2YgdGhlIG90aGVyIGFwcGxpY2F0aW9uIG1lc3NhZ2VzLiAg VGhpcw0KICAgICAgYWxzbyBpbXBsaWVzIHRoYXQgdGhlIG1lc3NhZ2VzIGdlbmVyYWxseSBlbmQg dXAgaW4gYSBjZW50cmFsDQogICAgICBhY2NvdW50aW5nIHNlcnZlci4gIEEgc3BsaXQgYWNjb3Vu dGluZyBtb2RlbCBpcyBhIGdvb2QgZGVzaWduDQogICAgICBjaG9pY2Ugd2hlbjoNCg0KICAgICAg KiAgVGhlIGFwcGxpY2F0aW9uIGl0c2VsZiB3aWxsIG5vdCBkZWZpbmUgaXRzIG93biB1bmlxdWUN CiAgICAgICAgIGFjY291bnRpbmcgY29tbWFuZHMuDQoNCiAgICAgICogIFRoZSBvdmVyYWxsIHN5 c3RlbSBhcmNoaXRlY3R1cmUgcGVybWl0cyB0aGUgdXNlIG9mIGNlbnRyYWxpemVkDQogICAgICAg ICBhY2NvdW50aW5nIGZvciBvbmUgb3IgbW9yZSBEaWFtZXRlciBhcHBsaWNhdGlvbnMuDQoNCiAg ICAgIEZyb20gYSBEaWFtZXRlciBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUsIHRoaXMgbW9kZWwg c2hvdWxkIGJlIHRoZQ0KICAgICAgdHlwaWNhbCBkZXNpZ24gY2hvaWNlLiAgTm90ZSB0aGF0IHdo ZW4gdXNpbmcgdGhpcyBtb2RlbCwgdGhlDQogICAgICBhY2NvdW50aW5nIHNlcnZlciBtdXN0IHVz ZSB0aGUgQWNjdC1BcHBsaWNhdGlvbi1JZCBBVlAgdG8NCiAgICAgIGRldGVybWluZSB3aGljaCBh cHBsaWNhdGlvbiBpcyBiZWluZyBhY2NvdW50ZWQgZm9yLiAgVGhlcmVmb3JlLA0KICAgICAgdGhl IGFwcGxpY2F0aW9uIGRlc2lnbmVyIHNob3VsZCBzcGVjaWZ5IHRoZSBwcm9wZXIgdmFsdWVzIHVz ZWQgaW4NCiAgICAgIEFjY3QtQXBwbGljYXRpb24tSWQgQVZQIHdoZW4gc2VuZGluZyBBQ1IgbWVz c2FnZXMuDQoNCiAgIENvdXBsZWQgQWNjb3VudGluZyBNb2RlbA0KDQogICAgICBJbiB0aGlzIG1v ZGVsLCB0aGUgYWNjb3VudGluZyBtZXNzYWdlcyB3aWxsIHVzZSB0aGUgYXBwbGljYXRpb24gSUQN CiAgICAgIG9mIHRoZSBhcHBsaWNhdGlvbiB1c2luZyB0aGUgYWNjb3VudGluZyBzZXJ2aWNlLiAg VGhlIGRlc2lnbg0KICAgICAgaW1wbGljYXRpb24gZm9yIHRoaXMgaXMgdGhhdCB0aGUgYWNjb3Vu dGluZyBtZXNzYWdlcyBpcyB0aWdodGx5DQogICAgICBjb3VwbGVkIHdpdGggdGhlIGFwcGxpY2F0 aW9uIGl0c2VsZjsgbWVhbmluZyB0aGF0IGFjY291bnRpbmcNCiAgICAgIG1lc3NhZ2VzIHdpbGwg YmUgcm91dGVkIGxpa2UgYW55IG90aGVyIGFwcGxpY2F0aW9uIG1lc3NhZ2VzLiAgSXQNCiAgICAg IHdvdWxkIHRoZW4gYmUgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBhcHBsaWNhdGlvbiBzZXJ2 ZXINCiAgICAgIChhcHBsaWNhdGlvbiBlbnRpdHkgcmVjZWl2aW5nIHRoZSBBQ1IgbWVzc2FnZSkg dG8gc2VuZCB0aGUNCiAgICAgIGFjY291bnRpbmcgcmVjb3JkcyBjYXJyaWVkIGJ5IHRoZSBhY2Nv dW50aW5nIG1lc3NhZ2VzIHRvIHRoZQ0KICAgICAgcHJvcGVyIGFjY291bnRpbmcgc2VydmVyLiAg VGhlIGFwcGxpY2F0aW9uIHNlcnZlciBpcyBhbHNvDQogICAgICByZXNwb25zaWJsZSBmb3IgZm9y bXVsYXRpbmcgYSBwcm9wZXIgcmVzcG9uc2UgKEFDQSkuICBBIGNvdXBsZWQNCiAgICAgIGFjY291 bnRpbmcgbW9kZWwgaXMgYSBnb29kIGRlc2lnbiBjaG9pY2Ugd2hlbjoNCg0KICAgICAgKiAgVGhl IHN5c3RlbSBhcmNoaXRlY3R1cmUgb3IgZGVwbG95bWVudCB3aWxsIG5vdCBwcm92aWRlIGFuDQog ICAgICAgICBhY2NvdW50aW5nIHNlcnZlciB0aGF0IHN1cHBvcnRzIERpYW1ldGVyLg0KDQogICAg ICAqICBUaGUgc3lzdGVtIGFyY2hpdGVjdHVyZSBvciBkZXBsb3ltZW50IHJlcXVpcmVzIHRoYXQg dGhlDQogICAgICAgICBhY2NvdW50aW5nIHNlcnZpY2UgZm9yIHRoZSBzcGVjaWZpYyBhcHBsaWNh dGlvbiBzaG91bGQgYmUNCiAgICAgICAgIGhhbmRsZWQgYnkgdGhlIGFwcGxpY2F0aW9uIGl0c2Vs Zi4NCg0KDQoNCg0KDQoNCkZhamFyZG8sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEphbnVhcnkg NywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICBEaWFt ZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRlbGluZXMgICAgICAgSnVseSAyMDA3DQoNCg0K ICAgICAgKiAgVGhlIGFwcGxpY2F0aW9uIHNlcnZlciBpcyBwcm92aXNpb25lZCB0byB1c2UgYSBk aWZmZXJlbnQNCiAgICAgICAgIHByb3RvY29sIHRvIGFjY2VzcyB0aGUgYWNjb3VudGluZyBzZXJ2 ZXI7IGkuZS4sIHZpYSBMREFQLCBYTUwNCiAgICAgICAgIGV0Yy4gIFRoaXMgaW5jbHVkZXMgYXR0 ZW1wdGluZyB0byBzdXBwb3J0aW5nIG9sZGVyIGFjY291bnRpbmcNCiAgICAgICAgIHN5c3RlbXMg dGhhdCBhcmUgbm90IERpYW1ldGVyIGF3YXJlLg0KDQogICAgICBJbiBhbGwgY2FzZXMgYWJvdmUs IHRoZXJlIHdpbGwgZ2VuZXJhbGx5IGJlIG5vIGRpcmVjdCBEaWFtZXRlcg0KICAgICAgYWNjZXNz IHRvIHRoZSBhY2NvdW50aW5nIHNlcnZlci4NCg0KICAgVGhlc2UgbW9kZWxzIHByb3ZpZGUgYSBi YXNpcyBmb3IgdXNpbmcgYWNjb3VudGluZyBtZXNzYWdlcy4NCiAgIEFwcGxpY2F0aW9uIGRlc2ln bmVycyBtYXkgb2J2aW91c2x5IGRldmlhdGUgZnJvbSB0aGVzZSBtb2RlbHMNCiAgIHByb3ZpZGVk IHRoYXQgdGhlIGZhY3RvcnMgYmVpbmcgYWRkcmVzc2VkIGhlcmUgaGF2ZSBhbHNvIGJlZW4gdGFr ZW4NCiAgIGludG8gYWNjb3VudC4gIFRob3VnaCBpdCBpcyBub3QgcmVjb21tZW5kZWQsIGV4YW1w bGVzIG9mIG90aGVyDQogICBtZXRob2RzIHdvdWxkIGJlIGRlZmluaW5nIGEgbmV3IHNldCBvZiBj b21tYW5kcyB0byBjYXJyeSBhcHBsaWNhdGlvbg0KICAgc3BlY2lmaWMgYWNjb3VudGluZyByZWNv cmRzLg0KDQogICBBZGRpdGlvbmFsbHksIHRoZSBhcHBsaWNhdGlvbiBJRCBpbiB0aGUgbWVzc2Fn ZSBoZWFkZXIgYW5kDQogICBBY2NvdW50aW5nLUFwcGxpY2F0aW9uLUlkIEFWUCBhcmUgcG9wdWxh dGVkIGRlcGVuZGluZyBvbiB0aGUNCiAgIGFjY291bnRpbmcgbW9kZWwgdXNlZCBmb3IgYSBzcGVj aWZpYyBhcHBsaWNhdGlvbiwgYXMgZGVzY3JpYmVkIGluDQogICBbMV0uICBUaGVyZWZvcmUsIGFw cGxpY2F0aW9uIGRlc2lnbmVycyBoYXZlIHRvIHNwZWNpZnkgdGhlIGFjY291bnRpbmcNCiAgIG1v ZGVsIHVzZWQgdG8gZ3VhcmFudGVlIHByb3BlciByb3V0aW5nIG9mIGFjY291bnRpbmcgcmVxdWVz dHMuDQoNCjYuMi4gIEdlbmVyaWMgRGlhbWV0ZXIgRXh0ZW5zaW9ucw0KDQogICBHZW5lcmljIERp YW1ldGVyIGV4dGVuc2lvbnMgYXJlIEFWUHMsIGNvbW1hbmRzIG9yIGFwcGxpY2F0aW9ucyB0aGF0 DQogICBhcmUgZGVzaWduZWQgdG8gc3VwcG9ydCBvdGhlciBEaWFtZXRlciBhcHBsaWNhdGlvbnMu ICBUaGV5IGFyZQ0KICAgYXV4aWxpYXJ5IGFwcGxpY2F0aW9ucyBtZWFudCB0byBpbXByb3ZlIG9y IGVuaGFuY2UgdGhlIERpYW1ldGVyDQogICBwcm90b2NvbCBpdHNlbGYgb3IgRGlhbWV0ZXIgYXBw bGljYXRpb25zL2Z1bmN0aW9uYWxpdHkuICBTb21lDQogICBleGFtcGxlcyBpbmNsdWRlIHRoZSBl eHRlbnNpb25zIHRvIHN1cHBvcnQgYXVkaXRpbmcgYW5kIHJlZHVuZGFuY3kNCiAgIChzZWUgWzld KSwgaW1wcm92ZW1lbnRzIGluIGR1cGxpY2F0ZSBkZXRlY3Rpb24gc2NoZW1lIChzZWUgWzEwXSku DQoNCiAgIFNpbmNlIGdlbmVyaWMgZXh0ZW5zaW9ucyBjYW4gY292ZXIgbWFueSBhc3BlY3RzIG9m IERpYW1ldGVyIGFuZA0KICAgRGlhbWV0ZXIgYXBwbGljYXRpb25zLCBpdCBpcyBub3QgcG9zc2li bGUgdG8gZW51bWVyYXRlIGFsbCB0aGUNCiAgIHByb2JhYmxlIHNjZW5hcmlvcyBpbiB0aGlzIGRv Y3VtZW50LiAgSG93ZXZlciwgc29tZSBvZiB0aGUgbW9zdA0KICAgY29tbW9uIGNvbnNpZGVyYXRp b25zIGFyZSBhcyBmb2xsb3dzOg0KDQogICBvICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5OiBEZWFs aW5nIHdpdGggZXhpc3RpbmcgYXBwbGljYXRpb25zIHRoYXQgZG8NCiAgICAgIG5vdCB1bmRlcnN0 YW5kIHRoZSBuZXcgZXh0ZW5zaW9uLiAgRGVzaWduZXJzIGFsc28gaGF2ZSB0byBtYWtlDQogICAg ICBzdXJlIHRoYXQgbmV3IGV4dGVuc2lvbnMgZG8gbm90IGJyZWFrIGV4cGVjdGVkIG1lc3NhZ2Ug ZGVsaXZlcnkNCiAgICAgIGxheWVyIGJlaGF2aW9yLg0KDQogICBvICBGb3J3YXJkIGNvbXBhdGli aWxpdHk6IE1ha2luZyBzdXJlIHRoYXQgdGhlIGRlc2lnbiB3aWxsIG5vdA0KICAgICAgaW50cm9k dWNlIHVuZHVlIHJlc3RyaWN0aW9ucyBmb3IgZnV0dXJlIGFwcGxpY2F0aW9ucy4gIEZ1dHVyZQ0K ICAgICAgYXBwbGljYXRpb25zIGF0dGVtcHRpbmcgdG8gc3VwcG9ydCB0aGlzIGZlYXR1cmUgc2hv dWxkIG5vdCBoYXZlIHRvDQogICAgICBnbyB0aHJvdWdoIGdyZWF0IGxlbmd0aHMgdG8gaW1wbGVt ZW50IGFueSBuZXcgZXh0ZW5zaW9ucy4NCg0KICAgbyAgVHJhZGVvZmZzIGluIHNpZ25hbGluZzog RGVzaWduZXJzIG1heSBoYXZlIHRvIGNob29zZSBiZXR3ZWVuIHRoZQ0KICAgICAgdXNlIG9mIG9w dGlvbmFsIEFWUHMgcGlnZ3liYWNrZWQgb250byBleGlzdGluZyBjb21tYW5kcyB2ZXJzdXMNCiAg ICAgIGRlZmluaW5nIG5ldyBjb21tYW5kcyBhbmQgYXBwbGljYXRpb25zLiAgT3B0aW9uYWwgQVZQ cyBhcmUgc2ltcGxlcg0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAg IERpYW1ldGVyIEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBKdWx5IDIwMDcN Cg0KDQogICAgICB0byBpbXBsZW1lbnQgYW5kIG1heSBub3QgbmVlZCBjaGFuZ2VzIHRvIGV4aXN0 aW5nIGFwcGxpY2F0aW9uczsNCiAgICAgIGkuZS4sIHVzZSBvZiBwcm94eSBhZ2VudHMuICBIb3dl dmVyLCB0aGUgZHJhd2JhY2sgaXMgdGhhdCB0aGUNCiAgICAgIHRpbWluZyBvZiBzZW5kaW5nIGV4 dGVuc2lvbiBkYXRhIHdpbGwgYmUgdGllZCB0byB3aGVuIHRoZQ0KICAgICAgYXBwbGljYXRpb24g d291bGQgYmUgc2VuZGluZyBhIG1lc3NhZ2UuICBUaGlzIGhhcyBjb25zZXF1ZW5jZXMgaWYNCiAg ICAgIHRoZSBhcHBsaWNhdGlvbiBhbmQgdGhlIGV4dGVuc2lvbnMgaGF2ZSBkaWZmZXJlbnQgdGlt aW5nDQogICAgICByZXF1aXJlbWVudHMuICBUaGUgdXNlIG9mIGNvbW1hbmRzIGFuZCBhcHBsaWNh dGlvbnMgc29sdmVzIHRoaXMNCiAgICAgIGlzc3VlIGJ1dCB0aGUgdHJhZGVvZmYgaXMgdGhlIGFk ZGl0aW9uYWwgY29tcGxleGl0eSBvZiBkZWZpbmluZw0KICAgICAgYW5kIGRlcGxveWluZyBhIG5l dyBhcHBsaWNhdGlvbi4gIEl0IGlzIGxlZnQgdXAgdG8gdGhlIGRlc2lnbmVyIHRvDQogICAgICBm aW5kIGEgZ29vZCBiYWxhbmNlIGFtb25nIHRoZXNlIHRyYWRlb2ZmcyBiYXNlZCBvbiB0aGUNCiAg ICAgIHJlcXVpcmVtZW50cyBvZiB0aGUgZXh0ZW5zaW9uLg0KDQoNCjYuMy4gIFVwZGF0aW5nIGFu IGV4aXN0aW5nIEFwcGxpY2F0aW9uDQoNCiAgIEFuIGFwcGxpY2F0aW9uIHRoYXQgaXMgYmVpbmcg dXBncmFkZWQgbXVzdCBmb2xsb3cgdGhlIHNhbWUgcnVsZXMNCiAgIG1lbnRpb25lZCBTZWN0aW9u IDQuICBFdmVuIGlmIHRoZSBuZXcgdmVyc2lvbiBpcyBmdW5kYW1lbnRhbGx5IHRoZQ0KICAgc2Ft ZSBhcHBsaWNhdGlvbiwgYWxsb2NhdGlvbiBvZiBhIG5ldyBhcHBsaWNhdGlvbiBJRCBpcyBwb3Nz aWJsZSBpZg0KICAgaXQgbWVldHMgdGhvc2UgY3JpdGVyaWEuDQoNCiAgIE9wdGlvbmFsIEFWUHMg Y2FuIGFsc28gYmUgdXNlZCB0byBpbmRpY2F0ZSB2ZXJzaW9uIGRpZmZlcmVuY2VzLiAgSWYNCiAg IHRoaXMgYXBwcm9hY2ggaXMgY2hvc2VuLCBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBvcHRp b25hbCBBVlAgaXMNCiAgIHVzZWQgc3BlY2lmaWNhbGx5IHRvIGluZGljYXRlIHZlcnNpb24gaW5m b3JtYXRpb24gb25seSBhbmQgbm90aGluZw0KICAgZWxzZS4gIEFkZGl0aW9uYWxseSwgdGhlIHVz ZSBvZiB0b28gbWFueSBvcHRpb25hbCBBVlBzIHRvIGNhcnJ5DQogICBhcHBsaWNhdGlvbiBlbmhh bmNlbWVudHMgc2hvdWxkIGJlIGF2b2lkZWQgc2luY2Ugc3VjaCBhcHByb2FjaCBoYXMgYQ0KICAg dGVuZGVuY3kgdG8gYmVjb21lIHVubWFuYWdlYWJsZSBhbmQgaW50cm9kdWNlIGludGVyb3BlcmFi aWxpdHkNCiAgIGlzc3Vlcy4gIFRoZXNlIHBpdGZhbGxzIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlv biA0LjIuMQ0KDQogICBGb3IgdGhlIHNhbWUgcmVhc29uLCBjYXJlIHNob3VsZCBiZSB0YWtlbiBp biBhdHRlbXB0aW5nIHRvIGp1c3RpZnkNCiAgIGFsbG9jYXRpb24gb2YgbmV3IGFwcGxpY2F0aW9u IElEIGZvciBldmVyeSBjaGFuZ2UuICBUaGUgcGl0ZmFsbHMgb2YNCiAgIHRoaXMgYXBwcm9hY2gg aXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNS4zLg0KDQogICBBY2NlcHRhYmxlIHRlY2huaXF1ZXMg Y2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBmZWF0dXJlIHVwZ3JhZGVzIHRvDQogICBleGlzdGluZyBh cHBsaWNhdGlvbnMuICBPbmUgb2YgdGhlc2UgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS41Lg0K DQo2LjQuICBTeXN0ZW0gQXJjaGl0ZWN0dXJlIGFuZCBEZXBsb3ltZW50DQoNCiAgIFRoZSBmb2xs b3dpbmcgYXJlIHNvbWUgb2YgdGhlIGFyY2hpdGVjdHVyZSBjb25zaWRlcmF0aW9ucyB0aGF0DQog ICBhcHBsaWNhdGlvbnMgZGVzaWduZXJzIHNob3VsZCBjb250ZW1wbGF0ZSB3aGVuIGRlZmluaW5n IG5ldw0KICAgYXBwbGljYXRpb25zOg0KDQogICBvICBGb3IgZ2VuZXJhbCBBQUEgYXBwbGljYXRp b25zLCBEaWFtZXRlciByZXF1aXJlcyBtb3JlIG1lc3NhZ2UNCiAgICAgIGV4Y2hhbmdlcyBmb3Ig dGhlIHNhbWUgc2V0IG9mIHNlcnZpY2VzIGNvbXBhcmVkIHRvIFJBRElVUy4NCiAgICAgIFRoZXJl Zm9yZSwgYXBwbGljYXRpb24gZGVzaWduZXJzIHNob3VsZCBjb25zaWRlciBzY2FsYWJpbGl0eQ0K ICAgICAgaXNzdWVzIGR1cmluZyB0aGUgZGVzaWduIHByb2Nlc3MuDQoNCiAgIG8gIEFwcGxpY2F0 aW9uIGRlc2lnbiBzaG91bGQgYmUgYWdub3N0aWMgdG8gYW55IERpYW1ldGVyIHRvcG9sb2d5Lg0K ICAgICAgQXBwbGljYXRpb24gZGVzaWduZXJzIHNob3VsZCBub3QgYWx3YXlzIGFzc3VtZSBhIHBh cnRpY3VsYXINCiAgICAgIERpYW1ldGVyIHRvcG9sb2d5OyBpLmUuLCBhc3N1bWUgdGhhdCB0aGVy ZSB3aWxsIGFsd2F5cyBiZQ0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg SmFudWFyeSA3LCAyMDA4ICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFm dCAgIERpYW1ldGVyIEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBKdWx5IDIw MDcNCg0KDQogICAgICBhcHBsaWNhdGlvbiBwcm94aWVzIGluIHRoZSBwYXRoIG9yIGFzc3VtZSB0 aGF0IG9ubHkgaW50cmEtZG9tYWluDQogICAgICByb3V0aW5nIGlzIGFwcGxpY2FibGUuDQoNCiAg IG8gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLiAgQXBwbGljYXRpb24gZGVzaWduZXJzIHNob3Vs ZCB0YWtlIGludG8NCiAgICAgIGFjY291bnQgdGhhdCB0aGVyZSBpcyBubyBlbmQtdG8tZW5kIGF1 dGhlbnRpY2F0aW9uIGJ1aWx0IGludG8NCiAgICAgIERpYW1ldGVyLg0KDQogICBvICBBcHBsaWNh dGlvbiBkZXNpZ24gc2hvdWxkIGNvbnNpZGVyIHNvbWUgZm9ybSBvZiByZWR1bmRhbmN5Lg0KICAg ICAgU2Vzc2lvbiBzdGF0ZSBpbmZvcm1hdGlvbiBpcyB0aGUgcHJpbWFyeSBkYXRhIG5lY2Vzc2Fy eSBmb3INCiAgICAgIGJhY2t1cC9yZWNvdmVyaW5nIGVuZHBvaW50cyB0byBjb250aW51ZSBwcm9j ZXNzaW5nIGZvciBhbg0KICAgICAgcHJldmlvdXNseSBleGlzdGluZyBzZXNzaW9uLiAgQ2Fycnlp bmcgZW5vdWdoIGluZm9ybWF0aW9uIGluIHRoZQ0KICAgICAgbWVzc2FnZXMgdG8gcmVjb25zdHJ1 Y3Qgc2Vzc2lvbiBzdGF0ZSBmYWNpbGl0YXRlcyByZWR1bmRhbnQNCiAgICAgIGltcGxlbWVudGF0 aW9ucyBhbmQgaXMgaGlnaGx5IHJlY29tbWVuZGVkLg0KDQogICBvICBBcHBsaWNhdGlvbiBkZXNp Z24gc2hvdWxkIHNlZ3JlZ2F0ZSBtZXNzYWdlIGRlbGl2ZXJ5IGxheWVyDQogICAgICBwcm9jZXNz aW5nIGZyb20gYXBwbGljYXRpb24gbGV2ZWwgcHJvY2Vzc2luZy4gIEFuIGV4YW1wbGUgaXMgdGhl DQogICAgICB1c2Ugb2YgdGltZXJzIHRvIGRldGVjdCBsYWNrIG9mIGEgcmVzcG9uc2UgZm9yIGEg cHJldmlvdXNseSBzZW50DQogICAgICByZXF1ZXN0cy4gIEFsdGhvdWdoIHRoZSBEaWFtZXRlciBi YXNlIHByb3RvY29sIGRlZmluZXMgYSB3YXRjaGRvZw0KICAgICAgdGltZXIgVHcsIGl0cyB1c2Ug b24gYXBwbGljYXRpb24gbGV2ZWwgaXMgZGlzY291cmFnZWQgc2luY2UgVHcgaXMNCiAgICAgIGEg aG9wLWJ5LWhvcCB0aW1lciBhbmQgaXQgd291bGQgbm90IGJlIHJlbGV2YW50IGZvciBlbmQtdG8t ZW5kDQogICAgICBtZXNzYWdlIGRlbGl2ZXJ5IGVycm9yIGRldGVjdGlvbi4gIEluIHN1Y2ggYSBj YXNlLCBpdCBpcw0KICAgICAgcmVjb21tZW5kZWQgdGhhdCBhcHBsaWNhdGlvbnMgc2hvdWxkIGRl ZmluZSB0aGVpciBvd24gc2V0IG9mDQogICAgICB0aW1lcnMgZm9yIHN1Y2ggcHVycG9zZS4NCiAg IG8gIEFwcGxpY2F0aW9ucyBzaG91bGQgc3BlY2lmeSBBVlBzIHdoaWNoIGNvdWxkIGJlIHVzZWQg dG8gZnVydGhlcg0KICAgICAgYWlkIGluIGR1cGxpY2F0aW9uIGRldGVjdGlvbi4gIEluIHNvbWUg Y2FzZXMsIHdoZW4gZXh0ZW5kaW5nIGFuDQogICAgICBhcHBsaWNhdGlvbiwgZXhpc3RpbmcgQVZQ cyBjYW4gYmUgcmV1c2VkIHRvIHByb3ZpZGUgYWRkaXRpb25hbA0KICAgICAgZHVwbGljYXRpb24g ZGV0ZWN0aW9uIGluZGljYXRvcnM7IGkuZS4sIGNvbWJpbmF0aW9uIG9mIFNlc3Npb24tSWQNCiAg ICAgIGFuZCBDQy1SZXF1ZXN0LU51bWJlciBBVlBzIGluIHRoZSBEaWFtZXRlciBDcmVkaXQgQ29u dHJvbA0KICAgICAgYXBwbGljYXRpb24gWzRdLiAgSW4gY2FzZXMgd2hlcmUgdGhlIGV4dGVuc2lv bnMgbmVlZHMgdG8gZGVmaW5lDQogICAgICBuZXcgQVZQcywgaXQgaXMgcmVjb21tZW5kZWQgdGhh dCB0aGUgbmV3IEFWUHMgYmUgdXNlZCBvbmx5IGZvcg0KICAgICAgdGhpcyBwdXJwb3NlLg0KDQoN CjcuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcmVx dWlyZSBhY3Rpb25zIGJ5IElBTkEuDQoNCg0KOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN CiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBwcm92aWRlcyBndWlkZWxpbmVzIGFuZCBjb25zaWRlcmF0 aW9ucyBmb3INCiAgIGV4dGVuZGluZyBEaWFtZXRlciBhbmQgRGlhbWV0ZXIgYXBwbGljYXRpb25z LiAgSXQgZG9lcyBub3QgZGVmaW5lIG5vcg0KICAgYWRkcmVzcyBzZWN1cml0eSByZWxhdGVkIHBy b3RvY29scyBvciBzY2hlbWVzLg0KDQoNCjkuICBBY2tub3dsZWRnbWVudHMNCg0KICAgV2UgZ3Jl YXRseSBhcHByZWNpYXRlIHRoZSBpbnNpZ2h0IHByb3ZpZGVkIGJ5IERpYW1ldGVyIGltcGxlbWVu dGVycw0KDQoNCg0KRmFqYXJkbywgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA3LCAy MDA4ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgIERpYW1ldGVy IEFwcGxpY2F0aW9ucyBEZXNpZ24gR3VpZGVsaW5lcyAgICAgICBKdWx5IDIwMDcNCg0KDQogICB3 aG8gaGF2ZSBoaWdobGlnaHRlZCB0aGUgaXNzdWVzIGFuZCBjb25jZXJucyBiZWluZyBhZGRyZXNz ZWQgYnkgdGhpcw0KICAgZG9jdW1lbnQuDQoNCg0KMTAuICBSZWZlcmVuY2VzDQoNCjEwLjEuICBO b3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbMV0gICBGYWphcmRvLCBWLiwgIkRpYW1ldGVyIEJh c2UgUHJvdG9jb2wiLA0KICAgICAgICAgZHJhZnQtaWV0Zi1kaW1lLXJmYzM1ODhiaXMtMDQgKHdv cmsgaW4gcHJvZ3Jlc3MpLCBKdW5lIDIwMDcuDQoNCiAgIFsyXSAgIEJvdXJuZWxsZSwgSi4sICJE aWFtZXRlciBNb2JpbGUgSVB2NjogU3VwcG9ydCBmb3IgSG9tZSBBZ2VudCB0bw0KICAgICAgICAg RGlhbWV0ZXIgU2VydmVyICBJbnRlcmFjdGlvbiIsIGRyYWZ0LWlldGYtZGltZS1taXA2LXNwbGl0 LTAzDQogICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIEp1bHkgMjAwNy4NCg0KICAgWzNdICAg Wm9ybiwgRy4sICJEaWFtZXRlciBRdWFsaXR5IG9mIFNlcnZpY2UgQXBwbGljYXRpb24iLA0KICAg ICAgICAgZHJhZnQtaWV0Zi1kaW1lLWRpYW1ldGVyLXFvcy0wMCAod29yayBpbiBwcm9ncmVzcyks DQogICAgICAgICBGZWJydWFyeSAyMDA3Lg0KDQogICBbNF0gICBIYWthbGEsIEguLCBNYXR0aWxh LCBMLiwgS29za2luZW4sIEotUC4sIFN0dXJhLCBNLiwgYW5kIEouDQogICAgICAgICBMb3VnaG5l eSwgIkRpYW1ldGVyIENyZWRpdC1Db250cm9sIEFwcGxpY2F0aW9uIiwgUkZDIDQwMDYsDQogICAg ICAgICBBdWd1c3QgMjAwNS4NCg0KICAgWzVdICAgM0dQUCwgIklNUyBDeCBhbmQgRHggaW50ZXJm YWNlcyA6IHNpZ25hbGxpbmcgZmxvd3MgYW5kIG1lc3NhZ2UNCiAgICAgICAgIGNvbnRlbnRzIiwg M0dQUCBUUyAyOS4yMjggVmVyc2lvbiA3LjAuMCAyMDA2Lg0KICAgICAgICAgICAgICAgICAgICBe Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl4NCiAgICAgICAgIFdTISBJcyBhdmFpbGFibGUg aW4gVmVyc2lvbiBWNy42LjAgKDIwMDctMDcpDQoNCiAgIFs2XSAgIDNHUFAsICJJTVMgQ3ggYW5k IER4IGludGVyZmFjZXMgYmFzZWQgb24gdGhlIERpYW1ldGVyIHByb3RvY29sOw0KICAgICAgICAg UHJvdG9jb2wgZGV0YWlscyIsIDNHUFAgVFMgMjkuMjI5IFZlcnNpb24gNy4wLjAgMjAwNi4NCiAg ICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQogICAgICAg ICBXUyEgSXMgYXZhaWxhYmxlIGluIFZlcnNpb24gVjcuNS4wICgyMDA3LTAzKQ0KDQogICBbN10g ICAzR1BQLCAiSU1TIFNoIGludGVyZmFjZSA6IHNpZ25hbGxpbmcgZmxvd3MgYW5kIG1lc3NhZ2UN CiAgICAgICAgIGNvbnRlbnQiLCAzR1BQIFRTIDI5LjMyOCBWZXJzaW9uIDYuOC4wIDIwMDUuDQog ICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXg0KICAgICAg ICAgV1MhIElzIGF2YWlsYWJsZSBpbiBWZXJzaW9uIFY3LjYuMCAoMjAwNy0wNykNCg0KICAgWzhd ICAgM0dQUCwgIklNUyBTaCBpbnRlcmZhY2UgYmFzZWQgb24gdGhlIERpYW1ldGVyIHByb3RvY29s Ow0KICAgICAgICAgUHJvdG9jb2wgZGV0YWlscyIsIDNHUFAgVFMgMjkuMzI5IFZlcnNpb24gNi42 LjAgMjAwNS4NCiAgICAgICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5e Xl5eDQogICAgICAgICBXUyEgSXMgYXZhaWxhYmxlIGluIFZlcnNpb24gVjcuMy4wICgyMDA2LTEw KQ0KDQoxMC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbOV0gICBDYWxob3VuLCBQ LiwgIkRpYW1ldGVyIFJlc291cmNlIE1hbmFnZW1lbnQgRXh0ZW5zaW9ucyIsDQogICAgICAgICBk cmFmdC1jYWxob3VuLWRpYW1ldGVyLXJlcy1tZ210LTA4LnR4dCAod29yayBpbiBwcm9ncmVzcyks DQogICAgICAgICBNYXJjaCAyMDAxLg0KDQogICBbMTBdICBBc3ZlcmVuLCBULiwgIkRpYW1ldGVy IER1cGxpY2F0ZSBEZXRlY3Rpb24gQ29ucy4iLA0KICAgICAgICAgZHJhZnQtYXN2ZXJlbi1kaW1l LWR1cGNvbnMtMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBdWd1c3QgMjAwNi4NCg0KDQoNCg0KDQoN Cg0KDQpGYWphcmRvLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDcsIDIwMDggICAg ICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgRGlhbWV0ZXIgQXBwbGlj YXRpb25zIERlc2lnbiBHdWlkZWxpbmVzICAgICAgIEp1bHkgMjAwNw0KDQoNCkF1dGhvcnMnIEFk ZHJlc3Nlcw0KDQogICBWaWN0b3IgRmFqYXJkbyAoZWRpdG9yKQ0KICAgVG9zaGliYSBBbWVyaWNh IFJlc2VhcmNoIEluYy4NCiAgIE9uZSBUZWxjb3JkaWEgRHJpdmUNCiAgIFBpc2NhdGF3YXksIE5K IDA4ODU0DQogICBVU0ENCg0KICAgRW1haWw6IHZmYWphcmRvQHRhcmkudG9zaGliYS5jb20NCg0K DQogICBUb2xnYSBBc3ZlcmVuDQogICBTb251cyBOZXR3b3JrDQogICA0NDAwIFJvdXRlIDkgU291 dGgNCiAgIEZyZWVob2xkLCBOSiwgMDc3MjgNCiAgIFVTQQ0KDQogICBFbWFpbDogdGFzdmVyZW5A c29udXNuZXQuY29tDQoNCg0KICAgSGFubmVzIFRzY2hvZmVuaWcNCiAgIE5va2lhIFNpZW1lbnMg TmV0d29ya3MNCiAgIE90dG8tSGFobi1SaW5nIDYNCiAgIE11bmljaCwgQmF2YXJpYSAgODE3MzkN CiAgIEdlcm1hbnkNCg0KICAgUGhvbmU6ICs0OSA4OSA2MzYgNDAzOTANCiAgIEVtYWlsOiBIYW5u ZXMuVHNjaG9mZW5pZ0Buc24uY29tDQogICBVUkk6ICAgaHR0cDovL3d3dy50c2Nob2ZlbmlnLmNv bQ0KDQoNCiAgIEdsZW5uIE1jR3JlZ29yDQogICBBbGNhdGVsLUx1Y2VudA0KICAgVVNBDQoNCiAg IEVtYWlsOiBnbGVubkBhYWEubHVjZW50LmNvbQ0KDQoNCiAgIEpvaG4gTG91Z2huZXkNCiAgIE5v a2lhIFJlc2VhcmNoIENlbnRlcg0KICAgVVNBDQoNCiAgIEVtYWlsOiBqb2huLmxvdWdobmV5QG5v a2lhLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCkZhamFyZG8sIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IEphbnVhcnkgNywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICBEaWFtZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRlbGluZXMgICAgICAgSnVseSAy MDA3DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhl IElFVEYgVHJ1c3QgKDIwMDcpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhl IHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJDUCA3 OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJldGFp biBhbGwgdGhlaXIgcmlnaHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBDT05UUklCVVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0K ICAgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhF IElFVEYgVFJVU1QgQU5EDQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5DTFVESU5H IEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQogICBUSEUg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElN UExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBUaGUg SUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9m IGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhh dCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv ciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9y IHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1p Z2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0 IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBz dWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3Bl Y3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzgg YW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUg bWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBv YnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMN CiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJ UFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJ RVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlv biBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Ig b3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRo YXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFz ZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0 Zi5vcmcuDQoNCg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0 b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZlIFN1 cHBvcnQgQWN0aXZpdHkgKElBU0EpLg0KDQoNCg0KDQoNCkZhamFyZG8sIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIEphbnVhcnkgNywgMjAwOCAgICAgICAgICAgICAgIFtQYWdlIDE5XQ0KDA0KDQo= ------_=_NextPart_001_01C7DE67.6545B8C2 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_001_01C7DE67.6545B8C2-- From dime-bounces@ietf.org Tue Aug 14 08:17: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 1IKvLP-00017i-6x; Tue, 14 Aug 2007 08:17:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvLO-00017d-2i for dime@ietf.org; Tue, 14 Aug 2007 08:17:54 -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 1IKvLN-0001nm-NP for dime@ietf.org; Tue, 14 Aug 2007 08:17:53 -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 l7ECHoAU006864; Tue, 14 Aug 2007 08:17:50 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46C19D6E.9060300@tari.toshiba.com> Date: Tue, 14 Aug 2007 08:17:50 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: Steigerwaldw Subject: Re: [Dime] AW: Diameter Design Guidelines Draft Reviewers References: <46B04B7E.4040404@gmx.net> <75404C7727619C4E81A6DABE442E42DD0255DD4F@S4DE9JSAANL.ost.t-com.de> In-Reply-To: <75404C7727619C4E81A6DABE442E42DD0255DD4F@S4DE9JSAANL.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l7ECHoAU006864 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 Wolfgang, Thanks for the review. We'll incorporate your edits. best regards, victor > Hello Hannes, > > I have reviewed the application design guideline document. I have found= only some editorial issues and marked them with "WS!" > > Regards=20 > Wolfgang =20 > > > T-Systems Enterprise Services GmbH > Systems Integration > Project & Design, Business Unit Telco > Line of Business Products & Services > Goslarer Ufer 35, 10589 Berlin=20 > Tel. +49 30 -3497 2058=20 > Fax +49 391 53475396=20 > Mobil +49 171 5664350=20 > E-Mail: wolfgang.steigerwald@t-systems.com=20 > > T-Systems Business Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Helmut Binder*, Albert Henn*, Olaf Heyden, Katrin = Horstmann, Ulrich Kemp*, Wilfried Peters*,=20 > Dr. Herbert Schaaff, Zvezdana Seeger > Handelsregister: Amtsgericht Bonn HRB 6787 > Sitz der Gesellschaft: Bonn > WEEE-Reg.-Nr. DE50335567 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > > Notice: This transmittal and/or attachments may be privileged or confid= ential. If you are not the intended recipient, you are hereby notified th= at you have received this transmittal in error; any review, dissemination= , or copying is strictly prohibited. If you received this transmittal in = error, please notify us immediately by reply and immediately delete this = message and all its attachments. Thank you.=20 > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 14 09:59: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 1IKwvc-00006u-Mt; Tue, 14 Aug 2007 09:59:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwvb-00006P-LQ; Tue, 14 Aug 2007 09:59:23 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKwvb-0005AS-7P; Tue, 14 Aug 2007 09:59:23 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1187099960!5212234!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4364 invoked from network); 14 Aug 2007 13:59:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 14 Aug 2007 13:59:20 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7EDxGrg012890; Tue, 14 Aug 2007 06:59:20 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l7EDxF1l004159; Tue, 14 Aug 2007 08:59:16 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7EDxF0k004148; Tue, 14 Aug 2007 08:59:15 -0500 (CDT) 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] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Tue, 14 Aug 2007 09:59:11 -0400 Message-ID: In-Reply-To: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAAAH596IA== References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip4@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 Alper Yegin wrote: >> There is no scalable way to maintain trust relationships between all >> pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are roaming to >> a given FA. The FA needs to make sure that the visited resources >> will be paid for, which is why it needs authorization from the AAA >> infrastructure. >=20 > FA-HA security association can also be dynamically created during the > network access authentication procedure.=20 That's exactly what the Diameter-MIPv4 application does. -Pete _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 15 13:27: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 1ILMeM-00008F-S7; Wed, 15 Aug 2007 13:27:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMeL-0008Vg-GL for dime@ietf.org; Wed, 15 Aug 2007 13:27:17 -0400 Received: from smtp108.rog.mail.re2.yahoo.com ([68.142.225.206]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ILMeL-0001lz-5V for dime@ietf.org; Wed, 15 Aug 2007 13:27:17 -0400 Received: (qmail 19161 invoked from network); 15 Aug 2007 17:27:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0iirQ9+dQ7/L+VkpWceo2fqUF+UVUoQPfJ9dzws7EH4H1RKOjIIp93y07T2sCGDKY6seahzeiZ6vGdsHk3haL8Wuw3ppW5DIsErHtpMNXoXxSPioODRvsNdWfOf6a9XVtkJNr8Xr4BB49X0OmEuTi5DvZMIVcy/C6j/zKpAwKdE= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 15 Aug 2007 17:27:16 -0000 X-YMail-OSG: fw_Ps6wVM1lIRt0SkRJh1dNPByvtY9.i8Bvn9_NkjE7_BYSmggmk0lt0mVKKybL6Fw-- Message-ID: <46C33772.3010700@rogers.com> Date: Wed, 15 Aug 2007 13:27:14 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dime@ietf.org, mip4@ietf.org, 'McCann Peter-A001034' 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 Isn't this what HOKEY is all about? Alper Yegin wrote: >>> MN is authenticated by the same entity (HAAA) whether requested by >>> the FA or the HA. If HA and FA has some trust relationship (e.g., >>> using FA-HA AE, or IPsec), then I believe letting the HA authenticate >>> the MN is sufficient. >> There is no scalable way to maintain trust relationships between >> all pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are >> roaming to a given FA. The FA needs to make sure that the >> visited resources will be paid for, which is why it needs >> authorization from the AAA infrastructure. > > FA-HA security association can also be dynamically created during the > network access authentication procedure. > > Alper > > > > _______________________________________________ > 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 Aug 15 16:32:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPXa-0006zI-PR; Wed, 15 Aug 2007 16:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPXY-0006yl-Rs; Wed, 15 Aug 2007 16:32:28 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILPXY-0000jL-9D; Wed, 15 Aug 2007 16:32:28 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1ILPXP3mAK-0005Es; Wed, 15 Aug 2007 16:32:27 -0400 From: "Alper Yegin" To: "'Tom Taylor'" Subject: RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Wed, 15 Aug 2007 23:32:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46C33772.3010700@rogers.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffYYbQ12tlM4I5ThmB/BWjLQA+nAAGc2yQ Message-Id: <0MKp8S-1ILPXP3mAK-0005Es@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+Zaj+tp4mOtqJWNoLMhX3dC6F46mtKnU1bf4q kavtyJsX8SOwSnf+L1ab3ARQsLWSJEXwRjPSVthmvgo2bn0pN2 SmXi6GpYf7ZEZjJxZgVCQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org, mip4@ietf.org, 'McCann Peter-A001034' 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 Yes, HOKEY has relevance to that. Alper > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Wednesday, August 15, 2007 8:27 PM > To: Alper Yegin > Cc: 'McCann Peter-A001034'; 'Ahmad Muhanna'; dime@ietf.org; mip4@ietf.org > Subject: Re: [Dime] RE: Issue 3: Diameter MIP4 Application vs. > RADIUSArchitecture > > Isn't this what HOKEY is all about? > > Alper Yegin wrote: > >>> MN is authenticated by the same entity (HAAA) whether requested by > >>> the FA or the HA. If HA and FA has some trust relationship (e.g., > >>> using FA-HA AE, or IPsec), then I believe letting the HA authenticate > >>> the MN is sufficient. > >> There is no scalable way to maintain trust relationships between > >> all pairs of (FA, HA). One of the main purposes of the Diameter > >> MIPv4 application is to distribute keys for those (FA, HA) > >> relationships that are necessary based on the MNs that are > >> roaming to a given FA. The FA needs to make sure that the > >> visited resources will be paid for, which is why it needs > >> authorization from the AAA infrastructure. > > > > FA-HA security association can also be dynamically created during the > > network access authentication procedure. > > > > Alper > > > > > > > > _______________________________________________ > > 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 Aug 15 17:59: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 1ILQtZ-0002ub-EL; Wed, 15 Aug 2007 17:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILQtY-0002uO-8p for dime@ietf.org; Wed, 15 Aug 2007 17:59:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILQtX-0003LH-1G for dime@ietf.org; Wed, 15 Aug 2007 17:59:16 -0400 Received: (qmail invoked by alias); 15 Aug 2007 21:59:13 -0000 Received: from p5498784B.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.120.75] by mail.gmx.net (mp021) with SMTP; 15 Aug 2007 23:59:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+s9QoHhGms7QEca9JJlyatTvHVCpcokdGyPbzgne h3A7foNqQgf2Y9 Message-ID: <46C37732.2050904@gmx.net> Date: Wed, 15 Aug 2007 23:59:14 +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: 2.9 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Dime] Meeting Minutes 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 Please check the meeting minutes: http://www3.ietf.org/proceedings/07jul/minutes/dime.txt _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 15 22:20:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILUyH-0003l3-EY; Wed, 15 Aug 2007 22:20:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILUyG-0003iw-Bh for dime@ietf.org; Wed, 15 Aug 2007 22:20:24 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILUyG-0003m9-0c for dime@ietf.org; Wed, 15 Aug 2007 22:20:24 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMU009XIH5Y98@usaga01-in.huawei.com> for dime@ietf.org; Wed, 15 Aug 2007 19:20:23 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JMU00EFUH5XOP@usaga01-in.huawei.com> for dime@ietf.org; Wed, 15 Aug 2007 19:20:22 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.70.145.77]) by szxmc04-in.huawei.com (mshttpd); Thu, 16 Aug 2007 10:20:18 +0800 Date: Thu, 16 Aug 2007 10:20:18 +0800 From: HarshaM 71438 To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_RXSbIdDdmMiyH8eEi4hnew)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Dime] Questions on Election 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 This is a multi-part message in MIME format. --Boundary_(ID_RXSbIdDdmMiyH8eEi4hnew) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi All, I have two questions related to Election. 1) See the following states Wait-I-CEA I-Rcv-CEA Process-CEA I-Open R-Conn-CER R-Accept, Wait-Returns Process-CER, Elect I-Peer-Disc I-Disc Closed I-Rcv-Non-CEA Error Closed Timeout Error Closed Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open I-Peer-Disc I-Disc, R-Open R-Snd-CEA I-Rcv-CEA R-Disc I-Open R-Peer-Disc R-Disc Wait-I-CEA R-Conn-CER R-Reject Wait-Returns Timeout Error Closed When we are in WAIT-I-CEA and get R-Conn-CER, we will go to WAIT-RETURNS. In WAIT-RETURNS we should be able to get all the events for initiator that are expected in WAIT-I-CEA. I mean to say that we should be able to handle I-RCV-CEA, I-Peer-Disc, I-Rcv-Non-CEA and Timeout. We are handling all except I-Rcv-Non-CEA in Wait-Returns. I think this event is missed out in the RFC.Please tell me if I am right. 2) When comparing the Origin-Hosts of local node and the peer node, RFC has suggested to pad 0s at the end. If we pad 0s at the end of the shorter hostname, the longer one will always succeed because of comparison with 0.Why should we do that? Why not compare only till the length of the shorter hostname. Please answer my questions. Thanks and Regards, Harsha --Boundary_(ID_RXSbIdDdmMiyH8eEi4hnew) Content-type: text/x-vcard; name=h71438.vcf; charset=windows-1252 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=h71438.vcf Content-description: Card for HarshaM 71438 begin:vcard n:Matadhikari ;Harsha fn:Harsha M tel;home:64510566 tel;work:1405 org:Huawei Technologies India Pvt Ltd.;Embedded BU adr:;;#875, 2nd Floor, 3rd Main, Hosakerehalli;Banashankari III Stage, Bangalore;Karnataka;560085;India version:2.1 email;internet:harsham@huawei.com title:TPL end:vcard --Boundary_(ID_RXSbIdDdmMiyH8eEi4hnew) 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 --Boundary_(ID_RXSbIdDdmMiyH8eEi4hnew)-- From dime-bounces@ietf.org Thu Aug 16 07:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILdlk-0003iQ-DG; Thu, 16 Aug 2007 07:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILdcy-0004rn-Mq; Thu, 16 Aug 2007 07:35:00 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILdcx-0003qj-25; Thu, 16 Aug 2007 07:35:00 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7GBYuVF001565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Aug 2007 04:34:57 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7GBYuCA010246; Thu, 16 Aug 2007 04:34:56 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 04:34:55 -0700 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: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Date: Thu, 16 Aug 2007 04:34:59 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4951568@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAAAH596IABfZtVg References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> From: "Tsirtsis, George" To: "McCann Peter-A001034" , "Alper Yegin" , "Ahmad Muhanna" , X-OriginalArrivalTime: 16 Aug 2007 11:34:55.0815 (UTC) FILETIME=[7819B570:01C7DFF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Thu, 16 Aug 2007 07:44:03 -0400 Cc: mip4@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 Sorry I have not followed this fully but I also think that sending RRQs encapsulated in DIAMETER messages is not always desirable. In fact it links two protocols in a way that is somewhat undesirable. The HA for example, has to be able to accept MIP registrations from two different protocols now (i.e., MIP and DIAMETER). The RADIUS way of doing this is a bit cleaner, but more importantly is widely deployed and current deployments are unlikely to change their model just because they want to upgrade to DIAMETER. My 2c George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Tuesday, August 14, 2007 2:59 PM To: Alper Yegin; Ahmad Muhanna; dime@ietf.org Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Alper Yegin wrote: >> There is no scalable way to maintain trust relationships between all >> pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are roaming to >> a given FA. The FA needs to make sure that the visited resources >> will be paid for, which is why it needs authorization from the AAA >> infrastructure. >=20 > FA-HA security association can also be dynamically created during the > network access authentication procedure.=20 That's exactly what the Diameter-MIPv4 application does. -Pete --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 16 08:07: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 1ILe8L-00036Y-9A; Thu, 16 Aug 2007 08:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILe2n-0007nw-QF; Thu, 16 Aug 2007 08:01:41 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILe2l-0004sx-Sq; Thu, 16 Aug 2007 08:01:41 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.190.104.34]) by omta02ps.mx.bigpond.com with ESMTP id <20070816120136.YGLA14578.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Thu, 16 Aug 2007 12:01:36 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070816120135.MTDZ14534.oaamta02ps.mx.bigpond.com@PC20005>; Thu, 16 Aug 2007 12:01:35 +0000 From: "Hesham Soliman" To: "'Alper Yegin'" , "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Subject: RE: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Date: Thu, 16 Aug 2007 22:01:32 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwACGBojQ In-Reply-To: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Thu, 16 Aug 2007 08:07:23 -0400 Cc: mip4@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 > > > Obviously it is a feature. But don't you think it is a > bit of a hack? > > > I mean, tunneling one protocol inside another for the > sake of saving > > > round-trips? For example, we could further reduce the > round-trips by > > > tunneling MIP4 inside EAP of network access authentication. > > > > I don't think it's a hack. When we have Mobile IP being used > > for access authentication I think it makes sense to carry the > > RRQ in a Diameter application. EAP is a different case because > > then we have a separate protocol doing access authentication. > > Using a mobility protocol's AAA for network access AAA is > another hack, > IMHO. These are two separate services. That may explain why > one protocol is > tunneled inside another, but it does not justify. > > I understand these are all driven by performance improvements. => I agree with Alper about this. I do think we should avoid this type of "performance improvement" :). I don't think it's a good idea for the RRQ or other MIP messages to be encapsulated in Diameter and I actually think the performance benefits are negligible. Hesham > > > > > I also understand that having to go to HAAA twice for > each MIP RegReq > > > is bothersome. But then, maybe we should re-consider the > necessity of > > > MN-FA authentication. Given that HA is going to > authenticate the MN, > > > does FA also need to do the same? > > > > The FA and HA might be part of different administrative domains. > > I think the FA has just as much reason to authenticate the MN as > > the HA. > > MN is authenticated by the same entity (HAAA) whether > requested by the FA or > the HA. If HA and FA has some trust relationship (e.g., > using FA-HA AE, or > IPsec), then I believe letting the HA authenticate the MN is > sufficient. > > Alper > > > > > > > > > > > > > Alper > > > > -Pete > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 19 12:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMnUR-0005sE-F7; Sun, 19 Aug 2007 12:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMnUQ-0005nI-2p for dime@ietf.org; Sun, 19 Aug 2007 12:18:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IMnUO-0008P2-GR for dime@ietf.org; Sun, 19 Aug 2007 12:18:58 -0400 Received: (qmail invoked by alias); 19 Aug 2007 16:18:55 -0000 Received: from p549857E4.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.87.228] by mail.gmx.net (mp043) with SMTP; 19 Aug 2007 18:18:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19KjoB4WgtK0htJCaXrngv6+BRE/RRsXluC4qOPZ7 aDZQotEdEISB9r Message-ID: <46C86D74.7040503@gmx.net> Date: Sun, 19 Aug 2007 18:19:00 +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: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Dime] [Fwd: RADEXT WG last call on "RADIUS Attributes for Filtering and Redirection"] 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 You might want to read through this document since it has an impact on Diameter (as I explained at the last IETF meeting). Please evaluate whether you like the string encoding of the rules. Ciao Hannes -------- Original Message -------- Subject: RADEXT WG last call on "RADIUS Attributes for Filtering and Redirection" Date: Sat, 18 Aug 2007 14:34:43 -0700 From: Bernard Aboba To: radiusext@ops.ietf.org On July 5, 2007 the RADEXT WG began WG last call on "RADIUS Attributes for Filtering and Redirection": http://ops.ietf.org/lists/radiusext/2007/msg00494.html http://ops.ietf.org/lists/radiusext/2007/msg00541.html This WG last call was to last until Monday, July 23, 2007. During the WG last call, only a single comment was received, from Hannes Tschofenig: http://ops.ietf.org/lists/radiusext/2007/msg00496.html No other messages were posted to the RADEXT WG mailing list indicating that WG participants had read the document. Given the light level of participation, we are going to extend the WG last call for 10 more days (until August 28, 2007). If you have read the document and approve of its publication as a Proposed Standard, please post your approval to the list, even if you have no comments to provide. If you have comments, please provide them in the format described on the RADEXT WG Issues page: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 19 16:21: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 1IMrGz-0008LY-TE; Sun, 19 Aug 2007 16:21:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMrGy-0008LS-Tk for dime@ietf.org; Sun, 19 Aug 2007 16:21:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IMrGy-0006Lf-3C for dime@ietf.org; Sun, 19 Aug 2007 16:21:20 -0400 Received: (qmail invoked by alias); 19 Aug 2007 20:21:18 -0000 Received: from p549857E4.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.87.228] by mail.gmx.net (mp054) with SMTP; 19 Aug 2007 22:21:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189lZ0AtTk9OfGO3iOtW7/mH9i8l2r33P5hHJNHXJ akoPfFUwwgi5tC Message-ID: <46C8A642.2040102@gmx.net> Date: Sun, 19 Aug 2007 22:21:22 +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: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] 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 During the IETF#69 meeting I have also asked for reviewers. Two persons offered help: * Jouni Korhonen * Tina Tsou Their review is still pending! -------- Original Message -------- Subject: Request for review of "AAA Framework for Multicasting" Date: Sat, 18 Aug 2007 14:49:00 -0700 From: Bernard Aboba To: radiusext@ops.ietf.org A request for review has been received relating to the document "AAA Framework for Multicasting" which is under development within the MBONED WG. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt The Request for Review will last until September 5, 2007. Please post your comments on this document to the RADEXT WG mailing list, CC:'ing the document authors. Information on the review request was previously posted to the RADEXT WG mailing list: http://ops.ietf.org/lists/radiusext/2007/msg00528.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Aug 19 16:54:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMrmc-0003zM-39; Sun, 19 Aug 2007 16:54:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMrmb-0003r7-5A for dime@ietf.org; Sun, 19 Aug 2007 16:54:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IMrmZ-0006EY-OJ for dime@ietf.org; Sun, 19 Aug 2007 16:54:01 -0400 Received: (qmail invoked by alias); 19 Aug 2007 20:53:58 -0000 Received: from p549857E4.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.87.228] by mail.gmx.net (mp028) with SMTP; 19 Aug 2007 22:53:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qTyFlfQPq+yxfS1T4HQfGPYAGw9rM1aBXLEZkTY n1u83j25flwrq/ Message-ID: <46C8ADEA.5000809@gmx.net> Date: Sun, 19 Aug 2007 22:54:02 +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: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Dime] DIME WG Status Update (August 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 A new DIME WG status update is available. See http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Aug 20 04:50: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 1IN2xe-00011L-Rw; Mon, 20 Aug 2007 04:50:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2xd-00011F-ON for dime@ietf.org; Mon, 20 Aug 2007 04:50:09 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2xc-000187-OR for dime@ietf.org; Mon, 20 Aug 2007 04:50:09 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN200AB5DUHPJ@szxga01-in.huawei.com> for dime@ietf.org; Mon, 20 Aug 2007 16:49:29 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN200J9ODUG9R@szxga01-in.huawei.com> for dime@ietf.org; Mon, 20 Aug 2007 16:49:29 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN2004YJDUGC4@szxml04-in.huawei.com> for dime@ietf.org; Mon, 20 Aug 2007 16:49:28 +0800 (CST) Date: Mon, 20 Aug 2007 16:49:28 +0800 From: Tina TSOU Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] To: dime@ietf.org, Hannes Tschofenig Message-id: <00b001c7e307$04c84b20$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46C8A642.2040102@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Hannes and all, Sorry for late...^o* Will provide it during this week. B. R. Tina ---------------------------------------------- All the other days should inherit from Monday. ---------------------------------------------- ----- Original Message ----- From: "Hannes Tschofenig" To: Sent: Monday, August 20, 2007 4:21 AM Subject: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] > During the IETF#69 meeting I have also asked for reviewers. Two persons > offered help: > * Jouni Korhonen > * Tina Tsou > > Their review is still pending! > > -------- Original Message -------- > Subject: Request for review of "AAA Framework for Multicasting" > Date: Sat, 18 Aug 2007 14:49:00 -0700 > From: Bernard Aboba > To: radiusext@ops.ietf.org > > > > A request for review has been received relating to the document "AAA > Framework for Multicasting" which is under development within the MBONED > WG. The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt > > The Request for Review will last until September 5, 2007. Please post > your comments on this document to the RADEXT WG mailing list, CC:'ing the > document authors. > > Information on the review request was previously posted to the RADEXT WG > mailing list: > http://ops.ietf.org/lists/radiusext/2007/msg00528.html > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > _______________________________________________ > 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 Aug 20 05:49: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 1IN3t7-000216-9L; Mon, 20 Aug 2007 05:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3t6-00020z-DT for dime@ietf.org; Mon, 20 Aug 2007 05:49:32 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN3t3-0007WJ-59 for dime@ietf.org; Mon, 20 Aug 2007 05:49:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Aug 2007 05:49:24 -0400 X-IronPort-AV: i="4.19,283,1183348800"; d="scan'208"; a="49198947:sNHT7920438" 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] DIME WG Status Update (August 2007) Date: Mon, 20 Aug 2007 11:48:43 +0200 Message-ID: In-Reply-To: <46C8ADEA.5000809@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME WG Status Update (August 2007) Thread-Index: AcfiozLeKZafgoc9SbCPOq2aJnUSXAAa3d1g References: <46C8ADEA.5000809@gmx.net> From: "Romascanu, Dan (Dan)" To: "Hannes Tschofenig" , 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 Questions: 1. Diameter QoS=20 Action item: Determine next steps for a potential document restructuring.=20 [DR} - whose action item is this?=20 2. Diameter Applications Design Guidelines=20 It is necessary to create another draft update to reflect recently received review comments, namely:=20 More clarification on application versioning using optional avps.=20 Comments centered around vendor specific command code allocation=20 Editorials.=20 Then, the document will be sent for review to other SDOs.=20 Planned WGLC: December 2007 [DR] - which SDOs? Do you plan to have the document first reviewed with other SDOs and then enter WGLC? Why not enter directly WGLC and ask the other SDOs to provide their inputs as WGLC comments?=20 Dan =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, August 19, 2007 11:54 PM > To: dime@ietf.org > Subject: [Dime] DIME WG Status Update (August 2007) >=20 > A new DIME WG status update is available. See=20 > http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate >=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 Aug 20 05:52: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 1IN3w0-0004rk-GD; Mon, 20 Aug 2007 05:52:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3vz-0004rQ-Rt for dime@ietf.org; Mon, 20 Aug 2007 05:52:31 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN3vz-0002N6-At for dime@ietf.org; Mon, 20 Aug 2007 05:52:31 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l7K9qM5w016831; Mon, 20 Aug 2007 11:52:22 +0200 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l7K9qMtM030090; Mon, 20 Aug 2007 11:52:22 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 11:52:22 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Dime] DIME WG Status Update (August 2007) Date: Mon, 20 Aug 2007 11:52:22 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB05552B@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] DIME WG Status Update (August 2007) Thread-Index: AcfiozLeKZafgoc9SbCPOq2aJnUSXAAa3d1gAAA2lIA= References: <46C8ADEA.5000809@gmx.net> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Romascanu, Dan (Dan)" , "Hannes Tschofenig" , X-OriginalArrivalTime: 20 Aug 2007 09:52:22.0484 (UTC) FILETIME=[CE14E940:01C7E30F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Dan,=20 > Questions: >=20 > 1. Diameter QoS=20 > Action item: Determine next steps for a potential document > restructuring.=20 >=20 > [DR} - whose action item is this?=20 Good point. That's my action item.=20 >=20 > 2. Diameter Applications Design Guidelines=20 > It is necessary to create another draft update to reflect recently > received review comments, namely:=20 >=20 > More clarification on application versioning using optional avps.=20 > Comments centered around vendor specific command code allocation=20 > Editorials.=20 > Then, the document will be sent for review to other SDOs.=20 >=20 > Planned WGLC: December 2007 >=20 > [DR] - which SDOs? Do you plan to have the document first=20 > reviewed with > other SDOs and then enter WGLC? Why not enter directly WGLC=20 > and ask the > other SDOs to provide their inputs as WGLC comments?=20 Regarding the SDOs:=20 I was thinking about 3GPP, OMA, ITU-T, TISPAN, and 3GPP2.=20 Your suggestion regarding combining the WGLC with the feedback from other SDOs is good.=20 >=20 >=20 > Dan Thanks for your feedback. Good to know that someone reads my mails... Ciao Hannes >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Sunday, August 19, 2007 11:54 PM > > To: dime@ietf.org > > Subject: [Dime] DIME WG Status Update (August 2007) > >=20 > > A new DIME WG status update is available. See=20 > > http://www.tschofenig.priv.at/twiki/bin/view/Dime/DimeStatusUpdate > >=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 Tue Aug 21 09:19:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTe5-0003sn-EQ; Tue, 21 Aug 2007 09:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTe4-0003ra-GM for dime@ietf.org; Tue, 21 Aug 2007 09:19:44 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INTe3-0000U5-Vb for dime@ietf.org; Tue, 21 Aug 2007 09:19:44 -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 l7LDJh4w022659; Tue, 21 Aug 2007 09:19:43 -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] QoS Application Review Date: Tue, 21 Aug 2007 09:19:43 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188176@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] QoS Application Review Thread-Index: AcfXudwqxDV2fHsnR1qRYHut1cL9KgBenZEQAq/VctA= References: <033458F56EC2A64E8D2D7B759FA3E7E702DF26@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Pete, Please find below a few more questions/comments (and sorry for the late reply). Thanks, Tolga > > 1- As indicated during IETF69 Dime sessions as well, more explanation > > is necessary for push mode operation; particularly state machines and > > explanation of the procedures at each step of the operation. IMHO, > > push and pull modes seem different enough to justify two different > > applications. >=20 > That might be a good idea; however, as was mentioned during the WG > meeting it may be possible to use both modes during a single session, > where some NEs use push mode and some NEs use pull mode. If we allow > that, it might make more sense to keep a single application. [TOLGA] Using different modes could be possible to reserve resources for a single service session, but this probably would map to multiple sessions from Diameter perspective. It seems to me that push and pull modes are quite different from protocol operations perspective. Both in terms of document organization/readability purposes and also for message routing purposes (e.g. if there is an authorizing entity, which can support only pull-mode scenarios, messages for push-mode sessions should not be routed to it)two applications could be a good alternative. [..snip..] > That's essentially what we did; we re-used the Cost-Information, > Cost-Unit, Tariff-Time-Change, and CC-Time AVPs within the > Diameter QoS commands but provided a much simpler framework > in which to work. >=20 > > If not all flexibility provided by CCA is necessary, this > > could be indicated as well. I will start a new thread about this > > (what to do if one wants to reuse an existing application -because > > the semantics provided by that application are a good match- but > > wants to add a few new AVPs with M-bit set) regarding its impact on > > Application Design Guideline work. >=20 > Ok let's talk about this. IMHO the commands in the Diameter QoS > application are the ones we want to use. [TOLGA]I agree. I think the current approach in the QoS document is in the right direction. We keep preaching to define new commands/applications when new mandatory AVPs are added/semantics are changed, so I guess this is a good example of what one should do. [..snip..] > > 5- I guess we should cover how emergency sessions are to be handled. > > I didn't check whether there is an already suitable AVP for this but > > some AVP identifying the priority of the QoS request could be useful > > (and semantics about its use should be defined as well) >=20 > I suppose we might need such an AVP either in QAA or QIR, in the > case where the Authorizing Entity knows about the emergency status; > Alternatively, such a field could be added to NSIS if only the > AE knows about the emergency status. I am not sure whether > such a field exists in NSIS - maybe experts could speak up? [TOLGA]Even if there is support from NSIS, we may need an emergency-level AVP for push mode. >=20 > > 6- Especially for push mode, there should be a way for NE to signal > > loss of an existing reservation. This mechanism should allow > > signaling of loss of a single flow in a session with multiple flows. >=20 > Are you thinking that the NE might be monitoring the flow for > active traffic, and then timeout when it detects no packets > for a certain period of time? We need to watch out for confusing > loss of bearer with silence suppression. Maybe you have in mind > that some specific link-layer trigger that tears-down the flow. > In general, we also may want to react to NSIS signaling that > "politely" tears down a flow. [TOLGA] What I had in mind was more close to what you described second. For example to allocate resources for an emergency call, it could be necessary to release some resources which are previously allocated for another call. I think it makes sense to notify PDF of such cases, so that it takes necessary action. >=20 > If we keep every flow as a different Diameter QoS session, it > should be possible to terminate them independently. Hopefully > we can just use STR / ASR for termination. [TOLGA] That could help simplify things from protocol perspective. PDF would need to associate different Diameter sessions to a single service session but I guess this should be fine. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 11:43: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 1INVsq-0001t0-6W; Tue, 21 Aug 2007 11:43:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVsp-0001sS-Ad for dime@ietf.org; Tue, 21 Aug 2007 11:43:07 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INVso-0002ip-Q9 for dime@ietf.org; Tue, 21 Aug 2007 11:43:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2007 11:45:24 -0400 Message-ID: From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Dime] 3588bis: Vendor Ids in CER/CEA 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 The description for the Vendor-Id AVP in CER/CEA messages state it is to identify the "vendor of the application" but in that case, it appears to be redundant. The application vendor is already advertised within the grouped Vendor-Specific-Application-Id AVP for a vendor-specific application.=20 Looking though my attic of draft-ietf-aaa-diameter-xx, I see this Vendor-Id AVP was originally destined to identify the device vendor. Hence the comment in 3588: "It is also envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information". I think we should fix this in 3588bis but backwards compatibility is likely an issue. On a related noted, I assume that advertising support for a vendor-specific application implies support for the vendor-specific AVPs from that same vendor. If so, I couldn't find this explicitly stated in 3588 and it probably should not be left as an assumption. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 11:45: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 1INVut-0003Ke-Dl; Tue, 21 Aug 2007 11:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INVus-0003KX-Dl for dime@ietf.org; Tue, 21 Aug 2007 11:45:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INVuq-0006gz-S0 for dime@ietf.org; Tue, 21 Aug 2007 11:45:14 -0400 Received: (qmail invoked by alias); 21 Aug 2007 15:45:11 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp043) with SMTP; 21 Aug 2007 17:45:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/xF4HUlO/eOpqpG8f8wzN6LFIR0zy7cO42Qo3Jx XyrteaZxBmjdFN Message-ID: <46CB0886.8050005@gmx.net> Date: Tue, 21 Aug 2007 17:45:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA 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: e1e48a527f609d1be2bc8d8a70eb76cb 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, do you plan to propose specific text to make it easier to finish this issue? Ciao Hannes Mark Jones wrote: > The description for the Vendor-Id AVP in CER/CEA messages state it is to > identify the "vendor of the application" but in that case, it appears to > be redundant. The application vendor is already advertised within the > grouped Vendor-Specific-Application-Id AVP for a vendor-specific > application. > > Looking though my attic of draft-ietf-aaa-diameter-xx, I see this > Vendor-Id AVP was originally destined to identify the device vendor. > Hence the comment in 3588: "It is also envisioned that the combination > of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision > (Section 5.3.4) AVPs MAY provide very useful debugging information". I > think we should fix this in 3588bis but backwards compatibility is > likely an issue. > > On a related noted, I assume that advertising support for a > vendor-specific application implies support for the vendor-specific AVPs > >from that same vendor. If so, I couldn't find this explicitly stated in > 3588 and it probably should not be left as an assumption. > > 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 Aug 21 11:53: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 1INW2v-0000kh-3Y; Tue, 21 Aug 2007 11:53:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INW2t-0000kY-JJ for dime@ietf.org; Tue, 21 Aug 2007 11:53:31 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INW2t-00033K-7S for dime@ietf.org; Tue, 21 Aug 2007 11:53:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 11:55:49 -0400 Message-ID: In-Reply-To: <46CB0886.8050005@gmx.net> References: <46CB0886.8050005@gmx.net> From: "Mark Jones" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > do you plan to propose specific text to make it easier to finish this=20 > issue? >=20 Absolutely Hannes. But I wanted to use the list to poll for any backwards compatibility concerns of changing the description back to "device vendor". Any concerns? I also wanted to check that my assumption on support of vendor-specific AVPs was correct. Does it make sense to you? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 12:01: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 1INWAK-0003zH-F3; Tue, 21 Aug 2007 12:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWAJ-0003z2-1m for dime@ietf.org; Tue, 21 Aug 2007 12:01:11 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INWAI-00079F-KE for dime@ietf.org; Tue, 21 Aug 2007 12:01:11 -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 l7LG19AB008345; Tue, 21 Aug 2007 12:01:09 -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] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 12:01:09 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfkCfuzhmJYc2GNTAC3vwUMVwpRMQAAOXuQ References: From: "Asveren, Tolga" To: "Mark Jones" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Mark, If certain vendor specific AVPs without M-bit set are added for a command, it seems possible to use an existing application. In such a case, it could be useful to signal which optional extensions are supported by an endpoint.=20 I think Supported-Vendor-Id could be used for the purpose I mentioned above. I am aware of a few implementations which use Vendor-Id for this purpose as well. Actually, considering that advertising support for optional extensions should be done end-to-end, using CER/CEA for that purpose is of limited use. There could be intermediaries between client and servers. It could be an idea to mention about this limitation and preferably address it. Or we can just deprecate this functionality assuming that if an extension is optional, it shouldn't matter much whether the server supports it (and if the extension is really vital, it should be a new application). Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Tuesday, August 21, 2007 11:45 AM > To: dime@ietf.org > Subject: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > The description for the Vendor-Id AVP in CER/CEA messages state it is to > identify the "vendor of the application" but in that case, it appears to > be redundant. The application vendor is already advertised within the > grouped Vendor-Specific-Application-Id AVP for a vendor-specific > application. >=20 > Looking though my attic of draft-ietf-aaa-diameter-xx, I see this > Vendor-Id AVP was originally destined to identify the device vendor. > Hence the comment in 3588: "It is also envisioned that the combination > of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision > (Section 5.3.4) AVPs MAY provide very useful debugging information". I > think we should fix this in 3588bis but backwards compatibility is > likely an issue. >=20 > On a related noted, I assume that advertising support for a > vendor-specific application implies support for the vendor-specific AVPs > from that same vendor. If so, I couldn't find this explicitly stated in > 3588 and it probably should not be left as an assumption. >=20 > Regards > Mark >=20 >=20 >=20 >=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 Tue Aug 21 14:28: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 1INYT4-0006qG-SC; Tue, 21 Aug 2007 14:28:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYT4-0006ls-6n for dime@ietf.org; Tue, 21 Aug 2007 14:28:42 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INYT3-00082H-P5 for dime@ietf.org; Tue, 21 Aug 2007 14:28:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 14:30:59 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Thanks Tolga. Answers inline.=20 > If certain vendor specific AVPs without M-bit set are added for a > command, it seems possible to use an existing application. In such a > case, it could be useful to signal which optional extensions are > supported by an endpoint.=20 >=20 Agreed but let me illustrate the ambiguity with an example: A Diameter peer supports a 3GPP application with some optional Bridgewater vendor-specific AVPs (no M-bit set). In the CER/CEA, 3GPP's vendor id would go into the Vendor-Id AVP in the Vendor-Specific-Application-Id AVP and Bridgewater's vendor id would go into the Support-Vendor-Id AVP. So far so good. But the 3GPP application uses 3GPP vendor-specific AVPs so should 3GPP's vendor id also be advertised in a Supported-Vendor-Id AVP? Non-IETF SDOs appear to disagree on the answer to this question. I think 3588bis should be opinionated otherwise interop will suffer on convergence between SDOs. I propose appending the following to section 5.3.6 (Supported-Vendor-Id): "If a peer advertises support of a vendor-specific application, it is implied that the peer supports (a subset of) the vendor-specific AVPs of that vendor. In this case, the CER/CEA SHOULD NOT contain a Supported-Vendor-Id AVP with the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] value of the application vendor." I don't think we can make that "SHOULD NOT" into a "SHALL NOT" due to backwards compatibility concerns. Any objections? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 14:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYoT-00069k-Uk; Tue, 21 Aug 2007 14:50:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYoS-00069e-L5 for dime@ietf.org; Tue, 21 Aug 2007 14:50:48 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INYoR-0000EV-R5 for dime@ietf.org; Tue, 21 Aug 2007 14:50:48 -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 l7LIoiVq028866; Tue, 21 Aug 2007 14:50:44 -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] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 14:50:44 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfkIRqYs0yvS0sxRv6jHTIe7h8MMwAAe+7w References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Mark Jones" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Mark, Please see below for comments/questions. Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Tuesday, August 21, 2007 2:31 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Thanks Tolga. Answers inline. >=20 > > If certain vendor specific AVPs without M-bit set are added for a > > command, it seems possible to use an existing application. In such a > > case, it could be useful to signal which optional extensions are > > supported by an endpoint. > > >=20 > Agreed but let me illustrate the ambiguity with an example: >=20 > A Diameter peer supports a 3GPP application with some optional > Bridgewater vendor-specific AVPs (no M-bit set). In the CER/CEA, 3GPP's > vendor id would go into the Vendor-Id AVP in the > Vendor-Specific-Application-Id AVP and Bridgewater's vendor id would go > into the Support-Vendor-Id AVP. So far so good. >=20 > But the 3GPP application uses 3GPP vendor-specific AVPs so should 3GPP's > vendor id also be advertised in a Supported-Vendor-Id AVP? [TOLGA] I would say "No" considering the existing text in RFC3588: "The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to the vendor of the Diameter application. In combination with the Supported-Vendor-Id AVP (Section 5.3.6), this MAY be used in order to know which vendor specific attributes may be sent to the peer." So, basically it seems Vendor-Id implies that AVPs for the corresponding vendor are supported as well. There shouldn't be a need to re-specify this with Supported-Vendor-Id AVP. >=20 > Non-IETF SDOs appear to disagree on the answer to this question. I think > 3588bis should be opinionated otherwise interop will suffer on > convergence between SDOs. I propose appending the following to section > 5.3.6 (Supported-Vendor-Id): >=20 > "If a peer advertises support of a vendor-specific application, it is > implied that the peer supports (a subset of) the vendor-specific AVPs of > that vendor. In this case, the CER/CEA SHOULD NOT contain a > Supported-Vendor-Id AVP with the IANA "SMI Network Management Private > Enterprise Codes" [RFC3232] value of the application vendor." >=20 > I don't think we can make that "SHOULD NOT" into a "SHALL NOT" due to > backwards compatibility concerns. Any objections? [TOLGA]Overall, I think embedding some end-to-end information into capability exchange procedure is not a good idea. This seems to be an oversight in RFC3588 (or a leftover from an early version, where there wasn't support for intermediaries). >=20 > Regards > Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 15:28: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 1INZOv-00058a-Pc; Tue, 21 Aug 2007 15:28:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INZOu-00057j-IU for dime@ietf.org; Tue, 21 Aug 2007 15:28:28 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INZOu-0004vm-5j for dime@ietf.org; Tue, 21 Aug 2007 15:28:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 15:30:43 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > So, basically it seems Vendor-Id implies that AVPs for the=20 > corresponding > vendor are supported as well. There shouldn't be a need to re-specify > this with Supported-Vendor-Id AVP. And that was the first point in my original email: The original intention of the Vendor-Id AVP in the CER/CEA was to communicate the 'device vendor' NOT the 'application vendor'. Admittedly this was a poor choice of AVP name given all the vendor ids flying around in CER/CEA and this vague name probably explains why the AVP description was later (mistakenly?) changed from 'device vendor' to 'application vendor'. So I also propose changing the first paragraph in section 5.3.3 to: The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] value assigned to the vendor of the Diameter device. It is=20 envisioned that the combination of the Vendor-Id, Product-Name=20 (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information. > [TOLGA]Overall, I think embedding some end-to-end information into > capability exchange procedure is not a good idea. This seems to be an > oversight in RFC3588 (or a leftover from an early version, where there > wasn't support for intermediaries). The 'very useful debugging information' here was only ever intended for debugging a single hop. I agree that CER/CEA exchanges offer no help in end-to-end debugging and that was never the intent of the Vendor-Id/Product-Name/Firmware-Revision AVPs. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 21 15:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INZd5-0000uy-Om; Tue, 21 Aug 2007 15:43:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INZd5-0000ut-0N for dime@ietf.org; Tue, 21 Aug 2007 15:43:07 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INZd4-0001qR-IJ for dime@ietf.org; Tue, 21 Aug 2007 15:43:06 -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 l7LJh51S000856; Tue, 21 Aug 2007 15:43:05 -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] 3588bis: Vendor Ids in CER/CEA Date: Tue, 21 Aug 2007 15:43:05 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfkKXPDiyKc8oiwSZSjkFnleeROFQAAD2SQ References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Mark Jones" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Mark, Please see below for comments. Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Tuesday, August 21, 2007 3:31 PM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > > So, basically it seems Vendor-Id implies that AVPs for the > > corresponding > > vendor are supported as well. There shouldn't be a need to re-specify > > this with Supported-Vendor-Id AVP. >=20 > And that was the first point in my original email: The original > intention of the Vendor-Id AVP in the CER/CEA was to communicate the > 'device vendor' NOT the 'application vendor'. Admittedly this was a poor > choice of AVP name given all the vendor ids flying around in CER/CEA and > this vague name probably explains why the AVP description was later > (mistakenly?) changed from 'device vendor' to 'application vendor'. >=20 > So I also propose changing the first paragraph in section 5.3.3 to: >=20 > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains > the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] > value assigned to the vendor of the Diameter device. It is > envisioned that the combination of the Vendor-Id, Product-Name > (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY > provide very useful debugging information. [TOLGA]Except backward compatibility issues, IMHO this change makes more sense than what is currently there in RFC3588. I don't know how serious of a backward compatibility issue we are talking about here. I saw people using Product-Name to indicate both the vendor and a specific product, e.g. "Company-A Product-Y". I saw people populating Vendor-Id AVP to advertise support for AVP extensions as well. Still, IMHO we should be able to digest this level of a change in the bis document. >=20 > > [TOLGA]Overall, I think embedding some end-to-end information into > > capability exchange procedure is not a good idea. This seems to be an > > oversight in RFC3588 (or a leftover from an early version, where there > > wasn't support for intermediaries). >=20 > The 'very useful debugging information' here was only ever intended for > debugging a single hop. I agree that CER/CEA exchanges offer no help in > end-to-end debugging and that was never the intent of the > Vendor-Id/Product-Name/Firmware-Revision AVPs. [TOLGA]The same problem is there for Supported-Vendor-Id as well.=20 >=20 > Regards > Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 08:36: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 1INpSC-00056b-Q0; Wed, 22 Aug 2007 08:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INpSB-00051N-Pw for dime@ietf.org; Wed, 22 Aug 2007 08:36:55 -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 1INpSB-00021A-FX for dime@ietf.org; Wed, 22 Aug 2007 08:36:55 -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 l7MCaYmx038938; Wed, 22 Aug 2007 08:36:34 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CC2DD2.8090605@tari.toshiba.com> Date: Wed, 22 Aug 2007 08:36:34 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) 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 Hi, >> So I also propose changing the first paragraph in section 5.3.3 to: >> >> The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains >> the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] >> value assigned to the vendor of the Diameter device. It is >> envisioned that the combination of the Vendor-Id, Product-Name >> (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY >> provide very useful debugging information. >> > [TOLGA]Except backward compatibility issues, IMHO this change makes more > sense than what is currently there in RFC3588. I don't know how serious > of a backward compatibility issue we are talking about here. I saw > people using Product-Name to indicate both the vendor and a specific > product, e.g. "Company-A Product-Y". I saw people populating Vendor-Id > AVP to advertise support for AVP extensions as well. Still, IMHO we > should be able to digest this level of a change in the bis document. > Backward compatibility may not be an issue since people have been given free reign on the interpretations of vendor-id to begin with; i.e. there's not set value to be backward compatible to. The proposed change is ok with me ... maybe a little tighter text would be better if we really want to be clear on the per-hop context of vendor-id. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 08:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INplp-0000dU-S3; Wed, 22 Aug 2007 08:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INplo-0000dJ-Ja for dime@ietf.org; Wed, 22 Aug 2007 08:57:12 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INplo-0002QP-6n for dime@ietf.org; Wed, 22 Aug 2007 08:57:12 -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 l7MCvAUs031241; Wed, 22 Aug 2007 08:57:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 08:57:10 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188184@sonusmail04.sonusnet.com> In-Reply-To: <46CC2DD2.8090605@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfkuSEsKCCUmEd0QPCmTpPaEKtM/wAAIdYg References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC2DD2.8090605@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, August 22, 2007 8:37 AM > To: Asveren, Tolga > Cc: Mark Jones; dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi, >=20 >=20 > >> So I also propose changing the first paragraph in section 5.3.3 to: > >> > >> The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains > >> the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] > >> value assigned to the vendor of the Diameter device. It is > >> envisioned that the combination of the Vendor-Id, Product-Name > >> (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY > >> provide very useful debugging information. > >> > > [TOLGA]Except backward compatibility issues, IMHO this change makes more > > sense than what is currently there in RFC3588. I don't know how serious > > of a backward compatibility issue we are talking about here. I saw > > people using Product-Name to indicate both the vendor and a specific > > product, e.g. "Company-A Product-Y". I saw people populating Vendor-Id > > AVP to advertise support for AVP extensions as well. Still, IMHO we > > should be able to digest this level of a change in the bis document. > > >=20 > Backward compatibility may not be an issue since people have been given > free reign on the interpretations of vendor-id to begin with; i.e. > there's not set value to be backward compatible to. The proposed change > is ok with me ... maybe a little tighter text would be better if we > really want to be clear on the per-hop context of vendor-id. [TOLGA] There is no set value, but consider the following situation: There a RFC3588 compliant stack, expecting Vendor-Id AVP to contain the vendor-Id of the corresponding application vendor. With RFC3588 compliant stacks, verifying this wouldn't cause a problem because Vendor-Id AVP would contain the expected value. With a RFC3588-bis compliant stack, such a check would fail because Vendor-Id would contain the vendor-Id of the product vendor not the application vendor. Having said that: a) I am not sure whether many implementations perform such a check b) I agree that the functionality defined in the proposed text is better c) I think that we should have this change in the bis d) It could be better to provide explanation for per-hop/end-to-end issue for Supported-Vendor-Id AVP (or for both cases) =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 09:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INpvd-0007ro-23; Wed, 22 Aug 2007 09:07:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INpvb-0007rj-65 for dime@ietf.org; Wed, 22 Aug 2007 09:07:19 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INpva-0000P8-OQ for dime@ietf.org; Wed, 22 Aug 2007 09:07:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 09:09:33 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Tolga,=20 Thank you for supporting the proposal to fix this Vendor-Id ambiguity in 3588bis. After reviewing rfc3588bis-05 for impacts, here are the proposed changes: --- 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] value assigned to the vendor of the Diameter device. It is envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information. --- 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) If a peer advertises support of a vendor-specific application in the Vendor-Specific-Application-Id AVP (Section 6.11), it is implied that the peer supports (a subset of) the vendor- specific AVPs of that vendor. In this case, the CER/CEA SHOULD=20 NOT contain a Supported-Vendor-Id AVP with the IANA "SMI=20 Network Management Private Enterprise Codes" [RFC3232] value of the application vendor." --- 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id AVP) The Vendor-Id AVP in this context contains the IANA "SMI=20 Network Management Private Enterprise Codes" [RFC3232] value assigned to the vendor of the Diameter application advertised=20 in the Auth-Application-Id or Acct-Application-Id AVP. It=20 indicates that the peer supports (a subset of) the vendor- specific AVPs of the application vendor. It MUST NOT be used as a means of defining a completely separate vendor-specific application identifier space. --- Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 09:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INqDf-0003sp-UX; Wed, 22 Aug 2007 09:25:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INqDe-0003sk-Pm for dime@ietf.org; Wed, 22 Aug 2007 09:25:58 -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 1INqDe-000389-GG for dime@ietf.org; Wed, 22 Aug 2007 09:25:58 -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 l7MDPVB7039193; Wed, 22 Aug 2007 09:25:31 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CC394B.3060505@tari.toshiba.com> Date: Wed, 22 Aug 2007 09:25:31 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC2DD2.8090605@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188184@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188184@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Tolga, >> is ok with me ... maybe a little tighter text would be better if we >> really want to be clear on the per-hop context of vendor-id. >> > [TOLGA] There is no set value, but consider the following situation: > There a RFC3588 compliant stack, expecting Vendor-Id AVP to contain the > vendor-Id of the corresponding application vendor. With RFC3588 > compliant stacks, verifying this wouldn't cause a problem because > Vendor-Id AVP would contain the expected value. With a RFC3588-bis > compliant stack, such a check would fail because Vendor-Id would contain > the vendor-Id of the product vendor not the application vendor. Having > said that: > a) I am not sure whether many implementations perform such a check > I think this is the main criteria why the bis should not be too concerned with backward compatibility. 3588 never mandated any validation/processing on the vendor-id so if extra functionality is added onto vendor-id then its already a risky implementation for any vendor despite of any changes we propose. > b) I agree that the functionality defined in the proposed text is better > c) I think that we should have this change in the bis > d) It could be better to provide explanation for per-hop/end-to-end > issue for Supported-Vendor-Id AVP (or for both cases) > Ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 09:44: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 1INqVF-0000UG-T7; Wed, 22 Aug 2007 09:44:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INqVE-0000UB-BO for dime@ietf.org; Wed, 22 Aug 2007 09:44:08 -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 1INqVD-0001ai-Th for dime@ietf.org; Wed, 22 Aug 2007 09:44:08 -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 l7MDi5N1039282; Wed, 22 Aug 2007 09:44:05 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CC3DA5.9030700@tari.toshiba.com> Date: Wed, 22 Aug 2007 09:44:05 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.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: f60d0f7806b0c40781eee6b9cd0b2135 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, > --- > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > 5.3.4) AVPs MAY provide very useful debugging information. > Ok. > --- > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > If a peer advertises support of a vendor-specific application > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > implied that the peer supports (a subset of) the vendor- > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value of > the application vendor." > I'm fine with this. > --- > > 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) > > > The Vendor-Id AVP in this context contains the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value > assigned to the vendor of the Diameter application advertised > in the Auth-Application-Id or Acct-Application-Id AVP. It > indicates that the peer supports (a subset of) the vendor- > specific AVPs of the application vendor. It MUST NOT be used > as a means of defining a completely separate vendor-specific > application identifier space. > 1. We can remove "(a subset of)". Advertising support for an application does not provide hints on "subsets" of avps. 2. s/peer/node/ regards, victor > --- > > 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 Wed Aug 22 10:58: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 1INrex-0000aV-Ok; Wed, 22 Aug 2007 10:58:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrew-0000aP-GM for dime@ietf.org; Wed, 22 Aug 2007 10:58:14 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INrev-0003Qm-6I for dime@ietf.org; Wed, 22 Aug 2007 10:58:14 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 16:58:11 +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] [Fwd: Request for review of "AAA Framework for Multicasting"] Date: Wed, 22 Aug 2007 16:58:04 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301F2773F@SEHAN021MB.tcad.telia.se> In-Reply-To: <46C8A642.2040102@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] Thread-Index: Acfino18Ig0d+RsrR/efZgw4J5Mw9wCF2BXg References: <46C8A642.2040102@gmx.net> From: To: , X-OriginalArrivalTime: 22 Aug 2007 14:58:11.0131 (UTC) FILETIME=[DB8DC0B0:01C7E4CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 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 All, Here are my initial comments on this draft. ---- Firstly idnits gives rather many errors and warning. The authors should check the draft against the idnits. Some editorial comments: Section 1.1 o "...communication schemes of any kind, such as 1-to-n (case of=20 TV broadcasting services for example) or n-to-p (case of..." rather use one-to-many and many-to-many o "...high-quality multicast transport using a Resource and=20 Admission Control System (RACS) with multicast..." I assume this refers to TiSPAN defined RACS functional entity. I would like to see a reference here. o "...presented in draft-ietf-mboned-maccnt-req-04.txt,..." Rather use the reference to [1] o "...MACCNT-REQ-draft describes the requirements in CDN services=20 using IP multicast[1]. The requirements are derived from:..." o "...Detailed requirements are presented in MACCNT-REQ-draft...." Again the reference.. Section 2.1 o " Note: The definition of a receiver (device) and a user=20 (human) should not be confused. " This note does not really fit into definitions as it is. Now it looks like yet another definition, which is not the intent I assume. =20 Section 2.2 o AAA, mAAA, NSP-AAA, CP-AAA, ID, API, IF, NAS, QoS and RACS are missing Section 3 o "...are divided between separate entities. The MACCNT-REQ- draft provides more detail of the multiple versus single..." =20 Reference. o "...entity CDS network models. " Expand CDS on the first use o "As such it should not be assumed that the entity=20 responsible for the multicasting structure and the entity=20 responsible for content serving are the same. Indeed=20 because the infrastructure for multicasting is expensive=20 and many content holders are not likely to be competent at=20 building and maintaining complicated infrastructures=20 necessary for multicasting, many content holders would=20 prefer to purchase transport and management services from a=20 network service provider and thus share the infrastructure=20 costs with other content holders." Consider revising.. to something like.. whatever.. "It should not be assumed that the entity responsible for the multicasting infrastructure is not the same as the entity=20 responsible for serving the content. Content holders are not likely to build and maintain their own multicast network infrastructure that is not part of their expertise area. Rather they are willing to purchase transport and management services from dedicated network service providers." o "...The use model of a single NSP providing multicasting=20 services to multiple CPs the following general requirements=20 from MACCNT-REQ-draft apply:..." References.. Expand CP on the first usage. Reword to something like "In the usage model of where a single NSP provides multicast services to multiple Content Providers (CP), the following general requirements from [1] apply:.." o "When the NSP and CP are the same single entity the general=20 requirements are as follows." revise to=20 "When the NSP and the CP are the same entity then the general=20 requirements are as follows:" =20 Section 4.1 o "A general high-level framework can be represented as=20 follows." =20 =20 revise to.. something like "A general high-level framework is presented in the=20 Figure 1." =20 o For relationships use similar style as in previous sections. e.g. 1:1 -> one-to-one or 1-to-1 etc.. o Expand STB on the first use. o What is STB? It is mentioned only once in this document in this section.. o "The CP is responsible for Authentication and Authorization.." use "authentication and authorization" =20 =20 o "...(authentication by proxy), and the NSP's relevant AAA.." Authentication via or through?=20 o NSP-AAA and CP-AAA? o "...without querying the CP-AAA. When the NSP cannot or=20 decides not to multicast to users, the NSP may notify the..." I don't get what this is supposed to mean. Section 4.2 o Heading -> "Multiple User Identities" o Expand ID on the first use. Section 4.2 o References to [1].. and a consistent way of doing those would be nice. o Reference to RFC3810 & RFC3376 o Expand API on the first use Section 4.5 o References Section 4.7 o "reestablish" to "re-establish"? Section 5 o "Section 3.1 introduces the high-level AAA framework for..." introduced o "...access to the User. First a user that requests content..." revise to.. something like "...access to a user. First the user.." =20 o "...to the appropriate CP for Authentication and Authorization..." authorization and authorization o Notation of relations.. 1:1 etc to similar as previously used Section 5.2 o References.. o Should these "well managed", "fully enabled AAA" etc be defined in section 2.1 o "Section 3.1 intriduces" -> introduced o "of a AAA" -> "of an AAA" o In the figure 2 the caption is partial.. or parts of it is before the figure.. should be fixed o Use consistent way of expanding abbreviations.. both types e.g. Content Provider (CP) and CP (Content Provider) are used o Figure 3 has similar caption issues as figure 2 I got a bit stuck to general presentation of the draft. It needs more work. For general readability of the draft I would suggest paying attention to overall formatting. This may sound naive but IMHO I would suggest using some tool that generates automatically a proper layout, such as xml2rfc.=20 And then some remotely technical comments, if any. o It is rather unclear to me how the actual AAA transactions are supposed to work (refer to fig. 1). CP auth/authz the user and the CP also auth/authz the NSP? Are these separate? What about user to NSP auth/authz? (this is then later described better in section 5.1 but not where the fig.1=20 is described) o "The actual mapping rules for NSPs and CPs to map user IDs=20 with the IDs in other provider domains is a matter for the=20 providers. A solution should provide an API between the=20 providers to flexibly support various mapping methods." The inter-working could be explained a bit more carefully. An example would be nice. Otherwise this is rather unambiguous. o Standardization of logs? Do you mean coming up with a file presentation format for user session tracking? Or rather just defining that billing record format? Could any of the existing ones be re-used or expanded? o "...This framework specifies an accounting API provided by the=20 NSP and accessed by the CP to allow for sharing user-..." I don't really find the API specification in this framework draft =20 o Does API here actually mean AAA interface or something else? The use of API-term is somewhat confusing.. o "content request" is AAA request? o It would be nice to have a separate sections (or something) going through each AAA interface (IFa, IFb, etc)=20 Cheers, Jouni > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Sunday, August 19, 2007 11:21 PM > To: dime@ietf.org > Subject: [Dime] [Fwd: Request for review of "AAA Framework=20 > for Multicasting"] >=20 >=20 > During the IETF#69 meeting I have also asked for reviewers.=20 > Two persons offered help: > * Jouni Korhonen > * Tina Tsou >=20 > Their review is still pending! >=20 > -------- Original Message -------- > Subject: Request for review of "AAA Framework for Multicasting" > Date: Sat, 18 Aug 2007 14:49:00 -0700 > From: Bernard Aboba > To: radiusext@ops.ietf.org >=20 >=20 >=20 > A request for review has been received relating to the=20 > document "AAA Framework for Multicasting" which is under=20 > development within the MBONED WG.=20 > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa > -framework-04.txt >=20 > The Request for Review will last until September 5, 2007. =20 > Please post your comments on this document to the RADEXT WG=20 > mailing list, CC:'ing the document authors. >=20 > Information on the review request was previously posted to=20 > the RADEXT WG mailing list: > http://ops.ietf.org/lists/radiusext/2007/msg00528.html >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=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 Wed Aug 22 11:59: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 1INscd-0003QV-HP; Wed, 22 Aug 2007 11:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INscb-0003FU-Mn for dime@ietf.org; Wed, 22 Aug 2007 11:59:53 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INsca-0006l1-De for dime@ietf.org; Wed, 22 Aug 2007 11:59:53 -0400 Received: by py-out-1112.google.com with SMTP id f31so670175pyh for ; Wed, 22 Aug 2007 08:59:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=d89HyJsKS5aCvvfqzu7js5f9qme7H4ecZsobKoc/GuSRjxhMT7Hf8GeyjuCzB23OywQaQv6blRoZJzS1gEj5yRLF3bojBwA2wSZZ11sIpd8+xtAW4e8CBqi+6LkSqj2Iq7D69vDJiDYFlmSV6iMrtsuyg6J7C05pBaX1MvMYGS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uITAdzkRQ3XZX78VYNgE8+dYp8F8daAppM2suQPUKe2EjHNuoqlNAx8LSNgP+s6bEyAgkCGXcq5z1mTlNjIFtlZCh5nITBcmq3SEBjHdgMga52AVUSL1C3kz3fqR9yoUGBOgBQcERLhxnwxlfAwFyfAd2V1HuCrWdedFN/mwKLA= Received: by 10.65.233.16 with SMTP id k16mr1256032qbr.1187798391828; Wed, 22 Aug 2007 08:59:51 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Wed, 22 Aug 2007 08:59:51 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 21:29:51 +0530 From: "Harish R Prabhu" To: dime@ietf.org Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA In-Reply-To: <46CC3DA5.9030700@tari.toshiba.com> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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="===============1807227411==" Errors-To: dime-bounces@ietf.org --===============1807227411== Content-Type: multipart/alternative; boundary="----=_Part_23399_30844994.1187798391624" ------=_Part_23399_30844994.1187798391624 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft? thanks, Harish On 8/22/07, Victor Fajardo wrote: > > Hi Mark, > > > --- > > > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > > contains the IANA "SMI Network Management Private Enterprise > > Codes" [RFC3232] value assigned to the vendor of the Diameter > > device. It is envisioned that the combination of the Vendor-Id, > > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > > 5.3.4) AVPs MAY provide very useful debugging information. > > > > Ok. > > > --- > > > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > > > If a peer advertises support of a vendor-specific application > > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > > implied that the peer supports (a subset of) the vendor- > > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI > > Network Management Private Enterprise Codes" [RFC3232] value of > > the application vendor." > > > > I'm fine with this. > > > --- > > > > 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id > > AVP) > > > > > > The Vendor-Id AVP in this context contains the IANA "SMI > > Network Management Private Enterprise Codes" [RFC3232] value > > assigned to the vendor of the Diameter application advertised > > in the Auth-Application-Id or Acct-Application-Id AVP. It > > indicates that the peer supports (a subset of) the vendor- > > specific AVPs of the application vendor. It MUST NOT be used > > as a means of defining a completely separate vendor-specific > > application identifier space. > > > > 1. We can remove "(a subset of)". Advertising support for an application > does not provide hints on "subsets" of avps. > 2. s/peer/node/ > > regards, > victor > > > --- > > > > 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 > -- Harish R Prabhu Bangalore, India. ------=_Part_23399_30844994.1187798391624 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft?

thanks,
Harish

On 8/22/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi Mark,

> ---
>
> 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP)
>
>  The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and
>  contains the IANA "SMI Network Management Private Enterprise
>  Codes" [RFC3232] value assigned to the vendor of the Diameter
>  device. It is envisioned that the combination of the Vendor-Id,
>  Product-Name (Section 5.3.7) and the Firmware-Revision (Section
>  5.3.4) AVPs MAY provide very useful debugging information.
>

Ok.

> ---
>
> 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP)
>
>  If a peer advertises support of a vendor-specific application
>  in the Vendor-Specific-Application-Id AVP (Section 6.11), it is
>  implied that the peer supports (a subset of) the vendor-
>  specific AVPs of that vendor. In this case, the CER/CEA SHOULD
>  NOT contain a Supported-Vendor-Id AVP with the IANA "SMI
>  Network Management Private Enterprise Codes" [RFC3232] value of
>  the application vendor."
>

I'm fine with this.

> ---
>
> 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id
> AVP)
>
>
>  The Vendor-Id AVP in this context contains the IANA "SMI
>  Network Management Private Enterprise Codes" [RFC3232] value
>  assigned to the vendor of the Diameter application advertised
>  in the Auth-Application-Id or Acct-Application-Id AVP. It
>  indicates that the peer supports (a subset of) the vendor-
>  specific AVPs of the application vendor. It MUST NOT be used
>  as a means of defining a completely separate vendor-specific
>  application identifier space.
>

1. We can remove "(a subset of)". Advertising support for an application
does not provide hints on "subsets" of avps.
2. s/peer/node/

regards,
victor

> ---
>
> 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



--
Harish R Prabhu
Bangalore, India. ------=_Part_23399_30844994.1187798391624-- --===============1807227411== 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 --===============1807227411==-- From dime-bounces@ietf.org Wed Aug 22 12:13: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 1INspq-0003ik-FA; Wed, 22 Aug 2007 12:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INspp-0003if-B9 for dime@ietf.org; Wed, 22 Aug 2007 12:13:33 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INspo-000707-2t for dime@ietf.org; Wed, 22 Aug 2007 12:13:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 12:15:48 -0400 Message-ID: In-Reply-To: <46CC3DA5.9030700@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Victor,=20 I'm fine with your proposed changes. Thanks Mark > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: August 22, 2007 15:44 > To: Mark Jones > Cc: Asveren, Tolga; dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi Mark, >=20 > > --- > > > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > > contains the IANA "SMI Network Management Private Enterprise > > Codes" [RFC3232] value assigned to the vendor of the Diameter > > device. It is envisioned that the combination of the Vendor-Id, > > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > > 5.3.4) AVPs MAY provide very useful debugging information. > > =20 >=20 > Ok. >=20 > > --- > > > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > > > If a peer advertises support of a vendor-specific application > > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > > implied that the peer supports (a subset of) the vendor- > > specific AVPs of that vendor. In this case, the CER/CEA SHOULD=20 > > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI=20 > > Network Management Private Enterprise Codes" [RFC3232] value of > > the application vendor." > > =20 >=20 > I'm fine with this. >=20 > > --- > > > > 3) Update 3rd paragraph in section 6.11=20 > (Vendor-Specific-Application-Id > > AVP) > > > > > > The Vendor-Id AVP in this context contains the IANA "SMI=20 > > Network Management Private Enterprise Codes" [RFC3232] value > > assigned to the vendor of the Diameter application advertised=20 > > in the Auth-Application-Id or Acct-Application-Id AVP. It=20 > > indicates that the peer supports (a subset of) the vendor- > > specific AVPs of the application vendor. It MUST NOT be used > > as a means of defining a completely separate vendor-specific > > application identifier space. > > =20 >=20 > 1. We can remove "(a subset of)". Advertising support for an=20 > application=20 > does not provide hints on "subsets" of avps. > 2. s/peer/node/ >=20 > regards, > victor >=20 > > --- > > > > Regards > > Mark > > > > _______________________________________________ > > 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 From dime-bounces@ietf.org Wed Aug 22 12:18: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 1INsuq-0004fV-PI; Wed, 22 Aug 2007 12:18:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsuq-0004fP-2w for dime@ietf.org; Wed, 22 Aug 2007 12:18:44 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INsup-0005D6-IK for dime@ietf.org; Wed, 22 Aug 2007 12:18:43 -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 l7MGIhum011264 for ; Wed, 22 Aug 2007 12:18:43 -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 Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 12:18:43 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718818B@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: Acfk1X/2D4SNGCEjRCaihBj/p2MT3QAAlO4w References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com><46CC3DA5.9030700@tari.toshiba.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Harish, What do you mean with "informational"? I assume you refer it being = between [] and optional. OTOH, the minimum count was given as 1, so = actually it was a mandatory AVP. Changing this could cause message = verification errors as many implementation try to validate an incoming = message based on command/Grouped AVP grammars. Thanks, Tolga ________________________________________ From: Harish R Prabhu [mailto:harish.r.prabhu@gmail.com]=20 Sent: Wednesday, August 22, 2007 12:00 PM To: dime@ietf.org Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA Does anyone perceive any impact of this discussion on Vendor-Id sub AVP = in Vendor-Specific-Application-Id AVP? As my understanding goes, = Application-Id is flat and there are no validation procedures for = Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in = the bis- draft?=20 thanks, Harish On 8/22/07, Victor Fajardo wrote: Hi Mark, > --- > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > >=A0=A0The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and >=A0=A0contains the IANA "SMI Network Management Private Enterprise=20 >=A0=A0Codes" [RFC3232] value assigned to the vendor of the Diameter >=A0=A0device. It is envisioned that the combination of the Vendor-Id, >=A0=A0Product-Name (Section 5.3.7) and the Firmware-Revision (Section=20 >=A0=A05.3.4) AVPs MAY provide very useful debugging information. > Ok. > --- > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > >=A0=A0If a peer advertises support of a vendor-specific application=20 >=A0=A0in the Vendor-Specific-Application-Id AVP (Section 6.11), it is >=A0=A0implied that the peer supports (a subset of) the vendor- >=A0=A0specific AVPs of that vendor. In this case, the CER/CEA SHOULD >=A0=A0NOT contain a Supported-Vendor-Id AVP with the IANA "SMI=20 >=A0=A0Network Management Private Enterprise Codes" [RFC3232] value of >=A0=A0the application vendor." > I'm fine with this. > --- > > 3) Update 3rd paragraph in section 6.11 = (Vendor-Specific-Application-Id > AVP) > > >=A0=A0The Vendor-Id AVP in this context contains the IANA "SMI >=A0=A0Network Management Private Enterprise Codes" [RFC3232] value >=A0=A0assigned to the vendor of the Diameter application advertised=20 >=A0=A0in the Auth-Application-Id or Acct-Application-Id AVP. It >=A0=A0indicates that the peer supports (a subset of) the vendor- >=A0=A0specific AVPs of the application vendor. It MUST NOT be used >=A0=A0as a means of defining a completely separate vendor-specific=20 >=A0=A0application identifier space. > 1. We can remove "(a subset of)". Advertising support for an application does not provide hints on "subsets" of avps. 2. s/peer/node/ regards, victor > --- > > 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 --=20 Harish R Prabhu=20 Bangalore, India.=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 12:27: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 1INt32-0003sS-2J; Wed, 22 Aug 2007 12:27:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INt31-0003sL-5X for dime@ietf.org; Wed, 22 Aug 2007 12:27:11 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INt30-0007HO-7q for dime@ietf.org; Wed, 22 Aug 2007 12:27:11 -0400 MIME-Version: 1.0 Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 12:29:29 -0400 Message-ID: In-Reply-To: References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com><033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com><46CC3DA5.9030700@tari.toshiba.com> From: "Mark Jones" To: "Harish R Prabhu" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 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: , Content-Type: multipart/mixed; boundary="===============1856536690==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1856536690== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E4D9.9E234FCB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E4D9.9E234FCB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harish, =20 The proposed update to section 6.11 means the Vendor-Id sub-AVP is no longer informational. It does mean that a vendor applying for a vendor-specific application will have to obtain a Private Enterprise Code too but they'd need to do that anyway in order to define any vendor-specific AVPs for their application. =20 Regards Mark =20 =20 ________________________________ From: Harish R Prabhu [mailto:harish.r.prabhu@gmail.com]=20 Sent: August 22, 2007 18:00 To: dime@ietf.org Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA =09 =09 Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft?=20 =09 thanks, Harish =09 =09 On 8/22/07, Victor Fajardo wrote:=20 Hi Mark, =09 > --- > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise=20 > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section=20 > 5.3.4) AVPs MAY provide very useful debugging information. > =09 Ok. =09 > --- > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > If a peer advertises support of a vendor-specific application=20 > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > implied that the peer supports (a subset of) the vendor- > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI=20 > Network Management Private Enterprise Codes" [RFC3232] value of > the application vendor." > =09 I'm fine with this. =09 > --- > > 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) > > > The Vendor-Id AVP in this context contains the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value > assigned to the vendor of the Diameter application advertised=20 > in the Auth-Application-Id or Acct-Application-Id AVP. It > indicates that the peer supports (a subset of) the vendor- > specific AVPs of the application vendor. It MUST NOT be used > as a means of defining a completely separate vendor-specific=20 > application identifier space. > =09 1. We can remove "(a subset of)". Advertising support for an application does not provide hints on "subsets" of avps. 2. s/peer/node/ =09 regards, victor =09 > --- > > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > =09 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 --=20 Harish R Prabhu=20 Bangalore, India.=20 ------_=_NextPart_001_01C7E4D9.9E234FCB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Harish,
 
The proposed update to section 6.11 means the = Vendor-Id=20 sub-AVP is no longer informational. It does mean that a vendor = applying for a vendor-specific application will have to obtain a Private = Enterprise Code too but they'd need to do that anyway in order to define = any=20 vendor-specific AVPs for their application.
 
Regards
Mark
 
 

From: Harish R Prabhu=20 [mailto:harish.r.prabhu@gmail.com]
Sent: August 22, 2007=20 18:00
To: dime@ietf.org
Subject: Re: [Dime] = 3588bis:=20 Vendor Ids in CER/CEA

Does anyone perceive any impact of this discussion on = Vendor-Id sub=20 AVP in Vendor-Specific-Application-Id AVP? As my understanding goes,=20 Application-Id is flat and there are no validation procedures for = Vendor-Id=20 sub-AVP (as it is informational). Then why is it mandatory in the bis- = draft?=20

thanks,
Harish

On 8/22/07, Victor=20 Fajardo <vfajardo@tari.toshiba.com&g= t;=20 wrote:
Hi=20 Mark,

> ---
>
> 1) Update 1st paragraph in = section=20 5.5.3 (Vendor-Id AVP)
>
>  The Vendor-Id AVP = (AVP Code=20 266) is of type Unsigned32 and
>  contains the IANA = "SMI=20 Network Management Private Enterprise
>  Codes" = [RFC3232]=20 value assigned to the vendor of the = Diameter
>  device. It=20 is envisioned that the combination of the=20 Vendor-Id,
>  Product-Name (Section 5.3.7) and the=20 Firmware-Revision (Section
>  5.3.4) AVPs MAY = provide very=20 useful debugging information.
>

Ok.

>=20 ---
>
> 2) Add new paragraph to section 5.3.6=20 (Supported-Vendor-Id AVP)
>
>  If a peer = advertises=20 support of a vendor-specific application
>  in the=20 Vendor-Specific-Application-Id AVP (Section 6.11), it=20 is
>  implied that the peer supports (a subset of) = the=20 vendor-
>  specific AVPs of that vendor. In this = case, the=20 CER/CEA SHOULD
>  NOT contain a Supported-Vendor-Id = AVP with=20 the IANA "SMI
>  Network Management Private = Enterprise=20 Codes" [RFC3232] value of
>  the application=20 vendor."
>

I'm fine with this.

> = ---
>
>=20 3) Update 3rd paragraph in section 6.11=20 (Vendor-Specific-Application-Id
>=20 AVP)
>
>
>  The Vendor-Id AVP in this = context=20 contains the IANA "SMI
>  Network Management Private = Enterprise Codes" [RFC3232] value
>  assigned to the = vendor=20 of the Diameter application advertised
>  in the=20 Auth-Application-Id or Acct-Application-Id AVP.=20 It
>  indicates that the peer supports (a subset of) = the=20 vendor-
>  specific AVPs of the application vendor. = It MUST=20 NOT be used
>  as a means of defining a completely = separate=20 vendor-specific
>  application identifier=20 space.
>

1. We can remove "(a subset of)". Advertising = support=20 for an application
does not provide hints on "subsets" of = avps.
2.=20 s/peer/node/

regards,
victor

> = ---
>
>=20 Regards
> Mark
>
>=20 _______________________________________________
> DiME mailing = list
> DiME@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/dime
>
>
>
>


__= _____________________________________________
DiME=20 mailing list
DiME@ietf.org
https://www1.ietf.or= g/mailman/listinfo/dime


--
Harish R Prabhu
Bangalore, India.=20 ------_=_NextPart_001_01C7E4D9.9E234FCB-- --===============1856536690== 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 --===============1856536690==-- From dime-bounces@ietf.org Wed Aug 22 12:37:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtCe-0004Ho-Nk; Wed, 22 Aug 2007 12:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtCd-0004Hi-Ic for dime@ietf.org; Wed, 22 Aug 2007 12:37:07 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INtCc-0007SB-Jp for dime@ietf.org; Wed, 22 Aug 2007 12:37:07 -0400 Received: by nz-out-0506.google.com with SMTP id n1so138068nzf for ; Wed, 22 Aug 2007 09:37:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=Lq5ol+DOrQATgJBwGNwblyQigvszCwjwvB5ce+F5cfvoSjgps3GcKu9IQrDxfzEJQ2+hXMIu/1BIjGd/Jd9fEmdrvJYPShpHFt1fgwjxTIoAq6xA//Eo3S/b2OpvNfFP8fv/JvRfOkWqkQQR7x68BOsrezaT6o85LfFImpifDJ8= 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=tUvVzby2krKtRgM5gLaB67XtpJ93r+WtlAlIJADL6Mcg7SLIq1s3p0nzw4BUrgZfzhzZUbKg0B0CuXU9xKlYCudFUJdaTKsEJbololFJdRzSkyXKfwO9heS6v6TIUCcNQ3Et7e0RN6hUaX9iKq/61b/FTj9sh4xbUo2b48yJMzU= Received: by 10.65.214.19 with SMTP id r19mr1327294qbq.1187800625660; Wed, 22 Aug 2007 09:37:05 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Wed, 22 Aug 2007 09:37:05 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 22:07:05 +0530 From: "Harish R Prabhu" To: "Mark Jones" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA In-Reply-To: MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f 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="===============1236935436==" Errors-To: dime-bounces@ietf.org --===============1236935436== Content-Type: multipart/alternative; boundary="----=_Part_24023_15943511.1187800625126" ------=_Part_24023_15943511.1187800625126 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This was the scenario I was trying to point out: 1. Application-IDs are allocated by IANA, and have to be obtained by a vendor with a Private Enterprise Code. 2. 1 implies that its possible to implicitly derive the Vendor info from the Application Id itself. Consider a situation wherein a diameter implementation sends a Vendor-Specific-Application-Id with an erroneous combination of (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose to validate the Vendor-Id and some may choose not to. Wouldnt this be an interoperability issue? If so, why have Vendor-Id in Vendor-Specific-Application-Id to create scope for this? thanks, Harish On 8/22/07, Mark Jones wrote: > > Hi Harish, > > The proposed update to section 6.11 means the Vendor-Id sub-AVP is no > longer informational. It does mean that a vendor applying for a > vendor-specific application will have to obtain a Private Enterprise Code > too but they'd need to do that anyway in order to define any vendor-specific > AVPs for their application. > > Regards > Mark > > > > ------------------------------ > *From:* Harish R Prabhu [mailto:harish.r.prabhu@gmail.com] > *Sent:* August 22, 2007 18:00 > *To:* dime@ietf.org > *Subject:* Re: [Dime] 3588bis: Vendor Ids in CER/CEA > > Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in > Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id > is flat and there are no validation procedures for Vendor-Id sub-AVP (as it > is informational). Then why is it mandatory in the bis- draft? > > thanks, > Harish > > On 8/22/07, Victor Fajardo wrote: > > > > Hi Mark, > > > > > --- > > > > > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > > > > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > > > contains the IANA "SMI Network Management Private Enterprise > > > Codes" [RFC3232] value assigned to the vendor of the Diameter > > > device. It is envisioned that the combination of the Vendor-Id, > > > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > > > 5.3.4) AVPs MAY provide very useful debugging information. > > > > > > > Ok. > > > > > --- > > > > > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > > > > > If a peer advertises support of a vendor-specific application > > > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > > > implied that the peer supports (a subset of) the vendor- > > > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > > > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI > > > Network Management Private Enterprise Codes" [RFC3232] value of > > > the application vendor." > > > > > > > I'm fine with this. > > > > > --- > > > > > > 3) Update 3rd paragraph in section 6.11(Vendor-Specific-Application-Id > > > AVP) > > > > > > > > > The Vendor-Id AVP in this context contains the IANA "SMI > > > Network Management Private Enterprise Codes" [RFC3232] value > > > assigned to the vendor of the Diameter application advertised > > > in the Auth-Application-Id or Acct-Application-Id AVP. It > > > indicates that the peer supports (a subset of) the vendor- > > > specific AVPs of the application vendor. It MUST NOT be used > > > as a means of defining a completely separate vendor-specific > > > application identifier space. > > > > > > > 1. We can remove "(a subset of)". Advertising support for an application > > does not provide hints on "subsets" of avps. > > 2. s/peer/node/ > > > > regards, > > victor > > > > > --- > > > > > > 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 > > > > > > -- > Harish R Prabhu > Bangalore, India. > > -- Harish R Prabhu Bangalore, India. ------=_Part_24023_15943511.1187800625126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This was the scenario I was trying to point out:

1. Application-IDs are allocated by IANA, and have to be obtained by a vendor with a Private Enterprise Code.

2. 1 implies that its possible to implicitly derive the Vendor info from the Application Id itself.

Consider a situation wherein a diameter implementation sends a Vendor-Specific-Application-Id with an erroneous combination of (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose to validate the Vendor-Id and some may choose not to.

Wouldnt this be an interoperability issue? If so, why have Vendor-Id in Vendor-Specific-Application-Id to create scope for this?

thanks,
Harish

On 8/22/07, Mark Jones <mark.jones@bridgewatersystems.com> wrote:
Hi Harish,
 
The proposed update to section 6.11 means the Vendor-Id sub-AVP is no longer informational. It does mean that a vendor applying for a vendor-specific application will have to obtain a Private Enterprise Code too but they'd need to do that anyway in order to define any vendor-specific AVPs for their application.
 
Regards
Mark
 
 

From: Harish R Prabhu [mailto:harish.r.prabhu@gmail.com]
Sent: August 22, 2007 18:00
To: dime@ietf.org
Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA

Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft?

thanks,
Harish

On 8/22/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi Mark,

> ---
>
> 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP)
>
>  The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and
>  contains the IANA "SMI Network Management Private Enterprise
>  Codes" [RFC3232] value assigned to the vendor of the Diameter
>  device. It is envisioned that the combination of the Vendor-Id,
>  Product-Name (Section 5.3.7) and the Firmware-Revision (Section
>  5.3.4) AVPs MAY provide very useful debugging information.
>

Ok.

> ---
>
> 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP)
>
>  If a peer advertises support of a vendor-specific application
>  in the Vendor-Specific-Application-Id AVP (Section 6.11), it is
>  implied that the peer supports (a subset of) the vendor-
>  specific AVPs of that vendor. In this case, the CER/CEA SHOULD
>  NOT contain a Supported-Vendor-Id AVP with the IANA "SMI
>  Network Management Private Enterprise Codes" [RFC3232] value of
>  the application vendor."
>

I'm fine with this.

> ---
>
> 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id
> AVP)
>
>
>  The Vendor-Id AVP in this context contains the IANA "SMI
>  Network Management Private Enterprise Codes" [RFC3232] value
>  assigned to the vendor of the Diameter application advertised
>  in the Auth-Application-Id or Acct-Application-Id AVP. It
>  indicates that the peer supports (a subset of) the vendor-
>  specific AVPs of the application vendor. It MUST NOT be used
>  as a means of defining a completely separate vendor-specific
>  application identifier space.
>

1. We can remove "(a subset of)". Advertising support for an application
does not provide hints on "subsets" of avps.
2. s/peer/node/

regards,
victor

> ---
>
> 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



--
Harish R Prabhu
Bangalore, India.



--
Harish R Prabhu
Bangalore, India. ------=_Part_24023_15943511.1187800625126-- --===============1236935436== 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 --===============1236935436==-- From dime-bounces@ietf.org Wed Aug 22 13:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtfX-0000xv-ST; Wed, 22 Aug 2007 13:06:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtfX-0000xq-9J for dime@ietf.org; Wed, 22 Aug 2007 13:06:59 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INtfV-00067j-VJ for dime@ietf.org; Wed, 22 Aug 2007 13:06:59 -0400 MIME-Version: 1.0 Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 13:09:16 -0400 Message-ID: In-Reply-To: References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> From: "Mark Jones" To: "Harish R Prabhu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82b297dca242a35ee50ccecf5bf2e37f 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="===============0482721438==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0482721438== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E4DF.2D009145" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E4DF.2D009145 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to make sure I've understood the validation part: Do you mean that an implementation would have a map from application Id to vendor Id and validate all incoming Vendor-Specific-Application-Id AVPs against this map? =20 So your proposal would be to make this map 'mandatory to implement' and remove the Vendor-Id sub-AVP altogether? =20 Regards Mark ________________________________ From: Harish R Prabhu [mailto:harish.r.prabhu@gmail.com]=20 Sent: August 22, 2007 18:37 To: Mark Jones Cc: dime@ietf.org Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA =09 =09 This was the scenario I was trying to point out: =09 1. Application-IDs are allocated by IANA, and have to be obtained by a vendor with a Private Enterprise Code.=20 =09 2. 1 implies that its possible to implicitly derive the Vendor info from the Application Id itself.=20 =09 Consider a situation wherein a diameter implementation sends a Vendor-Specific-Application-Id with an erroneous combination of (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose to validate the Vendor-Id and some may choose not to.=20 =09 Wouldnt this be an interoperability issue? If so, why have Vendor-Id in Vendor-Specific-Application-Id to create scope for this? =09 thanks, Harish =09 =09 On 8/22/07, Mark Jones wrote:=20 Hi Harish, =20 The proposed update to section 6.11 means the Vendor-Id sub-AVP is no longer informational. It does mean that a vendor applying for a vendor-specific application will have to obtain a Private Enterprise Code too but they'd need to do that anyway in order to define any vendor-specific AVPs for their application. =20 Regards Mark =20 =20 =09 =09 ________________________________ From: Harish R Prabhu [mailto:harish.r.prabhu@gmail.com]=20 Sent: August 22, 2007 18:00 To: dime@ietf.org Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA =09 =09 =09 Does anyone perceive any impact of this discussion on Vendor-Id sub AVP in Vendor-Specific-Application-Id AVP? As my understanding goes, Application-Id is flat and there are no validation procedures for Vendor-Id sub-AVP (as it is informational). Then why is it mandatory in the bis- draft?=20 =09 thanks, Harish =09 =09 On 8/22/07, Victor Fajardo wrote:=20 Hi Mark, =09 > --- > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise=20 > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section=20 > 5.3.4) AVPs MAY provide very useful debugging information. > =09 Ok. =09 > --- > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > If a peer advertises support of a vendor-specific application=20 > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > implied that the peer supports (a subset of) the vendor- > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI=20 > Network Management Private Enterprise Codes" [RFC3232] value of > the application vendor." > =09 I'm fine with this. =09 > --- > > 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) > > > The Vendor-Id AVP in this context contains the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value > assigned to the vendor of the Diameter application advertised=20 > in the Auth-Application-Id or Acct-Application-Id AVP. It > indicates that the peer supports (a subset of) the vendor- > specific AVPs of the application vendor. It MUST NOT be used > as a means of defining a completely separate vendor-specific=20 > application identifier space. > =09 1. We can remove "(a subset of)". Advertising support for an application does not provide hints on "subsets" of avps. 2. s/peer/node/ =09 regards, victor =09 > --- > > Regards > Mark > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > =09 =09 =09 _______________________________________________ DiME mailing list DiME@ietf.org =09 https://www1.ietf.org/mailman/listinfo/dime =09 --=20 Harish R Prabhu=20 Bangalore, India.=20 --=20 Harish R Prabhu Bangalore, India.=20 ------_=_NextPart_001_01C7E4DF.2D009145 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just to make sure I've understood the = validation part:=20 Do you mean that an implementation would have a map from = application=20 Id to vendor Id and validate all incoming Vendor-Specific-Application-Id = AVPs=20 against this map?
 
So your proposal would be to make this map = 'mandatory=20 to implement' and remove the Vendor-Id sub-AVP = altogether?
 
Regards
Mark

From: Harish R Prabhu=20 [mailto:harish.r.prabhu@gmail.com]
Sent: August 22, 2007=20 18:37
To: Mark Jones
Cc: = dime@ietf.org
Subject:=20 Re: [Dime] 3588bis: Vendor Ids in CER/CEA

This was the scenario I was trying to point out:

1.=20 Application-IDs are allocated by IANA, and have to be obtained by a = vendor=20 with a Private Enterprise Code.

2. 1 implies that its possible = to=20 implicitly derive the Vendor info from the Application Id itself.=20

Consider a situation wherein a diameter implementation sends a = Vendor-Specific-Application-Id with an erroneous combination of = (Vendor-Id,=20 Auth/Acct-Application-Id). Some implementations may choose to validate = the=20 Vendor-Id and some may choose not to.

Wouldnt this be an=20 interoperability issue? If so, why have Vendor-Id in=20 Vendor-Specific-Application-Id to create scope for=20 this?

thanks,
Harish

On 8/22/07, Mark=20 Jones <mark.jones@bridgewaters= ystems.com>=20 wrote:
Hi=20 Harish,
 
The=20 proposed update to section 6.11 means the Vendor-Id sub-AVP is no = longer=20 informational. It does mean that a vendor applying for a=20 vendor-specific application will have to obtain a Private Enterprise = Code=20 too but they'd need to do that anyway in order to define any = vendor-specific=20 AVPs for their application.
 
Regards
Mark
 
 

From: Harish R = Prabhu=20 [mailto:harish.r.prabhu@gmail.com] =
Sent:=20 August 22, 2007 18:00
To: dime@ietf.org
Subject: Re: [Dime] = 3588bis:=20 Vendor Ids in CER/CEA

Does anyone perceive any impact of this discussion on = Vendor-Id=20 sub AVP in Vendor-Specific-Application-Id AVP? As my understanding = goes,=20 Application-Id is flat and there are no validation procedures for=20 Vendor-Id sub-AVP (as it is informational). Then why is it = mandatory in=20 the bis- draft?

thanks,
Harish

On 8/22/07, Victor=20 Fajardo <vfajardo@tari.toshiba.com> wrote:=20
Hi=20 Mark,

> ---
>
> 1) Update 1st paragraph in = section=20 5.5.3 (Vendor-Id AVP)
>
>  The Vendor-Id = AVP (AVP=20 Code 266) is of type Unsigned32 and
>  contains = the IANA=20 "SMI Network Management Private Enterprise =
>  Codes"=20 [RFC3232] value assigned to the vendor of the=20 Diameter
>  device. It is envisioned that the=20 combination of the Vendor-Id,
>  Product-Name = (Section=20 5.3.7) and the Firmware-Revision (Section =
>  5.3.4)=20 AVPs MAY provide very useful debugging=20 information.
>

Ok.

> ---
>
> = 2) Add=20 new paragraph to section 5.3.6 (Supported-Vendor-Id=20 AVP)
>
>  If a peer advertises support of = a=20 vendor-specific application
>  in the=20 Vendor-Specific-Application-Id AVP (Section 6.11), it=20 is
>  implied that the peer supports (a subset = of) the=20 vendor-
>  specific AVPs of that vendor. In this = case,=20 the CER/CEA SHOULD
>  NOT contain a = Supported-Vendor-Id=20 AVP with the IANA "SMI
>  Network Management = Private=20 Enterprise Codes" [RFC3232] value of
>  the = application=20 vendor."
>

I'm fine with this.

>=20 ---
>
> 3) Update 3rd paragraph in section 6.11=20 (Vendor-Specific-Application-Id
>=20 AVP)
>
>
>  The Vendor-Id AVP in = this=20 context contains the IANA "SMI
>  Network = Management=20 Private Enterprise Codes" [RFC3232] = value
>  assigned to=20 the vendor of the Diameter application advertised =
>  in=20 the Auth-Application-Id or Acct-Application-Id AVP.=20 It
>  indicates that the peer supports (a subset = of) the=20 vendor-
>  specific AVPs of the application = vendor. It=20 MUST NOT be used
>  as a means of defining a = completely=20 separate vendor-specific
>  application = identifier=20 space.
>

1. We can remove "(a subset of)". = Advertising=20 support for an application
does not provide hints on = "subsets" of=20 avps.
2. s/peer/node/

regards,
victor

>=20 ---
>
> Regards
> Mark
>
>=20 _______________________________________________
> DiME = mailing=20 list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>>
>
>


_______________________________________= ________
DiME=20 mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime


--
Harish R Prabhu
Bangalore, India.=20



--=20
Harish R Prabhu
Bangalore, India. ------_=_NextPart_001_01C7E4DF.2D009145-- --===============0482721438== 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 --===============0482721438==-- From dime-bounces@ietf.org Wed Aug 22 13:31: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 1INu3P-0000G8-Cp; Wed, 22 Aug 2007 13:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INu3N-0000G2-VO for dime@ietf.org; Wed, 22 Aug 2007 13:31:37 -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 1INu3N-00005u-MI for dime@ietf.org; Wed, 22 Aug 2007 13:31:37 -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 l7MHV4fi040398; Wed, 22 Aug 2007 13:31:04 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CC72D8.7010504@tari.toshiba.com> Date: Wed, 22 Aug 2007 13:31:04 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Harish R Prabhu Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Harish, > > Consider a situation wherein a diameter implementation sends a > Vendor-Specific-Application-Id with an erroneous combination of > (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose > to validate the Vendor-Id and some may choose not to. > > Wouldnt this be an interoperability issue? If so, why have Vendor-Id > in Vendor-Specific-Application-Id to create scope for this? First, I think the bis does not mandate that such validation should take place. If that needs to be made clear by saying that vendor-id is informational value that contains the vendor info authoring the app and that the value is relevant for debugging purpose only then that will be good enough. Second, if ever somebody decides to validate these values and generate an "erroneous combination" type of error (not sure how efficient that would be since now you have to map all these values together ...) , it becomes an implementation issue and not an interoperability problem. I know other folks are putting too much meaning into these types of AVPs so making the usage context clear will help avoid limit this problem. Revising the importance of vendor-id to accommodate the (not so good) decisions other folks have made would worsen the problem. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 13:33: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 1INu5b-0002Cw-Ut; Wed, 22 Aug 2007 13:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INu5a-0002Cq-Ns for dime@ietf.org; Wed, 22 Aug 2007 13:33:54 -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 1INu5a-00008X-GH for dime@ietf.org; Wed, 22 Aug 2007 13:33:54 -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 l7MHXP1Q040407; Wed, 22 Aug 2007 13:33:25 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CC7365.10006@tari.toshiba.com> Date: Wed, 22 Aug 2007 13:33:25 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> 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: cf4fa59384e76e63313391b70cd0dd25 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, > Just to make sure I've understood the validation part: Do you mean > that an implementation would have a map from application Id to vendor > Id and validate all incoming Vendor-Specific-Application-Id AVPs > against this map? > > So your proposal would be to make this map 'mandatory to implement' > and remove the Vendor-Id sub-AVP altogether? I suggest not doing this. From the base protocol perspective, the vendor-id should not give more meaning that it deserves. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 13:51: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 1INuMi-0006lq-Bv; Wed, 22 Aug 2007 13:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INuMh-0006ll-HF for dime@ietf.org; Wed, 22 Aug 2007 13:51:35 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INuMg-0000Wp-U7 for dime@ietf.org; Wed, 22 Aug 2007 13:51:35 -0400 Received: by ik-out-1112.google.com with SMTP id b32so93443ika for ; Wed, 22 Aug 2007 10:51:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=lw+H6O2abwhzGoHZeTe9BuPY6ZBfEqjyTL9s4G5uueYeW8hxjmsTApHz1DJmUscRMGAFxwbHP//uGvqP4h4WNM/nW6ePVLDKasUjyejOPjbhJyTo010ynjtTd2kskPcqzBkII1TTvty71Ps0MTvhTWYyBNls8lPjwybwXiG8Y6c= 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=EsHgNp26/ByNsiI84LG5oeucKM7mpgpTZq0gNxT3tJoC9ysPUgR/FPdne0K+evACTWK8XYZU6Os8tcF9EhVD7uzfdApMG40gb1v301IehU9WKY5r1urS94IYcFwut9TxgNA4EIIYjL3r0D3N4C19pfs0xvVAgSfdxX4FU2Ti40c= Received: by 10.64.114.10 with SMTP id m10mr5019790qbc.1187805092443; Wed, 22 Aug 2007 10:51:32 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Wed, 22 Aug 2007 10:51:32 -0700 (PDT) Message-ID: Date: Wed, 22 Aug 2007 23:21:32 +0530 From: "Harish R Prabhu" To: "Victor Fajardo" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA In-Reply-To: <46CC72D8.7010504@tari.toshiba.com> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <46CC3DA5.9030700@tari.toshiba.com> <46CC72D8.7010504@tari.toshiba.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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="===============1858066297==" Errors-To: dime-bounces@ietf.org --===============1858066297== Content-Type: multipart/alternative; boundary="----=_Part_25293_10290978.1187805092368" ------=_Part_25293_10290978.1187805092368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Victor, I think a clarification text would be good enough so that an implementation would not validate Vendor-Id while updating its knowledge about peer-advertised applications. thanks, Harish On 8/22/07, Victor Fajardo wrote: > > Hi Harish, > > > > > Consider a situation wherein a diameter implementation sends a > > Vendor-Specific-Application-Id with an erroneous combination of > > (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose > > to validate the Vendor-Id and some may choose not to. > > > > Wouldnt this be an interoperability issue? If so, why have Vendor-Id > > in Vendor-Specific-Application-Id to create scope for this? > > First, I think the bis does not mandate that such validation should take > place. If that needs to be made clear by saying that vendor-id is > informational value that contains the vendor info authoring the app and > that the value is relevant for debugging purpose only then that will be > good enough. Second, if ever somebody decides to validate these values > and generate an "erroneous combination" type of error (not sure how > efficient that would be since now you have to map all these values > together ...) , it becomes an implementation issue and not an > interoperability problem. I know other folks are putting too much > meaning into these types of AVPs so making the usage context clear will > help avoid limit this problem. Revising the importance of vendor-id to > accommodate the (not so good) decisions other folks have made would > worsen the problem. > > regards, > victor > > -- Harish R Prabhu Bangalore, India. ------=_Part_25293_10290978.1187805092368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Victor,

I think a clarification text would be good enough so that an implementation would not validate Vendor-Id while updating its knowledge about peer-advertised applications.

thanks,
Harish

On 8/22/07, Victor Fajardo <vfajardo@tari.toshiba.com> wrote:
Hi Harish,

>
> Consider a situation wherein a diameter implementation sends a
> Vendor-Specific-Application-Id with an erroneous combination of
> (Vendor-Id, Auth/Acct-Application-Id). Some implementations may choose
> to validate the Vendor-Id and some may choose not to.
>
> Wouldnt this be an interoperability issue? If so, why have Vendor-Id
> in Vendor-Specific-Application-Id to create scope for this?

First, I think the bis does not mandate that such validation should take
place. If that needs to be made clear by saying that vendor-id is
informational value that contains the vendor info authoring the app and
that the value is relevant for debugging purpose only then that will be
good enough. Second, if ever somebody decides to validate these values
and generate an "erroneous combination" type of error (not sure how
efficient that would be since now you have to map all these values
together ...) , it becomes an implementation issue and not an
interoperability problem. I know other folks are putting too much
meaning into these types of AVPs so making the usage context clear will
help avoid limit this problem. Revising the importance of vendor-id to
accommodate the (not so good) decisions other folks have made would
worsen the problem.

regards,
victor




--
Harish R Prabhu
Bangalore, India. ------=_Part_25293_10290978.1187805092368-- --===============1858066297== 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 --===============1858066297==-- From dime-bounces@ietf.org Wed Aug 22 16:18: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 1INwf5-0006PU-I0; Wed, 22 Aug 2007 16:18:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INwf4-0006PO-G7 for dime@ietf.org; Wed, 22 Aug 2007 16:18:42 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INwf4-0001D6-0J for dime@ietf.org; Wed, 22 Aug 2007 16:18:42 -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 l7MKIfA0015943 for ; Wed, 22 Aug 2007 16:18:41 -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] 3588bis: Vendor Ids in CER/CEA Date: Wed, 22 Aug 2007 16:18:41 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfkvV7Lgdbv+YLfRFCJlZ1hGGA9cgAN4pJw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 While we are at this, I propose to add the following as well: (Text to replace in 5.3.6 Supported-Vendor-Id AVP) "This is used in the CER and CEA messages in order to inform the peer that the sender supports (a subset of) the vendor-specific AVPs defined by the vendor identified in this AVP." (Proposed Text) "This AVP can be used in CER, CEA or in any application command, which has it defined in the corresponding message grammar. It informs the peer that the sender supports (a subset of) the vendor-specific AVPs defined by the vendor identified in this AVP. It should be noted that CER/CEA messages are exchanged in a hop-by-hop fashion. If there are intermediary nodes, e.g. a relay agent, between a client and server, Supported-Vendor-Id AVP won't be exchanged between the client and the server." Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Wednesday, August 22, 2007 9:10 AM > To: Asveren, Tolga; dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi Tolga, >=20 > Thank you for supporting the proposal to fix this Vendor-Id ambiguity in > 3588bis. >=20 > After reviewing rfc3588bis-05 for impacts, here are the proposed > changes: >=20 > --- >=20 > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) >=20 > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > 5.3.4) AVPs MAY provide very useful debugging information. >=20 > --- >=20 > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) >=20 > If a peer advertises support of a vendor-specific application > in the Vendor-Specific-Application-Id AVP (Section 6.11), it is > implied that the peer supports (a subset of) the vendor- > specific AVPs of that vendor. In this case, the CER/CEA SHOULD > NOT contain a Supported-Vendor-Id AVP with the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value of > the application vendor." >=20 > --- >=20 > 3) Update 3rd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) >=20 >=20 > The Vendor-Id AVP in this context contains the IANA "SMI > Network Management Private Enterprise Codes" [RFC3232] value > assigned to the vendor of the Diameter application advertised > in the Auth-Application-Id or Acct-Application-Id AVP. It > indicates that the peer supports (a subset of) the vendor- > specific AVPs of the application vendor. It MUST NOT be used > as a means of defining a completely separate vendor-specific > application identifier space. >=20 > --- >=20 > Regards > Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 17:10: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 1INxTB-0006yv-St; Wed, 22 Aug 2007 17:10:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INxTA-0006yp-Ev for dime@ietf.org; Wed, 22 Aug 2007 17:10:28 -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 1INxTA-0001sn-1J for dime@ietf.org; Wed, 22 Aug 2007 17:10:28 -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 l7MLAReb041367; Wed, 22 Aug 2007 17:10:27 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CCA643.8090703@tari.toshiba.com> Date: Wed, 22 Aug 2007 17:10:27 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188190@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: 97adf591118a232206bdb5a27b217034 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 Tolga, > While we are at this, I propose to add the following as well: > > (Text to replace in 5.3.6 Supported-Vendor-Id AVP) > "This is used in the CER and CEA messages in order to inform the peer > that the sender supports (a subset of) the vendor-specific AVPs > defined by the vendor identified in this AVP." > > (Proposed Text) > "This AVP can be used in CER, CEA or in any application command, which > has it defined in the corresponding message grammar. It informs the peer > that the sender supports (a subset of) the vendor-specific AVPs defined > by the vendor identified in this AVP. > > It should be noted that CER/CEA messages are exchanged in a hop-by-hop > fashion. If there are intermediary nodes, e.g. a relay agent, between a > client and server, Supported-Vendor-Id AVP won't be exchanged between > the client and the server." > I'm ok with the text. Some editorial notes, maybe to simplify: "It should be noted that since CER/CEA messages are exchanged only between peers and does not extend beyond the single hop, Supported-Vendor-Id AVPs carried in these messages are relevant only between Diameter peers." Did I get your ideas correctly ? regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 22 18:16: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 1INyUe-0001Tw-KN; Wed, 22 Aug 2007 18:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyUd-0001Td-2m; Wed, 22 Aug 2007 18:16:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INyUc-0004aZ-N9; Wed, 22 Aug 2007 18:16:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 84B0B32935; Wed, 22 Aug 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INyTe-0007Pv-ER; Wed, 22 Aug 2007 18:15: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: Wed, 22 Aug 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-06.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-06.txt Pages : 158 Date : 2007-8-22 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-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dime-rfc3588bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-22171737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-22171737.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 Aug 23 00:49: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 1IO4dn-0006Dq-It; Thu, 23 Aug 2007 00:49:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO4dl-0006DW-KV for dime@ietf.org; Thu, 23 Aug 2007 00:49:53 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO4dj-0003Nq-D0 for dime@ietf.org; Thu, 23 Aug 2007 00:49:53 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN700332MPYYF@szxga03-in.huawei.com> for dime@ietf.org; Thu, 23 Aug 2007 12:49:10 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN70031JMPWY4@szxga03-in.huawei.com> for dime@ietf.org; Thu, 23 Aug 2007 12:49:10 +0800 (CST) Received: from z24109a ([10.70.76.134]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN700BYUMPWQR@szxml04-in.huawei.com> for dime@ietf.org; Thu, 23 Aug 2007 12:49:08 +0800 (CST) Date: Thu, 23 Aug 2007 12:49:07 +0800 From: Tina TSOU Subject: Re: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] To: dime@ietf.org, Hannes.Tschofenig@gmx.net, jouni.korhonen@teliasonera.com Message-id: <006901c7e540$f0c41b40$864c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <46C8A642.2040102@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED301F2773F@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec 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 all, Here are my preliminary comments on this draft as promised. 1. ".. activated to make sure a given requesting customer is (1) what he claims to be (identification purposes)," in section 2.1 is authentication, not authorization 2. It is not clear why RACS is not needed when NSP and CP are the same single entity 3. Can mAAA push unsolicited access control information to NAS? 4. "Refer to section 3.3" in section 7. There is no section 3.3 B. R. Tina +86-755-28972912 (Office) +86-13922884380 (Mobile) Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com ----- Original Message ----- From: To: ; Sent: Wednesday, August 22, 2007 10:58 PM Subject: RE: [Dime] [Fwd: Request for review of "AAA Framework for Multicasting"] Hi All, Here are my initial comments on this draft. ---- Firstly idnits gives rather many errors and warning. The authors should check the draft against the idnits. Some editorial comments: Section 1.1 o "...communication schemes of any kind, such as 1-to-n (case of TV broadcasting services for example) or n-to-p (case of..." rather use one-to-many and many-to-many o "...high-quality multicast transport using a Resource and Admission Control System (RACS) with multicast..." I assume this refers to TiSPAN defined RACS functional entity. I would like to see a reference here. o "...presented in draft-ietf-mboned-maccnt-req-04.txt,..." Rather use the reference to [1] o "...MACCNT-REQ-draft describes the requirements in CDN services using IP multicast[1]. The requirements are derived from:..." o "...Detailed requirements are presented in MACCNT-REQ-draft...." Again the reference.. Section 2.1 o " Note: The definition of a receiver (device) and a user (human) should not be confused. " This note does not really fit into definitions as it is. Now it looks like yet another definition, which is not the intent I assume. Section 2.2 o AAA, mAAA, NSP-AAA, CP-AAA, ID, API, IF, NAS, QoS and RACS are missing Section 3 o "...are divided between separate entities. The MACCNT-REQ- draft provides more detail of the multiple versus single..." Reference. o "...entity CDS network models. " Expand CDS on the first use o "As such it should not be assumed that the entity responsible for the multicasting structure and the entity responsible for content serving are the same. Indeed because the infrastructure for multicasting is expensive and many content holders are not likely to be competent at building and maintaining complicated infrastructures necessary for multicasting, many content holders would prefer to purchase transport and management services from a network service provider and thus share the infrastructure costs with other content holders." Consider revising.. to something like.. whatever.. "It should not be assumed that the entity responsible for the multicasting infrastructure is not the same as the entity responsible for serving the content. Content holders are not likely to build and maintain their own multicast network infrastructure that is not part of their expertise area. Rather they are willing to purchase transport and management services from dedicated network service providers." o "...The use model of a single NSP providing multicasting services to multiple CPs the following general requirements from MACCNT-REQ-draft apply:..." References.. Expand CP on the first usage. Reword to something like "In the usage model of where a single NSP provides multicast services to multiple Content Providers (CP), the following general requirements from [1] apply:.." o "When the NSP and CP are the same single entity the general requirements are as follows." revise to "When the NSP and the CP are the same entity then the general requirements are as follows:" Section 4.1 o "A general high-level framework can be represented as follows." revise to.. something like "A general high-level framework is presented in the Figure 1." o For relationships use similar style as in previous sections. e.g. 1:1 -> one-to-one or 1-to-1 etc.. o Expand STB on the first use. o What is STB? It is mentioned only once in this document in this section.. o "The CP is responsible for Authentication and Authorization.." use "authentication and authorization" o "...(authentication by proxy), and the NSP's relevant AAA.." Authentication via or through? o NSP-AAA and CP-AAA? o "...without querying the CP-AAA. When the NSP cannot or decides not to multicast to users, the NSP may notify the..." I don't get what this is supposed to mean. Section 4.2 o Heading -> "Multiple User Identities" o Expand ID on the first use. Section 4.2 o References to [1].. and a consistent way of doing those would be nice. o Reference to RFC3810 & RFC3376 o Expand API on the first use Section 4.5 o References Section 4.7 o "reestablish" to "re-establish"? Section 5 o "Section 3.1 introduces the high-level AAA framework for..." introduced o "...access to the User. First a user that requests content..." revise to.. something like "...access to a user. First the user.." o "...to the appropriate CP for Authentication and Authorization..." authorization and authorization o Notation of relations.. 1:1 etc to similar as previously used Section 5.2 o References.. o Should these "well managed", "fully enabled AAA" etc be defined in section 2.1 o "Section 3.1 intriduces" -> introduced o "of a AAA" -> "of an AAA" o In the figure 2 the caption is partial.. or parts of it is before the figure.. should be fixed o Use consistent way of expanding abbreviations.. both types e.g. Content Provider (CP) and CP (Content Provider) are used o Figure 3 has similar caption issues as figure 2 I got a bit stuck to general presentation of the draft. It needs more work. For general readability of the draft I would suggest paying attention to overall formatting. This may sound naive but IMHO I would suggest using some tool that generates automatically a proper layout, such as xml2rfc. And then some remotely technical comments, if any. o It is rather unclear to me how the actual AAA transactions are supposed to work (refer to fig. 1). CP auth/authz the user and the CP also auth/authz the NSP? Are these separate? What about user to NSP auth/authz? (this is then later described better in section 5.1 but not where the fig.1 is described) o "The actual mapping rules for NSPs and CPs to map user IDs with the IDs in other provider domains is a matter for the providers. A solution should provide an API between the providers to flexibly support various mapping methods." The inter-working could be explained a bit more carefully. An example would be nice. Otherwise this is rather unambiguous. o Standardization of logs? Do you mean coming up with a file presentation format for user session tracking? Or rather just defining that billing record format? Could any of the existing ones be re-used or expanded? o "...This framework specifies an accounting API provided by the NSP and accessed by the CP to allow for sharing user-..." I don't really find the API specification in this framework draft o Does API here actually mean AAA interface or something else? The use of API-term is somewhat confusing.. o "content request" is AAA request? o It would be nice to have a separate sections (or something) going through each AAA interface (IFa, IFb, etc) Cheers, Jouni > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, August 19, 2007 11:21 PM > To: dime@ietf.org > Subject: [Dime] [Fwd: Request for review of "AAA Framework > for Multicasting"] > > > During the IETF#69 meeting I have also asked for reviewers. > Two persons offered help: > * Jouni Korhonen > * Tina Tsou > > Their review is still pending! > > -------- Original Message -------- > Subject: Request for review of "AAA Framework for Multicasting" > Date: Sat, 18 Aug 2007 14:49:00 -0700 > From: Bernard Aboba > To: radiusext@ops.ietf.org > > > > A request for review has been received relating to the > document "AAA Framework for Multicasting" which is under > development within the MBONED WG. > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa > -framework-04.txt > > The Request for Review will last until September 5, 2007. > Please post your comments on this document to the RADEXT WG > mailing list, CC:'ing the document authors. > > Information on the review request was previously posted to > the RADEXT WG mailing list: > http://ops.ietf.org/lists/radiusext/2007/msg00528.html > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > _______________________________________________ > 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 Thu Aug 23 04:48: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 1IO8MX-0005P6-Ms; Thu, 23 Aug 2007 04:48:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO8MW-0005Ok-E2 for dime@ietf.org; Thu, 23 Aug 2007 04:48:20 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IO8MV-00005t-QI for dime@ietf.org; Thu, 23 Aug 2007 04:48:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 04:50:39 -0400 Message-ID: In-Reply-To: <46CCA643.8090703@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> From: "Mark Jones" To: "Asveren, Tolga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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,=20 I understand the goal of end-to-end advertisement but it is not clear to me how the Supported-Vendor-Id AVP would be interpreted in commands other than CER/CEA.=20 Would it be included to indicate to the peer that only the current command contains AVP from the advertised vendor?=20 Or is it intended to indicate to the peer that current and future commands MAY contain AVPs from the advertised vendor? Does it imply that the commands contain mandatory AVPs from the advertised vendor? If so, how should a peer behave if it receives a command advertising a vendor that it doesn't support?=20 Could a relay node add/delete this AVP? Under what conditions? Lots of other questions come to mind and I suspect that some of the answers depend on the specific command or application. So I'd prefer to leave it to the authors of the application which reuses this AVP to define how the Supported-Vendor-Id AVP is used in their commands rather than attempt to define a common set of required behavior in 3588bis. Since reuse of all AVPs is encouraged, it is not necessary to mention here that this particular AVP can be reused. Regards Mark > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Sent: August 22, 2007 23:10 > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi Tolga, >=20 > > While we are at this, I propose to add the following as well: > > > > (Text to replace in 5.3.6 Supported-Vendor-Id AVP) > > "This is used in the CER and CEA messages in order to=20 > inform the peer > > that the sender supports (a subset of) the vendor-specific AVPs > > defined by the vendor identified in this AVP." > > > > (Proposed Text) > > "This AVP can be used in CER, CEA or in any application=20 > command, which > > has it defined in the corresponding message grammar. It=20 > informs the peer > > that the sender supports (a subset of) the vendor-specific=20 > AVPs defined > > by the vendor identified in this AVP. > > > > It should be noted that CER/CEA messages are exchanged in a=20 > hop-by-hop > > fashion. If there are intermediary nodes, e.g. a relay=20 > agent, between a > > client and server, Supported-Vendor-Id AVP won't be=20 > exchanged between > > the client and the server." > > =20 >=20 > I'm ok with the text. Some editorial notes, maybe to simplify: >=20 > "It should be noted that since CER/CEA messages are exchanged only=20 > between peers and > does not extend beyond the single hop, Supported-Vendor-Id=20 > AVPs carried=20 > in these messages > are relevant only between Diameter peers." >=20 > Did I get your ideas correctly ? >=20 > regards, > victor >=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 Thu Aug 23 07:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBAN-0006PU-Jk; Thu, 23 Aug 2007 07:47:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBAM-0006PM-5H for dime@ietf.org; Thu, 23 Aug 2007 07:47:58 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBAL-0004IV-P6 for dime@ietf.org; Thu, 23 Aug 2007 07:47:58 -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 l7NBlvdS008396; Thu, 23 Aug 2007 07:47:57 -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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 07:47:56 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188191@sonusmail04.sonusnet.com> In-Reply-To: <46CCA643.8090703@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcflAN4nooVUg0V3RmW4aQLyO34SpgAeolLw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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, > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Wednesday, August 22, 2007 5:10 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi Tolga, >=20 > > While we are at this, I propose to add the following as well: > > > > (Text to replace in 5.3.6 Supported-Vendor-Id AVP) > > "This is used in the CER and CEA messages in order to inform the peer > > that the sender supports (a subset of) the vendor-specific AVPs > > defined by the vendor identified in this AVP." > > > > (Proposed Text) > > "This AVP can be used in CER, CEA or in any application command, which > > has it defined in the corresponding message grammar. It informs the peer > > that the sender supports (a subset of) the vendor-specific AVPs defined > > by the vendor identified in this AVP. > > > > It should be noted that CER/CEA messages are exchanged in a hop-by-hop > > fashion. If there are intermediary nodes, e.g. a relay agent, between a > > client and server, Supported-Vendor-Id AVP won't be exchanged between > > the client and the server." > > >=20 > I'm ok with the text. Some editorial notes, maybe to simplify: >=20 > "It should be noted that since CER/CEA messages are exchanged only > between peers and > does not extend beyond the single hop, Supported-Vendor-Id AVPs carried > in these messages > are relevant only between Diameter peers." >=20 > Did I get your ideas correctly ? [TOLGA]Perfectly ! ! ! _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 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 1IOBD3-0002TX-7z; Thu, 23 Aug 2007 07:50:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBD2-0002TS-CE for dime@ietf.org; Thu, 23 Aug 2007 07:50:44 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBD1-0004Mj-Qw for dime@ietf.org; Thu, 23 Aug 2007 07:50:44 -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 l7NBoegZ010718; Thu, 23 Aug 2007 07:50:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 07:50:40 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcflYlxhG8TLdNzlTY2FUEgGC7YnYwAGTVpw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> From: "Asveren, Tolga" To: "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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, Yes, I agree with your concerns. It would be difficult to define proper semantics for generic use and probably bis is not the right place to do so. Victor's version of the text mentions only about the hop-by-hop nature of capability exchange and warns people about it; it leaves the end-to-end part to applications. Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 4:51 AM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Tolga, >=20 > I understand the goal of end-to-end advertisement but it is not clear to > me how the Supported-Vendor-Id AVP would be interpreted in commands > other than CER/CEA. >=20 > Would it be included to indicate to the peer that only the current > command contains AVP from the advertised vendor? >=20 > Or is it intended to indicate to the peer that current and future > commands MAY contain AVPs from the advertised vendor? >=20 > Does it imply that the commands contain mandatory AVPs from the > advertised vendor? If so, how should a peer behave if it receives a > command advertising a vendor that it doesn't support? >=20 > Could a relay node add/delete this AVP? Under what conditions? >=20 > Lots of other questions come to mind and I suspect that some of the > answers depend on the specific command or application. So I'd prefer to > leave it to the authors of the application which reuses this AVP to > define how the Supported-Vendor-Id AVP is used in their commands rather > than attempt to define a common set of required behavior in 3588bis. > Since reuse of all AVPs is encouraged, it is not necessary to mention > here that this particular AVP can be reused. >=20 > Regards > Mark >=20 >=20 > > -----Original Message----- > > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > > Sent: August 22, 2007 23:10 > > To: Asveren, Tolga > > Cc: dime@ietf.org > > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA > > > > Hi Tolga, > > > > > While we are at this, I propose to add the following as well: > > > > > > (Text to replace in 5.3.6 Supported-Vendor-Id AVP) > > > "This is used in the CER and CEA messages in order to > > inform the peer > > > that the sender supports (a subset of) the vendor-specific AVPs > > > defined by the vendor identified in this AVP." > > > > > > (Proposed Text) > > > "This AVP can be used in CER, CEA or in any application > > command, which > > > has it defined in the corresponding message grammar. It > > informs the peer > > > that the sender supports (a subset of) the vendor-specific > > AVPs defined > > > by the vendor identified in this AVP. > > > > > > It should be noted that CER/CEA messages are exchanged in a > > hop-by-hop > > > fashion. If there are intermediary nodes, e.g. a relay > > agent, between a > > > client and server, Supported-Vendor-Id AVP won't be > > exchanged between > > > the client and the server." > > > > > > > I'm ok with the text. Some editorial notes, maybe to simplify: > > > > "It should be noted that since CER/CEA messages are exchanged only > > between peers and > > does not extend beyond the single hop, Supported-Vendor-Id > > AVPs carried > > in these messages > > are relevant only between Diameter peers." > > > > Did I get your ideas correctly ? > > > > regards, > > victor > > > > > > _______________________________________________ > > 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 Aug 23 11:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEXz-0003xg-Qr; Thu, 23 Aug 2007 11:24:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEXy-0003xa-Fk for dime@ietf.org; Thu, 23 Aug 2007 11:24:34 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOEXy-0000xB-0O for dime@ietf.org; Thu, 23 Aug 2007 11:24:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 11:26:40 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> From: "Mark Jones" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 It has been bought to my attention off the list that my proposal that a peer assumes support of vendor-specific AVPs based on the Vendor-Id sub-AVP would cause interop issues with existing implementations of certain TISPAN applications. I therefore withdraw my previous proposal and present a new one for your consideration. Harish suggested making the Vendor-Id sub-AVP optional/informational because it is not required to identify the application. This is true so if the Vendor-Id sub-AVP is made optional, it then becomes mandatory to identify support of the application vendor's AVPs in the Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications happy. So the proposed changes to 3588bis-06 are: 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] value assigned to the vendor of the Diameter device. It is envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information. --- 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) A peer advertising support of a vendor-specific application does not imply that it also supports the vendor-specific AVPs of the application vendor. The Capabilities Exchange=20 message MUST instead include a Supported-Vendor-Id AVP with the IANA "SMI Network Management Private Enterprise Codes"=20 [RFC3232] value of the application vendor. --- 3) Update 2nd paragraph in section 6.11 (Vendor-Specific-Application-Id AVP) The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor-specific=20 Diameter application. It MUST NOT be used as a means of=20 defining a completely separate vendor-specific application identifier space. --- 4) Update ABNF in section 6.11 (Vendor-Specific-Application-Id AVP) ::=3D < AVP Header: 260 > [ Vendor-Id ] ({ Auth-Application-Id } / { Acct-Application-Id }) --- These changes are in addition to the text suggested by Tolga/Victor to clarify the hop-by-hop nature of CER/CEA. I also agree to that addition. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 11:31:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEeJ-0000dZ-H5; Thu, 23 Aug 2007 11:31:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOEeH-0000Yr-UJ for dime@ietf.org; Thu, 23 Aug 2007 11:31:05 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOEeH-00016R-Cv for dime@ietf.org; Thu, 23 Aug 2007 11:31:05 -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 l7NFV3u2001913; Thu, 23 Aug 2007 11:31:03 -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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 11:31:03 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: Acflmbs9GFlMOfdTSmOmZ4HbTrKI5wAACiAw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Mark Jones" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Mark, So basically you are proposing to make Vendor-Id AVP in Vendor-Specific-Application-Id Grouped AVP optional. This changes the grammar of the Vendor-Specific-Application-Id. People verify incoming messages according to that grammar. This breaks backward compatibility. I also find it odd that people used Vendor-Id AVP in the Vendor-Specific-Application-Id AVP to signal support for AVPs defined by a vendor. They should have used Vendor-Id AVP in CER/CEA for that purpose according to RFC3588. Could you provide the text from the corresponding TISPAN specification, which you think would cause a problem? Thanks, Tolga > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 11:27 AM > To: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > It has been bought to my attention off the list that my proposal that a > peer assumes support of vendor-specific AVPs based on the Vendor-Id > sub-AVP would cause interop issues with existing implementations of > certain TISPAN applications. I therefore withdraw my previous proposal > and present a new one for your consideration. >=20 > Harish suggested making the Vendor-Id sub-AVP optional/informational > because it is not required to identify the application. This is true so > if the Vendor-Id sub-AVP is made optional, it then becomes mandatory to > identify support of the application vendor's AVPs in the > Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications > happy. >=20 > So the proposed changes to 3588bis-06 are: >=20 > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) >=20 > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > 5.3.4) AVPs MAY provide very useful debugging information. >=20 > --- >=20 > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) >=20 > A peer advertising support of a vendor-specific application > does not imply that it also supports the vendor-specific > AVPs of the application vendor. The Capabilities Exchange > message MUST instead include a Supported-Vendor-Id AVP with > the IANA "SMI Network Management Private Enterprise Codes" > [RFC3232] value of the application vendor. >=20 > --- >=20 > 3) Update 2nd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) >=20 >=20 > The Vendor-Id AVP is an informational AVP pertaining to > the vendor who may have authorship of the vendor-specific > Diameter application. It MUST NOT be used as a means of > defining a completely separate vendor-specific application > identifier space. >=20 > --- >=20 > 4) Update ABNF in section 6.11 (Vendor-Specific-Application-Id AVP) >=20 > ::=3D < AVP Header: 260 > > [ Vendor-Id ] > ({ Auth-Application-Id } / > { Acct-Application-Id }) >=20 > --- >=20 > These changes are in addition to the text suggested by Tolga/Victor to > clarify the hop-by-hop nature of CER/CEA. I also agree to that addition. >=20 > Regards > Mark >=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 Aug 23 11: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 1IOF5t-0008Kc-KW; Thu, 23 Aug 2007 11:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOF5s-0008KX-03 for dime@ietf.org; Thu, 23 Aug 2007 11:59: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 1IOF5r-00011I-M5 for dime@ietf.org; Thu, 23 Aug 2007 11:59:35 -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 l7NFxAHa059496; Thu, 23 Aug 2007 11:59:10 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CDAECE.6050407@tari.toshiba.com> Date: Thu, 23 Aug 2007 11:59:10 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> 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: b19722fc8d3865b147c75ae2495625f2 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, > Harish suggested making the Vendor-Id sub-AVP optional/informational > because it is not required to identify the application. This is true so > if the Vendor-Id sub-AVP is made optional, it then becomes mandatory to > identify support of the application vendor's AVPs in the > Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications > happy. > I think the right term as I mentioned yesterday is that 'the content of vendor-id is deemed to be informational' from the base protocol point of view. > --- > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > A peer advertising support of a vendor-specific application > does not imply that it also supports the vendor-specific > AVPs of the application vendor. The Capabilities Exchange > message MUST instead include a Supported-Vendor-Id AVP with > the IANA "SMI Network Management Private Enterprise Codes" > [RFC3232] value of the application vendor. > This text implies that the base protocol does some validity checking contrary to what I was mentioning yesterday. I'm beginning to think that these proposals are trying to cater to other SDOs rather than maintaining the sanity of the base protocol. I think extended text on how people treat Vendor-Id/Supported-Vendor-Id and what problems you need to deal with should be place in the app guide rather than bis. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 12:11: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 1IOFHK-0001LL-Pn; Thu, 23 Aug 2007 12:11:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFHJ-0001LF-KL for dime@ietf.org; Thu, 23 Aug 2007 12:11:25 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOFHJ-00029K-4t for dime@ietf.org; Thu, 23 Aug 2007 12:11: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 l7NGBN4V029756; Thu, 23 Aug 2007 12:11: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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 12:11:23 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188197@sonusmail04.sonusnet.com> In-Reply-To: <46CDAECE.6050407@tari.toshiba.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: Acflnp8FLCo8o8UlTrKEBlrzD61ZiAAAPTHw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <46CDAECE.6050407@tari.toshiba.com> From: "Asveren, Tolga" To: "Victor Fajardo" , "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Actually, after thinking a bit more, it started to make sense to me to use different values for the Vendor-Id in CER/CEA and in Vendor-Specific-Application-Id.=20 In case of CER/CEA, it makes sense to use the Id of the device vendor. For Vendor-Specific-Application-Id (although it is not really necessary but for the sake of not changing the grammar) Id of the application vendor can be used. One approach could be=20 a) Define Vendor-Id AVP itself lightly, i.e. "Vendor-Id AVP specifies the identity of a vendor" b) Provide information about what vendor identity needs to be used in the corresponding messages/grouped AVPs, i.e. i- CER/CEA, Vendor-Id AVP should contain vendor-Id of the device vendor ii- Vendor-Specific-Application-Id, Vendor-Id AVP should contain vendor-Id of the application vendor. I agree with the general principle of considering anything in Vendor-Id as informational. This should take care of any interoperability problems, which could arise due to some checks etc... Thanks, Tolga > -----Original Message----- > From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Sent: Thursday, August 23, 2007 11:59 AM > To: Mark Jones > Cc: dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Hi Mark, > > Harish suggested making the Vendor-Id sub-AVP optional/informational > > because it is not required to identify the application. This is true so > > if the Vendor-Id sub-AVP is made optional, it then becomes mandatory to > > identify support of the application vendor's AVPs in the > > Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications > > happy. > > >=20 > I think the right term as I mentioned yesterday is that 'the content of > vendor-id is deemed to be informational' from the base protocol point of > view. > > --- > > > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > > > A peer advertising support of a vendor-specific application > > does not imply that it also supports the vendor-specific > > AVPs of the application vendor. The Capabilities Exchange > > message MUST instead include a Supported-Vendor-Id AVP with > > the IANA "SMI Network Management Private Enterprise Codes" > > [RFC3232] value of the application vendor. > > >=20 > This text implies that the base protocol does some validity checking > contrary to what I was mentioning yesterday. I'm beginning to think that > these proposals are trying to cater to other SDOs rather than > maintaining the sanity of the base protocol. I think extended text on > how people treat Vendor-Id/Supported-Vendor-Id and what problems you > need to deal with should be place in the app guide rather than bis. >=20 > regards, > victor >=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 Aug 23 12:19: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 1IOFPB-0000Cn-Ou; Thu, 23 Aug 2007 12:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFP9-0000Cc-Tx for dime@ietf.org; Thu, 23 Aug 2007 12:19:32 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOFP8-0001U2-L1 for dime@ietf.org; Thu, 23 Aug 2007 12:19:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 12:22:00 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" 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 > So basically you are proposing to make Vendor-Id AVP in > Vendor-Specific-Application-Id Grouped AVP optional. This changes the > grammar of the Vendor-Specific-Application-Id. People verify incoming > messages according to that grammar. This breaks backward=20 > compatibility. >=20 I read the Vendor-Id sub-AVP as being optional in the original 3588 ABNF: ::=3D < AVP Header: 260 > 1* [ Vendor-Id ] 0*1{ Auth-Application-Id } 0*1{ Acct-Application-Id } By contract, it is now a required, single value AVP in the latest 3588bis.=20 Doesn't that break backwards compatibility? > I also find it odd that people used Vendor-Id AVP in the > Vendor-Specific-Application-Id AVP to signal support for AVPs=20 > defined by > a vendor. They should have used Vendor-Id AVP in CER/CEA for that > purpose according to RFC3588. >=20 Looks like TISPAN actually assumed that this AVP was meant to indicate "the manufacturer of the Diameter node". I don't follow TISPAN so can't comment on why. Maybe it was the text about product, firmware and debugging that tipped them off to its originally intended use. > Could you provide the text from the corresponding TISPAN=20 > specification, > which you think would cause a problem? >=20 As I mentioned, I don't follow TISPAN but here is the reference I was passed: ETSI TS 183 017: 6.6 Advertising application support "Additonally, the AF and SPDF shall advertise the support of additional Vendor-ID AVPs by including the value ETSI (13019) and 3GPP (10415) in two different Supported-Vendor-Id AVPs of the CER and CEA commands." So a peer implementing my previous proposal would not include the ETSI vendor id in a Supported-Vendor-ID AVP and then existing Gq' implementations would barf. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 12:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFZV-00077W-CL; Thu, 23 Aug 2007 12:30:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFZS-0006up-Jh for dime@ietf.org; Thu, 23 Aug 2007 12:30:11 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOFZS-0002Xc-4i for dime@ietf.org; Thu, 23 Aug 2007 12:30:10 -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 l7NGU8Rr010275; Thu, 23 Aug 2007 12:30:08 -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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 12:30:08 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcfloWLzZ88xVlDjQwmk6zuA48J5WAAAK7Gg References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 12:22 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > > So basically you are proposing to make Vendor-Id AVP in > > Vendor-Specific-Application-Id Grouped AVP optional. This changes the > > grammar of the Vendor-Specific-Application-Id. People verify incoming > > messages according to that grammar. This breaks backward > > compatibility. > > >=20 > I read the Vendor-Id sub-AVP as being optional in the original 3588 > ABNF: >=20 > ::=3D < AVP Header: 260 > > 1* [ Vendor-Id ] > 0*1{ Auth-Application-Id } > 0*1{ Acct-Application-Id } >=20 > By contract, it is now a required, single value AVP in the latest > 3588bis. > Doesn't that break backwards compatibility? [TOLGA]Please note the 1*. 1*[] actually means that to have at least a single instance is mandatory. The change in the bis is just to use a more appropriate notation for this. >=20 > > I also find it odd that people used Vendor-Id AVP in the > > Vendor-Specific-Application-Id AVP to signal support for AVPs > > defined by > > a vendor. They should have used Vendor-Id AVP in CER/CEA for that > > purpose according to RFC3588. > > >=20 > Looks like TISPAN actually assumed that this AVP was meant to indicate > "the manufacturer of the Diameter node". I don't follow TISPAN so can't > comment on why. Maybe it was the text about product, firmware and > debugging that tipped them off to its originally intended use. >=20 > > Could you provide the text from the corresponding TISPAN > > specification, > > which you think would cause a problem? > > >=20 > As I mentioned, I don't follow TISPAN but here is the reference I was > passed: >=20 > ETSI TS 183 017: 6.6 Advertising application support >=20 > "Additonally, the AF and SPDF shall advertise the support of additional > Vendor-ID AVPs by including the value ETSI (13019) and 3GPP (10415) in > two different Supported-Vendor-Id AVPs of the CER and CEA commands." >=20 > So a peer implementing my previous proposal would not include the ETSI > vendor id in a Supported-Vendor-ID AVP and then existing Gq' > implementations would barf. [TOLGA]Actually your real concern was about Vendor-Id AVP. Maybe we can leave Supported-Vendor-Id AVP intact. For certain cases it could be redundant but probably this is not a big deal. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 12:45:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFol-0007or-1I; Thu, 23 Aug 2007 12:45:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOFoj-0007ol-Ph for dime@ietf.org; Thu, 23 Aug 2007 12:45:57 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOFoi-00022o-Lf for dime@ietf.org; Thu, 23 Aug 2007 12:45:57 -0400 Received: by ik-out-1112.google.com with SMTP id b32so224619ika for ; Thu, 23 Aug 2007 09:45:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=ldD0vaHPRmnIgeIk2CoB+ECMGk74GfjBMlg/qOXGjYBee9a4Ny8aQtPWC3SEuO6FvxtRpxYwNwUyyb8CHU2TTBCpkPB6RqCCbTbKDE8wb3uhiUIOl8ZBSDzp+OQulBXo1llQWi6KFxh+xEf46PY/dqrsuef3AQnyjrwqxoTFORE= 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=o/PfjUxP7wT96RBjQxzhweuW4lZzRcp4jR61ziYL8ReF+9G0bKyTJeJYerYPqlR071hehJW5AVnEPdjz8IU/WFPTetWPul8aRyyd/S/E1kZpH6O4tIMuiUDrYiVjV1VVlnrTxloHBGxmvKTO3Rnq9EeFKL8TAE3Iu73onsnElAs= Received: by 10.65.225.7 with SMTP id c7mr7363584qbr.1187887554949; Thu, 23 Aug 2007 09:45:54 -0700 (PDT) Received: by 10.64.213.4 with HTTP; Thu, 23 Aug 2007 09:45:54 -0700 (PDT) Message-ID: Date: Thu, 23 Aug 2007 22:15:54 +0530 From: "Harish R Prabhu" To: "Asveren, Tolga" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.sonusnet.com> MIME-Version: 1.0 References: <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.sonusnet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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="===============2121611871==" Errors-To: dime-bounces@ietf.org --===============2121611871== Content-Type: multipart/alternative; boundary="----=_Part_39494_1967491.1187887554846" ------=_Part_39494_1967491.1187887554846 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that *1 [Vendor-Id] is more appropriate than { Vendor-Id} in the ABNF notation of the Vendor-Specific-Application-Id AVP. My understanding and interpretation of Vendor-Specific-Appication-Id is that it is used to identify an application which is authored by a specific Vendor (and not by multiple vendors). The Supported-Vendor-Id is used by a node to advertise to the peer that it can support AVPs belonging to a specifi vendor (but does not imply any applications from that vendor). In the light of this, its unrelated to this discussion it should be left as-is. My two cents. regards, Harish On 8/23/07, Asveren, Tolga wrote: > > Hi Mark, > > > -----Original Message----- > > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > > Sent: Thursday, August 23, 2007 12:22 PM > > To: Asveren, Tolga > > Cc: dime@ietf.org > > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA > > > > > So basically you are proposing to make Vendor-Id AVP in > > > Vendor-Specific-Application-Id Grouped AVP optional. This changes > the > > > grammar of the Vendor-Specific-Application-Id. People verify > incoming > > > messages according to that grammar. This breaks backward > > > compatibility. > > > > > > > I read the Vendor-Id sub-AVP as being optional in the original 3588 > > ABNF: > > > > ::= < AVP Header: 260 > > > 1* [ Vendor-Id ] > > 0*1{ Auth-Application-Id } > > 0*1{ Acct-Application-Id } > > > > By contract, it is now a required, single value AVP in the latest > > 3588bis. > > Doesn't that break backwards compatibility? > [TOLGA]Please note the 1*. 1*[] actually means that to have at least a > single instance is mandatory. The change in the bis is just to use a > more appropriate notation for this. > > > > > I also find it odd that people used Vendor-Id AVP in the > > > Vendor-Specific-Application-Id AVP to signal support for AVPs > > > defined by > > > a vendor. They should have used Vendor-Id AVP in CER/CEA for that > > > purpose according to RFC3588. > > > > > > > Looks like TISPAN actually assumed that this AVP was meant to indicate > > "the manufacturer of the Diameter node". I don't follow TISPAN so > can't > > comment on why. Maybe it was the text about product, firmware and > > debugging that tipped them off to its originally intended use. > > > > > Could you provide the text from the corresponding TISPAN > > > specification, > > > which you think would cause a problem? > > > > > > > As I mentioned, I don't follow TISPAN but here is the reference I was > > passed: > > > > ETSI TS 183 017: 6.6 Advertising application support > > > > "Additonally, the AF and SPDF shall advertise the support of > additional > > Vendor-ID AVPs by including the value ETSI (13019) and 3GPP (10415) in > > two different Supported-Vendor-Id AVPs of the CER and CEA commands." > > > > So a peer implementing my previous proposal would not include the ETSI > > vendor id in a Supported-Vendor-ID AVP and then existing Gq' > > implementations would barf. > [TOLGA]Actually your real concern was about Vendor-Id AVP. Maybe we can > leave Supported-Vendor-Id AVP intact. For certain cases it could be > redundant but probably this is not a big deal. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > -- Harish R Prabhu Bangalore, India. ------=_Part_39494_1967491.1187887554846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think that *1 [Vendor-Id] is more appropriate than { Vendor-Id} in the ABNF notation of the Vendor-Specific-Application-Id AVP. My understanding and interpretation of Vendor-Specific-Appication-Id is that it is used to identify an application which is authored by a specific Vendor (and not by multiple vendors).

The Supported-Vendor-Id is used by a node to advertise to the peer that it can support AVPs belonging to a specifi vendor (but does not imply any applications from that vendor). In the light of this, its unrelated to this discussion it should be left as-is.

My two cents.

regards,
Harish

On 8/23/07, Asveren, Tolga <tasveren@sonusnet.com> wrote:
Hi Mark,

> -----Original Message-----
> From: Mark Jones [mailto: mark.jones@bridgewatersystems.com]
> Sent: Thursday, August 23, 2007 12:22 PM
> To: Asveren, Tolga
> Cc: dime@ietf.org
> Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA
>
> > So basically you are proposing to make Vendor-Id AVP in
> > Vendor-Specific-Application-Id Grouped AVP optional. This changes
the
> > grammar of the Vendor-Specific-Application-Id. People verify
incoming
> > messages according to that grammar. This breaks backward
> > compatibility.
> >
>
> I read the Vendor-Id sub-AVP as being optional in the original 3588
> ABNF:
>
>   <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
>                                      1* [ Vendor-Id ]
>                                      0*1{ Auth-Application-Id }
>                                      0*1{ Acct-Application-Id }
>
> By contract, it is now a required, single value AVP in the latest
> 3588bis.
> Doesn't that break backwards compatibility?
[TOLGA]Please note the 1*. 1*[] actually means that to have at least a
single instance is mandatory. The change in the bis is just to use a
more appropriate notation for this.
>
> > I also find it odd that people used Vendor-Id AVP in the
> > Vendor-Specific-Application-Id AVP to signal support for AVPs
> > defined by
> > a vendor. They should have used Vendor-Id AVP in CER/CEA for that
> > purpose according to RFC3588.
> >
>
> Looks like TISPAN actually assumed that this AVP was meant to indicate
> "the manufacturer of the Diameter node". I don't follow TISPAN so
can't
> comment on why. Maybe it was the text about product, firmware and
> debugging that tipped them off to its originally intended use.
>
> > Could you provide the text from the corresponding TISPAN
> > specification,
> > which you think would cause a problem?
> >
>
> As I mentioned, I don't follow TISPAN but here is the reference I was
> passed:
>
> ETSI TS 183 017: 6.6 Advertising application support
>
> "Additonally, the AF and SPDF shall advertise the support of
additional
> Vendor-ID AVPs by including the value ETSI (13019) and 3GPP (10415) in
> two different Supported-Vendor-Id AVPs of the CER and CEA commands."
>
> So a peer implementing my previous proposal would not include the ETSI
> vendor id in a Supported-Vendor-ID AVP and then existing Gq'
> implementations would barf.
[TOLGA]Actually your real concern was about Vendor-Id AVP. Maybe we can
leave Supported-Vendor-Id AVP intact. For certain cases it could be
redundant but probably this is not a big deal.

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



--
Harish R Prabhu
Bangalore, India. ------=_Part_39494_1967491.1187887554846-- --===============2121611871== 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 --===============2121611871==-- From dime-bounces@ietf.org Thu Aug 23 13:08: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 1IOGAn-0002sz-21; Thu, 23 Aug 2007 13:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGAm-0002su-6V for dime@ietf.org; Thu, 23 Aug 2007 13:08:44 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGAl-0003SL-SU for dime@ietf.org; Thu, 23 Aug 2007 13:08:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 13:11:05 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.sonusnet. com> From: "Mark Jones" To: "Asveren, Tolga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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, Thanks for your continued input as we work through this. > [TOLGA]Please note the 1*. 1*[] actually means that to have at least a > single instance is mandatory. The change in the bis is just to use a > more appropriate notation for this. Wouldn't *{} be the notation for "at least a single instance is mandatory"? To be honest, 1*[] looks like an oxymoron and [] means optional to me. My notation confusion aside, if you insist that making Vendor-Id optional will cause backwards compatibility reasons, I can live with it being required as long as it is informational.=20 > [TOLGA]Actually your real concern was about Vendor-Id AVP.=20 > Maybe we can > leave Supported-Vendor-Id AVP intact. For certain cases it could be > redundant but probably this is not a big deal. >=20 There were two concerns in my original email. The second one concerns where a peer would advertise support of the VSAs of the application vendor: (a) Supported-Vendor-Id or (b) Vendor-Id sub-AVP. I still feel this requires a normative statement in the 3588bis. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 13:08: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 1IOGAt-0002vy-Bn; Thu, 23 Aug 2007 13:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGAr-0002vr-LS for dime@ietf.org; Thu, 23 Aug 2007 13:08:49 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGAq-0003SY-Cz for dime@ietf.org; Thu, 23 Aug 2007 13:08:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 13:11:09 -0400 Message-ID: In-Reply-To: <46CDAECE.6050407@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <46CDAECE.6050407@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Victor, Thanks for your continued input as we work through this. > Hi Mark, > > Harish suggested making the Vendor-Id sub-AVP optional/informational > > because it is not required to identify the application.=20 > This is true so > > if the Vendor-Id sub-AVP is made optional, it then becomes=20 > mandatory to > > identify support of the application vendor's AVPs in the > > Supported-Vendor-Id AVP. This proposal keeps the TISPAN applications > > happy. > > =20 >=20 > I think the right term as I mentioned yesterday is that 'the=20 > content of=20 > vendor-id is deemed to be informational' from the base=20 > protocol point of=20 > view. I'm fine with that term. If changing it to optional creates backwards compatibility issues then I'm OK if it remains required. > > --- > > > > 2) Add new paragraph to section 5.3.6 (Supported-Vendor-Id AVP) > > > > A peer advertising support of a vendor-specific application > > does not imply that it also supports the vendor-specific > > AVPs of the application vendor. The Capabilities Exchange=20 > > message MUST instead include a Supported-Vendor-Id AVP with > > the IANA "SMI Network Management Private Enterprise Codes"=20 > > [RFC3232] value of the application vendor. > > =20 >=20 > This text implies that the base protocol does some validity checking=20 > contrary to what I was mentioning yesterday. I'm beginning to=20 > think that=20 > these proposals are trying to cater to other SDOs rather than=20 > maintaining the sanity of the base protocol. I think extended text on=20 > how people treat Vendor-Id/Supported-Vendor-Id and what problems you=20 > need to deal with should be place in the app guide rather than bis. >=20 I assume implementations would validate the Supported-Vendor-Id AVP values against the vendor-specific dictionaries that they have available. Wasn't that the intent? I don't think this can go into the app design guide because it requires a normative statement: either the application vendor's vendor-id goes in the Vendor-Id sub-AVP or it goes in the Supported-Vendor-Id AVP. Sure you can leave it undefined and let every vendor-specific application specify their preferences but IMO this really is Base functionality so it should be defined in 3588bis. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 13:30: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 1IOGVa-0004Ya-SC; Thu, 23 Aug 2007 13:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGVZ-0004YT-TU for dime@ietf.org; Thu, 23 Aug 2007 13:30:13 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGVY-0004Ls-NQ for dime@ietf.org; Thu, 23 Aug 2007 13:30:13 -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 l7NHU8Ee020074; Thu, 23 Aug 2007 13:30:08 -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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 13:30:07 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcflqFs6tki2A8uiRAG2N2/skQ85BgAAFFug References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonusne t.com> From: "Asveren, Tolga" To: "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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, > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 1:11 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Tolga, Thanks for your continued input as we work through this. >=20 > > [TOLGA]Please note the 1*. 1*[] actually means that to have at least a > > single instance is mandatory. The change in the bis is just to use a > > more appropriate notation for this. >=20 > Wouldn't *{} be the notation for "at least a single instance is > mandatory"? > To be honest, 1*[] looks like an oxymoron and [] means optional to me. [TOLGA]I agree that 1*[] isn't elegant, but this is the very reason why it is changed to {}. Even with 1*[], what happens is that people check for the existence of this AVP because of the 1*. >=20 > My notation confusion aside, if you insist that making Vendor-Id > optional will cause backwards compatibility reasons, I can live with it > being required as long as it is informational. >=20 > > [TOLGA]Actually your real concern was about Vendor-Id AVP. > > Maybe we can > > leave Supported-Vendor-Id AVP intact. For certain cases it could be > > redundant but probably this is not a big deal. > > >=20 > There were two concerns in my original email. The second one concerns > where a peer would advertise support of the VSAs of the application > vendor: (a) Supported-Vendor-Id or (b) Vendor-Id sub-AVP. I still feel > this requires a normative statement in the 3588bis. [TOLGA] Just to summarize (and to make sure that I didn't get anything wrong), what we ideally want is: CER Vendor-Id =3D=3D> device vendor Supported-Vendor-Id =3D=3D> vendor of the supported AVPs Vendor-Specific-Application-Id Vendor-Id =3D=3D> application vendor IMHO, existing Supported-Vendor-Id AVP explanation in RFC3588 5.3.6 provides enough explanation for that type of usage. I asked whether it makes sense to add some text to warn people about hop-by-hop nature of CER/CEA but it is a different issue. For Vendor-Id, with your proposed changes, the first use case of Vendor-Id will be covered, we will use the Id of the device vendor. For the second use case of Vendor-Id, we can either say=20 that this information is anyhow redundant because application-Id space is flat and there is no harm using Id of the device vendor=20 OR organize the text in a way where the content of the Vendor-Id is specified at the sections where it is used, i.e. we can say that for CER/CEA it is device vendor and when used in the Vendor-Specific-Application-Id it is the application vendor. And I think we shouldn't forget to mention that Vendor-Id is informational, that would cover any type of interoperability issues. So, AFAICS, we need to choose whether we want different values for Vendor-Id depending on where it is used. I don't see any harm at doing so. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 14:03: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 1IOH1Z-00012l-K8; Thu, 23 Aug 2007 14:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOH1Z-00012g-2X for dime@ietf.org; Thu, 23 Aug 2007 14:03:17 -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 1IOH1X-0005o7-Uo for dime@ietf.org; Thu, 23 Aug 2007 14:03:17 -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 l7NI2lx9081467; Thu, 23 Aug 2007 14:02:48 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CDCBC7.1090409@tari.toshiba.com> Date: Thu, 23 Aug 2007 14:02:47 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Asveren, Tolga" Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <46CDAECE.6050407@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188197@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188197@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Tolga, > In case of CER/CEA, it makes sense to use the Id of the device vendor. > For Vendor-Specific-Application-Id (although it is not really necessary > but for the sake of not changing the grammar) Id of the application > vendor can be used. > > One approach could be > a) Define Vendor-Id AVP itself lightly, i.e. "Vendor-Id AVP specifies > the identity of a vendor" > Ok. > b) Provide information about what vendor identity needs to be used in > the corresponding messages/grouped AVPs, i.e. > i- CER/CEA, Vendor-Id AVP should contain vendor-Id of the device vendor > ii- Vendor-Specific-Application-Id, Vendor-Id AVP should contain > vendor-Id of the application vendor. > I'm ok with this as long as ... > I agree with the general principle of considering anything in Vendor-Id > as informational. This should take care of any interoperability > problems, which could arise due to some checks etc... > ... text meeting this criteria is meet. Beyond this, I don't think we need to add anything else in the bis. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 14:08: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 1IOH6m-0004gJ-6T; Thu, 23 Aug 2007 14:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOH6l-0004gD-4y for dime@ietf.org; Thu, 23 Aug 2007 14:08:39 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOH6j-0005wE-TL for dime@ietf.org; Thu, 23 Aug 2007 14:08:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 14:11:02 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Good summary Tolga, I think we're close. :) Vendor-Id =3D=3D> Device vendor Vendor-Specific-Application-Id Vendor-Id =3D=3D> not used during computation So the Vendor-Id sub-AVP ABNF and text remain unchanged from 3588bis-06. Now the ambiguous one: For TISPAN, the list of Supported-Vendor-Id AVPs MUST include one containing the vendor id assigned to the application vendor (ETSI in their case). If we agree with TISPAN, we add a new paragraph to section 5.3.6: A peer advertising support of a vendor-specific application does not imply that it also supports the vendor-specific AVPs of the application vendor. The Capabilities Exchange=20 message MUST instead include a Supported-Vendor-Id AVP with the IANA "SMI Network Management Private Enterprise Codes"=20 [RFC3232] value of the application vendor. If we disagree with TISPAN, where does the application vendor's vendor-id go? Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 14:15: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 1IOHDf-0002xh-LB; Thu, 23 Aug 2007 14:15:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHDe-0002xN-4t for dime@ietf.org; Thu, 23 Aug 2007 14:15:46 -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 1IOHDd-00071X-Qn for dime@ietf.org; Thu, 23 Aug 2007 14:15: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 l7NIANGj082716; Thu, 23 Aug 2007 14:10:23 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CDCD8F.20807@tari.toshiba.com> Date: Thu, 23 Aug 2007 14:10:23 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com> <46CCA643.8090703@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <46CDAECE.6050407@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: 7655788c23eb79e336f5f8ba8bce7906 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, > > I assume implementations would validate the Supported-Vendor-Id AVP > values against the vendor-specific dictionaries that they have > available. Wasn't that the intent? > Mmmm ... this is what I think should NOT be mandated in the bis. As I mentioned, the contents of this AVP is "for debugging and informational only" as far as the base protocol is concerned and therefore we should not assume anything. > I don't think this can go into the app design guide because it requires > a normative statement: either the application vendor's vendor-id goes in > the Vendor-Id sub-AVP or it goes in the Supported-Vendor-Id AVP. That's fine. Saying what the content should be is ok with me. Saying what processing would be done with the content is not ok. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 14:29: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 1IOHRJ-00029m-SU; Thu, 23 Aug 2007 14:29:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHRI-00029f-Tx for dime@ietf.org; Thu, 23 Aug 2007 14:29:52 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOHRI-0007WB-Gs for dime@ietf.org; Thu, 23 Aug 2007 14:29:52 -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 l7NITpXZ029471; Thu, 23 Aug 2007 14:29:51 -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] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 14:29:50 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718819A@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcflsKGXkO0KTj6YQO+k2JakSpinCAAAN2lw References: <033458F56EC2A64E8D2D7B759FA3E7E718817D@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E718817F@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! ! ! son usnet.com> < E7CCE8A83907104ABEE91AC3AE3709A00F269FDD@exchange.bridgewatersys.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> From: "Asveren, Tolga" To: "Mark Jones" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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, > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 2:11 PM > To: Asveren, Tolga > Cc: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Good summary Tolga, I think we're close. :) >=20 > Vendor-Id =3D=3D> Device vendor > Vendor-Specific-Application-Id > Vendor-Id =3D=3D> not used during computation >=20 > So the Vendor-Id sub-AVP ABNF and text remain unchanged from 3588bis-06. [TOLGA]That is fine with me. >=20 >=20 > Now the ambiguous one: For TISPAN, the list of Supported-Vendor-Id AVPs > MUST include one containing the vendor id assigned to the application > vendor (ETSI in their case). >=20 > If we agree with TISPAN, we add a new paragraph to section 5.3.6: >=20 > A peer advertising support of a vendor-specific application > does not imply that it also supports the vendor-specific > AVPs of the application vendor. The Capabilities Exchange > message MUST instead include a Supported-Vendor-Id AVP with > the IANA "SMI Network Management Private Enterprise Codes" > [RFC3232] value of the application vendor. >=20 > If we disagree with TISPAN, where does the application vendor's > vendor-id go? [TOLGA] Two points here: a) If an application is advertised as supported, isn't it obvious that the corresponding AVPs are supported as well? This makes me think that Supported-Vendor-Id is more useful to signal support for optional vendor specific AVPs, if the vendor is not the originator of the application. b) What text does prevent people adding Supported-Vendor-Id AVP for such a case? With the changes you proposed for the Vendor-Id, it will be clear that it is supposed to contain the device vendor. And considering the existing 5.3.6 text, people would use Supported-Vendor-Id to signal support for vendor specific AVPs. Basically, I don't think the text you propose for 5.3.6 is wrong, just it seems redundant to me (and MUST seems to be strong for this case, current 5.3.6 text does not use any IETF keywords).=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 14:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHUA-0002UN-1V; Thu, 23 Aug 2007 14:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHU8-0002Tf-JC for dime@ietf.org; Thu, 23 Aug 2007 14:32:48 -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 1IOHU8-0006c9-Ai for dime@ietf.org; Thu, 23 Aug 2007 14:32:48 -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 l7NIWOsf085639; Thu, 23 Aug 2007 14:32:24 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CDD2B8.2080204@tari.toshiba.com> Date: Thu, 23 Aug 2007 14:32:24 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> 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: 7655788c23eb79e336f5f8ba8bce7906 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, > Now the ambiguous one: For TISPAN, the list of Supported-Vendor-Id AVPs > MUST include one containing the vendor id assigned to the application > vendor (ETSI in their case). > > If we agree with TISPAN, we add a new paragraph to section 5.3.6: > > A peer advertising support of a vendor-specific application > does not imply that it also supports the vendor-specific > AVPs of the application vendor. The Capabilities Exchange > message MUST instead include a Supported-Vendor-Id AVP with > the IANA "SMI Network Management Private Enterprise Codes" > [RFC3232] value of the application vendor. > I'm still not convinced that putting this text in bis is proper. The bis is now starting to assume/imply some type validation processing between these AVPs, contradictory to its 'informational' status. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 16:38:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJRN-00033K-BI; Thu, 23 Aug 2007 16:38:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJRL-00033D-Uz for dime@ietf.org; Thu, 23 Aug 2007 16:38:04 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOJRL-0002sS-7d for dime@ietf.org; Thu, 23 Aug 2007 16:38:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 16:40:26 -0400 Message-ID: In-Reply-To: <46CDD2B8.2080204@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" , "Asveren, Tolga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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'm still not convinced that putting this text in bis is=20 > proper. The bis=20 > is now starting to assume/imply some type validation=20 > processing between=20 > these AVPs, contradictory to its 'informational' status. >=20 I am not suggesting for a second that 3588bis should contain any hints of what should be done with these AVPs. However, it also shouldn't leave any doubt in the mind of an implementor about what value an AVP contains. IMO it should be completely unnecessary for a vendor-specific application specification to detail what vendor id values go into which AVPs of the CER/CEA commands. Those are Base protocol commands and I look to RFC3588 to define their content. However, TISPAN had to describe that the ETSI vendor id goes in the Supported-Vendor-Id AVP. IMO they should have been able to simply list their application ids and vendor ids then refer implementors off to RFC3588. This is not a 'design choice' so I don't think the Applications Design Guidelines draft is the appropriate home for this. It is also interesting to note Tolga's comment that "If an application is advertised as supported, isn't it obvious that the corresponding AVPs are supported as well". I thought so too but the answer doesn't get you any closer to what goes in the Supported-Vendor-Id AVP. Maybe we think it is obvious but ETSI didn't think so and other SDOs appear to be divided on that question.=20 Regards Mark =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 17:13: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 1IOJzL-0008Ry-0L; Thu, 23 Aug 2007 17:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJzJ-0008PZ-Bs for dime@ietf.org; Thu, 23 Aug 2007 17:13:09 -0400 Received: from sonussf2.sonusnet.com ([208.45.178.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOJzI-0002wT-49 for dime@ietf.org; Thu, 23 Aug 2007 17:13:09 -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 l7NLD6Qg013486; Thu, 23 Aug 2007 17:13:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Thu, 23 Aug 2007 17:13:06 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E718819B@sonusmail04.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] 3588bis: Vendor Ids in CER/CEA Thread-Index: AcflxYF1pbenODu1SoCLzaYbDpz7SQAASOhA References: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> From: "Asveren, Tolga" To: "Mark Jones" , "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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, > -----Original Message----- > From: Mark Jones [mailto:mark.jones@bridgewatersystems.com] > Sent: Thursday, August 23, 2007 4:40 PM > To: Victor Fajardo; Asveren, Tolga > Cc: dime@ietf.org > Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > > I'm still not convinced that putting this text in bis is > > proper. The bis > > is now starting to assume/imply some type validation > > processing between > > these AVPs, contradictory to its 'informational' status. > > >=20 > I am not suggesting for a second that 3588bis should contain any hints > of what should be done with these AVPs. However, it also shouldn't leave > any doubt in the mind of an implementor about what value an AVP > contains. IMO it should be completely unnecessary for a vendor-specific > application specification to detail what vendor id values go into which > AVPs of the CER/CEA commands. Those are Base protocol commands and I > look to RFC3588 to define their content. >=20 > However, TISPAN had to describe that the ETSI vendor id goes in the > Supported-Vendor-Id AVP. IMO they should have been able to simply list > their application ids and vendor ids then refer implementors off to > RFC3588. This is not a 'design choice' so I don't think the Applications > Design Guidelines draft is the appropriate home for this. >=20 > It is also interesting to note Tolga's comment that "If an application > is advertised as supported, isn't it obvious that the corresponding AVPs > are supported as well". I thought so too but the answer doesn't get you > any closer to what goes in the Supported-Vendor-Id AVP. Maybe we think > it is obvious but ETSI didn't think so and other SDOs appear to be > divided on that question. [TOLGA] IMHO, a "Yes" answer provides some idea about what to put to Supported-Vendor-Id AVP. In such a case, one would use Supported-Vendor-Id to indicate support for optional vendor specific AVPs, where vendor is not the vendor of the application, e.g. 3GPP adding some optional AVPs to an IETF application. OTOH adding the Id of the application vendor probably wouldn't hurt either, if one chooses to do so. I am also wondering what ETSI (and other SDOs) are planning to do with Supported-Vendor-Id AVP. Do they define some semantics for it, e.g. if a server does not support the extensions signaled in the Supported-Vendor-Id it should reject the request. Any extension AVP has to be optional, so what is the big deal about advertising support for them in an AVP? What would be broken if it is not advertised or what benefit does it provide to advertise it? Just include the optional AVPs in the message and if they are not understood by the peer so be it (it may be used only to save some bandwidth by not including certain vendor defined optional AVPs AFAICS, and that is only after the first transaction of the session). Overall I think Supported-Vendor-Id AVP is not fit to enforce strong semantics. The more I think about it the more it makes sense to emphasize its informational nature. To me the explanation in RFC3588 5.3.6 is fine The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to a vendor other than the device vendor. This is used in the CER and CEA messages in order to inform the peer that the sender supports (a subset of) the vendor-specific AVPs defined by the vendor identified in this AVP. If there is a need for more explanation, that is O.K. IMHO as long as we don't introduce strong rules about it. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 23 17:17: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 1IOK3T-0000qC-MF; Thu, 23 Aug 2007 17:17:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOK3Q-0000et-Fl for dime@ietf.org; Thu, 23 Aug 2007 17:17:24 -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 1IOK3M-0004KT-Lk for dime@ietf.org; Thu, 23 Aug 2007 17:17:24 -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 l7NLHIiZ088267; Thu, 23 Aug 2007 17:17:18 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CDF95E.4080908@tari.toshiba.com> Date: Thu, 23 Aug 2007 17:17:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@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: 8b30eb7682a596edff707698f4a80f7d 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, > I am not suggesting for a second that 3588bis should contain any hints > of what should be done with these AVPs. However, it also shouldn't leave > any doubt in the mind of an implementor about what value an AVP > contains. IMO it should be completely unnecessary for a vendor-specific > application specification to detail what vendor id values go into which > AVPs of the CER/CEA commands. Those are Base protocol commands and I > look to RFC3588 to define their content. > This part is ok and your proposed changes to 5.5.3 and 6.11 should be enough. > However, TISPAN had to describe that the ETSI vendor id goes in the > Supported-Vendor-Id AVP. IMO they should have been able to simply list > their application ids and vendor ids then refer implementors off to > RFC3588. This is not a 'design choice' so I don't think the Applications > Design Guidelines draft is the appropriate home for this. > This is fine as well. But the proposed new paragraph in 5.3.6 is not related to this. > It is also interesting to note Tolga's comment that "If an application > is advertised as supported, isn't it obvious that the corresponding AVPs > are supported as well". I thought so too but the answer doesn't get you > any closer to what goes in the Supported-Vendor-Id AVP. Maybe we think > it is obvious but ETSI didn't think so and other SDOs appear to be > divided on that question. > Would'nt the proposed changes to 5.5.3 and 6.11 be enough ? IMHO, the proposed new paragraph in 5.3.6 goes beyond that since it requires which AVPs MUST be included in the CER/CEA. My two cents, -- victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 24 02:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSJI-0002ZL-Bx; Fri, 24 Aug 2007 02:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSJG-0002ZF-QM for dime@ietf.org; Fri, 24 Aug 2007 02:06:18 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOSJF-0007IQ-CF for dime@ietf.org; Fri, 24 Aug 2007 02:06:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Fri, 24 Aug 2007 02:08:37 -0400 Message-ID: In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E718819B@sonusmail04.sonusnet.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188181@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <033458F56EC2A64E8D2D7B759FA3E7E718819B@sonusmail04.sonusnet.com> From: "Mark Jones" To: "Asveren, Tolga" , "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Tolga, > To me the explanation in RFC3588 5.3.6 is fine > The Supported-Vendor-Id AVP (AVP Code 265) is of type=20 > Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise Codes" > [ASSIGNNO] value assigned to a vendor other than the device vendor. > This is used in the CER and CEA messages in order to=20 > inform the peer > that the sender supports (a subset of) the vendor-specific AVPs > defined by the vendor identified in this AVP. >=20 But it doesn't clarify was whether the list of Supported-Vendor-Id AVPs should include the vendor-id of the application vendor. That is all I'm looking for. > If there is a need for more explanation, that is O.K. IMHO as=20 > long as we > don't introduce strong rules about it. >=20 Understood. My proposed text includes a MUST and I realize this is too strong. I'll try to come up with new clause for the existing 5.3.6 paragraph (without any requirement keywords). Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 24 02:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSNa-0006iX-7K; Fri, 24 Aug 2007 02:10:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOSNY-0006iS-8a for dime@ietf.org; Fri, 24 Aug 2007 02:10:44 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOSNX-0000xk-Qy for dime@ietf.org; Fri, 24 Aug 2007 02:10:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Fri, 24 Aug 2007 02:13:04 -0400 Message-ID: In-Reply-To: <46CDF95E.4080908@tari.toshiba.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188190@sonusmail04.sonusnet.com><46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <46CDF95E.4080 908@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, > This is fine as well. But the proposed new paragraph in 5.3.6 is not=20 > related to this. >=20 The 5.3.6 text was only meant to clarify was whether the list of Supported-Vendor-Id AVPs should include the vendor-id of the vendor-specific application vendor. It apparently has implications beyond those I intended. =20 > Would'nt the proposed changes to 5.5.3 and 6.11 be enough ? IMHO, the=20 > proposed new paragraph in 5.3.6 goes beyond that since it=20 > requires which=20 > AVPs MUST be included in the CER/CEA. Now I think I understand your objection to my text: I have added a MUST around presence of the Supported-Vendor-Id AVP in CER/CEA where none existed before. Right? So how about:=20 The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to a vendor other than the device vendor=20 but including the vendor-specific application vendor. This is used=20 in the CER and CEA messages in order to inform the peer that the=20 sender supports (a subset of) the vendor-specific AVPs defined by=20 the vendor identified in this AVP. Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 24 08:02: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 1IOXsF-0000d4-SN; Fri, 24 Aug 2007 08:02:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOXsE-0000cw-7M for dime@ietf.org; Fri, 24 Aug 2007 08:02:46 -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 1IOXsD-0000ye-Pd for dime@ietf.org; Fri, 24 Aug 2007 08:02: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 l7OC2hit090763; Fri, 24 Aug 2007 08:02:43 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46CEC8E3.1070206@tari.toshiba.com> Date: Fri, 24 Aug 2007 08:02:43 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <46CDF95E.4080 908@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: 798b2e660f1819ae38035ac1d8d5e3ab 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, > Now I think I understand your objection to my text: I have added a MUST > around presence of the Supported-Vendor-Id AVP in CER/CEA where none > existed before. Right? > > So how about: > > The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise Codes" > [ASSIGNNO] value assigned to a vendor other than the device vendor > but including the vendor-specific application vendor. This is used > in the CER and CEA messages in order to inform the peer that the > sender supports (a subset of) the vendor-specific AVPs defined by > the vendor identified in this AVP. > Looks much better :) regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 24 08:29:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYHw-00024F-Om; Fri, 24 Aug 2007 08:29:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOYHw-000248-5F for dime@ietf.org; Fri, 24 Aug 2007 08:29:20 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOYHu-0007ro-Pd for dime@ietf.org; Fri, 24 Aug 2007 08:29:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Fri, 24 Aug 2007 08:31:39 -0400 Message-ID: In-Reply-To: <46CEC8E3.1070206@tari.toshiba.com> References: <46CCA643.8090703@tari.toshiba.com><033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <46CDF95E.4080 908@tari.toshiba.com> <46CEC8E3.1070206@tari.toshiba.com> From: "Mark Jones" To: "Victor Fajardo" , "Asveren, Tolga" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 much better :) Thanks guys.=20 Here is where we've ended up: --- 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [RFC3232] value assigned to the vendor of the Diameter device. It is envisioned that the combination of the Vendor-Id, Product-Name (Section 5.3.7) and the Firmware-Revision (Section 5.3.4) AVPs MAY provide very useful debugging information. --- 2) Update the first paragraph in section 5.3.6 (Supported-Vendor-Id AVP) The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and contains the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO] value assigned to a vendor other than the device vendor=20 but including the application vendor. This is used in the CER and=20 CEA messages in order to inform the peer that the sender supports=20 (a subset of) the vendor-specific AVPs defined by the vendor=20 identified in this AVP. --- 3) Update 2nd paragraph in section 6.11 (Vendor-Specific-Application-Id AVP) The Vendor-Id AVP is an informational AVP pertaining to the vendor who may have authorship of the vendor-specific=20 Diameter application. It MUST NOT be used as a means of=20 defining a completely separate vendor-specific application identifier space. --- Regards Mark _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Aug 24 16:01: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 1IOfLd-0003S9-1Z; Fri, 24 Aug 2007 16:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfLc-0003S4-FQ for dime@ietf.org; Fri, 24 Aug 2007 16:01:36 -0400 Received: from smtp109.rog.mail.re2.yahoo.com ([68.142.225.207]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IOfLb-0005fS-8t for dime@ietf.org; Fri, 24 Aug 2007 16:01:36 -0400 Received: (qmail 8532 invoked from network); 24 Aug 2007 20:01:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xyK5a6Pjr6ggb7fG7UiL0urqHbXYr6Yc0/mo64IsBnvmjCPiRu2wl/QZSFGt7nOTb8g8XaFKMBOkiKNYbEOBalZOrlelrxMLSAoBW1S2YMVnoY98Gt6pL6zjxlA5GLpP4NgCCUz24UyLY7bTKXGhf+/oYrYRa+fCf/HFheK8qw0= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp109.rog.mail.re2.yahoo.com with SMTP; 24 Aug 2007 20:01:34 -0000 X-YMail-OSG: YnwRnxYVM1nw2vr3xFlYM5Ctuxo3WWqjJewG9jhZY2EIX7g1I8xvMrqbgKjNDZmuqA-- Message-ID: <46CF391C.10504@rogers.com> Date: Fri, 24 Aug 2007 16:01:32 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Jones Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA References: <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <46CDF95E.4080 908@tari.toshiba.com> <46CEC8E3.1070206@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: 0a7aa2e6e558383d84476dc338324fab 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 Just the tiniest nit: in that first paragraph the "may" in "may provide" is not an RFC 2119 "MAY": we're not telling anyone what they're allowed to do. I'd also be happier to take out the "very" from "very useful" -- this is a standard rather than a sales brochure. Mark Jones wrote: >> Looks much better :) > > Thanks guys. > > Here is where we've ended up: > > --- > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise > Codes" [RFC3232] value assigned to the vendor of the Diameter > device. It is envisioned that the combination of the Vendor-Id, > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > 5.3.4) AVPs MAY provide very useful debugging information. > > --- > > 2) Update the first paragraph in section 5.3.6 (Supported-Vendor-Id AVP) > > The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and > contains the IANA "SMI Network Management Private Enterprise Codes" > [ASSIGNNO] value assigned to a vendor other than the device vendor > but including the application vendor. This is used in the CER and > CEA messages in order to inform the peer that the sender supports > (a subset of) the vendor-specific AVPs defined by the vendor > identified in this AVP. > > --- > > 3) Update 2nd paragraph in section 6.11 (Vendor-Specific-Application-Id > AVP) > > > The Vendor-Id AVP is an informational AVP pertaining to > the vendor who may have authorship of the vendor-specific > Diameter application. It MUST NOT be used as a means of > defining a completely separate vendor-specific application > identifier space. > > > --- > > 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 Fri Aug 24 16:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfSt-0001LP-7n; Fri, 24 Aug 2007 16:09:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOfSs-0001LI-NU for dime@ietf.org; Fri, 24 Aug 2007 16:09:06 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOfSs-0001KA-4O for dime@ietf.org; Fri, 24 Aug 2007 16:09:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] 3588bis: Vendor Ids in CER/CEA Date: Fri, 24 Aug 2007 16:11:24 -0400 Message-ID: In-Reply-To: <46CF391C.10504@rogers.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7188192@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188195@sonusmail04.sonusnet.com> <033458F56EC2A64E8D2D7B759FA3E7E7188198@sonusmail04.! ! sonus net.com> <033458F56EC2A64E8D2D7B759FA3E7E7188199@sonusmail04.sonusnet.com> <46CDD2B8.2080204@tari.toshiba.com> <46CDF95E.4080 908@tari.toshiba.com> <46CEC8E3.1070206@tari.toshiba.com> <46CF391C.10504@rogers.com> From: "Mark Jones" To: "Tom Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Thanks for reviewing the proposal Tom, Both nits are with the original 3588 text but I'm ok with Tom's suggestions. Regards Mark=20 > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com]=20 > Sent: August 24, 2007 22:02 > To: Mark Jones > Cc: Victor Fajardo; Asveren, Tolga; dime@ietf.org > Subject: Re: [Dime] 3588bis: Vendor Ids in CER/CEA >=20 > Just the tiniest nit: in that first paragraph the "may" in=20 > "may provide" is not=20 > an RFC 2119 "MAY": we're not telling anyone what they're=20 > allowed to do. I'd=20 > also be happier to take out the "very" from "very useful" --=20 > this is a standard=20 > rather than a sales brochure. >=20 > Mark Jones wrote: > >> Looks much better :) > >=20 > > Thanks guys.=20 > >=20 > > Here is where we've ended up: > >=20 > > --- > >=20 > > 1) Update 1st paragraph in section 5.5.3 (Vendor-Id AVP) > >=20 > > The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and > > contains the IANA "SMI Network Management Private Enterprise > > Codes" [RFC3232] value assigned to the vendor of the Diameter > > device. It is envisioned that the combination of the Vendor-Id, > > Product-Name (Section 5.3.7) and the Firmware-Revision (Section > > 5.3.4) AVPs MAY provide very useful debugging information. > >=20 > > --- > >=20 > > 2) Update the first paragraph in section 5.3.6=20 > (Supported-Vendor-Id AVP) > >=20 > > The Supported-Vendor-Id AVP (AVP Code 265) is of type=20 > Unsigned32 and > > contains the IANA "SMI Network Management Private Enterprise Codes" > > [ASSIGNNO] value assigned to a vendor other than the device vendor=20 > > but including the application vendor. This is used in the CER and=20 > > CEA messages in order to inform the peer that the sender supports=20 > > (a subset of) the vendor-specific AVPs defined by the vendor=20 > > identified in this AVP. > >=20 > > --- > >=20 > > 3) Update 2nd paragraph in section 6.11=20 > (Vendor-Specific-Application-Id > > AVP) > >=20 > >=20 > > The Vendor-Id AVP is an informational AVP pertaining to > > the vendor who may have authorship of the vendor-specific=20 > > Diameter application. It MUST NOT be used as a means of=20 > > defining a completely separate vendor-specific application > > identifier space. > >=20 > >=20 > > --- > >=20 > > Regards > > Mark > >=20 > > _______________________________________________ > > 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 From dime-bounces@ietf.org Sun Aug 26 12:18: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 1IPKp5-0002ca-T0; Sun, 26 Aug 2007 12:18:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPKp4-0002QO-6t; Sun, 26 Aug 2007 12:18:46 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPKp3-0006EE-Bo; Sun, 26 Aug 2007 12:18:46 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5a46d225a1; Mon, 27 Aug 2007 00:30:45 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm1746ccc31c; Thr, 23 Aug 2007 06:30:29 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 23 Aug 2007 06:30:29 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyUh-0001Ue-Dz; Wed, 22 Aug 2007 18:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyUd-0001Td-2m; Wed, 22 Aug 2007 18:16:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INyUc-0004aZ-N9; Wed, 22 Aug 2007 18:16:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 84B0B32935; Wed, 22 Aug 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INyTe-0007Pv-ER; Wed, 22 Aug 2007 18:15: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: Wed, 22 Aug 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-06.txt X-BeenThere: dime@ietf.org Reply-To: internet-drafts@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 --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-06.txt Pages : 158 Date : 2007-8-22 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-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dime-rfc3588bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a messa --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 Sun Aug 26 15: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 1IPNgR-0003Ml-Hd; Sun, 26 Aug 2007 15:22:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPNgP-0003KV-EE for dime@ietf.org; Sun, 26 Aug 2007 15:22:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IPNgN-0001ug-RQ for dime@ietf.org; Sun, 26 Aug 2007 15:22:01 -0400 Received: (qmail invoked by alias); 26 Aug 2007 19:21:58 -0000 Received: from p54987ADA.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.218] by mail.gmx.net (mp038) with SMTP; 26 Aug 2007 21:21:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xsoBRLWGxwlrUXcAK0n2mVFuQ4AfssnFKhc6QIk WucAJzY43h+rAh Message-ID: <46D1D2D1.9060808@gmx.net> Date: Sun, 26 Aug 2007 21:21:53 +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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org Subject: [Dime] WGLC: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction 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 Network Access Server to Diameter Server Interaction" (draft-ietf-dime-mip6-integrated-05.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt Please post comments and questions to the DIME mailing list no later than 9 September 2007. Ciao Hannes & Dave _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 28 02:37: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 1IPuhb-0003Ar-NJ; Tue, 28 Aug 2007 02:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPuha-000370-3v for dime@ietf.org; Tue, 28 Aug 2007 02:37:26 -0400 Received: from mglblrmail.mgl.com ([61.95.163.15] helo=mglblrmail.blr.mgl.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPuhY-0002Ml-5A for dime@ietf.org; Tue, 28 Aug 2007 02:37:25 -0400 Received: from Vishalbabu ([172.16.25.21]) by mglblrmail.blr.mgl.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 12:07:21 +0530 From: "Vishal Babu" To: Date: Mon, 27 Aug 2007 23:36:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: Normal X-OriginalArrivalTime: 28 Aug 2007 06:37:21.0330 (UTC) FILETIME=[E2F48120:01C7E93D] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] Routing 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 , In diameter how originator of the message sends the message if destinatio= n host and destination relam is not present. Regards Vishal EMAIL DISCLAIMER : This email and any files transmitted with it are confi= dential and intended solely for the use of the individual or entity to wh= om they are addressed. Any unauthorised distribution or copying is strict= ly prohibited. If you receive this transmission in error, please notify t= he sender by reply email and then destroy the message. Opinions, conclusi= ons and other information in this message that do not relate to official = business of Mascon shall be understood to be neither given nor endorsed b= y Mascon. Any information contained in this email, when addressed to Masc= on clients is subject to the terms and conditions in governing client con= tract.=0A=0AWhilst Mascon takes steps to prevent the transmission of viru= ses via e-mail, we can not guarantee that any email or attachment is free= from computer viruses and you are strongly advised to undertake your own= anti-virus precautions. Mascon grants no warranties regarding performanc= e, use or quality of any e-mail or attachment and undertakes no liability= for loss or damage, howsoever caused. =0A=0A _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 28 03:33: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 1IPva6-0007C7-OY; Tue, 28 Aug 2007 03:33:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Message-ID: <46D3CFCF.6070308@ericsson.com> Date: Tue, 28 Aug 2007 09:33:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: sip@ietf.org, dime@ietf.org, IETF SIPPING WG , tsvwg , NSIS Subject: [Dime] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications 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 again, I have received some more comments. So here is an updated version adding=20 DIME documents and correcting origin of documents. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim , Hannes Tschofenig , David Frascone Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =96 60 Rev.2). We would=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the DIME, SIP and SIPPING WG may be=20 of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 28 03:55: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 1IPvvU-0005r0-Du; Tue, 28 Aug 2007 03:55:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvvO-0005mj-4W; Tue, 28 Aug 2007 03:55:46 -0400 Received: from ccsmtpgate.mugla.edu.tr ([194.27.32.25] helo=ccsmtpgate.mu.edu.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvvM-0000NA-1O; Tue, 28 Aug 2007 03:55:45 -0400 Received: from ccexc01.mu.edu.tr ([10.1.1.15]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 11:01:48 +0300 Received: from mail pickup service by ccexc01.mu.edu.tr with Microsoft SMTPSVC; Tue, 28 Aug 2007 11:01:46 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ccsmtpgate.mu.edu.tr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 10:40:37 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPva6-0007Bz-N6; Tue, 28 Aug 2007 03:33:46 -0400 Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1IPva3-0007B5-6x for nsis-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 03:33:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPvZy-00078U-2t; Tue, 28 Aug 2007 03:33:38 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPvZw-0008UK-Bj; Tue, 28 Aug 2007 03:33:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1B9C210F1; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-42-46d3cfcfa7e9 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7CCBF203FB; Tue, 28 Aug 2007 09:33:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:33:35 +0200 Message-ID: <46D3CFCF.6070308@ericsson.com> Date: Tue, 28 Aug 2007 09:33:35 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 References: <46AF5370.9020304@ericsson.com> <46D2E80E.8000001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Aug 2007 07:33:35.0545 (UTC) FILETIME=[BE24DA90:01C7E945] X-Brightmail-Tracker: AAAAAA== Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.6 (+) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 1.6 (+) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Cc: sip@ietf.org, IETF SIPPING WG , dime@ietf.org, tsvwg , NSIS Subject: [Dime] [NSIS] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications 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 again, I have received some more comments. So here is an updated version adding=20 DIME documents and correcting origin of documents. Submission Date: , 2007 From: IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING To: Georges Sebek , Keith Knightson Cc: Magnus Westerlund , Lars Eggert , James Polk , Martin Stiemerling , John Loughney Dean Willis , Keith Drage , Mary Barnes , Gonzalo Camarillo , Scott Bradner , Kimberly King , Scott Brim , Hannes Tschofenig , David Frascone Response Contact: TSV WG (tsv-chairs@tools.ietf.org) NSIS (nsis-chairs@tools.ietf.org) SIPPING (sipping-chairs@tools.ietf.org) SIP (sip-chairs@tools.ietf.org) DIME (dime-chairs@tools.ietf.org) =09 Purpose: Response to Liaison Request Deadline: None Title: Response to liaison request from ITU-T Study Group 13 work on=20 emergency telecommunications This is a response to the liaison request made by Q.3/13 regarding=20 emergency telecommunications (REF: NGN-GSI/DOC =96 60 Rev.2). We would=20 first like to apologize for failing to meet the deadline in responding.=20 We do hope that the late answer still can be of some use. The liaison request was made to the following working groups (WG):=20 IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has=20 concluded. In addition to the WGs from which information was requested,=20 we also think that work performed by the DIME, SIP and SIPPING WG may be=20 of relevance. Pursuant to ITU-T Study Group 13 request for information on relevant and=20 related work in the IETF regarding emergency communications, we list=20 below RFCs and works in progress that we feel may be of interest to your=20 group. Some of the completed work is Informational, and others are in=20 the category of Standards Track. Q.3/13 also requested that we keep you informed of any developments in=20 regards to emergency telecommunications. In those regards we would like=20 to make you aware that IETF mailing list participation and document=20 information is free and open to anyone, allowing participants in Q.3/13=20 to keep themselves informed of any developments. If Q.3/13 desire to get=20 further information about specific ongoing work, then please send a=20 liaison request to the responsible WG for those specific documents. The following list is divided under the associated working groups from=20 which the work has been done within the IETF. SIP Working Group RFC 4412 Title: Communications Resource Priority for the Session Initiation Protocol (SIP) Abstract: This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers. The below two documents are proposed work items accepted to become IETF=20 WG items are likely of interest as they update RFC 4412. Work In Progress: draft-polk-sip-rph-in-responses-00 Title: Allowing SIP Resource Priority Header in SIP Responses Abstract: The Session Initiation Protocol (SIP) Resource Priority Header (RPH), in its current form, is ignored in SIP responses. This was a design choice during RFC 4412's development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412's communications model by optionally allowing a SIP server or user agent client to process the Resource-Priority Header in a response. Work In Progress: draft-polk-sip-rph-new-namespaces--00 Title: New Session Initiation Protocol Resource-Priority Header Namespaces for=20 the Defense Information Systems Agency Abstract: This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. SIPPING Working Group RFC 4411 Title: Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events Abstract: This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred. IEPREP Working Group RFC 3487 Title: Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) Abstract: This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP). RFC 3689 Title: General Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). RFC 3690 Title: IP Telephony Requirements for Emergency Telecommunication Service (ETS) Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within the context of IP telephony. It is an extension to the general requirements presented in RFC 3689. Solutions to these requirements are not presented in this document. RFC 4190 Title: Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony Abstract: This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. RFC 4375 Title: Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain Abstract: This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. TSV Working Group RFC 4542 Title: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite Abstract: RFCs 3689 and 3690 detail requirements for an Emergency Telecommunications Service (ETS), of which an Internet Emergency Preparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis. This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. Work In Progress: draft-ietf-tsvwg-emergency-rsvp-03.txt Title: Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services Abstract: An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. This document specifies RSVP extensions that can be used to support such an admission priority capability at the network layer. Note that these extensions represent one possible solution component in satisfying ETS requirements. Other solution components, or other solutions, are outside the scope of this document. NSIS Working Group Work In Progress: draft-ietf-nsis-qos-nslp-14.txt Title: NSLP for Quality-of-Service Signaling Abstract: This specification describes the NSIS Signaling Layer Protocol (NSLP)=20 for signaling QoS reservations in the Internet. It is in accordance=20 with the framework and requirements developed in NSIS. Together with=20 GIST, it provides functionality similar to RSVP and extends it. The QoS=20 NSLP is independent of the underlying QoS specification or architecture=20 and provides support for different reservation models. It is simplified=20 by the elimination of support for multicast flows. This specification=20 explains the overall protocol approach, design decisions made and=20 provides examples. It specifies object, message formats and processing=20 rules. DIME Working Group Work In Progress: draft-ietf-dime-diameter-qos-01.txt Title: Diameter Quality of Service Application Abstract: This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Work In Progress: draft-ietf-dime-qos-parameters-00.txt Title: Quality of Service Parameters for Usage with the AAA Framework Abstract: This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Work In Progress: draft-ietf-dime-qos-attributes-01.txt Title: Quality of Service Attributes for Diameter and RADIUS Abstract: This document extends the functionality of the Diameter Base protocol and other Diameter applications with respect to their ability to convey Quality of Service information. The AVPs defined in this document are also available for Remote Authentication Dial In User Service (RADIUS). Non-WG Documents Approved for publication: draft-carlberg-trip-attribute-rp-02.txt Title: TRIP Attribute for Resource Priority =09 Abstract: This document defines a new attribute for the TRIP protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the PSTN are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tupple defined for the SIP resource Priority field. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ 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 Aug 28 05:01: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 1IPwxO-0004LE-Qe; Tue, 28 Aug 2007 05:01:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPwxN-0004L9-3i for dime@ietf.org; Tue, 28 Aug 2007 05:01:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPwxM-0001tt-I8 for dime@ietf.org; Tue, 28 Aug 2007 05:01:53 -0400 Received: (qmail invoked by alias); 28 Aug 2007 09:01:51 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 28 Aug 2007 11:01:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kXBoRqvmkaKUbqsx+QEEvZ8Hl7oWD1oKeMxJPbt vB7sjBLg8YBJkA Message-ID: <46D3E478.3070909@gmx.net> Date: Tue, 28 Aug 2007 11:01:44 +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-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ding.xiaobo@zte.com.cn Subject: [Dime] [Fwd: Hello,I found two errors in RFC 3588(2003)] 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 message that bounced back -- Ding, you need to subscribe to the mailing list. Ciao Hannes -------- Original Message -------- Subject: Hello,I found two errors in RFC 3588(2003) Date: Tue, 28 Aug 2007 16:21:34 +0800 From: ding.xiaobo@zte.com.cn To: dime@ietf.org Hello,DIME I found two errors in the RFC3588 Copyright (C) The Internet Society (2003), The first one is in page 52 : there are something wrong about AVP length: Of session-Id AVP Header, AVP length should be 42 instead of 50; Of session-Id AVP Header, AVP length should be 39 instead of 51; Of recovery-Policy Header, AVP length should be 215 instead of 223. The second one is an inconsistency between ACA in page 121 and ACA in page 126: In page 121, there is no any AVP named Route-Record of the command ACA, but in page 126, there is 0+ AVPs named Route-Record of the command ACA. That's all. Thank you$B!*(B Sincerely yours, Xiaobo Ding $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B===== ZTE corporation in Nanjing, China Phone:+086 025 52878487 EMail:ding.xiaobo@zte.com.cn MSN$B!'(Bmirroryuri@hotmail.com $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B====== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Aug 28 08:32: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 1IQ0F9-0004Fg-PX; Tue, 28 Aug 2007 08:32:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ0F9-0004FV-0P for dime@ietf.org; Tue, 28 Aug 2007 08:32:27 -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 1IQ0F8-0006Gw-H2 for dime@ietf.org; Tue, 28 Aug 2007 08:32: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 l7SCWEn4007094; Tue, 28 Aug 2007 08:32:14 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46D415D2.7050600@tari.toshiba.com> Date: Tue, 28 Aug 2007 08:32:18 -0400 From: Victor Fajardo User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] [Fwd: Hello,I found two errors in RFC 3588(2003)] References: <46D3E478.3070909@gmx.net> In-Reply-To: <46D3E478.3070909@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: dime@ietf.org, ding.xiaobo@zte.com.cn 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 Thanks. We'll fix that in the next rev. We can plan to publish 07 sometime mid sept along with a summary/history. regards, victor > Here is a message that bounced back -- > > Ding, you need to subscribe to the mailing list. > > Ciao > Hannes > > -------- Original Message -------- > Subject: Hello,I found two errors in RFC 3588(2003) > Date: Tue, 28 Aug 2007 16:21:34 +0800 > From: ding.xiaobo@zte.com.cn > To: dime@ietf.org > > > > Hello,DIME > > I found two errors in the RFC3588 Copyright (C) The Internet Society > (2003), > The first one is in page 52 : there are something wrong about AVP length: > Of session-Id AVP Header, AVP length should be 42 instead of 50; > Of session-Id AVP Header, AVP length should be 39 instead of 51; > Of recovery-Policy Header, AVP length should be 215 instead of > 223. > The second one is an inconsistency between ACA in page 121 and ACA in page > 126: > In page 121, there is no any AVP named Route-Record of the command > ACA, > but in page 126, there is 0+ AVPs named Route-Record of the > command ACA. > > That's all. Thank you$B!*(B > > Sincerely yours, > Xiaobo Ding > > > $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B===== > ZTE corporation in Nanjing, China > > Phone:+086 025 52878487 > EMail:ding.xiaobo@zte.com.cn > MSN$B!'(Bmirroryuri@hotmail.com > $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B====== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > > _______________________________________________ > 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 Aug 28 17:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ92K-0002gU-MC; Tue, 28 Aug 2007 17:55:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ92J-0002dv-Cw for dime@ietf.org; Tue, 28 Aug 2007 17:55:47 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ92I-0001mG-8i for dime@ietf.org; Tue, 28 Aug 2007 17:55:46 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 23:55:43 +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: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Date: Tue, 28 Aug 2007 23:55:42 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222C94C@SEHAN021MB.tcad.telia.se> In-Reply-To: <46C37732.2050904@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Thread-Index: Acffh5CCoSXeAGn8Td2uw7q/UimjZwKK24IQ References: <46C37732.2050904@gmx.net> From: To: , X-OriginalArrivalTime: 28 Aug 2007 21:55:43.0863 (UTC) FILETIME=[2E9FC870:01C7E9BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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, I think I was asked to review the draft-dime-mip6-split I-D. So here we go.. Hopefully I got it right, as it is getting late here. ------- General: o First impression: The I-D has issues and needs some serious work on it. o About the RFC4285 support. The RFC4285 is Informational, so how was this making a normative reference from a standards track I-D to an informative RFC? o There is RFC4285bis coming out. Should the Dime I-D reference to that instead of RFC4285? o The IKEv2 based authentication talks only about EAP-based authentication. However, mip6-aaa-ha-goals & RFC4877 does not have this restriction. The Dime I-D should also reflect that and allow e.g. certificate based=20 authentication with IKEv2. Section 4. >One task of the Mobile IPv6 bootstrapping procedure is to assign an >appropriate HA to the MN. Furthermore, authorization and successful isn't HA known already at this phase? Finding the HA is more of integrated scenario task. >delivery of Mobile IPv6 to a MN through a HA, requires the HA to act "successful delivery of Mobile IPv6 to a MN through a HA.." is supposed to mean what? I suggest rewriting this sentence. >as a client to the Diameter infrastructure interconnecting it to the >MSP. As a Diameter client, the HA needs to perform the following >operations: =20 Section 5.1 >application, as defined in [8], is re-used. AVPs specific to Mobile >IPv6 bootstrapping are added to this command. How about something like: application, as defined in [8], is re-used. AVPs specific to Mobile IPv6 bootstrapping are added to the EAP application commands. >As part of the authentication process, the MN MAY request a Home- >Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST The reference should be [3] >IKEv2 responder may not know if IK Ev2 is used for MIP6 service or =20 s/IK Ev2/IKEv2 Section 5.2 In the figure 3 would it be better to change MN-ID with MN-NAI. That is what it eventually tries to say. Also the MN-ID is not defined anywhere else than in this figure. Section 6. o as said earlier, this I-D should not restrict the use of IKEv2 to EAP only (see draft-mip6-aaa-ha-goals and RFC4877). Then we also need support NASREQ commands within the Mobile IPv6 application. I know there is "must" only for EAP but others are not explicitly excluded either Section 6.1.1 o For what purpose the MIP6-Feature-Vector is in DER & DEA messages? Its use is not explained anywhere? o The use of the MIP-Mobile-Node-Address in both DER & DEA messages are not explained anywhere. I would expect that at least why it is needed in DEA would be explained. Section 6.2 o this section and its subsections need a major rework.. o The current text only talks about using MN-AAA auth option. Is there a particular reason to neglect MN-HA auth option for BUs? o There should be an AVP to distinguish between MN-AAA and MN-HA operations towards AAA. o For what purpose MIP6-Feature-Vector is needed? ` o MIP-MN-AAA-Auth AVP cannot really be used.. as it just points byte ranges within the BU. We do not seem to pass the BU from HA to AAA in the MRM message. o for MN-AAA computation the MRM is missing an AVP to carry a CoA to AAA o MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI are only usable for MN-HA auth option that this I-D does not support at the moment for Bus (btw.. I am not sure whether RFC4285 actually can have different SPIs to different directions) o We need a generic SPI AVP.. also for MN-AAA authentication o for MN-HA authentication we probably need an AVP to return the shared key from AAA to HA (well.. the used MIP-HA-to-MN-MSA AVP could do but its use should be specified as it is a grouped AVP and not all sub-AVPs are needed) o MN-AAA authentication probably needs an AVP to carry the timestamp from HA to AAA o MN-AAA authentication probably needs an AVP to carry the authentication data from HA to AAA o We probably need an AVP to carry the mobility data or a MAC of the mobility data from HA to AAA o Use of MIP-Session-Key? I assume it is used to MN-HA calculation in a BA as the shared secret. o Giving explanations of AVP usage and even RFC4285 compliant examples of auth option processing would be most beneficial. The RFC4285 has always been somewhat foggy ;) o A reference to draft-ietf-mip6-whyauthdataoption would be usefull I think it would be beneficial to check what e.g. 3GPP2 did for their MIP6 HA-AAA interface. After all, they use RFC4285. Cheers, Jouni > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, August 16, 2007 12:59 AM > To: dime@ietf.org > Subject: [Dime] Meeting Minutes >=20 >=20 > Please check the meeting minutes: > http://www3.ietf.org/proceedings/07jul/minutes/dime.txt >=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 Wed Aug 29 11:39: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 1IQPdW-0006hn-Af; Wed, 29 Aug 2007 11:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPdV-0006hi-6k for dime@ietf.org; Wed, 29 Aug 2007 11:39:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQPdT-00040P-Cw for dime@ietf.org; Wed, 29 Aug 2007 11:39:17 -0400 Received: (qmail invoked by alias); 29 Aug 2007 15:39:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 29 Aug 2007 17:39:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+s7w0h6Sasa8TS6eqoNxxbqSpPbKZHma8TXertyK 2FCNogKvnLrG3w Message-ID: <46D59311.8080001@gmx.net> Date: Wed, 29 Aug 2007 17:38:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: review of dime-mip6-split; was RE: [Dime] Meeting Minutes References: <46C37732.2050904@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222C94C@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222C94C@SEHAN021MB.tcad.telia.se> 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: 6ffdee8af20de249c24731d8414917d3 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 Jouni, thanks for the review. This is the first part of my response. jouni.korhonen@teliasonera.com wrote: > Hi, > > I think I was asked to review the draft-dime-mip6-split I-D. So here we > go.. Hopefully I got it right, as it is getting late here. > > ------- > > General: > > o First impression: The I-D has issues and needs some serious work on > it. > > o About the RFC4285 support. The RFC4285 is Informational, so how was > this > making a normative reference from a standards track I-D to an > informative > RFC? > > We have to apply the Down-Ref procedures described in RFC 3967. > o There is RFC4285bis coming out. Should the Dime I-D reference to that > instead of RFC4285? > I have checked the changes between RFC 4285 and RFC 4285bis and I would agree that it is better to reference the RFC 4285bis. We need to change that. > o The IKEv2 based authentication talks only about EAP-based > authentication. > However, mip6-aaa-ha-goals & RFC4877 does not have this restriction. > The > Dime I-D should also reflect that and allow e.g. certificate based > authentication with IKEv2. > > That's a good point. This means that we would use only the authorization procedure. Is this correct? > Section 4. > > >One task of the Mobile IPv6 bootstrapping procedure is to assign an > >appropriate HA to the MN. Furthermore, authorization and successful > > isn't HA known already at this phase? Finding the HA is more of > integrated scenario task. > > >delivery of Mobile IPv6 to a MN through a HA, requires the HA to act > > "successful delivery of Mobile IPv6 to a MN through a HA.." is > supposed to > mean what? I suggest rewriting this sentence. > This part has to be changed to make it more readable. > >as a client to the Diameter infrastructure interconnecting it to the > >MSP. As a Diameter client, the HA needs to perform the following > >operations: > > > Section 5.1 > > >application, as defined in [8], is re-used. AVPs specific to Mobile > >IPv6 bootstrapping are added to this command. > > How about something like: > > application, as defined in [8], is re-used. AVPs specific to Mobile > IPv6 bootstrapping are added to the EAP application commands. > > Sounds good . > >As part of the authentication process, the MN MAY request a Home- > >Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST > > The reference should be [3] > > Ok > >IKEv2 responder may not know if IK Ev2 is used for MIP6 service or > > s/IK Ev2/IKEv2 > > > Fixed. > Section 5.2 > > In the figure 3 would it be better to change MN-ID with MN-NAI. > That is what it eventually tries to say. Also the MN-ID is not > defined anywhere else than in this figure. > > OK > Section 6. > > o as said earlier, this I-D should not restrict the use of IKEv2 > to EAP only (see draft-mip6-aaa-ha-goals and RFC4877). Then we also > need > support NASREQ commands within the Mobile IPv6 application. I know > there > is "must" only for EAP but others are not explicitly excluded either > > I am not sure why we need to support NASREQ even when we add the certificate authentication support. We could just omit the authentication phase altogether. I need more time with the rest of your comments. Will respond to them in a separate mail. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Aug 29 13:12:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR60-0004uX-Uj; Wed, 29 Aug 2007 13:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR60-0004uR-BC for dime@ietf.org; Wed, 29 Aug 2007 13:12:48 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQR5y-0007co-Sd for dime@ietf.org; Wed, 29 Aug 2007 13:12:48 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 19:12:45 +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: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Date: Wed, 29 Aug 2007 19:12:40 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222C99B@SEHAN021MB.tcad.telia.se> In-Reply-To: <46D59311.8080001@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Thread-Index: AcfqUsFBGGNp7UBGRfisDDcOlJse2AAC9sMw From: To: X-OriginalArrivalTime: 29 Aug 2007 17:12:45.0324 (UTC) FILETIME=[D10A14C0:01C7EA5F] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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, Few quick comments. > > o The IKEv2 based authentication talks only about EAP-based > > authentication. > > However, mip6-aaa-ha-goals & RFC4877 does not have this=20 > restriction. > > The > > Dime I-D should also reflect that and allow e.g.=20 > certificate based=20 > > authentication with IKEv2. > > =20 > That's a good point. This means that we would use only the=20 > authorization=20 > procedure. Is this correct? I think it should be ok. > > Section 6. > > > > o as said earlier, this I-D should not restrict the use of IKEv2 > > to EAP only (see draft-mip6-aaa-ha-goals and RFC4877).=20 > Then we also > > need > > support NASREQ commands within the Mobile IPv6=20 > application. I know > > there > > is "must" only for EAP but others are not explicitly=20 > excluded either > > > > =20 > I am not sure why we need to support NASREQ even when we add the=20 > certificate authentication support. We could just omit the=20 > authentication phase altogether. This comes from the RFC4072 (EAP) section 2.3.3 and the comment there: "The NASREQ application is used here for authorization because the realm-specific routing table supports routing based on application, not on Diameter commands." The only text & examples in RFC4072 use NASREQ when Auth-Request-type is set to AUTHORIZATION_ONLY. Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 30 04:14: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 1IQfB3-0003yI-9N; Thu, 30 Aug 2007 04:14:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQfB2-0003xy-C0 for dime@ietf.org; Thu, 30 Aug 2007 04:14:56 -0400 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQfAt-00030F-7Y for dime@ietf.org; Thu, 30 Aug 2007 04:14:56 -0400 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id A1F2036011B; Thu, 30 Aug 2007 13:44:44 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws04.hcl.in (Postfix) with ESMTPid 68C563600F1; Thu, 30 Aug 2007 13:44:44 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 13:44:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Aug 2007 13:45:12 +0530 Message-ID: <66E8AEE9980BB44CA5FCAD39EBA56AC60236FBCB@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Reg. Diameter Path Authorization Thread-Index: Acfq27OeyMHY1JwoSlqaP+HjCvE9kQAAaLEg From: "Arun Santhanam, TLS-Chennai" To: X-OriginalArrivalTime: 30 Aug 2007 08:14:44.0244 (UTC) FILETIME=[D26DED40:01C7EADD] X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-18.6931 TC:02 TRN:90 TV:3.6.1039(15392.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.0 (+) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: Subject: [Dime] Reg. Diameter Path Authorization 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="===============0086402995==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0086402995== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C7EADD.D257F739"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7EADD.D257F739 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7EADD.D257F739" ------_=_NextPart_002_01C7EADD.D257F739 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I was just going through the 3588-bis-06 in=20 http://www=2Eietf=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=2Etxt The following statement looks bit contradictory=20 2=2E9=2E Diameter Path Authorization =2E=2E=2E=2E =2E=2E=2E=2E =2E=2E=2E=2E Similarly, the local Diameter agent, on receiving a Diameter response authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the response is acceptable=2E At each step, forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session=2E A local realm may wish to limit this exposure, for example, by =20 =20 The RFC says Route-Record AVP can be "0" for all response message except ACA in section=20 "10=2E1=2E Base Protocol Command AVP Table"=20 =20 please clear me on this issue=2E =20 =20 Thanks & Regards Arun Santhanam Lead Engineer- VOIP [ Products BU/CSS/Telecom] HCL Technologies Ltd=2E No 8, Mth Road Ambattur Industial estate Chennai (T=2EN) 600058 Tel: +91-044-439672000 Extn=2E (7278) Direct: +91-044-43967278=20 Mob: +91-9841951234 www=2Ehcltech=2Ecom/voip www=2Ehcltech=2Ecom =20 www=2Ehcl=2Ein =20 =20 DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have=20 received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_002_01C7EADD.D257F739 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi=
 Victor,
        I was just going through=
 the 3588-bis-06 in http://www=
=2Eietf=2Eorg/internet-drafts/draft-ietf-dime-rfc3588bis-06=
=2Etxt
         The following=
 statement looks bit contradictory=
 
2=2E9=
=2E  Diameter Path=
 Authorization
…
…
…
   Similarly, the local Diameter agent, on receiving a=
 Diameter response
   authorizing a session, MUST check the Route-Record=
 AVPs to make sure
   that the route traversed by the response is acceptable=
=2E  At each
   step, forwarding of an authorization response is=
 considered evidence
   of a willingness to take on financial risk relative to=
 the session=2E
   A local realm may wish to limit this exposure, for=
 example, by
 
 
The RFC=
 says Route-Record AVP can=
 be “0” for all response message except ACA in section=
 
“10=
=2E1=2E  Base Protocol Command AVP Table”=
 
 
please=
 clear me on this issue=2E

 

 

Thanks & Regards

Arun Santhanam

Lead Engineer- VOIP= [= Products BU/CSS/Telecom]

HCL Technologies Ltd= =2E

No 8, Mth Road Ambattur Industial= estate

Chennai (T=2EN)= 600058

Tel: +91-044-439672000  Extn=2E= (7278)

Direct: +91-044-43967278=

Mob:= +91-9841951234

www=2Ehcltech=2Ecom/voip

www=2Ehcltech= =2Ecom

www=2Ehcl= =2Ein

 

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_002_01C7EADD.D257F739-- ------_=_NextPart_001_01C7EADD.D257F739 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAZARwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aisf /hLfD3/QXtf+/go/4S3w9/0F7X/v4K09lU/lf3Gftaf8y+82KKx/+Et8Pf8AQXtf+/go/wCEt8Pf 9Bi1/wC/go9lU/lf3B7Wn/MvvNiisf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+ 82KKx/8AhLfD3/QYtf8Av4KP+Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4K P+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf 3B7Wn/MvvNiisf8A4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QY tf8Av4KP+Et8Pf8AQYtf+/go9lU/lf3B7Wn/ADL7zYorH/4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj 2VT+V/cHtaf8y+82KKx/+Et8Pf8AQYtf+/go/wCEt8Pf9Bi1/wC/go9lU/lf3B7Wn/MvvNiisf8A 4S3w9/0GLX/v4KP+Et8Pf9Bi1/7+Cj2VT+V/cHtaf8y+82KKx/8AhLfD3/QYtf8Av4Kv2WoWepQG eyuY7iMHaWjbIB9KThKKu0NTjJ2TLNc1491Q6Z4YmEblJrlhChBwRnkn8ga6WuK8d+H9a8QXVqlj FG1tAhJLSBcufb6AfnWmHUXVXM9DLEuSpPkV2cL4e10aZrMN5qEt1PDFkiNZCctjA6mt/wAUfECD WNI+xadFc27tIC7sQPlHOBg+uK6TwT4UfRdPn/tOCFrmaTOOHAUDjn86yPGHhHWdZ1rzrC1t0tY4 wifOq57k4+p/SvRdWhOvd9Ot9DzlSxFOhp16W1MbwdfvY/b9dvpp5YbGIKiGQnfI5wBz+P51ENY8 Q+M9ZSxjvGgWUn93ExVEUdSccn8a7DS/BJHguXR71hFc3EhlZ0O7awPy/XgD8zXN2ng/xb4e1IXe mxwzOmQHSRSGB7ENiqVWjKU5Jrm6X2JdKtGMItPl623NO4+FgFsXtdVka7HIMi4Un8OR+tX/AA1o XiXQbwPfanBPp4U+bGZXbbx1XI4qlPb/ABE1UorvFp6KescgTP1wSa1n0HW7bwzeW/8AaU2o6hdJ 5YMsmEQHg7c+2ea551JuPLOad/63OiFOClzQg1b+tjzPUdYvtT1i4niuJx9omPloshGAThRj8q9r 0uzNhpdtaFizRRqrMxySccn868vtPAXieyu4rqGC28yFw6bpQRkdOK6P/i4//Tj/AOO1piuSooxh JWXmZ4TnpuUqkXd+R3FFQWa3C2UIu3V7gIPNZRgFsc4/Gp68lnrLVHz39kuf+fab/v2f8KPslz/z 7Tf9+z/hX0JRXq/2k/5fxPK/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8 Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8A Cj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+ X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+ /Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACj7Jc/8APtN/37P+FfQl FH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/wCf ab/v2f8ACj7Jc/8APtN/37P+FfQlFH9pP+X8Q/sxfzfgfPf2S5/59pv+/Z/wo+yXP/PtN/37P+Ff QlFH9pP+X8Q/sxfzfgfPf2S5/wCfab/v2f8ACtXQ9Z1vw88rWEUgWUDekkLMpx0OPWvb6KUsw5la UNCo5dyu8Z2Z5R/wsDxV/wA+0f8A4DN/jR/wsDxV/wA+0f8A4DN/jXq9FY/WaX/PtG31Wr/z9Z5R /wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8Vf8APtH/AOAz f40f8LA8Vf8APtH/AOAzf416vRR9Zpf8+0H1Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+ Azf416vRR9Zpf8+0H1Wr/wA/WeUf8LA8Vf8APtH/AOAzf40f8LA8Vf8APtH/AOAzf416vRR9Zpf8 +0H1Wr/z9Z5R/wALA8Vf8+0f/gM3+NH/AAsDxV/z7R/+Azf416vRR9Zpf8+0H1Wr/wA/Wf/Z ------_=_NextPart_001_01C7EADD.D257F739-- --===============0086402995== 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 --===============0086402995==-- From dime-bounces@ietf.org Thu Aug 30 05:50: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 1IQgfN-00081J-Ot; Thu, 30 Aug 2007 05:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQgfM-0007u6-6o for dime@ietf.org; Thu, 30 Aug 2007 05:50:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IQgfK-0004u9-IB for dime@ietf.org; Thu, 30 Aug 2007 05:50:20 -0400 Received: (qmail invoked by alias); 30 Aug 2007 09:50:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp008) with SMTP; 30 Aug 2007 11:50:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+GGAZvTFeGhOTvlStT4oHwQtOot9A2Ig+bIoksZT CyMgatcJMP/LxC Message-ID: <46D692CF.80109@gmx.net> Date: Thu, 30 Aug 2007 11:50:07 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: review of dime-mip6-split; was RE: [Dime] Meeting Minutes References: <46C37732.2050904@gmx.net> <59D7431DE2527D4CB0F1EFEDA5683ED30222C94C@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED30222C94C@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.8 (+) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 Jouni, thanks again for your extremely detailed review. A few more comments below: > Section 6.1.1 > > o For what purpose the MIP6-Feature-Vector is in DER & DEA messages? > Its use is not explained anywhere? > > Currently, the MIP6-Feature-Vector contains the following values: (a) MOBILITY_CAPABILITY (b) MIP6_INTEGRATED (c) LOCAL_HOME_AGENT_ASSIGNMENT Item (a) is not really required because the AAA server is able to learn about the Diameter client's mobility capability from the MIP6 App-ID. Item (b) is not applicable since this is not the integrated scenario. This leaves us with item (c). If the AAA client is not in the same domain as the AAA server then this could be useful. Right? > o The use of the MIP-Mobile-Node-Address in both DER & DEA messages > are not explained anywhere. I would expect that at least why it is > needed in DEA would be explained. > The MIP-Mobile-Node-Address allows the AAA server to provide the MN's HoA to be conveyed to the AAA client. Does this make sense to you? > Section 6.2 > > o this section and its subsections need a major rework.. > > o The current text only talks about using MN-AAA auth option. > Is there a particular reason to neglect MN-HA auth option > for BUs? > Ideally, dime-mip6-split should be as close to RFC 4004 with regard to the usage of the communication between the HA and the AAA server. Hence, we should definitely make utilize MIP-MN-AAA-Auth (as defined in Section 7.6 of RFC 4004) as it is used in the AA-Mobile-Node-Request (AMR) message of RFC 4004. When you look at Section 6.2.1 of dime-mip6-split then you will find the MIP-MN-AAA-Auth AVP. Hence, I believe things are in place. > o There should be an AVP to distinguish between MN-AAA and > MN-HA operations towards AAA. > In what sense? What AVPs from RFC 4004 would be needed? > o For what purpose MIP6-Feature-Vector is needed? > Do you mean that we should instead use the MIP-Feature-Vector AVP from RFC 4004? > ` > o MIP-MN-AAA-Auth AVP cannot really be used.. as it just points > byte ranges within the BU. We do not seem to pass the BU from > HA to AAA in the MRM message. > This is what RFC 4004 says: 7.6. MIP-MN-AAA-Auth AVP The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains some ancillary data to simplify processing of the authentication data in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the target AAA server. Its value has the following ABNF grammar: MIP-MN-AAA-Auth ::= < AVP Header: 322 > { MIP-MN-AAA-SPI } { MIP-Auth-Input-Data-Length } { MIP-Authenticator-Length } { MIP-Authenticator-Offset } * [ AVP ] I agree with you that we cannot right away use it. I will investigate what other SDOs did, such as 3GPP2 or Wimax, with respect to this issue. I will come back to you on this one. > o for MN-AAA computation the MRM is missing an AVP to carry a CoA > to AAA > Is this missing in RFC 4004 as well or is this specific to MIPv6 bootstrapping? > o MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI are only usable for > MN-HA auth option that this I-D does not support at the moment > for Bus (btw.. I am not sure whether RFC4285 actually can have > different SPIs to different directions) > Could you please clarify your comment regarding MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI? I am not sure I understood the problem. Regarding the SPIs: I believe we should re-use RFC 4004 as much as possible to avoid additional implementation complexity on the AAA server side. In RFC 4004 two different SPIs are used. > o We need a generic SPI AVP.. also for MN-AAA authentication > Why? > o for MN-HA authentication we probably need an AVP to return > the shared key from AAA to HA (well.. the used MIP-HA-to-MN-MSA > AVP could do but its use should be specified as it is a > grouped AVP and not all sub-AVPs are needed) > I indeed thought that we could use the MIP-HA-to-MN-MSA AVP as is (without modifications). > o MN-AAA authentication probably needs an AVP to carry the > timestamp from HA to AAA > Why? RFC 4004 only defines one timestamp for accounting (see Event-Timestamp AVP). > o MN-AAA authentication probably needs an AVP to carry the > authentication data from HA to AAA > Which authentication data? > o We probably need an AVP to carry the mobility data or a > MAC of the mobility data from HA to AAA > I guess this refers to the previously mentioned MIP-MN-AAA-Auth AVP. Right? > o Use of MIP-Session-Key? I assume it is used to MN-HA calculation > in a BA as the shared secret. > The MIP-Session-Key AVP is contained in a couple of grouped AVPs. It's semantic depends on the grouped AVP it is carried in. > o Giving explanations of AVP usage and even RFC4285 compliant > examples of auth option processing would be most beneficial. > The RFC4285 has always been somewhat foggy ;) > RFC 4285 is, in my opinion, a replica of the corresponding MIPv4 authentication procedure (regarding the communication from the HA to the AAA server). > o A reference to draft-ietf-mip6-whyauthdataoption would be usefull > > I don't think we need that since this is mostly a job of RFC 4285/RFC4285bis. > I think it would be beneficial to check what e.g. 3GPP2 did > for their MIP6 HA-AAA interface. After all, they use RFC4285. > > I will do that. Ciao Hannes > Cheers, > Jouni > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, August 16, 2007 12:59 AM >> To: dime@ietf.org >> Subject: [Dime] Meeting Minutes >> >> >> Please check the meeting minutes: >> http://www3.ietf.org/proceedings/07jul/minutes/dime.txt >> >> >> >> _______________________________________________ >> 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 Aug 30 08:48: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 1IQjSE-0006er-7w; Thu, 30 Aug 2007 08:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQim3-0003H5-0K; Thu, 30 Aug 2007 08:05:23 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQim1-0000y2-Gf; Thu, 30 Aug 2007 08:05:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7UC5AcA007655; Thu, 30 Aug 2007 15:05:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:05:14 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:05:14 +0300 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, 30 Aug 2007 15:05:12 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D0601DBA0@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAQRcaCw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 30 Aug 2007 12:05:14.0174 (UTC) FILETIME=[05B5C5E0:01C7EAFE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Thu, 30 Aug 2007 08:48:57 -0400 Cc: mip4@ietf.org Subject: [Dime] RE: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture 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, Sorry for jumping in the thread but I fail to understand why we'd need to alter a MIPv4 initial retransmission timer due to a certain deployment model. If MIPv4 is deployed in such a way that the initial retransmission timer would need to be doubled, tripled,... then I'd say it is up to the service provider to provide such parameters. This is how 3GPP2 operators have solved it. Cheers, Markku=20 >-----Original Message----- >From: ext McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 >Sent: 09 August, 2007 22:02 >To: Ahmad Muhanna; dime@ietf.org >Cc: mip4@ietf.org; Hannes Tschofenig >Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs.=20 >RADIUSArchitecture > >Hi, Ahmad, > >Ahmad Muhanna wrote: >> 2. The point here is not about Diameter as an AAA protocol, however,=20 >> it is about the concept of coupling the MIPv4 control=20 >signaling to AAA=20 >> signaling. Which many people do not think it is a good idea and=20 >> believe that it is a deviation from RFC3344 initial MIPv4 >> registration procedure. Do not you agree? =20 > >No, I don't. Putting the Registration Request in the AMR is a feature. >It allows the registration to happen in one round-trip. >=20 >> 6. Actually, we are going to publish a new revision of this=20 >draft and=20 >> address the scenario of allocating a HA in the visited network. Have=20 >> you looked into the difference between the RADIUS and D-MIP4=20 >> performance in this scenario and what will happen if the MN happened >> to retransmit? =20 > >Obviously this scenario takes longer to process the RRQ and so=20 >the chance of hitting a retransmission is greater. >=20 >>> I agree that a Diameter (or RADIUS, for that matter) infrastructure=20 >>> might take more than 1 second to respond to an AMR or an=20 >>> Access-Request. It seems that the solution is to recommend a longer=20 >>> timeout value for the initial retransmission. Another=20 >solution would=20 >>> be to allow the MN to complete its registration successfully by=20 >>> receiving an RRP matching a previous RRQ (not just the most=20 >recently=20 >>> retransmitted one). >>>=20 >>> I don't think we should turn the MIP4 Diameter application into a=20 >>> 2-round-trips protocol. The goal of RFC4004 is to provide MIP=20 >>> registration in one round-trip. >>>=20 > >-Pete > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Aug 30 09:17: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 1IQjtP-0005m0-CG; Thu, 30 Aug 2007 09:17:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjtN-0005lh-Er for dime@ietf.org; Thu, 30 Aug 2007 09:17:01 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQjtM-0008Pw-8Q for dime@ietf.org; Thu, 30 Aug 2007 09:17:01 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:16:57 +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: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Date: Thu, 30 Aug 2007 15:16:53 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222C9D5@SEHAN021MB.tcad.telia.se> In-Reply-To: <46D692CF.80109@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of dime-mip6-split; was RE: [Dime] Meeting Minutes Thread-Index: Acfq6y30oJnmatpNTbuMx7oR1vMNoQACchyw From: To: X-OriginalArrivalTime: 30 Aug 2007 13:16:57.0715 (UTC) FILETIME=[0AD20430:01C7EB08] X-Spam-Score: 1.8 (+) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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, See my replies inline.=20 > Sent: 30. elokuuta 2007 12:50 >=20 > Hi Jouni, >=20 > thanks again for your extremely detailed review. >=20 > A few more comments below: >=20 > > Section 6.1.1 > > > > o For what purpose the MIP6-Feature-Vector is in DER & DEA=20 > messages? > > Its use is not explained anywhere? > > > > =20 > Currently, the MIP6-Feature-Vector contains the following values: >=20 > (a) MOBILITY_CAPABILITY > (b) MIP6_INTEGRATED > (c) LOCAL_HOME_AGENT_ASSIGNMENT >=20 > Item (a) is not really required because the AAA server is=20 > able to learn about the Diameter client's mobility capability=20 > from the MIP6 App-ID. > Item (b) is not applicable since this is not the integrated scenario. > This leaves us with item (c). If the AAA client is not in the=20 > same domain as the AAA server then this could be useful. Right? Fine. This question was motivated because MIP6-Feature-Vector is a new AVP to HA-AAA interface but the document does not really describe anything about it. IHMO there must be some text to describe its desired use in that interface. > > o The use of the MIP-Mobile-Node-Address in both DER & DEA messages > > are not explained anywhere. I would expect that at least=20 > why it is > > needed in DEA would be explained. > > =20 > The MIP-Mobile-Node-Address allows the AAA server to provide=20 > the MN's HoA to be conveyed to the AAA client. > Does this make sense to you? Yes. You should add that also to the document ;) > > Section 6.2 > > > > o this section and its subsections need a major rework.. > > > > o The current text only talks about using MN-AAA auth option. > > Is there a particular reason to neglect MN-HA auth option > > for BUs? > > =20 > Ideally, dime-mip6-split should be as close to RFC 4004 with=20 > regard to the usage of the communication between the HA and=20 > the AAA server. > Hence, we should definitely make utilize MIP-MN-AAA-Auth (as=20 > defined in Section 7.6 of RFC 4004) as it is used in the=20 > AA-Mobile-Node-Request > (AMR) message of RFC 4004. >=20 > When you look at Section 6.2.1 of dime-mip6-split then you=20 > will find the MIP-MN-AAA-Auth AVP. The way RFC4285 calculates MN-HA and MN-AAA are different. MN-HA is more or less local with fixed algorithms, except that you might receive the shared-key from the AAA. On the other hand you can let AAA do all MN-AAA calculations.. or divide it between HA and AAA. It should be clarified what AVPs to use and what to put into those when processing MN-HA or MN-AAA received from the MN. Even if we are reusing RFC4004 AVPs we cannot assume that it is directly clear what to do. > Hence, I believe things are in place. >=20 > > o There should be an AVP to distinguish between MN-AAA and > > MN-HA operations towards AAA. > > =20 >=20 > In what sense? What AVPs from RFC 4004 would be needed? I don't think there's one. > > o For what purpose MIP6-Feature-Vector is needed? > > =20 > Do you mean that we should instead use the MIP-Feature-Vector=20 > AVP from RFC 4004? No, I just want a line of text saying for what and how the AAA expects to use the MIP6-Feature-Vector. We have defined few values for integrated scenario and explained their use in that domain. Would be nice to have the same for split scenario aswell. > > o MIP-MN-AAA-Auth AVP cannot really be used.. as it just points > > byte ranges within the BU. We do not seem to pass the BU from > > HA to AAA in the MRM message. > > =20 > This is what RFC 4004 says: >=20 > 7.6. MIP-MN-AAA-Auth AVP >=20 > The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains > some ancillary data to simplify processing of the=20 > authentication data > in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the > target AAA server. Its value has the following ABNF grammar: >=20 > MIP-MN-AAA-Auth ::=3D < AVP Header: 322 > > { MIP-MN-AAA-SPI } > { MIP-Auth-Input-Data-Length } > { MIP-Authenticator-Length } > { MIP-Authenticator-Offset } > * [ AVP ] >=20 >=20 > I agree with you that we cannot right away use it. >=20 > I will investigate what other SDOs did, such as 3GPP2 or=20 > Wimax, with respect to this issue. I will come back to you on=20 > this one. RFC4004 passes the whole BU message in the AMR to AAA. 3GPP2 passes only those parts of the message that are needed to for MN-AAA authentication. 3GPP has no clue ;) And WiMAX does its own thing. All those are deployment dependant. It might=20 be really hard to come up with a proper HA-AAA interface for RFC4285 that is actually usable. > > o for MN-AAA computation the MRM is missing an AVP to carry a CoA > > to AAA > > =20 > Is this missing in RFC 4004 as well or is this specific to MIPv6=20 > bootstrapping? RFC4004 passes the whole BU to AAA.. so it finds the CoA etc by parsing the data. I think this is not the right way ;) If AAA does MN-AAA authentication it needs CoA and HoA to verify the authentication data provided by the HA and MN. > > o MIP-MN-to-HA-SPI & MIP-HA-to-MN-SPI are only usable for > > MN-HA auth option that this I-D does not support at the moment > > for Bus (btw.. I am not sure whether RFC4285 actually can have > > different SPIs to different directions) > > =20 > Could you please clarify your comment regarding MIP-MN-to-HA-SPI &=20 > MIP-HA-to-MN-SPI? I am not sure I understood the problem. Well.. for MN-AAA authentication you would use MIP-MN-AAA-SPI (that is part of MIP-MN-AAA-Auth grouped AVP. So if you authentication MN using MN-AAA you don't use MIP-MN-to-HA-SPI etc, right?=20 And the current text in the draft does not difference between MN-HA and MN-AAA authentications. They would need slightly different set or way of using AVPs. These should be clarified. > Regarding the SPIs: I believe we should re-use RFC 4004 as much as=20 > possible to avoid additional implementation complexity on the=20 > AAA server=20 > side. > In RFC 4004 two different SPIs are used. Yes.. my question in parenthesis was something more general related to RFC4285.=20 > > o We need a generic SPI AVP.. also for MN-AAA authentication > > =20 > Why? Sorry, missed the MIP-MN-AAA-SPI in the MIP-MN-AAA-Auth grouped AVP. That can be used for MN-AAA. > > o for MN-HA authentication we probably need an AVP to return > > the shared key from AAA to HA (well.. the used MIP-HA-to-MN-MSA > > AVP could do but its use should be specified as it is a > > grouped AVP and not all sub-AVPs are needed) > > =20 > I indeed thought that we could use the MIP-HA-to-MN-MSA AVP as is=20 > (without modifications). Within the MIP-HA-to-MN-MSA AVP we don't seem to need MIP-Algorithm-Type as RFC4285 has a fixed one. Hmm.. maybe we could state that for the MN-HA authentication the algorithm is always set to HMAC-SHA-1 (2) within RFC4285 scope. > > o MN-AAA authentication probably needs an AVP to carry the > > timestamp from HA to AAA > > =20 > Why? RFC 4004 only defines one timestamp for accounting (see=20 > Event-Timestamp AVP). Some deployments might want to use timestamp as one parameter that is used by the AAA to derive session keys. > > o MN-AAA authentication probably needs an AVP to carry the > > authentication data from HA to AAA > > =20 > Which authentication data? >From the Message Auth option.. if AAA does the MN-AAA authentication it probably wants to have the authentication data. > > o We probably need an AVP to carry the mobility data or a > > MAC of the mobility data from HA to AAA > > =20 > I guess this refers to the previously mentioned=20 > MIP-MN-AAA-Auth AVP. Right? Not really. MIP-MN-AAA-Auth AVP does not provide way to transfer e.g. calculated MAC mobility data calculated HA to AAA, if HA wished to do that calculation. > > o Use of MIP-Session-Key? I assume it is used to MN-HA calculation > > in a BA as the shared secret. > > =20 > The MIP-Session-Key AVP is contained in a couple of grouped=20 > AVPs. It's=20 > semantic depends on the grouped AVP it is carried in. Probably those semantics should be explained. > > o Giving explanations of AVP usage and even RFC4285 compliant > > examples of auth option processing would be most beneficial. > > The RFC4285 has always been somewhat foggy ;) > > =20 > RFC 4285 is, in my opinion, a replica of the corresponding MIPv4=20 > authentication procedure (regarding the communication from=20 > the HA to the=20 > AAA server). It is close but not replica. > > o A reference to draft-ietf-mip6-whyauthdataoption would be usefull > > > > =20 > I don't think we need that since this is mostly a job of RFC=20 > 4285/RFC4285bis. Ok. Cheers, Jouni > > I think it would be beneficial to check what e.g. 3GPP2 did > > for their MIP6 HA-AAA interface. After all, they use RFC4285. > > > > =20 > I will do that. >=20 > Ciao > Hannes >=20 > > Cheers, > > Jouni > > > > > > =20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > >> Sent: Thursday, August 16, 2007 12:59 AM > >> To: dime@ietf.org > >> Subject: [Dime] Meeting Minutes > >> > >> > >> Please check the meeting minutes: > >> http://www3.ietf.org/proceedings/07jul/minutes/dime.txt > >> > >> > >> > >> _______________________________________________ > >> 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