From dime-bounces@ietf.org Mon Feb 2 03:51:40 2009 Return-Path: X-Original-To: dime-archive@megatron.ietf.org Delivered-To: ietfarch-dime-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49D93A6A8A; Mon, 2 Feb 2009 03:51:40 -0800 (PST) X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461CF28C17A for ; Mon, 2 Feb 2009 03:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3p7PfE79N4B for ; Mon, 2 Feb 2009 03:51:38 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C23CB28C13A for ; Mon, 2 Feb 2009 03:51:32 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 163CE19871D for ; Mon, 2 Feb 2009 13:51:13 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 36D571986EE for ; Mon, 2 Feb 2009 13:51:10 +0200 (EET) Message-ID: <4986DDE7.1080400@piuha.net> Date: Mon, 02 Feb 2009 13:49:59 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: dime@ietf.org References: <49730194.1060207@piuha.net> <4973A419.5080508@piuha.net> In-Reply-To: <4973A419.5080508@piuha.net> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Dime] review of rfc3588bis, pages 20 through 30 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: dime-bounces@ietf.org Errors-To: dime-bounces@ietf.org Continuing with my review... > The base Diameter protocol concerns itself with capabilities > negotiation, how messages are sent and how peers may eventually be > abandoned. Here's a possibly better way to say this: "The base Diameter protocol concerns itself with establishing connections to peers, capabilities negotiation, how messages are sent and routed through peers, and how the connections are eventually torn down." > One AVP > that is included to reference a user's session is the Session-Id. > > The initial request for authentication and/or authorization of a user > would include the Session-Id. The Session-Id is then used in all > subsequent messages to identify the user's session I feel that the first sentence is unnecessary, given the remaining explanations. Perhaps you could say: "The initial request for authentication and/or authorization of a user would include the Session-Id AVP. ..." > Diameter Relays and redirect agents are, by definition, protocol > transparent application transparent? Section 2.3 talks about application Ids being advertised in capabilities negotiation, and then Section 2.4 actually defines what these IDs are and repeats the same story about capabilities negotiation. Perhaps some reorganization of text would be useful here. > Diameter implementations SHOULD be able to interpret ICMP protocol > port unreachable messages as explicit indications that the server is > not reachable, subject to security policy on trusting such messages. > Diameter implementations SHOULD also be able to interpret a reset > from the transport and timed-out connection attempts. If Diameter > receives data up from TCP that cannot be parsed or identified as a > Diameter error made by the peer, the stream is compromised and cannot > be recovered. The transport connection MUST be closed using a RESET > call (send a TCP RST bit) or an SCTP ABORT message (graceful closure > is compromised). > This text needs some softening, or perhaps you could add a reference to some other work, e.g., "Further guidance regarding the treatment of ICMP errors can be found in [draft-ietf-tcpm-icmp-attacks, draft-ietf-tcpm-soft-errors]." The references should be informative. Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From root@core3.amsl.com Thu Feb 5 01:15:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4264F3A6847; Thu, 5 Feb 2009 01:15:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090205091501.4264F3A6847@core3.amsl.com> Date: Thu, 5 Feb 2009 01:15:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter User-Name and Realm Based Request Routing Clarifications Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-nai-routing-01.txt Pages : 10 Date : 2009-02-05 This specification clarifies the Diameter realm based request routing. We focus on the case where a Network Access Identifier in the User-Name AVP is used to populate the Destination-Realm AVP and the Network Access Identifier contains more than one realm. This particular case is possible when the Network Access Identifier decoration is used to force a routing of request messages through a predefined list of realms. However, this functionality is not unambiguously specified in the Diameter Base Protocol specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-nai-routing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-05010131.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Thu Feb 5 03:35:24 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB0E3A69B9 for ; Thu, 5 Feb 2009 03:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo3VZiY+yWR7 for ; Thu, 5 Feb 2009 03:35:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7F6833A6940 for ; Thu, 5 Feb 2009 03:35:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231131600"; d="scan'208";a="136516720" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Feb 2009 06:35:01 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Feb 2009 06:35:00 -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 Date: Thu, 5 Feb 2009 12:34:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review for draft-jones-dime-3gpp-eps-command-codes-01 thread-index: AcmHhbqyKHrUOtUvQh2ItSBTTxLqHQ== From: "Romascanu, Dan (Dan)" To: "Mark Jones" , "MORAND Lionel RD-CORE-ISS" Cc: dime@ietf.org, hannu.hietalahti@nokia.com Subject: [Dime] AD Review for draft-jones-dime-3gpp-eps-command-codes-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 11:35:24 -0000 I have reviewed this AD-sponsored individual submission I-D. I believe that it is ready for IETF Last Call. The comments below can be treated as Last Call comments and dealt with together with the other IETF Last Call comments.=20 1. It would be useful to explain in a few words what is the scope of the 3GPP S6a and 3GPP S13 applications - the current descriptions in the I-D (vendor-specific application id ...) say nothing about the functionality. For example: 'The S6a application describes the subscriber information between MME and HSS as defined in section 5 of [TS29.272]', 'The S13 application enables the ME identity check procedure between the MME and the EIR as defined in section 6 of [TS29.272]'.=20 2. In section 4 in the table of command codes values that will be requested from IANA add '3GPP' to the name of each command in order to avoid confusions and names clashes with other similar requests that may be made to IANA. For example '3GPP-Update-Location-Request', etc.=20 3. The name of the document referred by [TS29.272] seems to have changed since the submission of the I-D. Please use the most recent name.=20 Dan From dromasca@avaya.com Thu Feb 5 07:33:45 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9725E3A6A8A; Thu, 5 Feb 2009 07:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV93--Oex4xB; Thu, 5 Feb 2009 07:33:44 -0800 (PST) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 7F22E3A6AFE; Thu, 5 Feb 2009 07:33:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,385,1231131600"; d="scan'208";a="151259513" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Feb 2009 10:33:24 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 05 Feb 2009 10:33:23 -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 Date: Thu, 5 Feb 2009 16:33:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-jones-dime-3gpp-eps-command-codes (Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)) to Informational RFC thread-index: AcmHnHteYLJo5yYDRNeWVaYYhBENgQACl71w From: "Romascanu, Dan (Dan)" To: , , Subject: [Dime] FW: Last Call: draft-jones-dime-3gpp-eps-command-codes (Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)) to Informational RFC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 15:33:45 -0000 FYI - please send your comments to ietf@ietf.org.=20 Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, February 05, 2009 4:17 PM To: IETF-Announce Subject: Last Call: draft-jones-dime-3gpp-eps-command-codes (Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Diameter Command Code Registration for Third Generation Partnership=20 Project (3GPP) Evolved Packet System (EPS) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command-co des-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 18081&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From hannes.tschofenig@nsn.com Mon Feb 9 06:34:33 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249EA3A6C1C for ; Mon, 9 Feb 2009 06:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GINp3QYkdTm for ; Mon, 9 Feb 2009 06:34:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0C5963A6BA0 for ; Mon, 9 Feb 2009 06:34:31 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n19EYZVl025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 9 Feb 2009 15:34:35 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n19EYZh5000781 for ; Mon, 9 Feb 2009 15:34:35 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Feb 2009 15:34:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98AC3.8712EA6E" Date: Mon, 9 Feb 2009 16:35:23 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC : draft-ietf-dime-nai-routing-01.txt Thread-Index: AcmKw6RGDhqE4cg0R36/s5Lu9U/7SQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 09 Feb 2009 14:34:35.0299 (UTC) FILETIME=[877AAF30:01C98AC3] Subject: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 14:34:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98AC3.8712EA6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, this is a DIME Working Group Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-01.txt Please send your comments to the list by Feb 23, 2009. Ciao Hannes ------_=_NextPart_001_01C98AC3.8712EA6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC : draft-ietf-dime-nai-routing-01.txt

Hi all,

this is a DIME Working Group Last = Call for comments on

http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-01.t= xt

Please send your comments to the = list by Feb 23, 2009.

Ciao
Hannes

------_=_NextPart_001_01C98AC3.8712EA6E-- From vfajardo@tari.toshiba.com Mon Feb 9 10:24:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF30C3A69A3 for ; Mon, 9 Feb 2009 10:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JekqTo7OWMQq for ; Mon, 9 Feb 2009 10:24:43 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id CE3763A689A for ; Mon, 9 Feb 2009 10:24:42 -0800 (PST) Received: from [127.0.0.1] (smtp.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n19IKvbm040197; Mon, 9 Feb 2009 13:20:58 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <499074EA.7070502@tari.toshiba.com> Date: Mon, 09 Feb 2009 13:24:42 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Jari Arkko References: <49730194.1060207@piuha.net> <4973A419.5080508@piuha.net> <4986DDE7.1080400@piuha.net> In-Reply-To: <4986DDE7.1080400@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] review of rfc3588bis, pages 20 through 30 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 18:24:43 -0000 Hi Jari, Thanks for the continued review. > Continuing with my review... > >> The base Diameter protocol concerns itself with capabilities >> negotiation, how messages are sent and how peers may eventually be >> abandoned. > Here's a possibly better way to say this: "The base Diameter protocol > concerns itself with establishing connections to peers, capabilities > negotiation, how messages are sent and routed through peers, and how > the connections are eventually torn down." Ok > >> One AVP >> that is included to reference a user's session is the Session-Id. >> >> The initial request for authentication and/or authorization of a user >> would include the Session-Id. The Session-Id is then used in all >> subsequent messages to identify the user's session > I feel that the first sentence is unnecessary, given the remaining > explanations. Perhaps you could say: "The initial request for > authentication and/or authorization of a user would include the > Session-Id AVP. ..." Ok > >> Diameter Relays and redirect agents are, by definition, protocol >> transparent > application transparent? > > Section 2.3 talks about application Ids being advertised in > capabilities negotiation, and then Section 2.4 actually defines what > these IDs are and repeats the same story about capabilities > negotiation. Perhaps some reorganization of text would be useful here. How about re-wording the entire paragraph to: "Diameter Relays and redirect agents are transparent to the Diameter applications but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications." > >> Diameter implementations SHOULD be able to interpret ICMP protocol >> port unreachable messages as explicit indications that the server is >> not reachable, subject to security policy on trusting such messages. >> Diameter implementations SHOULD also be able to interpret a reset >> from the transport and timed-out connection attempts. If Diameter >> receives data up from TCP that cannot be parsed or identified as a >> Diameter error made by the peer, the stream is compromised and cannot >> be recovered. The transport connection MUST be closed using a RESET >> call (send a TCP RST bit) or an SCTP ABORT message (graceful closure >> is compromised). >> > > This text needs some softening, or perhaps you could add a reference > to some other work, e.g., "Further guidance regarding the treatment of > ICMP errors can be found in [draft-ietf-tcpm-icmp-attacks, > draft-ietf-tcpm-soft-errors]." The references should be informative. Ok. regards, victor > > Jari > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From jari.arkko@piuha.net Mon Feb 9 12:01:41 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2BD3A6C17 for ; Mon, 9 Feb 2009 12:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbEuh4ElVoWz for ; Mon, 9 Feb 2009 12:01:40 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 58A523A6C30 for ; Mon, 9 Feb 2009 12:01:36 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 681EB19872A; Mon, 9 Feb 2009 22:01:37 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 1D9C41986EE; Mon, 9 Feb 2009 22:01:37 +0200 (EET) Message-ID: <49908B57.4070502@piuha.net> Date: Mon, 09 Feb 2009 22:00:23 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Victor Fajardo References: <49730194.1060207@piuha.net> <4973A419.5080508@piuha.net> <4986DDE7.1080400@piuha.net> <499074EA.7070502@tari.toshiba.com> In-Reply-To: <499074EA.7070502@tari.toshiba.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dime@ietf.org Subject: Re: [Dime] review of rfc3588bis, pages 20 through 30 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 20:01:41 -0000 Victor, > > How about re-wording the entire paragraph to: > > "Diameter Relays and redirect agents are transparent to the Diameter > applications but they MUST support the Diameter base protocol, which > includes accounting, and all Diameter applications." OK Jari From glenzorn@comcast.net Tue Feb 10 19:38:27 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C2F3A69F8 for ; Tue, 10 Feb 2009 19:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxViYEcYJLiP for ; Tue, 10 Feb 2009 19:38:26 -0800 (PST) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 9C6473A680D for ; Tue, 10 Feb 2009 19:38:26 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id ECJB1b0060EPchoA7TeXdN; Wed, 11 Feb 2009 03:38:31 +0000 Received: from gwzPC ([124.121.211.131]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id ETeC1b00C2qfE1Y8MTeJR8; Wed, 11 Feb 2009 03:38:29 +0000 From: "Glen Zorn" To: References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> Date: Wed, 11 Feb 2009 10:37:58 +0700 Message-ID: <001f01c98bfa$2ce09390$86a1bab0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C98C34.D93F6B90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmKw6RGDhqE4cg0R36/s5Lu9U/7SQBNYKqQ Content-Language: en-us Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 03:38:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01C98C34.D93F6B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I must admit that I am extremely confused by this document: first, I don't understand why it even exists, since basically all it says is to follow RFC 4282 & second (and this has me really confused) the claim is made that it is somehow incompatible w/RFC 3588 routing. I suppose that might be true if one were to take 3588 in a vacuum (how is that possible?), but in combination with 4282 it's rather painfully obvious that the only way to handle decorated NAIs in Diameter is the way discussed in the draft. So what is the point? ------=_NextPart_000_0020_01C98C34.D93F6B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WGLC : draft-ietf-dime-nai-routing-01.txt

I must admit that I am extremely confused by this = document: first, I don't understand why it even exists, since basically all it = says is to follow RFC 4282 & second (and this has me really confused) = the claim is made that it is somehow incompatible w/RFC 3588 routing.  I = suppose that might be true if one were to take 3588 in a vacuum (how is that = possible?), but in combination with 4282 it's rather painfully obvious that the only = way to handle decorated NAIs in Diameter is the way discussed in the = draft.  So what is the point?

------=_NextPart_000_0020_01C98C34.D93F6B90-- From dromasca@avaya.com Wed Feb 11 00:53:51 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F203A684D; Wed, 11 Feb 2009 00:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp2hBYeCAf0k; Wed, 11 Feb 2009 00:53:50 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7AB1E3A67C1; Wed, 11 Feb 2009 00:53:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,191,1233550800"; d="scan'208";a="161057675" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Feb 2009 03:53:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Feb 2009 03:53:53 -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 Date: Wed, 11 Feb 2009 09:53:30 +0100 Message-ID: In-Reply-To: <2421D12A-7BBE-4148-8D3D-8843E6E8305F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-jones-dime-3gpp-eps-command-codes (DiameterCommand Code Registration for Third Generation PartnershipProject (3GPP) Evolved Packet System (EPS)) to Informational RFC Thread-Index: AcmL+LhBQTgSDkJpSIORds6s/Vci1gALNOFg References: <20090205141701.0E5883A69E6@core3.amsl.com> <2421D12A-7BBE-4148-8D3D-8843E6E8305F@cisco.com> From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" , Cc: dime@ietf.org Subject: Re: [Dime] Last Call: draft-jones-dime-3gpp-eps-command-codes (DiameterCommand Code Registration for Third Generation PartnershipProject (3GPP) Evolved Packet System (EPS)) to Informational RFC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 08:53:51 -0000 Cullen, The current allocation policy is defined by RFC 3588, section 11.2.1 which indeed makes no distinction between permanent, standard commands and vendor-specific command codes and requires IETF consensus for all. This will be fixed by http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-15.txt but until this document is approved we are trying to answer the requests coming from other SDOs (3GPP in this case) according to the existing IANA registration process.=20 Dan > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Wednesday, February 11, 2009 5:28 AM > To: ietf@ietf.org > Subject: Re: Last Call:=20 > draft-jones-dime-3gpp-eps-command-codes (DiameterCommand Code=20 > Registration for Third Generation PartnershipProject (3GPP)=20 > Evolved Packet System (EPS)) to Informational RFC >=20 >=20 > My understanding is that this registry requires "IETF=20 > Consensus" as defined in 2434. However, theses registration=20 > are being defined by 3GPP TS 29.272 which does not have IETF=20 > Consensus. If the DIME community wishes to allow=20 > registrations like this, why not update the IANA registration=20 > process to be "Specification Required"? >=20 >=20 > On Feb 5, 2009, at 7:17 AM, The IESG wrote: >=20 > > The IESG has received a request from an individual submitter to=20 > > consider the following document: > > > > - 'Diameter Command Code Registration for Third Generation=20 > Partnership > > Project (3GPP) Evolved Packet System (EPS) ' > > as an=20 > Informational=20 > > RFC > > > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send substantive comments to=20 > > the ietf@ietf.org mailing lists by 2009-03-05.=20 > Exceptionally, comments=20 > > may be sent to iesg@ietf.org instead. In either case, please retain=20 > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > >=20 > http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps-command- > > codes-01.txt > > > > > > IESG discussion can be tracked via > >=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > > g=3D18081&rfc_flag=3D0 > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From hannes.tschofenig@nsn.com Thu Feb 12 01:38:42 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4F83A6AA4 for ; Thu, 12 Feb 2009 01:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1euV8zCr6DmH for ; Thu, 12 Feb 2009 01:38:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 2A4203A6A49 for ; Thu, 12 Feb 2009 01:38:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1C9cikD003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Feb 2009 10:38:44 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1C9ci88017993 for ; Thu, 12 Feb 2009 10:38:44 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 10:38:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 11:39:33 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010AE593@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Virtual Interim Meeting Thread-Index: AcmM9c9mSWMFtSEzToK5B9D6oOSO4A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Feb 2009 09:38:43.0877 (UTC) FILETIME=[B20BE550:01C98CF5] Subject: [Dime] DIME Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:38:42 -0000 Hi all,=20 I put all the information about the phone conference on one place, namely on our Wiki: http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge Please take a look at it.=20 Ciao Hannes From hannes.tschofenig@nsn.com Thu Feb 12 01:42:30 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAB8C3A6AA4 for ; Thu, 12 Feb 2009 01:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvu-iHjGgZjE for ; Thu, 12 Feb 2009 01:42:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 515A03A685A for ; Thu, 12 Feb 2009 01:42:29 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1C9gX16016239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 12 Feb 2009 10:42:33 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1C9gTPf032504 for ; Thu, 12 Feb 2009 10:42:32 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 10:42:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C98CF6.3994E1E7" Date: Thu, 12 Feb 2009 11:43:22 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45010AE5A5@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DIME Virtual Interim Meeting: AGENDA! Thread-Index: AcmM9lglcloSCVodTfCl3wUTMBQOLA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Feb 2009 09:42:32.0101 (UTC) FILETIME=[3A141D50:01C98CF6] Subject: [Dime] DIME Virtual Interim Meeting: AGENDA! X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 09:42:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C98CF6.3994E1E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You can also find the agenda on our Wiki: http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge ------_=_NextPart_001_01C98CF6.3994E1E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIME Virtual Interim Meeting: AGENDA!

You can also find the agenda on = our Wiki:
http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge=


------_=_NextPart_001_01C98CF6.3994E1E7-- From stefan.winter@restena.lu Tue Feb 17 02:22:51 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C82A28C150 for ; Tue, 17 Feb 2009 02:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTFpZYcsND+v for ; Tue, 17 Feb 2009 02:22:50 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [158.64.1.34]) by core3.amsl.com (Postfix) with ESMTP id 9039F28C14F for ; Tue, 17 Feb 2009 02:22:50 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 872CBA98B2; Tue, 17 Feb 2009 11:23:00 +0100 (CET) Received: from [158.64.1.155] (aragorn.restena.lu [158.64.1.155]) by legolas.restena.lu (Postfix) with ESMTPA id 7AE60AF03E; Tue, 17 Feb 2009 11:23:00 +0100 (CET) Message-ID: <499A9004.5080305@restena.lu> Date: Tue, 17 Feb 2009 11:23:00 +0100 From: Stefan Winter User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:22:51 -0000 Hi, > Please send your comments to the list by Feb 23, 2009. > This revision looks better than the previous one. Most points of my original review of -00 were adressed (and the rest is so minor that I don't care). One point in my original review still stands though (quoting myself): "The mechanisms in this document have such a wide-reaching use that I would much rather recommend to put it into 3588bis and require it also for existing Apps." This draft does little more than state that 3588 was ambiguous, clarifies it and updates the NAI reference. There is ongoing work on 3588bis which could easily achieve the same result with just a few sentences, be standards-track and binding for all Diameter apps. Going all the way for an own RFC looks like overkill to me. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From tena@huawei.com Tue Feb 17 02:33:08 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 733A23A6B00 for ; Tue, 17 Feb 2009 02:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ana+D-rIFuzu for ; Tue, 17 Feb 2009 02:33:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0A1913A65A5 for ; Tue, 17 Feb 2009 02:33:07 -0800 (PST) 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 <0KF700GFRHBFE8@szxga03-in.huawei.com> for dime@ietf.org; Tue, 17 Feb 2009 18:33:16 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF700HLVHBFEO@szxga03-in.huawei.com> for dime@ietf.org; Tue, 17 Feb 2009 18:33:15 +0800 (CST) Received: from [192.168.5.101] (100.61.18.218.broad.sz.gd.dynamic.163data.com.cn [218.18.61.100]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KF700J10HBAL1@szxml02-in.huawei.com>; Tue, 17 Feb 2009 18:33:15 +0800 (CST) Date: Tue, 17 Feb 2009 18:33:10 +0800 From: Tina TSOU In-reply-to: <499A9004.5080305@restena.lu> To: Stefan Winter Message-id: <0DD4FF9B-AAFB-42D8-8AF8-032FDDB3524A@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: multipart/alternative; boundary="Boundary_(ID_XKE55vd6Kvukyx7oqrTnYQ)" References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu> Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:33:08 -0000 --Boundary_(ID_XKE55vd6Kvukyx7oqrTnYQ) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi, I'm happy with the current version of the document and that the document is ready for the IESG. B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_XKE55vd6Kvukyx7oqrTnYQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi,
I'm happy with the current version of the document and that the document is ready for the IESG.
--Boundary_(ID_XKE55vd6Kvukyx7oqrTnYQ)-- From hannes.tschofenig@nsn.com Tue Feb 17 05:04:14 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33BEA3A6B52 for ; Tue, 17 Feb 2009 05:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpp7Y+zZ4d55 for ; Tue, 17 Feb 2009 05:04:13 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 28AB63A6A97 for ; Tue, 17 Feb 2009 05:04:12 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n1HD4McI026633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Feb 2009 14:04:22 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n1HD4M3J032557; Tue, 17 Feb 2009 14:04:22 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 14:04:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 15:05:15 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> In-Reply-To: <499A9004.5080305@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt Thread-Index: AcmQ6bib4VUjpLXJRCGFENvjCefIIAAFpDSg References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Stefan Winter" X-OriginalArrivalTime: 17 Feb 2009 13:04:21.0124 (UTC) FILETIME=[3FAF2440:01C99100] Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 13:04:14 -0000 Hi Stefan,=20 We took this approach into consideration earlier but the group did not = want to put this functionality into RFC3588bis.=20 Hence, a separate document was created.=20 Ciao Hannes =20 >-----Original Message----- >From: ext Stefan Winter [mailto:stefan.winter@restena.lu]=20 >Sent: 17 February, 2009 12:23 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: dime@ietf.org >Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt > >Hi, > >> Please send your comments to the list by Feb 23, 2009. >> > >This revision looks better than the previous one. Most points=20 >of my original review of -00 were adressed (and the rest is so=20 >minor that I don't care). One point in my original review=20 >still stands though (quoting myself): > >"The mechanisms in this document have such a wide-reaching use=20 >that I would much rather recommend to put it into 3588bis and=20 >require it also for existing Apps." > >This draft does little more than state that 3588 was=20 >ambiguous, clarifies it and updates the NAI reference. There=20 >is ongoing work on 3588bis which could easily achieve the same=20 >result with just a few sentences, be standards-track and=20 >binding for all Diameter apps. Going all the way for an own=20 >RFC looks like overkill to me. > >Greetings, > >Stefan Winter > >-- >Stefan WINTER >Ingenieur de Recherche >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 >Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi >L-1359 Luxembourg > >Tel: +352 424409 1 >Fax: +352 422473 > > From glenzorn@comcast.net Tue Feb 17 05:29:58 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A280F3A6949 for ; Tue, 17 Feb 2009 05:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UarJwEBQSVFd for ; Tue, 17 Feb 2009 05:29:57 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id B61763A6822 for ; Tue, 17 Feb 2009 05:29:57 -0800 (PST) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id H0dP1b00D0cQ2SLA51W9mV; Tue, 17 Feb 2009 13:30:09 +0000 Received: from gwzPC ([124.121.211.18]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id H1Vs1b0010QNFrQ8W1VxfM; Tue, 17 Feb 2009 13:30:07 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Stefan Winter'" References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu> <3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> Date: Tue, 17 Feb 2009 20:29:45 +0700 Message-ID: <038401c99103$d6c2f480$8448dd80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmQ6bib4VUjpLXJRCGFENvjCefIIAAFpDSgAACxEdA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 13:29:58 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: > Hi Stefan, >=20 > We took this approach into consideration earlier but the group did not > want to put this functionality into RFC3588bis. As I mentioned in my review, I can't find any functionality in this document; at best, it's just making even more obvious what should = already be painfully so from reading RFCs 3588 & 4282. Therefore, I've got to = agree with Stefan: unless I'm missing something huge, this is at most a clarification & belongs in 3588bis. > Hence, a separate document was created. >=20 > Ciao > Hannes >=20 >=20 > >-----Original Message----- > >From: ext Stefan Winter [mailto:stefan.winter@restena.lu] > >Sent: 17 February, 2009 12:23 > >To: Tschofenig, Hannes (NSN - FI/Espoo) > >Cc: dime@ietf.org > >Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt > > > >Hi, > > > >> Please send your comments to the list by Feb 23, 2009. > >> > > > >This revision looks better than the previous one. Most points > >of my original review of -00 were adressed (and the rest is so > >minor that I don't care). One point in my original review > >still stands though (quoting myself): > > > >"The mechanisms in this document have such a wide-reaching use > >that I would much rather recommend to put it into 3588bis and > >require it also for existing Apps." > > > >This draft does little more than state that 3588 was > >ambiguous, clarifies it and updates the NAI reference. There > >is ongoing work on 3588bis which could easily achieve the same > >result with just a few sentences, be standards-track and > >binding for all Diameter apps. Going all the way for an own > >RFC looks like overkill to me. > > > >Greetings, > > > >Stefan Winter > > > >-- > >Stefan WINTER > >Ingenieur de Recherche > >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education > >Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > >L-1359 Luxembourg > > > >Tel: +352 424409 1 > >Fax: +352 422473 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Mark.Jones@bridgewatersystems.com Tue Feb 17 07:26:50 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF92C3A697D for ; Tue, 17 Feb 2009 07:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+7leIvVsU2D for ; Tue, 17 Feb 2009 07:26:50 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id EA6623A68E1 for ; Tue, 17 Feb 2009 07:26:49 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Tue, 17 Feb 2009 10:27:00 -0500 From: Mark Jones To: "dime@ietf.org" Date: Tue, 17 Feb 2009 10:26:58 -0500 Thread-Topic: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt Thread-Index: AcmQ6zPNRPRF3cobSJ6RnOPxGu4DEgAKI/HQ Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu> <0DD4FF9B-AAFB-42D8-8AF8-032FDDB3524A@huawei.com> In-Reply-To: <0DD4FF9B-AAFB-42D8-8AF8-032FDDB3524A@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D6824C8074596B4E9CA38F6A62454F5C0A3332EB18exchange02bri_" MIME-Version: 1.0 Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:26:51 -0000 --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332EB18exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here. Ship it. ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tin= a TSOU Sent: February 17, 2009 04:33 To: Stefan Winter Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt Hi, I'm happy with the current version of the document and that the document is= ready for the IESG. B. R. Tina http://tinatsou.weebly.com/contact.html --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332EB18exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Same=20 here. Ship it.

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Tina TSOU
Sent:<= /B>=20 February 17, 2009 04:33
To: Stefan Winter
Cc:=20 dime@ietf.org
Subject: Re: [Dime] WGLC :=20 draft-ietf-dime-nai-routing-01.txt

Hi,
I'm happy with the current version of the document and that= the=20 document is ready for the IESG.

B. R.
Tina
http://tinatsou.weebly.c= om/contact.html

--_000_D6824C8074596B4E9CA38F6A62454F5C0A3332EB18exchange02bri_-- From lionel.morand@orange-ftgroup.com Tue Feb 17 07:41:25 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503043A68F0 for ; Tue, 17 Feb 2009 07:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzjbWDiU+mMP for ; Tue, 17 Feb 2009 07:41:24 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id D02403A68E1 for ; Tue, 17 Feb 2009 07:41:21 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 16:41:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99116.2B5D540A" Date: Tue, 17 Feb 2009 16:41:12 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A32@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt Thread-Index: AcmQ6zPNRPRF3cobSJ6RnOPxGu4DEgAKI/HQAABvqdA= References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net><499A9004.5080305@restena.lu><0DD4FF9B-AAFB-42D8-8AF8-032FDDB3524A@huawei.com> From: To: X-OriginalArrivalTime: 17 Feb 2009 15:41:14.0038 (UTC) FILETIME=[2A37D560:01C99116] Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:41:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99116.2B5D540A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 The last version of draft captured all my previous comments/concerns et = is ready for me me for IESG evaluation and RFC publication. =20 BR, =20 Lionel ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de = Mark Jones Envoy=E9 : mardi 17 f=E9vrier 2009 16:27 =C0 : dime@ietf.org Objet : Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt =09 =09 Same here. Ship it. ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of Tina TSOU Sent: February 17, 2009 04:33 To: Stefan Winter Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt =09 =09 =09 Hi, I'm happy with the current version of the document and that the = document is ready for the IESG.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 B. R. Tina http://tinatsou.weebly.com/contact.html ------_=_NextPart_001_01C99116.2B5D540A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The=20 last version of draft captured all my previous comments/concerns et is = ready for=20 me me for IESG evaluation and RFC publication.
 
BR,
 
Lionel

De : dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] De la part de Mark=20 Jones
Envoy=E9 : mardi 17 f=E9vrier 2009 = 16:27
=C0 :=20 dime@ietf.org
Objet : Re: [Dime] WGLC :=20 draft-ietf-dime-nai-routing-01.txt

Same=20 here. Ship it.

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 February 17, 2009 04:33
To: Stefan Winter
Cc:=20 dime@ietf.org
Subject: Re: [Dime] WGLC :=20 draft-ietf-dime-nai-routing-01.txt

Hi,
I'm happy with the current version of the document and = that=20 the document is ready for the IESG.=20

B. R.
Tina
http://tinatsou.weebly.c= om/contact.html
=
------_=_NextPart_001_01C99116.2B5D540A-- From lionel.morand@orange-ftgroup.com Tue Feb 17 08:05:29 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5733A6870 for ; Tue, 17 Feb 2009 08:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9RcIrS9EBh7 for ; Tue, 17 Feb 2009 08:05:29 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 7DC293A6CA0 for ; Tue, 17 Feb 2009 08:05:28 -0800 (PST) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Feb 2009 17:05:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 17:05:27 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A41@ftrdmel2> In-Reply-To: <038401c99103$d6c2f480$8448dd80$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt Thread-Index: AcmQ6bib4VUjpLXJRCGFENvjCefIIAAFpDSgAACxEdAABOXRMA== References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu><3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> <038401c99103$d6c2f480$8448dd80$@net> From: To: , , X-OriginalArrivalTime: 17 Feb 2009 16:05:26.0678 (UTC) FILETIME=[8C0F1B60:01C99119] Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:05:29 -0000 Hi Glen and Stefan, I can just acknowledge what it is said in this draft. The initial proposal was to put this material inside the RFC3588bis = document. But it was decided to let it out and to go for a stand-alone = document that could be see as as a RFC3588bis's companion document. If I remember correctly, the motivation for this path was the potential = backward compatibility issue with pre-existing Diameter implementations = that might not support the Decorated NAI. And the objectives of the = RFC3588bis was to minimize this kind of impacts. But at least, I'm glad with the fact that the content of the draft seems = right, clear and even obvious ;) BR, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Glen Zorn > Envoy=E9 : mardi 17 f=E9vrier 2009 14:30 > =C0 : 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ext Stefan Winter' > Cc : dime@ietf.org > Objet : Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt >=20 > Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] > writes: >=20 > > Hi Stefan, > >=20 > > We took this approach into consideration earlier but the=20 > group did not=20 > > want to put this functionality into RFC3588bis. >=20 > As I mentioned in my review, I can't find any functionality=20 > in this document; at best, it's just making even more obvious=20 > what should already be painfully so from reading RFCs 3588 &=20 > 4282. Therefore, I've got to agree with Stefan: unless I'm=20 > missing something huge, this is at most a clarification &=20 > belongs in 3588bis. >=20 > > Hence, a separate document was created. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > >-----Original Message----- > > >From: ext Stefan Winter [mailto:stefan.winter@restena.lu] > > >Sent: 17 February, 2009 12:23 > > >To: Tschofenig, Hannes (NSN - FI/Espoo) > > >Cc: dime@ietf.org > > >Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt > > > > > >Hi, > > > > > >> Please send your comments to the list by Feb 23, 2009. > > >> > > > > > >This revision looks better than the previous one. Most=20 > points of my=20 > > >original review of -00 were adressed (and the rest is so=20 > minor that I=20 > > >don't care). One point in my original review still stands though=20 > > >(quoting myself): > > > > > >"The mechanisms in this document have such a wide-reaching=20 > use that I=20 > > >would much rather recommend to put it into 3588bis and require it=20 > > >also for existing Apps." > > > > > >This draft does little more than state that 3588 was ambiguous,=20 > > >clarifies it and updates the NAI reference. There is=20 > ongoing work on=20 > > >3588bis which could easily achieve the same result with just a few=20 > > >sentences, be standards-track and binding for all Diameter apps.=20 > > >Going all the way for an own RFC looks like overkill to me. > > > > > >Greetings, > > > > > >Stefan Winter > > > > > >-- > > >Stefan WINTER > > >Ingenieur de Recherche > > >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20 > Nationale=20 > > >et de la Recherche 6, rue Richard Coudenhove-Kalergi > > >L-1359 Luxembourg > > > > > >Tel: +352 424409 1 > > >Fax: +352 422473 > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From sdecugis@nict.go.jp Tue Feb 17 18:17:52 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B19C3A6804 for ; Tue, 17 Feb 2009 18:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4Kxw1E8Xha1 for ; Tue, 17 Feb 2009 18:17:51 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 3F7033A6941 for ; Tue, 17 Feb 2009 18:17:51 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n1I2EFpn013133 for ; Wed, 18 Feb 2009 11:14:15 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n1I2EFJu003904 for ; Wed, 18 Feb 2009 11:14:15 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n1I2EFmG003901 for ; Wed, 18 Feb 2009 11:14:15 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id BE9FB6F34 for ; Wed, 18 Feb 2009 11:14:14 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id 9BCEE6F14 for ; Wed, 18 Feb 2009 11:14:14 +0900 (JST) Message-ID: <499B6EE4.1080002@nict.go.jp> Date: Wed, 18 Feb 2009 11:13:56 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: dime@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu><3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> <038401c99103$d6c2f480$8448dd80$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A41@ftrdmel2> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A41@ftrdmel2> X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:17:52 -0000 Hello, lionel.morand@orange-ftgroup.com a écrit : > If I remember correctly, the motivation for this path was the potential backward compatibility issue with pre-existing Diameter implementations that might not support the Decorated NAI. And the objectives of the RFC3588bis was to minimize this kind of impacts. > In this case, I guess the situation is worth re-examination, since it looks like rfc3588bis will not be backward-compatible with 3588 anyway (hence the proposal from Victor to bump the version number in the protocol). I would believe the most important question is: is the support for this feature optional or mandatory for Diameter implementations? That should direct the choice of creating a separate RFC or merging in 3588bis.... My 2 cents... Sebastien. From tena@huawei.com Wed Feb 18 01:11:31 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE303A68DD for ; Wed, 18 Feb 2009 01:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvJMh+c-4DLL for ; Wed, 18 Feb 2009 01:11:30 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3BFD53A6920 for ; Wed, 18 Feb 2009 01:11:30 -0800 (PST) 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 <0KF900K7A87719@szxga01-in.huawei.com> for dime@ietf.org; Wed, 18 Feb 2009 17:11:31 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KF9004FK877KN@szxga01-in.huawei.com> for dime@ietf.org; Wed, 18 Feb 2009 17:11:31 +0800 (CST) Received: from [192.168.5.101] (100.61.18.218.broad.sz.gd.dynamic.163data.com.cn [218.18.61.100]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KF900C9187646@szxml02-in.huawei.com> for dime@ietf.org; Wed, 18 Feb 2009 17:11:31 +0800 (CST) Date: Wed, 18 Feb 2009 17:11:30 +0800 From: Tina TSOU To: dime@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Subject: [Dime] slides for diameter routing in Diameter Virtual Interim Meeting and DT Work X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 09:11:31 -0000 http://groups.google.com/group/diameter-routing/browse_thread/thread/bf7bfd6a7b45767a?hl=en B. R. Tina http://tinatsou.weebly.com/contact.html From jouni.nospam@gmail.com Wed Feb 18 03:59:47 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EA23A68CD for ; Wed, 18 Feb 2009 03:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcV81n-eoTrm for ; Wed, 18 Feb 2009 03:59:46 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 14EE93A6805 for ; Wed, 18 Feb 2009 03:59:45 -0800 (PST) Received: by ewy14 with SMTP id 14so2666280ewy.13 for ; Wed, 18 Feb 2009 03:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=hIj7NfBIgmb9mT4XdbCVrRfHaK8DRvrAYReLdPfUDws=; b=eDs2sEtwE2LzxRtG+/GgcyXRdQON9dSXHgcG1ro7F+9y5uxjTDhVVZFlwuYqoLqlyp mKaxV5xTKrmZDTIk67FofF9ZdwFa0oyDzRroE+thdTmXUpTT6GJJ9Z6hPuIXEMRe1GyN geKvnCni9urpNI9y+wqO6AcNVXzh4eNjrOWpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=lSBErQ16p5wSu1u3I9AynO9ie0daNSeMvKM8FiVJzlDWGiBS9vwfkk+o8fodpNMrbd 1OZCYZr27fNzsVJb0OwCT9rJUccv6KLsoElKktkw9CAUsbSdV706TYmLoDxVG151ET95 4mZydHcdjnY17SIAICNZ1JRLwCrRFRmDrq4cE= Received: by 10.211.196.13 with SMTP id y13mr4626898ebp.171.1234958395765; Wed, 18 Feb 2009 03:59:55 -0800 (PST) Received: from ?10.183.180.60? ([192.100.124.156]) by mx.google.com with ESMTPS id i7sm10944979nfh.66.2009.02.18.03.59.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 03:59:55 -0800 (PST) Message-Id: <152982B9-E1AB-4780-84E6-F993FEB8ACB3@gmail.com> From: jouni korhonen To: Sebastien Decugis In-Reply-To: <499B6EE4.1080002@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 13:59:52 +0200 References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu><3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> <038401c99103$d6c2f480$8448dd80$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A41@ftrdmel2> <499B6EE4.1080002@nict.go.jp> X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:59:47 -0000 Hi, On Feb 18, 2009, at 4:13 AM, Sebastien Decugis wrote: > Hello, > > lionel.morand@orange-ftgroup.com a =E9crit : >> If I remember correctly, the motivation for this path was the =20 >> potential backward compatibility issue with pre-existing Diameter =20 >> implementations that might not support the Decorated NAI. And the =20 >> objectives of the RFC3588bis was to minimize this kind of impacts. >> > > In this case, I guess the situation is worth re-examination, since it > looks like rfc3588bis will not be backward-compatible with 3588 anyway > (hence the proposal from Victor to bump the version number in the =20 > protocol). > > I would believe the most important question is: is the support for =20 > this > feature optional or mandatory for Diameter implementations? That =20 > should > direct the choice of creating a separate RFC or merging in 3588bis.... > Due my ultimate xml skills the -01 draft does not show that also =20 rfc3588 is in the "updates" list of affected documents. As Glen's =20 detailed review pointed out, the changes this draft proposes are =20 straight forward. There are few points why the draft exists. One, =20 rfc3588 is ambiguous related to aspects what the draft clarifies (and =20= also picks up one decoration approach of several possibilities that =20 rfc4282 has). Second, the draft allows small incremental upgrade to =20 rfc3588 (with clearly pointed out backwards compatibility concerns) =20 without mandating a full rfc3588bis changes. This was envisioned to be =20= easier approach as we can maintain full rfc3588 backwards =20 compatibility, except in cases where the draft's solution is =20 explicitly referenced (i.e. per application within a deployment). =20 Third, it was earlier asked to implement the draft content to =20 rfc3588bis. We were advised to make a separate draft to keep =20 rfc3588bis request routing part intact compared to rfc3588. I am more =20= than happy to implement the draft's solution as a mandatory feature to =20= rfc3588bis. I would still need a solution for rfc3588 during the =20 migration period. Cheers, Jouni > My 2 cents... > Sebastien. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From Hannes.Tschofenig@gmx.net Wed Feb 18 07:51:35 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E346E3A69ED for ; Wed, 18 Feb 2009 07:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-1.381, BAYES_05=-1.11, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScpItxvP8GyO for ; Wed, 18 Feb 2009 07:51:35 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 34BB73A690B for ; Wed, 18 Feb 2009 07:51:31 -0800 (PST) Received: (qmail invoked by alias); 18 Feb 2009 15:51:43 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.124.156] by mail.gmx.net (mp054) with SMTP; 18 Feb 2009 16:51:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX191rJV0+hZ1oIw+20TxG5C+N8dFFFmm7PEb1qKK/s B2/SMrHlyfL+R1 From: "Hannes Tschofenig" To: Date: Wed, 18 Feb 2009 17:52:40 +0200 Message-ID: <006401c991e0$ef145a00$93b4b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmM9lglcloSCVodTfCl3wUTMBQOLAE6aSDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [Dime] REMINDER: DIME Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:51:36 -0000 Date: 19th February, 8PM PST Conference Bridge: Number: +1 (712) 432-1100 PIN: 292812# Webex and Agenda: http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge From vfajardo@tari.toshiba.com Wed Feb 18 10:29:22 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88563A6999 for ; Wed, 18 Feb 2009 10:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM0GTWjnLukA for ; Wed, 18 Feb 2009 10:29:22 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id D90533A6917 for ; Wed, 18 Feb 2009 10:29:21 -0800 (PST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n1IIPMKC048203; Wed, 18 Feb 2009 13:25:22 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <499C538C.4040700@tari.toshiba.com> Date: Wed, 18 Feb 2009 13:29:32 -0500 From: Victor Fajardo User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Sebastien Decugis References: <3D3C75174CB95F42AD6BCC56E5555B4501081CF1@FIESEXC015.nsn-intra.net> <499A9004.5080305@restena.lu><3D3C75174CB95F42AD6BCC56E5555B4501102BE5@FIESEXC015.nsn-intra.net> <038401c99103$d6c2f480$8448dd80$@net> <7DBAFEC6A76F3E42817DF1EBE64CB026063A0A41@ftrdmel2> <499B6EE4.1080002@nict.go.jp> In-Reply-To: <499B6EE4.1080002@nict.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:29:22 -0000 Hi, > Hello, > > lionel.morand@orange-ftgroup.com a écrit : > >> If I remember correctly, the motivation for this path was the potential backward compatibility issue with pre-existing Diameter implementations that might not support the Decorated NAI. And the objectives of the RFC3588bis was to minimize this kind of impacts. >> >> > > In this case, I guess the situation is worth re-examination, since it > looks like rfc3588bis will not be backward-compatible with 3588 anyway > (hence the proposal from Victor to bump the version number in the protocol). > To me, it seems that decorated NAI is something specific to certain deployment situations. There are a lot of things in bis that remain generalized specifically because it is a "base" protocol. Adding specific solutions for specific scenarios into bis is probably not a good choice ... obviously because the list of specific items is exponential. We would also like to retain a certain level of modularity and this is why we have diameter extensibility. > I would believe the most important question is: is the support for this > feature optional or mandatory for Diameter implementations? That should > direct the choice of creating a separate RFC or merging in 3588bis.... > I doubt that this should be a mandated feature for all implementations but certain aspects of this functionality can be mandated within the scope of this document and hence required by the implementations that support this document. regards, victor > My 2 cents... > Sebastien. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > From rfc-editor@rfc-editor.org Wed Feb 18 11:43:09 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1373A6AC4; Wed, 18 Feb 2009 11:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.31 X-Spam-Level: X-Spam-Status: No, score=-16.31 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pa24RNEQ6AE; Wed, 18 Feb 2009 11:43:09 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 119D83A6AE3; Wed, 18 Feb 2009 11:43:09 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id CC98C227000; Wed, 18 Feb 2009 11:42:58 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090218194258.CC98C227000@bosco.isi.edu> Date: Wed, 18 Feb 2009 11:42:58 -0800 (PST) Cc: dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 5447 on Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:43:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5447 Title: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction Author: J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury Status: Standards Track Date: February 2009 Mailbox: jouni.nospam@gmail.com, julien.bournelle@orange-ftgroup.com, Hannes.Tschofenig@nsn.com, charliep@wichorus.com, kchowdhury@starentnetworks.com Pages: 17 Characters: 38656 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-mip6-integrated-12.txt URL: http://www.rfc-editor.org/rfc/rfc5447.txt A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication, Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network Access Server to home AAA server interface. [STANDARDS TRACK] This document is a product of the Diameter Maintanence and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From Hannes.Tschofenig@gmx.net Thu Feb 19 07:25:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712153A6B08 for ; Thu, 19 Feb 2009 07:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6qCemfUmgcM for ; Thu, 19 Feb 2009 07:25:39 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3319F3A6915 for ; Thu, 19 Feb 2009 07:25:39 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2009 15:25:51 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 19 Feb 2009 16:25:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1910ihXKq11aloV4MFDI6qhKeostYTSvYetFpF05u db5b+jbdY721gi From: "Hannes Tschofenig" To: Date: Thu, 19 Feb 2009 17:26:45 +0200 Message-ID: <000e01c992a6$7adf70e0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C992B7.3E6840E0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmSomI2KbvmYCseQIy9xMwiXQcNow== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67,0.67 Subject: [Dime] Code Sprint X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:25:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C992B7.3E6840E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Russ has been organizing code sprints for a couple of IETF meetings now. The latest event was announced here: http://www.mail-archive.com/ietf-announce@ietf.org/msg05656.html Within the GEOPRIV working group we have used this event to play around with code as well. We met on Saturday morning before the IETF meeting started and tested various implementations of the protocols we developed within the working group. This was always a lot of fun. Now, I was wondering whether someone from this group is already in San Francisco on Saturday and would like todo a bit of coding. Drop me a mail if you are interested. Remore participation is also possible. Ciao Hannes ------=_NextPart_000_000F_01C992B7.3E6840E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Code Sprint

Hi all,

Russ has been organizing code = sprints for a couple of IETF meetings now. The latest event was = announced here:
http://www.mail-archive.com/ietf-announce@ietf.org/msg05656.html

Within the GEOPRIV working group = we have used this event to play around with code as well. We met on = Saturday morning before the IETF meeting started and tested various = implementations of the protocols we developed within the working group. = This was always a lot of fun.

Now, I was wondering whether = someone from this group is already in San Francisco on Saturday and = would like todo a bit of coding. Drop me a mail if you are interested. = Remore participation is also possible. 

Ciao
Hannes



------=_NextPart_000_000F_01C992B7.3E6840E0-- From mdolly@att.com Thu Feb 19 08:13:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D1228C0FE for ; Thu, 19 Feb 2009 08:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mzodwrzhfmz for ; Thu, 19 Feb 2009 08:13:23 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 233A93A6B84 for ; Thu, 19 Feb 2009 08:13:23 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-129.messagelabs.com!1235060014!29181374!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23956 invoked from network); 19 Feb 2009 16:13:35 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-8.tower-129.messagelabs.com with AES256-SHA encrypted SMTP; 19 Feb 2009 16:13:35 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1JGDYOk018642; Thu, 19 Feb 2009 11:13:34 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n1JGDXM3018629; Thu, 19 Feb 2009 11:13:33 -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 Date: Thu, 19 Feb 2009 11:13:32 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0264EF3E@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <006401c991e0$ef145a00$93b4b70a@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] REMINDER: DIME Virtual Interim Meeting Thread-Index: AcmM9lglcloSCVodTfCl3wUTMBQOLAE6aSDgADM9flA= References: <006401c991e0$ef145a00$93b4b70a@nsnintra.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Hannes Tschofenig" , Subject: Re: [Dime] REMINDER: DIME Virtual Interim Meeting X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:13:23 -0000 Where is the host? -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Wednesday, February 18, 2009 10:53 AM To: dime@ietf.org Subject: [Dime] REMINDER: DIME Virtual Interim Meeting Date:=20 19th February, 8PM PST Conference Bridge:=20 Number: +1 (712) 432-1100=20 PIN: 292812# Webex and Agenda:=20 http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From Hannes.Tschofenig@gmx.net Thu Feb 19 08:14:10 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B96E3A6B93 for ; Thu, 19 Feb 2009 08:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-KJX52cQosk for ; Thu, 19 Feb 2009 08:14:09 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7113A28B23E for ; Thu, 19 Feb 2009 08:14:09 -0800 (PST) Received: (qmail invoked by alias); 19 Feb 2009 16:14:22 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 19 Feb 2009 17:14:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX186uIQ2VXs6gPXbweQ++WqVFqflaCD213vXGcBDrJ RbOjLVuI8JVNIz From: "Hannes Tschofenig" To: Date: Thu, 19 Feb 2009 18:15:18 +0200 Message-ID: <001d01c992ad$41ed5480$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmSrUE1o4ATpAX2TL2lhMZeVlTuOA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 Subject: [Dime] Slides X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:14:10 -0000 I uploaded a few slides already to http://tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge. I add more as I receive them at hannes.tschofenig@gmx.net. Ciao Hannes From sdecugis@nict.go.jp Thu Feb 19 22:31:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735CD3A672F for ; Thu, 19 Feb 2009 22:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKJAhdbUWRAe for ; Thu, 19 Feb 2009 22:31:47 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by core3.amsl.com (Postfix) with ESMTP id 6C2613A68F7 for ; Thu, 19 Feb 2009 22:31:47 -0800 (PST) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id n1K6SE00015324 for ; Fri, 20 Feb 2009 15:28:14 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id n1K6SE66003418 for ; Fri, 20 Feb 2009 15:28:14 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id n1K6SEJ6003412 for ; Fri, 20 Feb 2009 15:28:14 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id 2FD036E92 for ; Fri, 20 Feb 2009 15:28:14 +0900 (JST) Received: from [133.243.146.164] (5gou2f-dhcp04.nict.go.jp [133.243.146.164]) by mail2.nict.go.jp (Postfix) with ESMTP id E24956E78 for ; Fri, 20 Feb 2009 15:28:13 +0900 (JST) Message-ID: <499E4D7A.8090408@nict.go.jp> Date: Fri, 20 Feb 2009 15:28:10 +0900 From: Sebastien Decugis User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 0.95.7 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] 3588 bis: recommended L4 protocol? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:31:48 -0000 Hello, I think the latest 3588bis draft (-15) is a bit confusing for implementors. >From RFC3539 and several references in the draft, SCTP seems to be the recommended transport protocol. On the other side, the recommended security mechanism is TLS, and in the latest update TLS/SCTP is not considered at all. So what should be preferably deployed, TLS/TCP or SCTP(/IPsec) ? I guess a little clarification would be useful if any new revision is made... Best regards, Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From Hannes.Tschofenig@gmx.net Fri Feb 20 03:30:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB8F3A6A99 for ; Fri, 20 Feb 2009 03:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slmZI2T968k9 for ; Fri, 20 Feb 2009 03:30:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 124183A684C for ; Fri, 20 Feb 2009 03:30:00 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2009 11:30:13 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp044) with SMTP; 20 Feb 2009 12:30:13 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+2CgNBqKi2DnnMY3QhEG3y2HGF0potN7yn8MqSEp dbNA3tCPU9/LKW From: "Hannes Tschofenig" To: "'Sebastien Decugis'" , References: <499E4D7A.8090408@nict.go.jp> Date: Fri, 20 Feb 2009 13:31:09 +0200 Message-ID: <004d01c9934e$ba8c9f80$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <499E4D7A.8090408@nict.go.jp> Thread-Index: AcmTJPJMRgL5kFnOSxKubm1SKkfNaAAKbP4g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Dime] 3588 bis: recommended L4 protocol? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:30:02 -0000 The mandatory to implement protocol (from an interoperability point of view) is TCP (and TLS). Ciao Hannes >-----Original Message----- >From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >Behalf Of Sebastien Decugis >Sent: 20 February, 2009 08:28 >To: dime@ietf.org >Subject: [Dime] 3588 bis: recommended L4 protocol? > >Hello, > >I think the latest 3588bis draft (-15) is a bit confusing for >implementors. > >>From RFC3539 and several references in the draft, SCTP seems to be the >recommended transport protocol. >On the other side, the recommended security mechanism is TLS, >and in the latest update TLS/SCTP is not considered at all. So >what should be preferably deployed, TLS/TCP or SCTP(/IPsec) ? > >I guess a little clarification would be useful if any new >revision is made... > >Best regards, >Sebastien. > >-- >Sebastien Decugis >Research fellow >Network Architecture Group >NICT (nict.go.jp) > >_______________________________________________ >DiME mailing list >DiME@ietf.org >https://www.ietf.org/mailman/listinfo/dime > From tena@huawei.com Fri Feb 20 04:04:40 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0258B28C11B for ; Fri, 20 Feb 2009 04:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RS4UsOFXt7O for ; Fri, 20 Feb 2009 04:04:39 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 246753A67B3 for ; Fri, 20 Feb 2009 04:04:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFD00K285JZRR@szxga04-in.huawei.com> for dime@ietf.org; Fri, 20 Feb 2009 20:04:48 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFD0056I5JZTM@szxga04-in.huawei.com> for dime@ietf.org; Fri, 20 Feb 2009 20:04:47 +0800 (CST) Received: from [192.168.5.101] ([121.34.106.180]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFD00L0X5JY22@szxml01-in.huawei.com>; Fri, 20 Feb 2009 20:04:47 +0800 (CST) Date: Fri, 20 Feb 2009 20:04:45 +0800 From: Tina TSOU In-reply-to: <0074F19FF6F8534E8F74C56BB84397BB04175E7C@esealmw118.eemea.ericsson.se> To: Raymond Forbes Message-id: <60E24B5D-F991-4C1C-9610-33E54BA357BA@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: multipart/alternative; boundary="Boundary_(ID_8HwBZvZstdgLU18SEwapfg)" References: <0074F19FF6F8534E8F74C56BB84397BB04175E7C@esealmw118.eemea.ericsson.se> Cc: TISPAN_WG3@LIST.ETSI.ORG, dime@ietf.org Subject: Re: [Dime] WI-03117-1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 12:04:40 -0000 --Boundary_(ID_8HwBZvZstdgLU18SEwapfg) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable I cc to WG DIME. B. R. Tina http://tinatsou.weebly.com/contact.html On Feb 20, 2009, at 6:30 PM, Raymond Forbes wrote: > To my awareness we are still waiting on the IETF Geopriv to =20 > Allocated a AVP code and Register it with IANA for Location Data > > I believe that the IETF still has not done this; even though this =20 > Issue was raised in May 2008. > > TS 183 059-1 > DTS/TISPAN-03117-1-NGN-R2 > a2 interface =96 Diameter based > 20WTDxxx is due to be WG approved at TISPAN# 20WGs at v0.5.4. > > Please Keep us informed of any IETF Progress on this issue. > > Regards, > > Ray Forbes > TISPAN WG3 Chairman > > Telephone: +442476435151 > Fax: +442476436136 (832)36136 > Switchboard: +441483303666 x 35151 > Mobile: +447718511361 > Email: Raymond.Forbes@Ericsson.com > Mail archive for TISPAN_WG3 can be browsed at the following url : > > http://list.etsi.org/TISPAN_WG3.html > --Boundary_(ID_8HwBZvZstdgLU18SEwapfg) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable
I cc to WG = DIME.


On Feb 20, 2009, at 6:30 PM, Raymond Forbes = wrote:

To my awareness we are still waiting on the = IETF Geopriv to Allocated a AVP code and Register it with IANA for = Location Data
 
=
I = believe that the IETF still has not done this; even though this Issue = was raised in May 2008. 
 
=
TS 183 = 059-1
DTS/TISPAN-03117-1-NGN-R2
a2 interface =96 Diameter = based
20WTDxxx is due to be WG approved at = TISPAN# 20WGs at = v0.5.4.
=
 
Please Keep us informed of any IETF Progress = on this issue.
 

Regards,

Ray = Forbes
TISPAN = WG3 Chairman
 
Telephone: = +442476435151
Fax: +442476436136 = (832)36136
Switchboard: = +441483303666 x 35151 
Mobile: +447718511361
Email: = Raymond.Forbes@Ericsson.com

Mail archive for TISPAN_WG3 can be = browsed at the following url :

http://list.etsi.org/TISPAN_= WG3.html


= --Boundary_(ID_8HwBZvZstdgLU18SEwapfg)-- From Hannes.Tschofenig@gmx.net Fri Feb 20 04:24:20 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEC13A6AF3 for ; Fri, 20 Feb 2009 04:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raxv4RHYhZO3 for ; Fri, 20 Feb 2009 04:24:20 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EF4693A6968 for ; Fri, 20 Feb 2009 04:24:19 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2009 12:17:53 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 20 Feb 2009 13:17:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19uX0V4xN5ui9WFkdpNOZ/M/B8duZLXVANgdSB73b xHzFhO4BF4ivRK From: "Hannes Tschofenig" To: References: <0074F19FF6F8534E8F74C56BB84397BB04175E7C@esealmw118.eemea.ericsson.se> <60E24B5D-F991-4C1C-9610-33E54BA357BA@huawei.com> Date: Fri, 20 Feb 2009 14:18:50 +0200 Message-ID: <006201c99355$63ab8c60$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <60E24B5D-F991-4C1C-9610-33E54BA357BA@huawei.com> Thread-Index: AcmTU3O7BhKrwqjBSyCAHkSqOlxFIQAAZCvg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 Cc: 'Raymond Forbes' , dime@ietf.org Subject: [Dime] draft-ietf-geopriv-radius-lo -- was RE: WI-03117-1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 12:24:21 -0000 -- redirect it to the right mailing list (GEOPRIV). I understand your impatience. I also got nervous a long time ago. The document is currently blocked by a review from Glen Zorn. I hope that the issue gets resolved soon. Ciao Hannes ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Tina TSOU Sent: 20 February, 2009 14:05 To: Raymond Forbes Cc: TISPAN_WG3@LIST.ETSI.ORG; dime@ietf.org Subject: Re: [Dime] WI-03117-1 I cc to WG DIME. B. R. Tina http://tinatsou.weebly.com/contact.html On Feb 20, 2009, at 6:30 PM, Raymond Forbes wrote: To my awareness we are still waiting on the IETF Geopriv to Allocated a AVP code and Register it with IANA for Location Data I believe that the IETF still has not done this; even though this Issue was raised in May 2008. TS 183 059-1 DTS/TISPAN-03117-1-NGN-R2 a2 interface - Diameter based 20WTDxxx is due to be WG approved at TISPAN# 20WGs at v0.5.4. Please Keep us informed of any IETF Progress on this issue. Regards, Ray Forbes TISPAN WG3 Chairman Telephone: +442476435151 Fax: +442476436136 (832)36136 Switchboard: +441483303666 x 35151 Mobile: +447718511361 Email: Raymond.Forbes@Ericsson.com ________________________________ Mail archive for TISPAN_WG3 can be browsed at the following url : http://list.etsi.org/TISPAN_WG3.html ________________________________ From pankajkumar.gupta@gmail.com Fri Feb 20 06:36:55 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD47C3A6B17 for ; Fri, 20 Feb 2009 06:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xNXRHcy1GfD for ; Fri, 20 Feb 2009 06:36:54 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id B02D03A6932 for ; Fri, 20 Feb 2009 06:36:54 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so890004rvb.49 for ; Fri, 20 Feb 2009 06:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=JY69B9LMSd6z11CFE5bxd5XOW+Du8RLNTflsoxXxQN0=; b=HC/f9UJSJrR0Qc6LwG7ef0wIWi3tKG+UGTWeflyoGivRh/2tVRF/wq/QXz9i5jZ7ZB VyQL4pDpF3MUMWiXbljbniNIkJt1uKa8ePfXz+XWC068NlzZbLbD+kR3b2z2Cgt+5IQE b2xqIrx6kULMIonF40efe9bdcWJpkg8zx6yFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KrnLgHe+ZfWkPertpdlcxK9QoRLWvxYOSWH9/d63/uxsr5S0p1L7n3c2zz5QEyx+OT ct4FPW5LhT+6kSfg1roWtpsgTsNolmY0Tl0xY8fxdys96ye1G6VL3kGalbCB7nb+u9P8 Q24wVS/ulA6drVznWOX6cSrpmM4WI9A8wYBcI= MIME-Version: 1.0 Received: by 10.142.199.15 with SMTP id w15mr428292wff.297.1235140628143; Fri, 20 Feb 2009 06:37:08 -0800 (PST) Date: Fri, 20 Feb 2009 20:07:08 +0530 Message-ID: From: Pankaj Gupta To: dime@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32fae63600d04635a96e3 Subject: [Dime] RFC 3588 query X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 14:38:29 -0000 --000e0cd32fae63600d04635a96e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I have a query in DIAMETER base application RFC 3588. Its regarding the Accounting state machine to be observed by the client. There is a state called "PendingB" which is to be used when the record was stored and need to be sent at some later time (assuming peer connection went down). Now, consider the scenario mentioned below: Current state: PendingI, Event: Failure to send and (buffer space available or old record can be overwritten) and realtime not equal to DELIVER_AND_GRANT. Action: Store Interim record, Final state: Open. Now, when the state is "open", there is no mention of how and when the stored Interim record would be sent to the server as the event "Records in storage" is not handled in the Open state. So, is there no requirement of standardizing this behavior? has it been left to the implementers to define the behavior? Best Regards, Pankaj --000e0cd32fae63600d04635a96e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a query in DIAMETER base application RFC 3588. 
 

Its regarding the Accounting state machine to be observed by the client. T= here is a state called "PendingB" which is to be used when the record was s= tored and need to be sent at some later time (assuming peer connection went= down). Now, consider the scenario mentioned below:

 

Current state: PendingI,  

Event: Failure to send and (buffer space available or old record can be ov= erwritten) and realtime not equal to DELIVER_AND_GRANT.

Action: Store Interim record,

Final state: Open.

 

Now, when the state is "open", there is no mention of how and when the sto= red Interim record would be sent to the server as the event "Records in sto= rage" is not handled in the Open state.

 

So, is there no requirement of standardizing this behavior? has it been le= ft to the implementers to define the behavior?

 

Best Regards,

Pankaj

--000e0cd32fae63600d04635a96e3-- From Hannes.Tschofenig@gmx.net Fri Feb 20 08:29:04 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F7A28C141 for ; Fri, 20 Feb 2009 08:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU3S-HHCWQi5 for ; Fri, 20 Feb 2009 08:29:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 32D9A28C110 for ; Fri, 20 Feb 2009 08:29:03 -0800 (PST) Received: (qmail invoked by alias); 20 Feb 2009 16:29:16 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 20 Feb 2009 17:29:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+cWz5l6xqc+xa05hYnyk7skiVjq79HpA15ZZX0IH lCb1ttSmFsEVEI From: "Hannes Tschofenig" To: Date: Fri, 20 Feb 2009 18:30:12 +0200 Message-ID: <00ae01c99378$829c9bf0$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmTeIDE2ZXCwC54RRGLrrY3L8AKog== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: [Dime] Notes for DIME Virtual Meeting, Feb 19, 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 16:29:04 -0000 Hi all, We had a good discussion during our virtual interim meeting and we went through our documents and discussed a few issues. I believe it was worth to organize it. Thanks to those who contributed! Ciao Hannes ---------- * Participants - Victor Fajardo - Martin Dolly - Sebastien Decugis - Janet Gunn - Mark Jones - Behcet Sarikaya - Jouni Korhonen - Hannes Tschofenig - Viqar Shaikh - Glen Zorn - Tom Taylor Meeting minutes by Victor * Slides http://trac.tools.ietf.org/wg/dime/trac/wiki/ConferenceBridge * WG Status Hannes goes through the slides. - RFC 5447 published - API Draft still waiting for update * Diameter API Presentation was skipped. Dave was not on the call. He will report to the list about the document. * QoS parameter Martin : We view priority as different from QoS parameters. Priority handling is done separately but related to QoS. Certain levels are related by they are different. Viqar : Concerned why priority is lumped together in QoS Martin : Example: pre-engineer a VPN with certain QoS. Priority is something that is added on top of QoS. So this is mixing apples and oranges. Tom : Are they in the same controlling entity ? Martin : Generally no. We engineer QoS based on traffic. Tom : My use case is PCN termination. Martin : In the case of the US, we do not do pre-emption. QoS and priority is related by they are different. Hannes : All parameters come from RSVP. Martin : But RSVP deals with media priority. In 3GPP, diameter is signaling. Hannes : Understand where the point is heading. Example is application-level resource priority? Martin : There's a debate going on what's the proper AVP to use for priority. All the interface in-and-around HSS. There's no impact to the media, it's just signaling. Hannes : What specifically should be clarified in this document ? Martin : From service provider, the end-user is always not trusted. Hannes : This document just lists a couple of AVPs but does not specify their use. It points to the documents where these AVPs come from. We did not go into details on how they are used in specific use cases. Did not think this was an issue. Viqar : ALRP has references to session layer but some confusion in other references. Hannes : Trying to figure out if the reference to the specific document is correct. Martin : We would run additional authorization procedures for entities not perceived to be secure. We don't assume where the policy decision and policy control are being made. We run into problems when we make this generic. Hannes : We need to figure out the way forward. Hannes : Pls post a mail on the list summarizing this issue. Martin : Will do today. * Base Protocol Glen : Would like to roll over nai doc into bis Victor : Would prefer to keep it separate Mark : Need to move forward with the bis so not including nai is ok Hannes : Stick with the decision we made a few months ago. There is no technical issue that has changed since then and we told folks to write that document because we wanted to have it separate. We should stick with our initial decision and progress the document as planned. Victor : Rev up the version number because of backward compatibility issue Glen : Agree Hannes : Victor, make an announcement on list of the rev increase. Label it "Diameter Version 2" -- this will wake up folks. Glen : Change bis heading to clearly include rev number --> Diameter NAI presentation was skipped because of the discussion in the context of RFC 3588bis. * QoS attributes Mark goes through the slides. Status - the next draft update is ready to go to IESG. Draft will be submitted next week. No comments * Diameter ERP Sebastian leads through the presentation. Status - Initial Rev. Many design aspects are not yet clear. Hannes : Impression that you have to define a new app-id. Glen : There's a mis-understanding of hokey. There is no problem with Diameter routing. In hokey, we assume that there is a separate hokey server and it gets contacted by whatever protocol is used to carry the AAA messages. So using to the same proxy for round-trip path is not correct. In re-auth, there is not even a need for a proxy to be involved. If diameter is used, a new app-id is needed. Sebastian: You want to send key material even you don't know who gets it ? Glen : The hokey server will get it. It just needs to be notified and key sent to it along with identifying material. Hannes : We need to have an architectural diagram in this document. Glen : Too tight coupling with diameter infrasturcture and hokey infrastructure. They are different. Need to fix that in hokey. Hannes : We should go forward with the document at least with the issue related to diameter. Document needs to be change such that you define a new diameter id and contain an architectural description. * Mip6 split Jouni goes through the slides and the document is in good shape and progressed by the IESG. Hannes : Document is with the AD. Will check with Dan on the status. * PMIP6 Jouni goes through the slides and explains what the new draft update will contain. Hannes : When is the new doc ready ? Jouni : As soon as the draft authors give their OK. Early next week. Hannes : Very good. * Routing Status Update Tom presents the slides. Glen : Don't understand the diff between combined server and client and a proxy Tom : Understand that the design is not robust. We just need this in application level. So individual drafts and verdor specific AVPs is needed by the apps. Glen : Expect that we don't need any sponsor. Hannes : Host level based solution did not find traction in IETF. So we just wrestle with realm based redirect. Tom : Basically, we are guardians of protocols that are totally reliable and don't want anything to retract from that. Glen : Will work with Tina on a document that can be submitted to the RFC Editor as an independent submission From fluffy@cisco.com Wed Feb 11 12:12:17 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5F83A68D5; Wed, 11 Feb 2009 12:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqwUOPdz9r-h; Wed, 11 Feb 2009 12:12:16 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B0DFC3A6C24; Wed, 11 Feb 2009 12:12:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,193,1233532800"; d="scan'208";a="63073744" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2009 20:12:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1BKCLsQ013711; Wed, 11 Feb 2009 12:12:21 -0800 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1BKCJai005514; Wed, 11 Feb 2009 20:12:19 GMT From: Cullen Jennings To: "Romascanu, Dan (Dan)" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <20090205141701.0E5883A69E6@core3.amsl.com> <2421D12A-7BBE-4148-8D3D-8843E6E8305F@cisco.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 13:12:18 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2838; t=1234383141; x=1235247141; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-jones-dime-3gpp- eps-command-codes=20(DiameterCommand=20Code=20Registration=2 0for=20Third=20Generation=20PartnershipProject=20(3GPP)=20Ev olved=20Packet=20System=20(EPS))=20to=20Informational=20RFC |Sender:=20; bh=LxQ7RD4Swvmwgj61i4yIQBlw7SKohFHrknRXMskmxTg=; b=KS2bWs6demvy9XVUQi8JXIRGT6x1yZmVJYyKUPvJEQSdCRPW+Wfvs5gkOX HRJ/erMHoYaB8/L8OsQrZiwE9Ttrb4k5OP8Z1UU2PIQiI7I5F/D3XSjBqPW3 0jwFGlmWTg; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Sat, 21 Feb 2009 01:11:09 -0800 Cc: dime@ietf.org, ietf@ietf.org Subject: Re: [Dime] Last Call: draft-jones-dime-3gpp-eps-command-codes (DiameterCommand Code Registration for Third Generation PartnershipProject (3GPP) Evolved Packet System (EPS)) to Informational RFC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:12:17 -0000 Thanks Dan and Jouni, Seems reasonable. I did not know about 3588bis. Cullen On Feb 11, 2009, at 1:53 AM, Romascanu, Dan (Dan) wrote: > Cullen, > > The current allocation policy is defined by RFC 3588, section 11.2.1 > which indeed makes no distinction between permanent, standard commands > and vendor-specific command codes and requires IETF consensus for all. > This will be fixed by > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-15.txt > but until this document is approved we are trying to answer the > requests > coming from other SDOs (3GPP in this case) according to the existing > IANA registration process. > > Dan > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Wednesday, February 11, 2009 5:28 AM >> To: ietf@ietf.org >> Subject: Re: Last Call: >> draft-jones-dime-3gpp-eps-command-codes (DiameterCommand Code >> Registration for Third Generation PartnershipProject (3GPP) >> Evolved Packet System (EPS)) to Informational RFC >> >> >> My understanding is that this registry requires "IETF >> Consensus" as defined in 2434. However, theses registration >> are being defined by 3GPP TS 29.272 which does not have IETF >> Consensus. If the DIME community wishes to allow >> registrations like this, why not update the IANA registration >> process to be "Specification Required"? >> >> >> On Feb 5, 2009, at 7:17 AM, The IESG wrote: >> >>> The IESG has received a request from an individual submitter to >>> consider the following document: >>> >>> - 'Diameter Command Code Registration for Third Generation >> Partnership >>> Project (3GPP) Evolved Packet System (EPS) ' >>> as an >> Informational >>> RFC >>> >>> The IESG plans to make a decision in the next few weeks, >> and solicits >>> final comments on this action. Please send substantive comments to >>> the ietf@ietf.org mailing lists by 2009-03-05. >> Exceptionally, comments >>> may be sent to iesg@ietf.org instead. In either case, please retain >>> the beginning of the Subject line to allow automated sorting. >>> >>> The file can be obtained via >>> >> http://www.ietf.org/internet-drafts/draft-jones-dime-3gpp-eps- >> command- >>> codes-01.txt >>> >>> >>> IESG discussion can be tracked via >>> >> https://datatracker.ietf.org/public/pidtracker.cgi? >> command=view_id&dTa >>> g=18081&rfc_flag=0 >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> From gwz@net-zen.net Fri Feb 20 04:32:23 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68C528C28A for ; Fri, 20 Feb 2009 04:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8LNtmJtFXv5 for ; Fri, 20 Feb 2009 04:32:22 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id C575228C287 for ; Fri, 20 Feb 2009 04:32:22 -0800 (PST) Received: (qmail 12730 invoked from network); 20 Feb 2009 12:32:37 -0000 Received: from unknown (124.122.162.130) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 20 Feb 2009 12:32:36 -0000 From: "Glen Zorn" To: "'Hannes Tschofenig'" , References: <0074F19FF6F8534E8F74C56BB84397BB04175E7C@esealmw118.eemea.ericsson.se> <60E24B5D-F991-4C1C-9610-33E54BA357BA@huawei.com> <006201c99355$63ab8c60$0201a8c0@nsnintra.net> In-Reply-To: <006201c99355$63ab8c60$0201a8c0@nsnintra.net> Date: Fri, 20 Feb 2009 19:32:14 +0700 Organization: Network Zen Message-ID: <009101c99357$45d0a7f0$d171f7d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmTU3O7BhKrwqjBSyCAHkSqOlxFIQAAZCvgAABzkVA= Content-Language: en-us X-Mailman-Approved-At: Sat, 21 Feb 2009 01:11:09 -0800 Cc: 'Raymond Forbes' , dime@ietf.org Subject: Re: [Dime] [Geopriv] draft-ietf-geopriv-radius-lo -- was RE: WI-03117-1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 12:32:23 -0000 Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] writes: > -- redirect it to the right mailing list (GEOPRIV). > > I understand your impatience. I also got nervous a long time ago. > > The document is currently blocked by a review from Glen Zorn. Um, technically, it's being blocked by the IESG; they could just blow off my concerns (wouldn't be the first time ;-). > I hope that the issue gets resolved soon. Me, too. > > Ciao > Hannes > > ________________________________ > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On > Behalf > Of Tina TSOU > Sent: 20 February, 2009 14:05 > To: Raymond Forbes > Cc: TISPAN_WG3@LIST.ETSI.ORG; dime@ietf.org > Subject: Re: [Dime] WI-03117-1 > > > I cc to WG DIME. > > > B. R. > Tina > > http://tinatsou.weebly.com/contact.html > > > > > > > > > > On Feb 20, 2009, at 6:30 PM, Raymond Forbes wrote: > > > To my awareness we are still waiting on the IETF Geopriv to > Allocated a AVP code and Register it with IANA for Location Data > > I believe that the IETF still has not done this; even > though > this Issue was raised in May 2008. > > TS 183 059-1 > DTS/TISPAN-03117-1-NGN-R2 > a2 interface - Diameter based > 20WTDxxx is due to be WG approved at > TISPAN# 20WGs at v0.5.4. > > > Please Keep us informed of any IETF Progress on this issue. > > Regards, > > Ray Forbes > TISPAN WG3 Chairman > > Telephone: +442476435151 > Fax: +442476436136 (832)36136 > Switchboard: +441483303666 x 35151 > Mobile: +447718511361 > Email: Raymond.Forbes@Ericsson.com > > > ________________________________ > > > Mail archive for TISPAN_WG3 can be browsed at the following > url : > > http://list.etsi.org/TISPAN_WG3.html > > ________________________________ > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From dromasca@avaya.com Sun Feb 22 07:22:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FC13A685A for ; Sun, 22 Feb 2009 07:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4coEMSC2jjpm for ; Sun, 22 Feb 2009 07:22:05 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 07A813A6783 for ; Sun, 22 Feb 2009 07:22:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,250,1233550800"; d="scan'208";a="138222074" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Feb 2009 10:22:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Feb 2009 10:22:17 -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 Date: Sun, 22 Feb 2009 16:21:55 +0100 Message-ID: In-Reply-To: <00ae01c99378$829c9bf0$0201a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Notes for DIME Virtual Meeting, Feb 19, 2008 Thread-Index: AcmTeIDE2ZXCwC54RRGLrrY3L8AKogBh3v2A References: <00ae01c99378$829c9bf0$0201a8c0@nsnintra.net> From: "Romascanu, Dan (Dan)" To: "Hannes Tschofenig" , Subject: Re: [Dime] Notes for DIME Virtual Meeting, Feb 19, 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 15:22:06 -0000 What document is this discussion targeting? Is this about http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-09.tx t? This document is on the IESG agenda for approval as Proposed Standard this Thursday after having been in works for two years in the WG and having passed IETF Last Call. Is the Working Group asking for this document to be taken away from the agenda of the IESG telechat?=20 Thanks and Regards, Dan > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Hannes Tschofenig >=20 > * QoS parameter >=20 > Martin : We view priority as different from QoS=20 > parameters. Priority handling is done separately > but related to QoS. Certain levels are related by=20 > they are different. > Viqar : Concerned why priority is lumped together in QoS > Martin : Example: pre-engineer a VPN with certain QoS.=20 > Priority is something that is added on top=20 > of QoS. So this is mixing apples and oranges. > Tom : Are they in the same controlling entity ? > Martin : Generally no. We engineer QoS based on traffic. > Tom : My use case is PCN termination. > Martin : In the case of the US, we do not do pre-emption.=20 > QoS and priority is related by=20 > they are different. > Hannes : All parameters come from RSVP. > Martin : But RSVP deals with media priority. In 3GPP,=20 > diameter is signaling.=20 > Hannes : Understand where the point is heading. Example is=20 > application-level resource=20 > priority? > Martin : There's a debate going on what's the proper AVP=20 > to use for priority. All the=20 > interface in-and-around HSS. There's no impact to=20 > the media, it's just signaling. > Hannes : What specifically should be clarified in this document ? > Martin : From service provider, the end-user is always not trusted. > Hannes : This document just lists a couple of AVPs but=20 > does not specify their use. It points=20 > to the documents where these AVPs come from. We=20 > did not go into details on how they=20 > are used in specific use cases. Did not think=20 > this was an issue. > Viqar : ALRP has references to session layer but some=20 > confusion in other > references. > Hannes : Trying to figure out if the reference to the=20 > specific document is correct. > Martin : We would run additional authorization procedures=20 > for entities not perceived=20 > to be secure. We don't assume where the policy=20 > decision and policy control=20 > are being made. We run into problems when we make=20 > this generic. > Hannes : We need to figure out the way forward. > Hannes : Pls post a mail on the list summarizing this issue. > Martin : Will do today.=20 >=20 From Hannes.Tschofenig@gmx.net Sun Feb 22 10:43:43 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A57428C0E1 for ; Sun, 22 Feb 2009 10:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tTiogE6D+9Y for ; Sun, 22 Feb 2009 10:43:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2C67E3A6818 for ; Sun, 22 Feb 2009 10:43:41 -0800 (PST) Received: (qmail invoked by alias); 22 Feb 2009 18:43:56 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp067) with SMTP; 22 Feb 2009 19:43:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BjHMiu2rBBKKh71w7/BO8UnR3TsOfHNVe8Mpr9d 5Y6QkErRHWcG3a From: "Hannes Tschofenig" To: "'Romascanu, Dan \(Dan\)'" , References: <00ae01c99378$829c9bf0$0201a8c0@nsnintra.net> Date: Sun, 22 Feb 2009 20:44:50 +0200 Message-ID: <029b01c9951d$a6e81e70$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: AcmTeIDE2ZXCwC54RRGLrrY3L8AKogBh3v2AAAdb/xA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Subject: Re: [Dime] Notes for DIME Virtual Meeting, Feb 19, 2008 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:43:43 -0000 Hi Dan, Yes, the discussions during the DIME virtual interim meeting focused on draft-ietf-dime-qos-parameters-09.txt. I did not got the impression that the group asks the document to be taken off the IESG telechat agenda. I believe the issues can be clarified in an email discussion. Ciao Hannes >-----Original Message----- >From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >Sent: 22 February, 2009 17:22 >To: Hannes Tschofenig; dime@ietf.org >Subject: RE: [Dime] Notes for DIME Virtual Meeting, Feb 19, 2008 > >What document is this discussion targeting? Is this about >http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-paramet >ers-09.tx >t? This document is on the IESG agenda for approval as >Proposed Standard this Thursday after having been in works for >two years in the WG and having passed IETF Last Call. Is the >Working Group asking for this document to be taken away from >the agenda of the IESG telechat? > >Thanks and Regards, > >Dan > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf >> Of Hannes Tschofenig > >> >> * QoS parameter >> >> Martin : We view priority as different from QoS parameters. >> Priority handling is done separately >> but related to QoS. Certain levels are related >by they are >> different. >> Viqar : Concerned why priority is lumped together in QoS >> Martin : Example: pre-engineer a VPN with certain QoS. >> Priority is something that is added on top >> of QoS. So this is mixing apples and oranges. >> Tom : Are they in the same controlling entity ? >> Martin : Generally no. We engineer QoS based on traffic. >> Tom : My use case is PCN termination. >> Martin : In the case of the US, we do not do pre-emption. >> QoS and priority is related by >> they are different. >> Hannes : All parameters come from RSVP. >> Martin : But RSVP deals with media priority. In 3GPP, diameter is >> signaling. >> Hannes : Understand where the point is heading. Example is >> application-level resource >> priority? >> Martin : There's a debate going on what's the proper AVP >to use for >> priority. All the >> interface in-and-around HSS. There's no impact to the >> media, it's just signaling. >> Hannes : What specifically should be clarified in this document ? >> Martin : From service provider, the end-user is always >not trusted. >> Hannes : This document just lists a couple of AVPs but does not >> specify their use. It points >> to the documents where these AVPs come from. We >did not go >> into details on how they >> are used in specific use cases. Did not think >this was an >> issue. >> Viqar : ALRP has references to session layer but some >> confusion in other >> references. >> Hannes : Trying to figure out if the reference to the specific >> document is correct. >> Martin : We would run additional authorization procedures for >> entities not perceived >> to be secure. We don't assume where the policy decision >> and policy control >> are being made. We run into problems when we make this >> generic. >> Hannes : We need to figure out the way forward. >> Hannes : Pls post a mail on the list summarizing this issue. >> Martin : Will do today. >> > > From root@core3.amsl.com Mon Feb 23 13:45:01 2009 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E5E0B28C168; Mon, 23 Feb 2009 13:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090223214501.E5E0B28C168@core3.amsl.com> Date: Mon, 23 Feb 2009 13:45:01 -0800 (PST) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-qos-attributes-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Quality of Service Attributes for Diameter Author(s) : J. Korhonen, et al. Filename : draft-ietf-dime-qos-attributes-11.txt Pages : 43 Date : 2009-02-23 This document extends the IPFilterRule AVP functionality of the Diameter Base protocol and the functionality of the QoS-Filter-Rule AVP defined in RFC 4005. The ability to convey Quality of Service information using the AVPs defined in this document is available to existing and future Diameter applications where permitted by the command ABNF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-qos-attributes-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-23134358.I-D@ietf.org> --NextPart-- From agowda@starentnetworks.com Wed Feb 25 22:53:39 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984B528C1F8 for ; Wed, 25 Feb 2009 22:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNJC1Ct0YyF9 for ; Wed, 25 Feb 2009 22:53:36 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 3E52F28C1DE for ; Wed, 25 Feb 2009 22:53:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 651D39077B for ; Thu, 26 Feb 2009 01:53:53 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28054-12 for ; Thu, 26 Feb 2009 01:53:52 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 26 Feb 2009 01:53:52 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 01:53:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C997DE.F8393817" Date: Thu, 26 Feb 2009 12:23:45 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Auth-Application-Id AVP in Diameter answer messages Thread-Index: AcmX3vf+g+KLkHDFTmKGcJp8gvurYA== From: "Gowda, Avinash" To: X-OriginalArrivalTime: 26 Feb 2009 06:53:52.0069 (UTC) FILETIME=[FBDA4750:01C997DE] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Dime] Question on Auth-Application-Id AVP in Diameter answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 06:53:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C997DE.F8393817 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have question on mandating Auth-Application-Id AVP in answer messages. =20 In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4 --------------------------------------------- < AA-Answer > ::=3D < Diameter Header: 268, PXY, 16777250 > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Session-Timeout ] [ Accounting-Interim-Interval ] *[ APN-Configuration ] ... *[ AVP ] =20 According to this spec, Auth-Application-Id is a mandatory AVP in AA-Answer message. =20 I have following questions: =20 * Is it necessary to have Auth-Application-Id AVP as a mandatory AVP in answer message?=20 * Is there any specific use by mandating it? Can't we have it as an optional AVP ([Auth-Application-Id])? =20 Please help me to understand this. =20 Thanks, Avinash Gowda =20 ------_=_NextPart_001_01C997DE.F8393817 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have question on mandating Auth-Application-Id = AVP in answer messages.

 

In 3GPP TS 29.273 V8.0.0 Section = 5.2.2.3.4

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

< AA-Answer > ::=3D < Diameter = Header: 268, PXY, 16777250 >

< Session-Id >

{ Auth-Application-Id = }

{ Auth-Request-Type }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

[ Session-Timeout = ]

[ Accounting-Interim-Interval ]

*[ APN-Configuration ]

…

*[ AVP ]

 

According to this spec, Auth-Application-Id is a = mandatory AVP in AA-Answer message.

 

I have following = questions:

 

  • Is it necessary to have Auth-Application-Id AVP as a = mandatory AVP in answer message?
  • Is there any specific use by mandating it? Can’t we = have it as an optional AVP ([Auth-Appl= ication-Id])?

 

Please help me to understand = this.

&n= bsp;

Thanks,

Avinash Gowda

 

------_=_NextPart_001_01C997DE.F8393817-- From jouni.nospam@gmail.com Wed Feb 25 23:22:05 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB84D3A6B8F for ; Wed, 25 Feb 2009 23:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35gecmwRyvPk for ; Wed, 25 Feb 2009 23:22:05 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 910AF3A68ED for ; Wed, 25 Feb 2009 23:22:04 -0800 (PST) Received: by ewy25 with SMTP id 25so460758ewy.37 for ; Wed, 25 Feb 2009 23:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=6buUsxUDHBkW3uUtBHtmbahC2li9Ef2t+zLhTrVzw5I=; b=FNdzgiABO4UP8bsWq3hXA7bWRcUvj1zbQAtloBkcqPUqHIBC1t2L4He0B6CXQQTbe0 1K5qOLoBWDvGNfftC3xo5D09qJKFqJ0gxvgAB+8kG2i1+1PtIHAlUQ92t+l9M+D2PKmO X+YYufDs+F205SnFesqOWdxBzM97RvuP78UAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=Kpo6cX2wDE7dPtSdvURRr9sT9GEaXXIU3wK7zRn/a7W4XsH6wzWtVIVy0hWO2/t1jq QSkQBfldDfcsvGFZauVNvadEypgvFzDzEJl389g3JZIiKQSFbzgvJdslevGjMoTTyAKo 0ClmhCdDAbNQgqTc+sbbE2c15kk3ZOdKdYnB0= Received: by 10.210.112.4 with SMTP id k4mr671166ebc.81.1235632944907; Wed, 25 Feb 2009 23:22:24 -0800 (PST) Received: from ?10.183.180.98? ([192.100.124.156]) by mx.google.com with ESMTPS id 5sm5615908eyh.41.2009.02.25.23.22.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 23:22:24 -0800 (PST) Message-Id: <4919A053-1B82-41A0-9169-912A8828178E@gmail.com> From: jouni korhonen To: "Gowda, Avinash" In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 09:22:22 +0200 References: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> X-Mailer: Apple Mail (2.930.3) Cc: dime@ietf.org Subject: Re: [Dime] Question on Auth-Application-Id AVP in Diameter answer messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 07:22:06 -0000 Hi, On Feb 26, 2009, at 8:53 AM, Gowda, Avinash wrote: > Hi All, > > I have question on mandating Auth-Application-Id AVP in answer =20 > messages. > > In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4 > --------------------------------------------- > < AA-Answer > ::=3D < Diameter Header: 268, PXY, 16777250 > > < Session-Id > > { Auth-Application-Id } > { Auth-Request-Type } > { Result-Code } > [ Experimental-Result ] > { Origin-Host } > { Origin-Realm } > [ Session-Timeout ] > [ Accounting-Interim-Interval ] > *[ APN-Configuration ] > =85 > *[ AVP ] > > According to this spec, Auth-Application-Id is a mandatory AVP in AA-=20= > Answer message. > > I have following questions: > > =95 Is it necessary to have Auth-Application-Id AVP as a = mandatory =20 > AVP in answer message? RFC4005 which defines the AAA has { Auth-Application-Id }. So the =20 above is correct according to the RFC. > =95 Is there any specific use by mandating it? Can=92t we have = it as an =20 > optional AVP ([Auth-Application-Id])? Honestly, I have no history data why {} is used. You cannot really =20 change it without causing an allocation of a new Command Code (as it =20 would be a change in ABNF). While you are at this, the Command Code is actually wrong. It should =20 be 265, not 268. Btw, you should bring these questions to 3GPP CT4 mailing list = (http://list.etsi.org/3gpp_tsg_ct_wg4.html=20 ) as CT4 owns this spec and the work is done there. You might also =20 want to wait few days for the latest spec version (there was a meeting =20= last week). > > Please help me to understand this. Cheers, Jouni > > Thanks, > Avinash Gowda > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ankit.sharma@aricent.com Thu Feb 26 03:17:55 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921993A68C1 for ; Thu, 26 Feb 2009 03:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUKzGRaR52aO for ; Thu, 26 Feb 2009 03:17:50 -0800 (PST) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 4DEF73A67C1 for ; Thu, 26 Feb 2009 03:17:49 -0800 (PST) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n1QB9HUw003017 for ; Thu, 26 Feb 2009 16:39:17 +0530 Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (8.13.8/8.13.8) with ESMTP id n1QB9GIm002952 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 26 Feb 2009 16:39:16 +0530 Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.136]) with mapi; Thu, 26 Feb 2009 16:48:08 +0530 From: Ankit Kumar Sharma To: "Gowda, Avinash" , "dime@ietf.org" Date: Thu, 26 Feb 2009 16:48:06 +0530 Thread-Topic: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages Thread-Index: AcmX3vf+g+KLkHDFTmKGcJp8gvurYAAIi5Yg Message-ID: <28D43D510069B644A3980EDF9AF1AB7544FF1E555F@GUREXMB01.ASIAN.AD.ARICENT.COM> References: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_28D43D510069B644A3980EDF9AF1AB7544FF1E555FGUREXMB01ASIA_" MIME-Version: 1.0 Subject: Re: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 11:17:55 -0000 --_000_28D43D510069B644A3980EDF9AF1AB7544FF1E555FGUREXMB01ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my comments inline... ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gow= da, Avinash Sent: Thursday, February 26, 2009 12:24 PM To: dime@ietf.org Subject: [Dime] Question on Auth-Application-Id AVP in Diameter answermessa= ges Hi All, I have question on mandating Auth-Application-Id AVP in answer messages. In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4 --------------------------------------------- < AA-Answer > ::=3D < Diameter Header: 268, PXY, 16777250 > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Session-Timeout ] [ Accounting-Interim-Interval ] *[ APN-Configuration ] ... *[ AVP ] According to this spec, Auth-Application-Id is a mandatory AVP in AA-Answer= message. I have following questions: * Is it necessary to have Auth-Application-Id AVP as a mandatory AVP in = answer message? * Is there any specific use by mandating it? Can't we have it as an opti= onal AVP ([Auth-Application-Id])? Please help me to understand this. Thanks, Avinash Gowda Regards, Ankit ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_28D43D510069B644A3980EDF9AF1AB7544FF1E555FGUREXMB01ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see my comments inline…

From: dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash
Sent: Thursday, February 26,= 2009 12:24 PM
To: dime@ietf.org
Subject: [Dime] Question on = Auth-Application-Id AVP in Diameter answermessages=

 

Hi All,

 

I have question on mandating Auth-Application-Id AVP i= n answer messages.

 

In 3GPP TS 29.273 V8.0.0 Section 5.2.= 2.3.4

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

< AA-Answer > ::=3D < Diamete= r Header: 268, PXY, 16777250 >

< Session-Id >

{ Auth-Application-Id }

{ Auth-Request-Type }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

[ Session-Timeout ]

[ Accounting-Interim-Interval ]<= /font>

*[ APN-Configu= ration ]

…

*[ AVP ]<= /o:p>

 

According to this spec, Auth-Application-Id is a manda= tory AVP in AA-Answer message.

 

I have following questions:

 

  • Is it necessary to have Auth-Application-Id AVP as a mandatory A= VP in answer message?

       <Yes, because specs are mandating= it>

 

  • Is there any specific use by mandating it? Can’t we have i= t as an optional AVP ([Auth-Application-Id])?

       <I could think of a scenario wher= e we have more than one User Diameter applications in a single process on o= ur local node, and each one is capable of sending AAR command for ex. we have= NASREQ and Tx . In this case, Auth-Application-Id could be used to route t= he incoming AAA from peer to correct local application module. In this exam= ple, user wants to be authenticated on two different interfaces and Auth-Application-Id is used to distinguish= the answers of both requests>

 

Please help me to understand this.

 

Thanks,

Avinash Gowda

 

Regards,

Ankit

 


"DISCLAIMER: This messa= ge is proprietary to Aricent and is intended solely for the use of the indi= vidual to whom it is addressed. It may contain privileged or confidential i= nformation and should not be circulated or used for any purpose other than for what it is intended. If you have recei= ved this message in error,please notify the originator immediately. If you = are not the intended recipient, you are notified that you are strictly proh= ibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibil= ity for loss or damage arising from the use of the information transmitted = by this email including damage from virus."
 --_000_28D43D510069B644A3980EDF9AF1AB7544FF1E555FGUREXMB01ASIA_-- From Mark.Jones@bridgewatersystems.com Thu Feb 26 07:19:57 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C0C3A6BFF for ; Thu, 26 Feb 2009 07:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NnNM-AV6Mmw for ; Thu, 26 Feb 2009 07:19:51 -0800 (PST) Received: from webmail.bridgewatersystems.com (webmail.bridgewatersystems.com [66.46.199.134]) by core3.amsl.com (Postfix) with ESMTP id 12BC03A6BFE for ; Thu, 26 Feb 2009 07:19:49 -0800 (PST) Received: from exchange02.bridgewatersys.com ([192.168.150.32]) by exchange02.bridgewatersys.com ([192.168.150.32]) with mapi; Thu, 26 Feb 2009 10:20:10 -0500 From: Mark Jones To: "dime@ietf.org" Date: Thu, 26 Feb 2009 10:20:09 -0500 Thread-Topic: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages Thread-Index: AcmX3vf+g+KLkHDFTmKGcJp8gvurYAAIi5YgAAbKmyA= Message-ID: References: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> <28D43D510069B644A3980EDF9AF1AB7544FF1E555F@GUREXMB01.ASIAN.AD.ARICENT.COM> In-Reply-To: <28D43D510069B644A3980EDF9AF1AB7544FF1E555F@GUREXMB01.ASIAN.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D6824C8074596B4E9CA38F6A62454F5C0A3332ED07exchange02bri_" MIME-Version: 1.0 Subject: Re: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:19:58 -0000 --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332ED07exchange02bri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline... ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Ank= it Kumar Sharma Sent: February 26, 2009 06:18 To: Gowda, Avinash; dime@ietf.org Subject: Re: [Dime] Question on Auth-Application-Id AVP in Diameter answerm= essages Please see my comments inline... ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gow= da, Avinash Sent: Thursday, February 26, 2009 12:24 PM To: dime@ietf.org Subject: [Dime] Question on Auth-Application-Id AVP in Diameter answermessa= ges Hi All, I have question on mandating Auth-Application-Id AVP in answer messages. In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4 --------------------------------------------- < AA-Answer > ::=3D < Diameter Header: 268, PXY, 16777250 > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Session-Timeout ] [ Accounting-Interim-Interval ] *[ APN-Configuration ] ... *[ AVP ] According to this spec, Auth-Application-Id is a mandatory AVP in AA-Answer= message. I have following questions: * Is it necessary to have Auth-Application-Id AVP as a mandatory AVP in = answer message? [mj] And those spec writers are infallibull ;) But seriously, if you search= the DIME archives, you'll find the same question and the issue was address= ed in the design guidelines (section 8.1) and 3588bis (section 3 and 6.1.6)= . In the meantime, the existing ABNF must be followed and {} makes this a r= equired AVP. * Is there any specific use by mandating it? Can't we have it as an opti= onal AVP ([Auth-Application-Id])? [mj] The Auth/Acct/Vendor-Specific-Application-Id AVPs should not be used f= or routing given that the Diameter header already contains an application i= d and "the value of the application id in the header MUST be the same as an= y relevant application-id AVPs contained in the message" (section 3 in 3588= bis). And as Jouni said, if you know of specifications where this is not th= e case, please take the issue up with the SDO concerned. Please help me to understand this. Thanks, Avinash Gowda Regards, Ankit ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error,please notify the originator immediately. If you are not th= e intended recipient, you are notified that you are strictly prohibited fro= m using, copying, altering, or disclosing the contents of this message. Ari= cent accepts no responsibility for loss or damage arising from the use of t= he information transmitted by this email including damage from virus." --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332ED07exchange02bri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Comments inline...

From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] On Behalf Of Ankit Kumar=20 Sharma
Sent: February 26, 2009 06:18
To: Gowda, Avina= sh;=20 dime@ietf.org
Subject: Re: [Dime] Question on Auth-Application-= Id=20 AVP in Diameter answermessages

Please=20 see my comments inline…

From:=20 dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash
= Sent: Thursday, February 26, 2009 = 12:24=20 PM
To:=20 dime@ietf.org
Subject:= [Dime]=20 Question on Auth-Application-Id AVP in Diameter=20 answermessages

 

Hi=20 All,

 <= /FONT>

I have question on mandat= ing=20 Auth-Application-Id AVP in answer messages.

 <= /FONT>

In 3GP= P TS=20 29.273 V8.0.0 Section 5.2.2.3.4

-------------------------= --------------------

< AA-Answer >= ::=3D=20 < Diameter Header: 268, PXY, 16777250 >

< Session-Id=20 >

{=20 Auth-Application-Id }

{ Auth-Request-Type= =20 }

{ Result-Code=20 }

[ Experimental-Resu= lt=20 ]

{ Origin-Host=20 }

{ Origin-Realm=20 }

[=20 Session-Timeout ]

[=20 Accounting-Interim-Interval ]

*[ APN-Configuration=20 ]

…<= /SPAN>

*[ AVP ]

 <= /FONT>

According to this spec,=20 Auth-Application-Id is a mandatory AVP in AA-Answer=20 message.

 <= /FONT>

I have following=20 questions:

 <= /FONT>

  • Is i= t=20 necessary to have Auth-Application-Id AVP as a mandatory AVP in answer= =20 message?

      =20 <Yes, because specs are mandating it> 

 

[mj] And those spec writ= ers are=20 infallibull ;) But seriously, if you search the DIME archives, you'l= l=20 find the same question and the issue was addressed in the design=20 guidelines (section 8.1) and 3588bis (section 3 and 6.1.6). In the=20 meantime, the existing ABNF must be followed and {} makes this a req= uired=20 AVP.

 

  • Is t= here=20 any specific use by mandating it? Can’t we have it as an optional= AVP=20 ([Auth-Application-Id])?

      =20 <I could think of a scenario where we have more than one User Diameter= =20 applications in a single process on our local node, and each one is capab= le of=20 sending AAR command for ex. we have NASREQ and Tx . In this case,=20 Auth-Application-Id could be used to route the incoming AAA from peer to= =20 correct local application module. In this example, user wants to be=20 authenticated on two different interfaces and Auth-Application-Id is used= to=20 distinguish the answers of both requests> 

 

[mj] The=20 Auth/Acct/Vendor-Specific-Application-Id AVPs should not be used for= =20 routing given that the Diameter header already contains an application id= and=20 "the value of the application id in the header MUST be the same as any=20 relevant application-id AVPs contained in the message" (section 3 in 3588= bis).=20 And as Jouni said, if you know of specifications where this is not t= he=20 case, please take the issue up with the SDO=20 concerned.

 <= /FONT>

Please help me to underst= and=20 this.

 

Thanks,

Avinash=20 Gowda

 

Regards,<= /o:p>

Ankit

 


"DISCLAIMER: This message is pro= prietary to=20 Aricent and is intended solely for the use of the individual to whom it i= s=20 addressed. It may contain privileged or confidential information and shou= ld=20 not be circulated or used for any purpose other than for what it is inten= ded.=20 If you have received this message in error,please notify the originator=20 immediately. If you are not the intended recipient, you are notified that= you=20 are strictly prohibited from using, copying, altering, or disclosing the= =20 contents of this message. Aricent accepts no responsibility for loss or d= amage=20 arising from the use of the information transmitted by this email includi= ng=20 damage from virus."
 --_000_D6824C8074596B4E9CA38F6A62454F5C0A3332ED07exchange02bri_-- From agowda@starentnetworks.com Thu Feb 26 08:58:06 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717E03A6802 for ; Thu, 26 Feb 2009 08:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.629, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GFrYXBwDhpX for ; Thu, 26 Feb 2009 08:58:00 -0800 (PST) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 80AAC28C258 for ; Thu, 26 Feb 2009 08:57:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 611EF9008D for ; Thu, 26 Feb 2009 11:58:09 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12379-20 for ; Thu, 26 Feb 2009 11:58:08 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 26 Feb 2009 11:58:08 -0500 (EST) Received: from exchindia3.starentnetworks.com ([10.6.7.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Feb 2009 11:58:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99833.625587AA" Date: Thu, 26 Feb 2009 22:28:01 +0530 Message-ID: <69FADB84C90B1248A7DE59422771FA0C0C8A1063@exchindia3.starentnetworks.com> In-Reply-To: <28D43D510069B644A3980EDF9AF1AB7544FF1E555F@GUREXMB01.ASIAN.AD.ARICENT.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages Thread-Index: AcmX3vf+g+KLkHDFTmKGcJp8gvurYAAIi5YgAAyJVeA= References: <69FADB84C90B1248A7DE59422771FA0C0C8A0E80@exchindia3.starentnetworks.com> <28D43D510069B644A3980EDF9AF1AB7544FF1E555F@GUREXMB01.ASIAN.AD.ARICENT.COM> From: "Gowda, Avinash" To: "Ankit Kumar Sharma" , X-OriginalArrivalTime: 26 Feb 2009 16:58:08.0619 (UTC) FILETIME=[6670C3B0:01C99833] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: Re: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 16:58:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99833.625587AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ankit, =20 As per RFC 3588 Bis15 =20 6.8. Auth-Application-Id AVP The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of the Authentication and Authorization portion of an application (see Section 2.4 ). If present in a message other than CER and CEA, the value of the Auth- Application-Id AVP MUST match the Application Id present in the Diameter message header. When the same Application-Id is present in Diameter Header then what is the necessity of having duplicate data in this Auth-Application-Id AVP? Thanks, Avinash Gowda ________________________________ From: Ankit Kumar Sharma [mailto:ankit.sharma@aricent.com]=20 Sent: Thursday, February 26, 2009 4:48 PM To: Gowda, Avinash; dime@ietf.org Subject: RE: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages =20 Please see my comments inline... ________________________________ From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash Sent: Thursday, February 26, 2009 12:24 PM To: dime@ietf.org Subject: [Dime] Question on Auth-Application-Id AVP in Diameter answermessages =20 Hi All, =20 I have question on mandating Auth-Application-Id AVP in answer messages. =20 In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4 --------------------------------------------- < AA-Answer > ::=3D < Diameter Header: 268, PXY, 16777250 > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Session-Timeout ] [ Accounting-Interim-Interval ] *[ APN-Configuration ] ... *[ AVP ] =20 According to this spec, Auth-Application-Id is a mandatory AVP in AA-Answer message. =20 I have following questions: =20 * Is it necessary to have Auth-Application-Id AVP as a mandatory AVP in answer message?=20 =20 * Is there any specific use by mandating it? Can't we have it as an optional AVP ([Auth-Application-Id])?=20 =20 Please help me to understand this. =20 Thanks, Avinash Gowda =20 Regards, Ankit =20 =20 ________________________________ "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." ------_=_NextPart_001_01C99833.625587AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ankit,

 

As per RFC 3588 = Bis15

 

6.8.  Auth-Application-Id AVP

   The Auth-Application-Id AVP =
(AVP Code 258) is of type Unsigned32 =
and
   is used in order to advertise support of the =
Authentication and
   Authorization portion of an application (see Section 2.4).  If
= 
   present in a message other than CER and CEA, the =
value of the Auth-
   Application-Id AVP MUST match the Application Id =
present in the
   Diameter message =
header.

When the same Application-Id is present in Diameter Header = then what is the necessity of having duplicate data in this = Auth-Application-Id AVP?

Thanks,

Avinash = Gowda

From: Ankit = Kumar Sharma [mailto:ankit.sharma@aricent.com]
Sent: Thursday, February = 26, 2009 4:48 PM
To: Gowda, Avinash; = dime@ietf.org
Subject: RE: [Dime] = Question on Auth-Application-Id AVP in Diameter = answermessages

 

Please see my comments inline…

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Gowda, Avinash
Sent: Thursday, February = 26, 2009 12:24 PM
To: dime@ietf.org
Subject: [Dime] Question = on Auth-Application-Id AVP in Diameter = answermessages

 

Hi All,

 

I have question on mandating Auth-Application-Id = AVP in answer messages.

 

In 3GPP TS 29.273 V8.0.0 Section 5.2.2.3.4

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

< AA-Answer > ::=3D < Diameter = Header: 268, PXY, 16777250 >

< Session-Id >

{ Auth-Application-Id = }

{ Auth-Request-Type }

{ Result-Code }

[ Experimental-Result ]

{ Origin-Host }

{ Origin-Realm }

[ Session-Timeout = ]

[ Accounting-Interim-Interval ]

*[ APN-Configuration = ]

…

*[ AVP ]

 

According to this spec, Auth-Application-Id is a = mandatory AVP in AA-Answer message.

 

I have following = questions:

 

  • Is it necessary to have Auth-Application-Id AVP as a = mandatory AVP in answer message?

=        <Yes, because specs are mandating = it>

=  

  • Is there any specific use by mandating it? Can’t we = have it as an optional AVP ([Auth-Application-Id])?

=        <I could think of a scenario where we have more than one User = Diameter applications in a single process on our local node, and each one is = capable of sending AAR command for ex. we have NASREQ and Tx . In this case, Auth-Application-Id could be used to route the incoming AAA from peer to correct local application module. In this example, user wants to be = authenticated on two different interfaces and Auth-Application-Id is used to = distinguish the answers of both requests>

 

Please help me to understand = this.

&n= bsp;

Thanks,

Avinash Gowda

 

Regards,

Ankit

 

 

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

------_=_NextPart_001_01C99833.625587AA-- From glenzorn@comcast.net Thu Feb 26 21:33:15 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7FA3A699D for ; Thu, 26 Feb 2009 21:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1iCugjlqcdC for ; Thu, 26 Feb 2009 21:33:14 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id B292B3A6812 for ; Thu, 26 Feb 2009 21:33:13 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id LkC21b00M0vp7WLA5tZchc; Fri, 27 Feb 2009 05:33:36 +0000 Received: from gwzPC ([124.120.227.89]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id LtZN1b00K1wMr2L8RtZUz3; Fri, 27 Feb 2009 05:33:34 +0000 From: "Glen Zorn" To: Date: Fri, 27 Feb 2009 12:32:54 +0700 Message-ID: <000801c9989c$de55e0e0$9b01a2a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYnNadWG2Y70HDRvKEtrgLKsLvEw== Content-Language: en-us Subject: [Dime] Result-Code or Experimental-Result-Code? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:33:15 -0000 I'm busily working on the Explicit Routing draft, which now uses vendor-specific AVPs to carry the discovered route. There are several error conditions that may occur that only occur as a result of the explicit routing process, however, and need to be returned in the associated answer message. Reading section 7.2ff of RFC 3588, it's not really clear if I should allocate new Result-Code values for the errors or if they should be returned in an Experimental-Result AVP. Any suggestions? ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From tena@huawei.com Thu Feb 26 22:08:44 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4383A6810 for ; Thu, 26 Feb 2009 22:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HErtRFjpUtgA for ; Thu, 26 Feb 2009 22:08:42 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 25E223A672F for ; Thu, 26 Feb 2009 22:08:37 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP00HXVNQLAE@szxga04-in.huawei.com> for dime@ietf.org; Fri, 27 Feb 2009 14:08:45 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP001OYNQLVO@szxga04-in.huawei.com> for dime@ietf.org; Fri, 27 Feb 2009 14:08:45 +0800 (CST) Received: from [192.168.1.3] (63.66.40.59.broad.sz.gd.dynamic.163data.com.cn [59.40.66.63]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFP00FYINQKUH@szxml02-in.huawei.com>; Fri, 27 Feb 2009 14:08:44 +0800 (CST) Date: Fri, 27 Feb 2009 14:08:43 +0800 From: Tina TSOU In-reply-to: <000801c9989c$de55e0e0$9b01a2a0$@net> To: Glen Zorn Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) Content-type: multipart/alternative; boundary="Boundary_(ID_+TE1lm7WRAwLiCFsGhH6sA)" References: <000801c9989c$de55e0e0$9b01a2a0$@net> Cc: dime@ietf.org Subject: Re: [Dime] Result-Code or Experimental-Result-Code? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:08:44 -0000 --Boundary_(ID_+TE1lm7WRAwLiCFsGhH6sA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Glen, > The allocated AVP codes are maintained as a list. Based on this > 35000 to 35100 range can be used for the I-D. > The allocated experimental result codes are not maintained in any > such list, So I suggest in each error class, we can use result codes > which are offset to the base by 500 (2501, 5501 etc.), if later we > find any clash, we will update these numbers in the I-D. B. R. Tina http://tinatsou.weebly.com/contact.html On Feb 27, 2009, at 1:32 PM, Glen Zorn wrote: > I'm busily working on the Explicit Routing draft, which now uses > vendor-specific AVPs to carry the discovered route. There are > several error > conditions that may occur that only occur as a result of the explicit > routing process, however, and need to be returned in the associated > answer > message. Reading section 7.2ff of RFC 3588, it's not really clear > if I > should allocate new Result-Code values for the errors or if they > should be > returned in an Experimental-Result AVP. Any suggestions? > > ~gwz > > Play assigns meaning to human activity--work erases it. > -- P.L. Wilson > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_+TE1lm7WRAwLiCFsGhH6sA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Glen,
The allocated AVP codes are maintained as a list. Based on this 35000 to 35100 range can be used for the I-D.
The allocated experimental result codes are not maintained in any such list, So I suggest in each error class, hich are offset to the base by 500 (2501, 5501 etc.), if later we find any clash, we will update these numbers in the I-D.


On Feb 27, 2009, at 1:32 PM, Glen Zorn wrote:

I'm busily working on the Explicit Routing draft, which now uses
vendor-specific AVPs to carry the discovered route.  There are several error
conditions that may occur that only occur as a result of the explicit
routing process, however, and need to be returned in the associated answer
message.  Reading section 7.2ff of RFC 3588, it's not really clear if I
should allocate new Result- Code val they should be
returned in an Experimental-Result AVP.  Any suggestions?

~gwz

Play assigns meaning to human activity--work erases it.
 -- P.L. Wilson



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

--Boundary_(ID_+TE1lm7WRAwLiCFsGhH6sA)-- From glenzorn@comcast.net Thu Feb 26 22:15:02 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24CEB3A6A71 for ; Thu, 26 Feb 2009 22:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zlQbo5Q4cFZ for ; Thu, 26 Feb 2009 22:14:59 -0800 (PST) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 038E53A672F for ; Thu, 26 Feb 2009 22:14:58 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Lu9i1b0080lTkoCA5uFNsK; Fri, 27 Feb 2009 06:15:22 +0000 Received: from gwzPC ([124.120.227.89]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id LuF61b0071wMr2L8QuFCVr; Fri, 27 Feb 2009 06:15:20 +0000 From: "Glen Zorn" To: "'Tina TSOU'" References: <000801c9989c$de55e0e0$9b01a2a0$@net> In-Reply-To: Date: Fri, 27 Feb 2009 13:14:37 +0700 Message-ID: <001301c998a2$b3af64f0$1b0e2ed0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C998DD.600E3CF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYodscgD6vjQD1Ts2w3xakp/bGcwAACxlw Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] Result-Code or Experimental-Result-Code? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:15:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0014_01C998DD.600E3CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tina TSOU [mailto:tena@huawei.com] writes: Hi Glen, The allocated AVP codes are maintained as a list. Based on this 35000 to 35100 range can be used for the I-D. The allocated experimental result codes are not maintained in any such list, So I suggest in each error class, hich are offset to the base by 500 (2501, 5501 etc.), if later we find any clash, we will update these numbers in the I-D. Sorry, I see now that my original message was a model of murkiness ;-(. The real question was whether to use the Result-Code AVP or a vendor-specific value in the Experimental-Result AVP. . ------=_NextPart_000_0014_01C998DD.600E3CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tina TSOU [mailto:tena@huawei.com] writes:
Hi Glen,

The allocated AVP codes are maintained as a list. Based on = this 35000 to 35100 range can be used for the I-D.

The allocated experimental result codes are not maintained = in any such list, So I suggest in each error class, hich are offset to the base = by 500 (2501, 5501 etc.), if later we find any clash, we will update these = numbers in the I-D.

Sorry, I see now that my original message was a model of murkiness ;-(.  The real question was whether to use the = Result-Code AVP or a vendor-specific value in the Experimental-Result = AVP.

…

 

------=_NextPart_000_0014_01C998DD.600E3CF0-- From fqhuang@huawei.com Fri Feb 27 02:07:29 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3842928C26A for ; Fri, 27 Feb 2009 02:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.971 X-Spam-Level: X-Spam-Status: No, score=0.971 tagged_above=-999 required=5 tests=[AWL=2.685, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBgKWpTFDyDn for ; Fri, 27 Feb 2009 02:07:28 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2777928B56A for ; Fri, 27 Feb 2009 02:07:27 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP00J01YSZI3@szxga04-in.huawei.com> for dime@ietf.org; Fri, 27 Feb 2009 18:07:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFP00ESWYSZVY@szxga04-in.huawei.com> for dime@ietf.org; Fri, 27 Feb 2009 18:07:47 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFP00FS0YSZLY@szxml04-in.huawei.com> for dime@ietf.org; Fri, 27 Feb 2009 18:07:47 +0800 (CST) Date: Fri, 27 Feb 2009 18:07:46 +0800 From: Fortune HUANG In-reply-to: <001301c998a2$b3af64f0$1b0e2ed0$@net> To: 'Glen Zorn' , 'Tina TSOU' Message-id: <003701c998c3$3d209540$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_JtPAKRudxQftk7aMDk0WRw)" Thread-index: AcmYodscgD6vjQD1Ts2w3xakp/bGcwAACxlwAAb7v8A= Cc: dime@ietf.org Subject: Re: [Dime] Result-Code or Experimental-Result-Code? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:07:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JtPAKRudxQftk7aMDk0WRw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Glen, =20 Let me try to answer your question with the example of the STA message = defined in 3GPP Rx interface. =20 ::=3D < Diameter Header: 275, PXY > < Session=E2=80=91Id > { Origin=E2=80=91Host } { Origin=E2=80=91Realm } [ Result=E2=80=91Code ] [ Experimental=E2=80=91Result ] ... You can see both the Result-Code and Experimental-Result AVPs are = included in this message. =20 The usage of these two AVP for the sender of the STA message should be = like the following: 1) If the result can be precisely matched to any of the codes managed by = the IANA for the Result-Code AVP, We should not include the Experimental-Result AVP in this message. 2) Or else, vendors can use the Experimental-Result in order to carry a = precise result. For this case, we can also include the Result-Code AVP = with a not-so-precise but general result.(For a vendor like 3GPP, the = vendor specific result code will also be strictly managed by the = standard body. ) =20 For the receiver, once the Experimetal-Result AVP is included in the = message, it will always imply that this Experimetal-Result AVP will be = more precise.=20 =20 Best Regards, Fortune =20 =20 =20 _____ =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: dime-bounces@ietf.org = [mailto:dime-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Glen Zorn =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B42=E6=9C=8827=E6=97=A5 = 14:15 =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Tina TSOU' =E6=8A=84=E9=80=81: dime@ietf.org =E4=B8=BB=E9=A2=98: Re: [Dime] Result-Code or Experimental-Result-Code? Tina TSOU [mailto:tena@huawei.com] = writes: Hi Glen, The allocated AVP codes are maintained as a list. Based on this 35000 to = 35100 range can be used for the I-D. The allocated experimental result codes are not maintained in any such = list, So I suggest in each error class, hich are offset to the base by = 500 (2501, 5501 etc.), if later we find any clash, we will update these = numbers in the I-D. Sorry, I see now that my original message was a model of murkiness ;-(. = The real question was whether to use the Result-Code AVP or a = vendor-specific value in the Experimental-Result AVP. =E2=80=A6 =20 --Boundary_(ID_JtPAKRudxQftk7aMDk0WRw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi Glen,
 
Let me try to answer your question with the = example of=20 the STA message defined in 3GPP Rx interface.
 

           &nbs= p;  =20  < = Session=E2=80=91Id=20 >

           &nbs= p;  =20  { = Origin=E2=80=91Host=20 }

           &nbs= p;  =20  { = Origin=E2=80=91Realm=20 }

           &nbs= p;  =20  [ = Result=E2=80=91Code=20 ]

           &nbs= p;  =20  [ Experimental=E2=80=91Result ]

           &nbs= p;    ...

You can see both the=20 Result-Code and Experimental-Result AVPs are included in this=20 message.

 

The usage of these=20 two AVP for the sender of the STA message should be like the=20 following:

1) If the result can=20 be precisely matched to any of the codes managed by the IANA for = the=20 Result-Code AVP,

We should=20 not include the Experimental-Result AVP in this = message.

2) Or else,=20 vendors can use the Experimental-Result in order to carry a = precise=20 result. For this case, we can also include the Result-Code AVP with a=20 not-so-precise but general result.(For a vendor like 3GPP, the vendor = specific=20 result code will also be strictly managed by the standard body.=20 )

 

For the receiver,=20 once the Experimetal-Result AVP is included in the message, it will = always imply=20 that this Experimetal-Result AVP will be more precise. =

 

Best=20 Regards,

Fortune

 

 

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Glen = Zorn
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2009=E5=B9=B42=E6=9C=8827=E6=97=A5=20 14:15
=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Tina = TSOU'
=E6=8A=84=E9=80=81: = dime@ietf.org
=E4=B8=BB=E9=A2=98: Re:=20 [Dime] Result-Code or Experimental-Result-Code?

Tina=20 TSOU [mailto:tena@huawei.com]=20 writes:
Hi Glen,

The=20 allocated AVP codes are maintained as a list. Based on this 35000 to = 35100=20 range can be used for the I-D.

The=20 allocated experimental result codes are not maintained in any such = list, So I=20 suggest in each error class, hich are offset to the base by 500 (2501, = 5501=20 etc.), if later we find any clash, we will update these numbers in the = I-D.

Sorry,=20 I see now that my original message was a model of murkiness ;-(.  = The=20 real question was whether to use the Result-Code AVP or a = vendor-specific=20 value in the Experimental-Result=20 AVP.

=E2=80=A6

 

<ST=E2=80=91Answer>  ::=3D < Diameter Header: = 275, PXY=20 >
--Boundary_(ID_JtPAKRudxQftk7aMDk0WRw)-- From Hannes.Tschofenig@gmx.net Sat Feb 28 01:23:48 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C2F3A6840 for ; Sat, 28 Feb 2009 01:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKY2Ip3uIzYr for ; Sat, 28 Feb 2009 01:23:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 8CC563A6823 for ; Sat, 28 Feb 2009 01:23:46 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2009 09:24:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp043) with SMTP; 28 Feb 2009 10:24:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19aAalh9zNaLUWwAkl2hyaSOZuZ2rF9jJvq3b6FLl OZqVI1OpbgcrBj From: "Hannes Tschofenig" To: Date: Sat, 28 Feb 2009 11:25:08 +0200 Message-ID: <07c701c99986$73684350$2ab5b70a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmZhnLBCottasOMTfm0ghEK2rc/lg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: [Dime] Diameter QoS Parameter -- DECISION TO MAKE X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 09:23:48 -0000 Hi all, we have a normative reference in the Diameter QoS parameter draft http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-09.txt pointing to http://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-11 Yesterday, Magnus posted a mail to the TSVWG list that draft-ietf-tsvwg-emergency-rsvp-11.txt is having a lot of problems getting through the IESG and the document bounced back to the working group. The mail can be found here: http://www.ietf.org/mail-archive/web/tsvwg/current/msg09070.html Now, there is the risk of considerable delay in publication of our Diameter QoS parameter document as it will be blocked (for potentially a long time). Since the Diameter QoS attribute and the Diameter QoS application document normatively depend on the QoS parameter document they will be blocked as well. So, I have been thinking of what we could do to deal with this issue and here is a proposal to the group. *************** My proposal is to move the priority parameters (Priority AVP, Admission-Priority AVP, and ALRP AVP) into a separate document and to progress them independently to get the main part of the Diameter QoS parameters document finalized. *************** Please let me know if you find this idea acceptable. Please respond as quickly as possible! Ciao Hannes PS: We would have to find an editor and authors for that the new document that contains the priority parameters but we can worry about that part larter. From fqhuang@huawei.com Sat Feb 28 01:50:33 2009 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F9D3A6918 for ; Sat, 28 Feb 2009 01:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.283 X-Spam-Level: * X-Spam-Status: No, score=1.283 tagged_above=-999 required=5 tests=[AWL=1.777, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNz2--ZBsApz for ; Sat, 28 Feb 2009 01:50:32 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 438D73A67CC for ; Sat, 28 Feb 2009 01:50:32 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFR00JOBSOGFR@szxga04-in.huawei.com> for dime@ietf.org; Sat, 28 Feb 2009 17:50:40 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KFR00ICTSOG7W@szxga04-in.huawei.com> for dime@ietf.org; Sat, 28 Feb 2009 17:50:40 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KFR007KPSOGCR@szxml06-in.huawei.com> for dime@ietf.org; Sat, 28 Feb 2009 17:50:40 +0800 (CST) Date: Sat, 28 Feb 2009 17:50:40 +0800 From: Fortune HUANG To: dime@ietf.org Message-id: <005301c9998a$03eba040$7b27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8i8DQyjecznxLwnpS6umhg)" Thread-index: AcmZigPfw3ZQR/rXRsqe9mSq7RK14g== Subject: [Dime] Comments on RFC3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 09:50:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8i8DQyjecznxLwnpS6umhg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, With the wide use in multiple applications, I think nowadays the Diameter protocol should not be considered as only a AAA protocol. Many of the Diameter applications have nothing to do with the Authentication, Authorization and Accounting, although the AAA applications are some of the important applications. Therefore, I propose we revise RFC3588bis to reflect this fact. Take the definitions in section 1.3 for example. " Diameter Client A Diameter Client is a device at the edge of the network that performs access control. ... ... Diameter Server A Diameter Server is one that handles authentication, authorization and accounting requests for a particular realm. ..." For an non-AAA application, these defintions are not precise at all. Best Regards, Fortune --Boundary_(ID_8i8DQyjecznxLwnpS6umhg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
 
With the wide use in multiple applications, I think nowadays the Diameter protocol should not be considered as only a AAA protocol. Many of the Diameter applications have nothing to do with the Authentication, Authorization and Accounting, although the AAA applications are some of the important applications. Therefore, I propose we revise RFC3588bis to reflect this fact.
 
Take the definitions in section 1.3 for example.
 
"   Diameter Client
 
      A Diameter Client is a device at the edge of the network that
      performs access control.  ...
...
 
Diameter Server
 
      A Diameter Server is one that handles authentication,
      authorization and accounting requests for a particular realm.  ..."
 
For an non-AAA application, these defintions are not precise at all.
 
 
Best Regards,
Fortune
 
--Boundary_(ID_8i8DQyjecznxLwnpS6umhg)--